Re: [boost] [Serialization] BOOST_CLASS_EXPORT regression on SunCC

Subject: Re: [boost] [Serialization] BOOST_CLASS_EXPORT regression on SunCC
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-02-17 12:27:45

Sohail Somani wrote:
> David Abrahams wrote:

> Still, why intentionally restrict portability even further when the
> alternative was not burdensome to begin with?

The header ordering requirement of the previous system was considered
a very large burden by a number of people.  My view was that it wasn't
that burdensome, but that if it could be eliminated, so much the better.
Of course this meant some of the indicated hacking to implement
some things not guarenteed by the C++ standard.  But then, the
serialization library has a lot of that.  On the upside, the implementation
has been much improved so that these hacks are now all focused
in a few places.  This is much, much better.  Downside is that
whenever one changes anything in this area, some compiler is
going to be left out in the cold.

> I would have better luck
> implementing a portable export (the previous version) rather than
> figuring out hacks for each compiler.

I don't think the previous was any more portable.  It just seemed that
way because it had been worked over longer.

Test results look to indicate to me that only a few - maybe only one -
compiler is having trouble with the current system.  Hopefully, some
interested party will find the missing magic.  The current hacks
in export.hpp should provide hints of what to do.

> I think the export documentation should be modified to say (in big fat
> bold letters) that it should not be used in portable code.

I believe that the documentation does mention this. (Though not
in big bold letters). I'm always gratified to receive suggestions for
documentation enhancements through TRAK items.

Note there is one important scenario for which EXPORT is
by far the best solution.  That is for plug-ins in DLLS.  In this
scenario, each DLL automagically registers the types it uses
when it is loaded, and unregisters those same types when it
is unloaded.  This means that one can make a main program
which will handle all future types even though they are not currently
known.  As far as I know, runtime linking and its implications
for code compilation are not addressed by the C++ standard
and this is why we have those compiler specific hacks in there.

(Maybe C++ commitee gurus want to think about this?).

So a good place to start to address this for your SunCC compiler
is how is such a compiler used to create a DLL? What has to be
done to tell the compiler to instantiate code not explicitly called
and the optimizer not to strip it as dead code? This is basically
how we came up wth the hacks that are in there now.

Good Luck with this.

Robert Ramey