Re: ostream::operator <<( size_t )
On Feb 15, 11:48 pm, "Daniel Kr?gler" <daniel.krueg...@googlemail.com>
wrote:
A possible solution would be to require the provision of streaming
inserters and extractors for intmax_t and uintmax_t (with same if's
and
else's ensuring that these are not identical to the long long and it's
unsigned counter part).
I would like to add some further comments here:
Viewing from the C(99) side, there should already exist the backbone
to realize such support for (u)intmax_t streaming.
9899:1999 (E) (in sect 7.19.6.1) describes support for these types
in fprintf/fscanf and there are new strtoimax/strtoumax functions
which
correspond to strtol(l) and strtoul(l), resp. (The "maters" of all
streaming
related stuff).
One could argue that the virtual functions of the num_get/num_put
class templates could cause backwards problems, but exactly the
same problems occurred during the step assimilating the new
(unsigned) long long type into the language. The current decision
(see
current draft n2134 from
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf
) seems to be a simple interface extension of these facets.
Regrettably this solution has one remaining disadvantage: While
insertion of an arbitrary integer type would cause no problem at all,
it would be necessary to always extract the type as either intmax_t
or uintmax_t before casting to the corresponding integer.
Greetings from Bremen,
Daniel Kr?gler
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]