centralizing 'export'
Gabriel Dos Reis
gdr@codesourcery.com
Thu Jun 13 00:09:00 GMT 2002
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
More information about the Gcc
mailing list