Subject: Re: [boost] [Serialization] BOOST_CLASS_EXPORT regression on SunCC
From: Sohail Somani (sohail_at_[hidden])
Date: 2009-02-17 14:00:34
David Abrahams wrote:
> on Tue Feb 17 2009, Sohail Somani <sohail-AT-taggedtype.net> wrote:
>> 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?
> No, I don't think so. Header ordering is deadly-hard to control.
> That's why we don't use qualified calls and overloading in the library
> namespace for customization points ;-)
In general, yes. But I found that the way Robert had documented it was
sufficient for it not to be a problem.
>> 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 :-)
> How's that? There's no longer a way to manually instantiate what you
Manually instantiating for hundreds of classes is not exactly easy. So
it will eventually be healed, but may take a while :-)
> When did all this stuff start breaking for you? I made my changes to
> BOOST_CLASS_EXPORT years ago. IIRC it was still doing nonportable
> things before my changes, but was worse because of the header ordering
I am currently attempting to upgrade from 1.34.1.
>>> 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 thought I had done that.
You are right!
>>>> 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.
> Nope. The way I remember it:
> * I assumed Robert knew about his existing non-portability with
> BOOST_CLASS_EXPORT, so didn't feel the need to alert him
> * Robert didn't know about it
> * Robert found out some time after 1.34.1 came out and documented it.
Anyway, what is done is done.
-- Sohail Somani http://uint32t.blogspot.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk