Re: [Boost-users] [serialization] class versioning changes in boost 1.42 [patch]

Subject: Re: [Boost-users] [serialization] class versioning changes in boost 1.42 [patch]
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-02-27 18:23:16

David Raulo wrote:
> On Sat, 27 Feb 2010 10:17:19 -0800
> "Robert Ramey" <ramey_at_[hidden]> wrote:
>
>> David Raulo wrote:
>>
>>> - boost_version  used to be an unsigned int, which for the vast
>>>  majority of your users was 32 bits at least;
>>
>> I believe that the C++ standard permits an int to be 16 bits.  That
>> in itself would be an indicator that assuming 32 bits might be an
>> issue.

> which is why I proposed using uint_least32_t, instead of going back to
> unsigned int.

which is good thinking.  what I really want to do is to use uint_least_8_t
to document and enforce the current design.

>Out of curiosity, do you know of a c++ compiler on some
> boost-supported platform which is using 16 bits ints?

When faced with writing something like the serialization library one
can take two approaches:

> Some beefy microcontroller perhaps?   Or is this concern about 16-bits 
> ints
> purely hypothetical?

a) select the group of compilers that one is interested in and
make sure everything works for all members of that group.
b) code to the C++ standard.  Then introduce work-arounds
for those compilers which fail to support the standard in some way.

I've chose b) because it results in much portable code and is
less work to implement and maintain.  In short, it's scalable.
One only needs to consider differences between each compiler
and the standard rather than an ever larger group of compilers.
There are other reasons to support doing it this way but these are
enough for me.

One thing that is a bad idea, and this case illustrates it, is to make
assumptions about the implementation which are not explicit.  That
is - if a integer has to be able to contain 32 bits for the program to
work, one should use a type which indicates and guarentees that.

> Try to see it that way: you seem to be implying that using
> uint_least32_t now would somehow increase risks of future problems,

Actually, it would create problems immediately.  In fact, you have one
right now.  You haven't come upon it because you only use a
type of archive where the problem doesn't show up.

> but at the same time you suggest that we do just that.

Well, your case is special now.

> Now I'm  wondering what those risks really are, and if we should take 
> them.

I suppose the risk is that there is another ambiguous issue inside the
library that no one knows about which could later become a problem.
You'll have to weigh the risk of alternatives- writing your own
code, using a different library, etc.. to determine if they're less risky.

> But for the sake of the argument, let's continue evaluating the
> downsides of that patch, which prevent it from being applied to
> official boost.  Yes, I understood long ago that you won't, but with
> all that time spent arguing, you have not yet shown a single concrete
> scenario where applying that patch would create you or any user any
> problem. See below.

Your situation is a concrete case.  If you want to use binary_archive to
to make the process faster, you can't. Your program will fail.

>>> - Would this patch cause any regression? Break any user code which
>>> was working fine before?  Break user archive backward compatibilty?

> The fact remains that this "guarantee" was never there before, is
> still not there, and so the patch does not incur any regression here
> either.

Thinking about it some more, I'll look into the possibility of permiting
the loading of larger version # from older text archives.  I see now
that's what you have in mind.  I would likely implement it in a different
way but I think I can make it work.  I'll have to think about it.

> Besides, binary and xml are not equal anyway wrt serialization.
> Imagine that scenario: a user becomes accustomed to the fact that xml
> archives, the only kind she tests at first, is portable between
> platforms.   Her application becomes dependant on that portability.

> Then at one point she discovers that binary archives, which she wanted
> to use, are not portable. She is now stuck with XML.  Strangely, you
> are not suggesting that we make xml non-portable, so that users do not
> "couple the concepts or archive and serialization", are you?  ;-)

Not that it matters - but this is totally not understandable to me.

> And finally: if I were to complete the patch with code to enable 32
> bits versions for  binary archives too, that would take care of your
> only argument against the first patch so far, yes?  Would you accept
> it then? Or is there another rule that I missed?

Actually, it would be easy to "upgrade" the version # to 32 bits.  But
this would only encourage more mis-usage of the version # and make
all binary_archives a little bit bigger.

Give me some time to think about it some more.

Robert Ramey