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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk