Daniel Kr   gler wrote:
> On 16 Feb., 15:52, "James Kanze" <james.ka...@gmail.com> wrote:
> > Daniel Kr   gler wrote:

    [...]
> > 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?

Yes.  Something along the lines (not in good formalese): "In
addition, an implementation is required to provide overloaded
member operator<< and operator>> for all extended integral types
is supports.

> 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?

I presume that it will be allowed.  I don't have my copy of C99
handy, but I think that it allows the extended integral types.
(I don't have my copy of the latest draft here either; I know it
says something about extended integral types, but I don't know
what, so I can't comment.)

> 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?

The same thing: the implementor has to provide the additional
membes.  Of course, the creates somewhat a problem for the poor
user trying to create his own instances:-).  I'm not sure that
this is a real problem, however; why on earth would one ever
replace and overload num_get and num_put.  (By design, one is
supposed to replace numpunct, which these facets use.  Why
they're even in locale is a mystery to me.)

> Adding one additional overload for intmax_t and uintmax_t should
> be sufficient for all the remaining integer types, shouldn't it?

Almost.  A quality implementation would certainly want to do
bounds checking, and generate an error on overflow (even if the
standard says it is undefined behavior).

Requiring one additional overload, of course, can only be done
correctly if we also make intmax_t and uintmax_t independant
types, and not typedefs.  Otherwise, the user doesn't know
whether to overload it (if they are not one of the required
basic types) or not (if they are).

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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                      ]

Hi All,
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:
size_t S = sizeof(int);
std::cout << S;
I get a warning about possible loss of data due to conversion to
shorter type. Now, I suppose that __int64 is a substitute for comming
long long int, but the problem is more general and anyone can imagine
size_t as typedef of some __int128 and the problem reappears.

Is there any way to communicate that to the C++ Standards Committee?

Regards,
&rzej

---
[ 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                      ]

On 15 Feb., 22:33, "restor" <akrze...@interia.pl> wrote:
> Hi All,
> 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:
> size_t S = sizeof(int);
> std::cout << S;
> I get a warning about possible loss of data due to conversion to
> shorter type. Now, I suppose that __int64 is a substitute for comming
> long long int, but the problem is more general and anyone can imagine
> size_t as typedef of some __int128 and the problem reappears.
>
> Is there any way to communicate that to the C++ Standards Committee?

I guess you did that with this contribution ;-)

(No, I'm not member of the Committee)

Honestly, I agree that this problem exists. Notably, it is not limited
to
size_t, but will apply also for the upcoming so-called extended
integer
types as well (at least to those which's limits exceed those of the
standard integer types), e.g. those of the new <cstdint> header.

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).

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                      ]

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                      ]

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.

> > size_t S = sizeof(int);
> > std::cout << S;
> > I get a warning about possible loss of data due to conversion to
> > shorter type. Now, I suppose that __int64 is a substitute for comming
> > long long int, but the problem is more general and anyone can imagine
> > size_t as typedef of some __int128 and the problem reappears.

> > Is there any way to communicate that to the C++ Standards Committee?

> I guess you did that with this contribution ;-)

> (No, I'm not member of the Committee)

> Honestly, I agree that this problem exists. Notably, it is not
> limited to size_t, but will apply also for the upcoming
> so-called extended integer types as well (at least to those
> which's limits exceed those of the standard integer types),
> e.g. those of the new <cstdint> header.

> 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.)
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.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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                      ]

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                      ]