[boost] Re: Serialization Submission version 6

From: Alberto Barbati (abarbati_at_[hidden])
Date: 2002-11-15 17:15:53

Vladimir Prus wrote:
> Robert Ramey wrote:
>> Now I remember why I included this.
>>
>> Suppose that an archive is created where the default local is a 
>> spanish speaking country where the number 123 thousand is written
>>
>> 123.000
>>
>> The archive is sent to another country where the default locale is an 
>> english speaking country where the string
>>
>> 123.000
>>
>> means 123
>> That's why I set the local to classic.

I'm well aware of this issue. See below.

> is it a good idea to change stream locale without user's consent. Maybe,
> archive should create *their own* (i/o)stream, sharing streambuffer with
> the stream the user has passed, and with appropriately modified locale?

In my opinion it the archive should not change the stream locale without 
the programmer's consent. The main reason for this is that she may 
indeed want to use her own locale, for example to allow Unicode output.

Ovverriding only num_put/num_get (and why not ctype also?) is not a nice 
solution, in my opinion, it's just a hack. Moreover, I can imagine a 
brave programmer that is aware that her serialized data will not be read 
by any other application except hers and decides to have the text output 
to follow her native language conventions.

In the end, between the two possibilities:

1) override the locale (entirely or partially), reducing programmer's 
freedom of customizing the output but guaranteeing a perfect portable 
output;

2) not override the locale, leaving to the programmer the complete 
responsiblity to set the right one that satisfies her specific 
requirements, with the risk that she messes things up;

I vote without doubt for number 2.

To be paranoid, on output we could write in each archive a magic number 
like 12345.678, on input we try to read it and if it doesn't match the 
magic number, we issue an error. I know that this hack won't catch 100% 
of the problems, but it will catch most of them and is not less safe 
than writing the sizeof() of the basic types as we are currently doing.

Alberto Barbati