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 10:34:03

I figured as much. I've been looking for some equivalent way of
snookering but no such luck. Hopefully Dave's response will get me on
the right track.

If this doesn't work, would you be open to a patch which falls back to a
mechanism like the old export.hpp? I'll have to figure out the
void_cast_register problem first though.

Robert Ramey wrote:
> 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 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 

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