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