Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-12-13 16:30:20

Emil Dotchevski wrote:
> I apologize if this has been discussed before, but this message
> caught my attention and I decided to ask: why do you need any
> statics/globals for the serialization?

The static instantiations are used for a couple of things:

a) maintaining table which is used to convert between different pointers to
different types of objects at runtime - with or without RTTI existing. See
void_cast ...

b) To hold a constant string type "export" key as RTTI systems don't provide
a portable one.

c) To hold pointers to serialization functions for derived pointers.

d) To guarentee instantiation of serialization functions not otherwise
explicitly referred to.

For more information - feel free to preuse the code.

> I understand that you need global class registration to handle the
> case of reading a base pointer when the stream contains derived
> object, but when you serialize data you just assume that all classes
> have been registered ahead
> of time.

Not necessarily. The export functionality eliminates the requirement to
explicitly register all derived types. Its original implementation
initialized the type table upon first usage - the current one intializes the
type table on start-up. This one of the changes I've been referring to in
my belief that the situation may no longer exist.

>Because you don't need mutable access to the class
> registration table, you don't have thread safety problems.

Iff and only iff you can get everthing initialize at pre-main time or upon
DLL loading. Which has been exactly the problem up until now.

> The other piece of data that I can think of is the table that tracks
> which objects have already been serialized so that when you serialize
> a second pointer that points to the same object you don't serialize
> the object again, however this table has to be per-stream because I
> may have multiple opened streams that I'm reading from. Assuming you
> don't access the same stream
> from multiple threads, I see no thread safety problems here either.

This is correct - there are no theading problems associated with

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at