Boost logo

Boost :

Subject: Re: [boost] [Serialization] BOOST_CLASS_EXPORT regression on SunCC
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-02-17 09:19:09


As I understand the standard, there is on reason that the indicated
code has to be instantiated. That's why we "snooker" the compiler
into instantiating the code and "re-snooker" the optimizer so that
it doesn't strip the code even though it's never explicitly invoked.
(for this we use the DLL macros). So its just a case of SunCC
compiler being too literal minded for boost export. I would hope
that there is a way to indicate to the SunCC that the indicated
code should be instantiated.

Robert Ramey

Sohail Somani wrote:
> Hey Robert,
>
> I guess that is possible. I have no idea *why* it is not getting
> instantiated though so I wouldn't know where to start. Any
> suggestions?
>
> In any case, what part of the standard says that the return type
> should be instantiated? I read the part referenced in
> register_archive.hpp (temp.dep.candidate) but I can't see how to
> interpret that as "must instantiate the return type."
>
> Also, it turns out that base_object also has a regression which may be
> related. I had to explicitly instantiate void_cast_register to get the
> test to pass.
>
> Robert Ramey wrote:
>> Look at the code - It's not just SunCC
>>
>> template <class Archive, class Serializable>
>> struct ptr_serialization_support
>> {
>> # if defined(BOOST_MSVC)
>> virtual BOOST_DLLEXPORT void instantiate() BOOST_USED;
>> # elif defined(__BORLANDC__)
>> static BOOST_DLLEXPORT void instantiate() BOOST_USED;
>> enum { x = sizeof(instantiate(),3) };
>> # else
>> static BOOST_DLLEXPORT void instantiate() BOOST_USED;
>> typedef instantiate_function<
>> &ptr_serialization_support::instantiate
>>> x;
>> # endif
>> };
>>
>> Can we not find some bit of magic to make SunCC instatiate that whic
>> is needed?
>>
>> Robert Ramey
>>
>> Sohail Somani wrote:
>>>> From version 1.34 to 1.35, the export of classes was modified so
>>>> that
>>> all the archives did not need to be included before calls to
>>> BOOST_CLASS_EXPORT. I don't know why this was a problem to begin
>>> with.
>>>
>>> Anyway, this feature used to work on SunCC but with the new changes,
>>> there is a regression. This is caused by the dependence on ADL to
>>> instantiate the ptr_serialization_support members: SunCC just
>>> doesn't do
>>> it. So the instantiations never occur and you get an assertion
>>> failure when running the serialization tests under debug:
>>>
>>> Assertion failed: it != boost::serialization::singleton<
>>> oserializer_map<Archive> >::get_const_instance().end(), file
>>> vendor/boost_1_37_0/boost/archive/impl/archive_pointer_oseri\
>>> alizer.ipp, line 64
>>>
>>> I know how to fix it (instantiating manually for each
>>> Archive,Serializable pair, not a huge problem).
>>>
>>> I would suggest that Boost Serialization should have a fallback
>>> mechanism for
>>> these compilers. Perhaps along the lines of the old export
>>> functionality where the user would define the archives they are
>>> interested in.
>>>
>>> Thoughts?
>>>
>>> _______________________________________________
>>> Unsubscribe & other changes:
>>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk