[Serialization] assertion failure on exit
I'm getting the following assertion failure on exit when instantiating certain serializable classes: Assertion failed: NULL != l, file libs\serialization\src\extended_type_info.cpp, line 47 I was finally able to determine a difference between the classes that caused the assertion failure and those that didn't. Here's some code: ////////////////////////////////////////////////////////////////// // Serializable.hpp: class Serializable { public: virtual ~Serializable() = 0; template< typename Archive > void serialize( Archive& /*ar*/, const unsigned int /*version*/ ) { } private: }; inline Serializable::~Serializable() { } BOOST_CLASS_EXPORT( Serializable ) ////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////// // Foo.hpp: struct Foo : Serializable { template< typename Archive > void serialize( Archive& ar, const unsigned int /*version*/ ) { ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP( Serializable ); } }; BOOST_CLASS_EXPORT( Foo ) ////////////////////////////////////////////////////////////////// The above code does not assert on exit after instantiating a Foo object. If I make Foo not header-only like so: ////////////////////////////////////////////////////////////////// // Foo.hpp: struct Foo : Serializable { Foo(); template< typename Archive > void serialize( Archive& ar, const unsigned int /*version*/ ) { ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP( Serializable ); } }; BOOST_CLASS_EXPORT( Foo ) ////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////// // Foo.cpp: Foo::Foo() { } ////////////////////////////////////////////////////////////////// then I get the assertion failure on program exit if I so much as instantiate a Foo object.
On Friday 05 December 2008 16:39:33 Kenny Riddile wrote:
I'm getting the following assertion failure on exit when instantiating certain serializable classes:
[snip]
class Serializable { public: virtual ~Serializable() = 0;
[snip]
};
Do you have the same problem if your destructor is not pure virtual? As a side note, why is this destructor pure virtual, rather than just be virtual? Are you trying to make your class not be instantiable directly, but only be instantiable from a derived class? In that case, simply make your constructors protected. Regards, Ravi
Do you have the same problem if your destructor is not pure virtual?
Yes, it still asserts if the base class destructor is virtual rather than pure-virtual.
As a side note, why is this destructor pure virtual, rather than just be virtual? Are you trying to make your class not be instantiable directly, but only be instantiable from a derived class? In that case, simply make your constructors protected.
Yes, it is pure-virtual to prevent direct instantiation. Adding a constructor definition and making it protected just seems like a more obfuscated, verbose way of achieving the same result. It isn't even the same result either. With the protected constructor method, someone could still add a friend later on which could instantiate a Serializable object directly.
After further experimentation, it seems I only get the assertion on exit when the same class is exported via the BOOST_CLASS_EXPORT macro in multiple translation units. So I could probably fix my problem by adding a cpp for all of my simple classes and putting the export macro in there, but that's silly. I must be missing something.
Ah, well I finally happened across this link: http://www.boost.org/doc/libs/1_37_0/libs/serialization/doc/special.html#exp... which contains the blurb: "Also, when making shared libraries, there is currently a restriction that only one such library can use BOOST_CLASS_EXPORT for any given type. All this will most likely make it inconvenient to include BOOST_CLASS_EXPORT as part of the header of the class to be serialized. So, the best way to use BOOST_CLASS_EXPORT is to include it in the same module which implements the class." Are there any plans to remove this restriction somehow in the future?
If someone comes up with a way to do it. This has a somewhat tortured history. Implementation of export relies on non portable aspects of C++ compilers. Coupled with dynamic loading of libraries it has been difficult to get this working accross all plaforms and circumstances. It has steadily improved to the current state. It's may not be perfect, but its much better than it used to be and quite servicable. Robert Ramey Kenny Riddile wrote:
Ah, well I finally happened across this link: http://www.boost.org/doc/libs/1_37_0/libs/serialization/doc/special.html#exp...
which contains the blurb:
"Also, when making shared libraries, there is currently a restriction that only one such library can use BOOST_CLASS_EXPORT for any given type. All this will most likely make it inconvenient to include BOOST_CLASS_EXPORT as part of the header of the class to be serialized. So, the best way to use BOOST_CLASS_EXPORT is to include it in the same module which implements the class."
Are there any plans to remove this restriction somehow in the future?
Robert Ramey wrote:
If someone comes up with a way to do it.
This has a somewhat tortured history. Implementation of export relies on non portable aspects of C++ compilers. Coupled with dynamic loading of libraries it has been difficult to get this working accross all plaforms and circumstances. It has steadily improved to the current state. It's may not be perfect, but its much better than it used to be and quite servicable.
Robert Ramey
Thanks. That does sound like a complex problem to solve, but implementing serialization myself sounds like a much more complex problem, so I'm happy to have the library :)
On Mon, Dec 8, 2008 at 4:21 PM, Kenny Riddile <kfriddile@yahoo.com> wrote:
Ah, well I finally happened across this link: http://www.boost.org/doc/libs/1_37_0/libs/serialization/doc/special.html#exp...
which contains the blurb:
"Also, when making shared libraries, there is currently a restriction that only one such library can use BOOST_CLASS_EXPORT for any given type. All this will most likely make it inconvenient to include BOOST_CLASS_EXPORT as part of the header of the class to be serialized. So, the best way to use BOOST_CLASS_EXPORT is to include it in the same module which implements the class."
Are there any plans to remove this restriction somehow in the future?
As Robert pointed out, BOOST_CLASS_EXPORT relies on platform-specific hacks to work, but note that you *can* use boost.serialization without BOOST_CLASS_EXPORT. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (4)
-
Emil Dotchevski -
Kenny Riddile -
Ravi -
Robert Ramey