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