Boost logo

Boost :

From: rameysb (ramey_at_[hidden])
Date: 2002-02-27 18:14:46

--- In boost_at_y..., "George A. Heintzelman" <georgeh_at_a...> wrote:
> Hmm. Yes, but. I am somewhat concerned because pool implementations
> likely to produce objects which have the same address as previously
> existing ones of the same type, and I worry that some naivete' here
> lead someone to problems. I don't have a concrete example though,
> except of course for deliberate sabotage.

Previously serialized addresses of the same type are fine as long as
are serialized the same way. The problem occurs only when it is
serialized different ways. So it turns out that things like maps
and lists of duplicated pointers, etc work fine. I believe the
situations where this would be a non-trivial problem - if they exist
would have to be contrived.

> More worrisome to me is trying to use a serialization library --
> I see as a fairly fundamental piece -- to implement more
> functionality. For example, it seems natural to want to use a
> serialization library under some persistence or object database
> library. In such cases, saving and restoring pointers is a much
> complex issue, and I worry that your implementation could
interfere. So
> even if you have a default mechanism in place, perhaps a user ought
> be able to replace the mechanism?

Its hard for me to comment on this without a more concrete example

>> This presumes that the state of the objects doesn't change when an
>> archive is being written or read. This implementation of the
>> makes this assumption. I havn't considered what would happen if
>> assumption didn't hold. In an attempt to enforce this assumption,
>> all the class member save functions are marked const. This should
>> prevent the data from being changed while being serialized.

> The assumption is not an unreasonable one, though it needs to be
> explicit in documentation. But I fear the constness of class member
> save functions will help you little, if at all:

> class Y;
> class X {
> scoped_ptr<Y> p;

I believe that this not a serious problem. When class members are
serialized they are also serialize through const functions. So
the whole call stack is instantiated with constant functions. This
occurs only when serializing through pointers. So I believe that
is why the problem never comes up.

> I'm not sure it is that easy to avoid. It would probably be fairly
> common to give out pointers/references to elements of a map which
is a
> data member, for example. I know that I do this frequently. If one
> writing from scratch, it might be possible to avoid, but to
retrofit a
> workaround onto an existing class seems like trouble.

I don't believe this is any problem - I do it all the time see above.

Robert Ramey

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