Boost logo

Boost :

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

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

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

Dave Abrahams
BoostPro Computing

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