Re: [Boost-users] Design for boost::serialization of STL iterators.

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-03-12 20:37:01

Carlo Wood wrote:

> I think that at the moment of serialization, the actual container
> needs to be known. So, only concentrating on the syntax of the code
> that serializes an iterator, the following cannot work:
>
>  ar & iter;
>
> However, the container will be known at that point (or at least,
> we might as well assume that). Therefore, I could imagine a syntax
> like:
>
>  ar & foobar(container, iter);
>
> where 'foobar' is some template function (that will be part of
> boost::serialization in the future).

This sounds believable to me.  for foobar - look at the documentation
on serialization wrappers.  nvp is an example of a serialization wrapper.

> Therefore, the following syntax can work imho:
>
>  ar & FooBar(container, iter);
>
> Would you agree?

sounds believable.  FooBar would be a

> There are a zillion questions and implementation details
> open - but I'd like to get anyones feedback about this
> type of interface for iterators before continuing.
>
> Current questions: What is a good name for Foobar?

> Am I right when I think that Foobar needs to be declared
> in boost::serialization?

not necessarily. But that's were serialization of the stl
collections have been implemented so that would be a
natural spot.

> Now the hard part (for me) is that part that involves
> the internals of the boost library.

Its not obvious to me that one has to be aware of the
internals of the boost library to do this.  I would hope
that this would be the case.  Your FooBar(container, iterator)
object would have its own serialization methods
independent of the library implementation  In this
sense it is one more serialization wrapper like nvp
and (soon perhaps) array.  It is a user of the library rather
than a component of the library.  Note that stl collections
are also users of the library.  The library code has no
notion of any specific seriliazable type (almost).

> At the moment one tries to serialize an iterator, it is
> possible (though not necessarily) that the object that
> the iterator points to is already serialized. In the case
> that we are dealing with an associative container (map or
> set etc), we don't want to store the contents of the
> object (or key part, in the case of a map) again: I'd
> like to just store that once, and store a reference in
> the archive at the other place. How can I make the library
> store an object only the first time and the store a
> reference the second time?

This is usually done automatically by the library - look
in the documentation under the heading "object tracking"

> This would be for an object
> of arbitrary type thus. I think that it is only feasible
> to do this when it's actually the same object (same
> memory address), which is the case; but while storing
> the object element of the container, the address of it
> isn't stored as well, is it?

It would be if tracking were enabled for that particular type.

>Is there a way to make:
> std::set<SomeData> s;
> [...]
>  ar << s;
>
> Store the address of s (&s) along with the contents of s?

> And would that then automatically cause the library to
> not store that same object again when I do:
>
>  std::set<SomeData>::iterator iter = s.find(...);
> [...]
>  ar << *iter;
>
> Because then, &*iter would again be the same memory
> address as what was stored before.

see above.

Its apparent that accomplishing this will require a thorough
understanding of  serialization library and the faclities it
provides.  I might well be possible, time will tell.

Robert Ramey