|
|
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
that.
>> 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:
http://www.boost.org/doc/libs/1_35_0/libs/serialization/doc/special.html#export
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk