Boost logo

Boost :

From: Hugh Hoover (hugh_at_[hidden])
Date: 2006-02-24 18:16:29


> Marcin Kalicinski wrote:
>> I noticed strange behavior of serialization on VC 8.0. I use
>> BOOST_CLASS_EXPORT macro in a .cpp file to register a derived class,
>> so that it can be properly serialized through base class pointer.
>> This works fine, as long the .obj file resulting from compilation
>> of .cpp
>> file which
>> uses BOOST_CLASS_EXPORT macro is linked directly to the final
>> executable. But when I first put this .obj file into a static
>> library, and
>> then link
>> the library to executable, I start getting unregistered_class
>> exceptions - as if there was no BOOST_CLASS_EXPORT invoked.

I'm having what appears to be a similar problem, although I can't get
the BOOST_CLAS_EXPORT to work at all. I have to use the
ar.register_type form in order to get anything to work with derived
classes. (Also, i'm using gcc4)

Note that (at least so far) ALL of my serialization code is within a
single file (that is, the code that actually does an "oa << foo", so
that code was able to see all appropriate declarations and the
BOOST_CLASS_EXPORT.

Any thoughts on that?

On Feb 23, 2006, at 18:22, Robert Ramey wrote:
> I recommend puting BOOST_CLASS_EXPORT in the header rather
> than in the *.cpp file. The same goes for all serialization traits.
> Generally
> a class should be loaded with the same traits as when it is saved.
> Putting
> traits in the header assures this to be the case.
>
> Robert Ramey

This just doesn't seem right to me - I had thought that
BOOST_CLASS_EXPORT actually registered the appropriate type
information globally, so that the ar.register_type calls wouldn't be
required. The extended_type_info class appears to contain a map that
could be used for such. As such, there shouldn't be any reason to
have the EXPORT globally visible (and that introduces a problem for
MY code).

I'm clearly not understanding something here, can someone enlighten me?

Hugh Hoover
Enumclaw Software


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