This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: centralizing 'export'
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- To: Nathan Myers <ncm-nospam at cantrip dot org>
- Cc: libstdc++ at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: 13 Jun 2002 08:57:46 +0200
- Subject: Re: centralizing 'export'
- Organization: CodeSourcery, LLC
- References: <20020612173403.A4755@disaster.basement.lan> <20020612215035.C57605@cantrip.org> <20020612175533.A5037@disaster.basement.lan> <20020613020413.D57605@cantrip.org>
Nathan Myers <ncm-nospam@cantrip.org> writes:
| On Wed, Jun 12, 2002 at 05:55:33PM -0400, Phil Edwards wrote:
| > On Wed, Jun 12, 2002 at 09:50:35PM +0000, Nathan Myers wrote:
| > > If I recall correctly, the idea about putting the "#define export"
| > > line at the point where it is was to allow export to be meaningful
| > > (and applied to forward declarations) until you got into the .tcc
| > > header, which is supposed to have everything declared "export" if
| > > you really are "compiling separate", but not if you are just
| > > #include-ing the definitions in headers as we must do today.
| >
| > Why not just declare the class "export" in the header, and not touch
| > any of the out-of-class definitions? Supposed to have the same
| > effect, right?
|
| I don't know much about how export works. I do know that we probably
| don't want to leave "export" #defined to nothing when users' code is
| scanned.
The users' code is scanned by the compiler that doesn't have support
for export, there is no observable harm to it.
[...]
| You might as well just rip it all out.
I don't think we want that.
-- Gaby