Re: ostream::operator <<( size_t )
On 16 Feb., 15:52, "James Kanze" <james.ka...@gmail.com> wrote:
Daniel Kr?gler wrote:
On 15 Feb., 22:33, "restor" <akrze...@interia.pl> wrote:
I found that the current standard lacks the requirement that ostream
should have operator "<<" for type "size_t". If size_t is typedefed to
unsigned long we have this requirement indirectly, but if it is an
implementation speciffic integral type we might have a narrowing cast.
This is exactly the case for VC++ 7.0. size_t is typedefed to some
__int64 integer, and the code like:
Note that this is not a legal implementation according to the
current standard. size_t must be a typedef for an unsigned
integral type, and in the current standard, unsigned char,
unsigned short, unsigned int and unsigned long is an exhaustive
list of the unsigned integral types. size_t cannot be a typedef
for a non-existant type.
Although I have not said something else ;-), you are right, that I
also
did not recognize the exact description ("some __int64 integer")
of the OP. But I guess, that this is an misunderstanding
(due to fuzzy wording of the OP), because size_t is an unsigned
integer type on all Visual Studio versions I remember off.
To be sure I tested both VS2003 (version 7.1 if you like) and
VS2005 SP1 (version 8.0) and both support my view.
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).
The C++ IO is largely based on C with regards to what is and is
not supported. Presumable, like printf and scanf, iostreams
will be extended to support long long and [u]intmax_t. (An
#ifdef isn't necessary, of course, since the implementation
knows whether the two types are identical or not.)
Oh, I did not mean #ifdef's and other preprocessor directives,
I just meant ifs/defs in the exact wording of the standard.
Alternatively (and IMHO better), language could be added to
?27.6.1 and ?27.6.2 requiring implementations to add overloads
for >> and << for all additional integral types which they
support.
Do you mean for both standard and extended integer types?
Or for all "basic integral types"? - OK, the last one was a joke,
but do you know, btw, what originally was meant with these
types I asked for in my thread
http://tinyurl.com/2homlz
?
Shouldn't it be allowed for size_t theoretically to be anyone
of extended types, even identical to uintmax_t?
Back to your proposal: While I see not much problems in ?27.6.1/.2,
what do you think concerning the virtual classes in ?22.2.2.1/.2?
Adding one additional overload for intmax_t and uintmax_t should
be sufficient for all the remaining integer types, shouldn't it?
Greetings,
Daniel
---
[ 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 ]