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

Subject: Re: [boost] [Serialization] BOOST_CLASS_EXPORT regression on SunCC
From: David Abrahams (dave_at_[hidden])
Date: 2009-02-17 13:42:51

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 ;-)

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

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.

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

>> 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:
>
> http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boost-bin-v2-libs-serialization-test-test_exported_text_warchive-test-sun-5-9-debug-stdlib-sun-stlport.html
>
>>> 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.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com