Boost logo

Boost :

Subject: Re: [boost] [Serialization] BOOST_CLASS_EXPORT regression on SunCC
From: Sohail Somani (sohail_at_[hidden])
Date: 2009-02-17 13:26:40

Hi Robert,

Robert Ramey wrote:
> 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.

Is that a large burden by a few, vocal people? Anyway, it has been done
and from the sounds of it, does not appear to be reversible. The main
issue is that it eliminated a wart for some but broke someone else's arm :-)

I'll file items for these issues so that they are tracked.

> Of course this meant some of the indicated hacking to implement
> some things not guaranteed 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.

Factoring of compiler hacks is helpful, so I am happy you decided to do

>> 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.

I'm not so sure. It wasn't thread-safe but the behaviour was definitely
well-defined according to the C++ standard.

> 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.

It seems export.hpp is the least of the problems since that is somewhat
well understood. base_object seems to not work anymore either:

>> 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.

Yep, I see it now:

I don't recall reading such a thing in the 1.34.1 documentation.

> 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?).

Simple, mandated [[init]] and [[fini]] attributes would be awesome.

> 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.

It seems that there is support for GCC's __attribute__((constructor)) in
the latest version so I might give that a shot.

Maybe I'll just have to bite the bullet and stop using these features.

> Good Luck with this.

Thanks! I'll let you know if anything comes of it.

Boost list run by bdawes at, gregod at, cpdaniel at, john at