Re: Grrr... C++ file I/O
On Jun 13, 5:21 pm, Charles Bailey <usenetspa...@hashpling.org> wrote:
On 2007-06-13, James Kanze <james.ka...@gmail.com> wrote:
On Jun 13, 9:33 am, Charles Bailey <usenetspa...@hashpling.org> wrote:
If you want the change the way in which various types are written out
then you may find that you can achieve what you want by implementing a
local::facet. You might, for instance, decide that integers should
really be serialised in a custom base64 style encoding. You could
then implement num_get and num_out facets. You can use this with the
standard iostreams by creating a new locale (std::locale has methods
for retrieving a copy of either the global locale or the "classic"
one), patching in your custom facets and imbueing (calling
ios_base::imbue) the stream with your custom locale.
That sounds a lot like abuse to me, and is likely to cause
trouble, since more complex objects like std::complex count on a
particular format. (In fact, std::complex doesn't even work
correctly in most European locales. That, I believe, is
considered an error, but I don't think the committee would
recognize it an error if e.g. it didn't work with
num_get/num_put facets which did binary output.)
My example was bad. The usual facets are fairly flexible but in
theory, if you have an obscure locale with an interesting way of
writing numbers that you need to support (or have invented ;) ) you
should be able to provide your own locale and not break everything if
your locale is consistent.
You should be able to, at least within very liberal limits. In
practice, I'm less sure. I would consider something like using
a different base an abuse, and in practice, I'd be sceptical of a
facet which provided a new num_get or num_put (as opposed to
simply a new num_punct). As you say, you should be able to,
but...
I haven't had to work with serializing complex numbers but I hadn't
realised how broken it apprears to be.
It is very, very broken, probably because it doesn't take locale
at all into account. This will be fixed, I hope, in the next
release of the standard; at present, it fails in most of the
locales I normally use.
#include <iostream>
#include <sstream>
#include <complex>
#include <locale>
int main(int argc, char* argv[])
{
std::stringstream sstr;
if (argc > 1)
{
sstr.imbue(std::locale(argv[1]));
}
std::complex<double> c1(1.5), c2(1, 5);
std::complex<double> c3, c4;
sstr << c1 << c2;
std::cout << sstr.str() << std::endl;
sstr >> c3 >> c4;
std::cout << c3 << c4 << std::endl;
}
$ ./a.out
(1.5,0)(1,5)
(1.5,0)(1,5)
OK, that works.
$ ./a.out fr_FR
(1,5,0)(1,5)
(1.5,0)(1.5,0)
Oops!
The normal way of writing a complex in France is "(1,5;1,5)".
For obvious reasons, we don't use a , as a separator.
$ ./a.out en_GB
(1.5,0)(1,5)
(1.5,0)(0,0)
This one surprised me. Attaching a debugger reveals that the
comma in (1,5) is parsed as part of the real part as ',' is a
valid thousands separator.
The whole way thousands separators work probably needs to be
rethought out. The usual thousands separator in France is a
space, which causes no end of problems. (I'm afraid I don't
have a solution to propose for this one. My own input
conversion routines ignore spaces, where ever they appear. But
this means that the user must first parse the text enough to
isolate the number before trying to convert it.)
The real read stops when it hits the ')' and then flags a
failure as the thousands seperator was in the wrong place. At
least that's my interpretation of what my implementation is
doing.
It sounds likely. There should be a means of inhibiting the use
of thousands separators in certain numbers, regardless of the
locale, and this should be activated when reading complex.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34