Re: centralizing 'export'

[Gabriel Dos Reis <gdr at codesourcery dot com>]

Nathan Myers <ncm-nospam@cantrip.org> writes:

[...]

| > This will have zero effect, since valarray is the only class actually
| > declaring anything as 'export', and that file was already inside a '#define
| > export' region of code.  But it's slightly cleaner.
| 
| 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.

Well, the right and the cleaner place to put export is on the
*declarations*.  For most of the classes in the library, that means on
their definitions.  That way, the compiler knows upfront that
something is being exported. I even recall John Spicer raising the
issue on the core group.  In order words, I fully support Phil's
initiative.  

Let's not get trapped into the new compaign anti-export. Clearing the
headers as suggested by Phil won't cost us anything, but it will make
easier the job of porting the library to a compiler support export.

Phil's initiative has my support.

-- Gaby