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