[boost] Re: Serialization Library Review

[Alberto Barbati]

Robert Ramey wrote:

Alberto Barbati wrote

Please note that the "registry" class I described *does not* attempt to solve the broader issue of UUIDs I read about in the discussion between you and Vladimir. My proposal is just a way to separate the "registration" part from the "serialization" into two different compontents. Still the classes will be matched according to their registration order, as it happens now. I am ready to discuss the opportunity and/or usefulness of this approach, but I don't see the reason why this could not be done.

I considered this approach and found the following problem

It seems from the objections you raise that I did not explain myself well enough. Before answering to them, I think a code snippet would help. Consider this code, that uses current implementation:

---begin code

std::ofstream s("...");
boost::oarchive a(s);
a.register_type<t1>();
a.register_type<t2>();
a.register_type<t3>();
a.register_type<t4>();

// do serialization

---end code

What I am suggesting is to allow, possibly in addition to that form, the following form:

---begin code

boost::serialization_registry r;
r.register_type<t1>();
r.register_type<t2>();
r.register_type<t3>();
r.register_type<t4>();

std::ofstream s("...");
boost::oarchive a(s, r); // in the body of the constructor an
// equivalent of register_type()
// is immediately called 4 times
// do serialization

---end code

I am *not* suggesting to change in *any way* the serialization process. The purpose of serialization_registry is just to allow for a finer granularity of responsibilities.

> a) register all the types in the global collection in the archive.
> bad idea - this would require that the reading program register
> all the types of the writing program. An intolerable requirement

With my approach you are going to register the same types you would register anyway. Not one less, not one more. Why would it be intolerable?

> b) register types as needed as the library is written
> wouldn't work - on loading, we wouldn't know which types to register
> c) after creating the archive, append a "registration file" on loading,
> process the "registration file first. In my view this cure is worse
> than the disease.

The types are going to be physically output in exactly the same way as it's being done by current implementation. So this two objections do not apply.

So you may be wondering, what's the point in having this registry class? There are two main advantages:

1) the module that sets up the registry can be distinct from the one that effectively performs the serialization. This can solve a lot of dependency issues.

2) the registration can be done in *one* place for *both* input and output. With current implementation, the registration code will be duplicated and duplication is always a bad thing. Imagine yourself trying to keep two (possibly very) long lists of register_type calls synchronized.

I'm still at a loss.  Aside from addressing the "classic" above, what exactly
do you recommend I do?  How about if I change the wording to specify
that the library supports wide streams and leave unicode out of it?

Yes, it all boils down to change the wording as you said: you just can't mention Unicode. I got a little carried away because I'm working on the subject and I'm having a hard time getting people aware of the issue. I apologize for that.

On a different topic, I found a portability issue. The current implementation record in the archives the size of the basic types int, long, float and double. This gives you a *false* sense of security that the "writing" and "reading" platform agree on the type size.

this is for the native binary archive which is explicitly described as
being non-portable. It was included because some users felt it
would be more efficient. It has no pretensions at all to portability.
Knowing that some one will ignore this admonishment and
try to move such a binary to another machine architecture, Included free detection so that it would crash in a more graceful manner.

All right, but still the size_t issue with read_string/write_string is a bug, as it does not involve cross-platform. With current implementation a program will fail reading its own serialized strings on a least one plaform (i64).

Alberto Barbati



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost