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

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
> need?

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

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
>> that.
> 
> I thought I had done that.

You are right!

[snip]
>>>> 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.
> 
> 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.

Where?

http://www.boost.org/doc/libs/1_34_1/libs/serialization/doc/special.html#export

Anyway, what is done is done.

-- 
Sohail Somani
http://uint32t.blogspot.com