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 18:20:45

Robert Ramey wrote:
> Just to let everyone know:
> 
> Between 1.34 and the present export has undergone a lot more that one 
> change.
> The one's I recall are ( more or less in order)
> 
> ehancement to eliminate header order requirement
> 
> enhancement to support multi-threading.  This required implemenation
> of a suitable singleton and changing a lot of code to use it.
> 
> enhancement to support serialization code dispurseed accross
> dynamically DLLS.
> 
> enhancement to remove dependence on __LINE__ to
> maintain some unique names.

Can you please describe this further? I thought __LINE__ is the best way
to maintain unique names.

> clarification in the documentation as to the best way
> to use export.
> 
> And after all there this there is ONLY ONE regression?
> (maybe two - recently detected).

I hope that I have not come across as saying that I disagree with you there.

I am also very pleased that this is the only regression!

> So I'm personally very pleased to take credit for all this.

Oh I dunno, Dave had something to do with it ;-)

> Note that its not all that easy to detect such regressions from
> looking at the trunk tests.  The table shows as errors such
> things as usage with libraries which don't support wide characters
> or don't support spirit.  Also some test platforms arn't setup
> correctly.  And often there is a lapse of time between the change
> is made and when the error shows up.  And also results hang
> around a long time so there is no easy way to see that one
> has actually fixed something.

Thanks for explaining. The Boost test harness is pretty awesome but part
of that awesomeness results in information overload.

> So as far as SunCC is concerned: I've reviewed the latest
> trunk tests and it looks to me that a little effort could resolve
> the problems with instantiation of extended_type_info for
> these types.  In the worst case, probably a SunCC specific
> macro could be included.  In any case, it'll have to be addressed
> by someone who has the compiler on hand.  I'd would much
> like to see this looked at.  The only other compiler which
> shows problems is the VACPP and I have it on qt that that
> maybe on the road to getting addressed as well.

I will be looking at it but if Steven is looking at it, I will lose the
race.

One thing I was experimenting with was a macro with the explicit purpose
of calling some function before main. As you have mentioned, this is not
portable but that is the point. So for SunCC it looks something like:

#define BOOST_SUNCC_PRAGMA(x) _Pragma(#x)
#define BOOST_INIT(function) BOOST_SUNCC_PRAGMA(init(function))

For GCC/Visual C++, the macro expands into a singleton as is currently
done with a call to function() in the constructor.

Then if you wanted to execute some type-specific code at initialization
time, you could modify BOOST_CLASS_EXPORT to do so.

So I am thinking something like the following (pretend that names are
unique):

#define BOOST_CLASS_EXPORT_GUID(T,K)               \
namespace                                          \
{                                                  \
  void register_function()                         \
  {                                                \
    singleton<type_info_implementation<T>::type>   \
      ::get_mutable_instance().key_register(K);    \
  }                                                \
}                                                  \
BOOST_INIT(register_function)

BOOST_INIT(x) guarantees that x() is called before main. I believe x
must be a vanilla function (not function template) to work portably.

The benefit is that there are equivalent attributes for UNIX platforms
that *specifically* implement this init behaviour so it is more likely
to be portable.

I guess this doesn't really solve the problem with SunCC not
instantiating ptr_serialization_support::instantiate but atleast has a
specific place for porting purposes.

Thanks for your time.

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