centralizing 'export'

[Nathan Myers]

On Wed, Jun 12, 2002 at 05:34:03PM -0400, Phil Edwards wrote:
> Right now we have a bunch of headers which all end with
> 
>     #ifdef _GLIBCPP_NO_TEMPLATE_EXPORT
>     # define export
>       ... do something unique to this file ...
>     #endif
> 
> As part of cleaning up the STL headers and splitting the definitions out
> into tcc files, I think I'm going to move
> 
>     #ifdef _GLIBCPP_NO_TEMPLATE_EXPORT
>     # define export
>     #endif
> 
> to c++config, and leave
> 
>     #ifdef _GLIBCPP_NO_TEMPLATE_EXPORT
>       ... do something unique to this file ...
>     #endif
> 
> behind in the headers.
> 
> 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.

So the placement of the #define matters.  Or, it would matter if 
we were putting on export decorations where they should be.  No 
doubt there has been some other decay in connection with export
that will need auditing before we can make the library take 
advantage of the export feature (if indeed there is any advantage 
to be had).  The alternative is to scrap any apparatus meant for
support of export, on the premise that it's really useless.

Nathan Myers
ncm at cantrip dot org