Re: [boost] [serialization] use of unsigned int instead of size_type

From: Kim Barrett (kab_at_[hidden])
Date: 2006-02-12 23:25:20

At 9:14 AM -0800 2/12/06, Robert Ramey wrote:
>  >> David Abrahams wrote:
>  >> A strong typedef should work, if all archives implement its
>  >> serialization.
>
>  as a general rule, the included archives only implment serialization
>  for primitives.  This permits all serializations to work with all
>  archives.  Its been a constant battle to keep these things
>  decoupled in order to preserve this feature.
>
>  serializations should be attributes of the type NOT any
>  particular archive.

This is the objection I expected to hear from Robert much earlier in
this discussion. A strong typedef for this purpose effectively widens
the archive concept by adding a new thing that needs to be supported.
That conceptual widening occurs even if the default archive behavior
for a strong typedef is to just serialize the underlying type. It
still needs to be documented as part of the archive concept, and
anyone defining a new kind of archive ought to consider whether that
default is the correct behavior for this new archive type, or whether
something else is needed.

And I think he would have a pretty good rationale for feeling that
way. Keeping the archive interface narrow and minimizing the coupling
between serialization and archives minimal is, I think, one of the
strengths of the serialization library's design.

I would be in full agreement with Robert here, except that all of the
alternatives I can think of seem worse to me.

1. std::size_t

This causes major problems for portable binary archives. I'm aware
that portable binary archives are tricky (and perhaps not truly
possible in the most general sense of "portable"). In particular,
they require that users of such archives be very careful about the
types that they include in such archives, avoiding all explicit use
of primitive types with implementation-defined representations in
favor of types with a fixed representation. So no int's or long's,
only int32_t and the like. Floating point types add their own
complexity.

Some (potential) users of the serialization library (such as us) are
already doing that, and have been working under such restrictions for
a long time (long before we ever heard of boost.serialization),
because cross-platform serialization is important to us.

The problem for portable binary archives caused by using std::size_t
as the container count is that it is buried inside the container
serializer, where the library client has no control over it. All the
archive gets out of the serializer is the underlying primitive type,
with which it does whatever it does on the given platform. The
semantic information that this is a container count is lost by the
time the archive sees the value, so there's nothing a "portable"
archive can do to address this loss of information. And this occurs
no matter how careful clients are in their own adherence to use of
fixed representation value types.

This leaves a client needing a portable binary archive with several
unappealing options (in no particular order)

- Modify the library to use one of the other options.

- Override all of the needed container serializers specifically for
the portable archive.

- Don't attempt to serialize any standard container types.

2. standard fixed-size type

We already know that uint32_t is inadequate; there are users with
very large containers. Maybe uint64_t is big enough, though of course
predictions of that sort have a history of proving false, sometimes
in a surprisingly short time. And uint64_t isn't truly portable
anyway, since an implementation might not have that type at all.
Also, some might object to always requiring 8 bytes of count
information, even when the actual size will never be anything like
that large. This was my preferred approach before I learned about the
strong typedef approach, in spite of the stated problems.

3. some self-contained variable-size type

This might be possible, but the additional complexity is
questionable. Also, all of the ideas I've thought of along this line
make the various text-based archives less human readable, which some
might reasonably find objectionable.

4. something else

I haven't thought of any. Anybody else?

So it appears to me that all of the available options have downsides.
While my initial reaction to the strong typedef approach was rather
ambivalent because of the associated expansion of the archive
concept, it seems to me to be the best of the available options.