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
>> The archive is sent to another country where the default locale is an
>> english speaking country where the string
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk