James Kuyper <kuyper@wizard.net> writes:

| Gabriel Dos_Reis wrote:
| >
| > James Kuyper <kuyper@wizard.net> writes:
| ...
| > | I think it's appropriate for people to know the minimum limits
| > | guaranteed by the standard for each of the standard types, and to
| use
| > | them whenever possible in choosing data types. The only fully
| portable
| > | alternative requires using a messy set of #if's based upon the *_MAX
| > | macros, and that's more trouble than it's worth for most
| applications.
| > | The new <inttypes.h> header in C9x provides a better solution, and I
| > | hope it gets incorporated into the next version of the C++ standard.
| >
| > Standard C++ already sets up a framework such a thing, namely
| > std::numeric_limits<> (it should have been named numeric_trait<>).
|
| C9X's <inttypes.h> provides a large group of typedefs like the
| following:

[...]

| I don't believe that numeric_limits<> provides anything directly
| comparable to these size-named types.

Well, I didn't say that numeric_limits<> does provide something
directly comparable to those size-named types." I did say that it sets
up a *framework*.

Assuming that numeric_limits is renamed to numeric_trait (as I suggested
before), I don't have a pain to imagine an implementation to define

 numeric_trait<int, 8>::exact_type

to be equivalent to C9x's int8_t and

 numeric_trait<int, 32>::fast_type

to C9x's intfast32_t.


That framework is extensible.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marty Fouts wrote:
>
> James Kuyper pounded silicon into:
...
> > I couldn't find a direct statement of the guarantees in the C++
> > standard. However, it incorporates some aspects of ISO/IEC 9899:1990
> > C standard by referece. One of these is the C header <limits.h>, and
> > the C standard does specify minimum values for the *_MAX macros and
> > maximum values for the *_MIN macros defined in that header. An
> > unsigned short int unambigously can store 65535. Whether it can hold
> > larger values is implementation-defined.
>
> Well yes, that was the point of 'sort of', in the above.  IMO, it is
> bad practice to teach neophytes to associate particular variable sizes
> with specific fixed limits, rather than understanding that the limits
> are implementation specific.

I think it's appropriate for people to know the minimum limits
guaranteed by the standard for each of the standard types, and to use
them whenever possible in choosing data types. The only fully portable
alternative requires using a messy set of #if's based upon the *_MAX
macros, and that's more trouble than it's worth for most applications.
The new <inttypes.h> header in C9x provides a better solution, and I
hope it gets incorporated into the next version of the C++ standard.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

| Marty Fouts wrote:
| >
| > James Kuyper pounded silicon into:
| ...
| > > I couldn't find a direct statement of the guarantees in the C++
| > > standard. However, it incorporates some aspects of ISO/IEC 9899:1990
| > > C standard by referece. One of these is the C header <limits.h>, and
| > > the C standard does specify minimum values for the *_MAX macros and
| > > maximum values for the *_MIN macros defined in that header. An
| > > unsigned short int unambigously can store 65535. Whether it can hold
| > > larger values is implementation-defined.
| >
| > Well yes, that was the point of 'sort of', in the above.  IMO, it is
| > bad practice to teach neophytes to associate particular variable sizes
| > with specific fixed limits, rather than understanding that the limits
| > are implementation specific.
|
| I think it's appropriate for people to know the minimum limits
| guaranteed by the standard for each of the standard types, and to use
| them whenever possible in choosing data types. The only fully portable
| alternative requires using a messy set of #if's based upon the *_MAX
| macros, and that's more trouble than it's worth for most applications.
| The new <inttypes.h> header in C9x provides a better solution, and I
| hope it gets incorporated into the next version of the C++ standard.

Standard C++ already sets up a framework such a thing, namely
std::numeric_limits<> (it should have been named numeric_trait<>).

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Dos_Reis wrote:
>
> James Kuyper <kuyper@wizard.net> writes:
...
> | I think it's appropriate for people to know the minimum limits
> | guaranteed by the standard for each of the standard types, and to
use
> | them whenever possible in choosing data types. The only fully
portable
> | alternative requires using a messy set of #if's based upon the *_MAX
> | macros, and that's more trouble than it's worth for most
applications.
> | The new <inttypes.h> header in C9x provides a better solution, and I
> | hope it gets incorporated into the next version of the C++ standard.
>
> Standard C++ already sets up a framework such a thing, namely
> std::numeric_limits<> (it should have been named numeric_trait<>).

C9X's <inttypes.h> provides a large group of typedefs like the
following:

int8_t  Typdef for a signed integer type with a width of exactly
8
  bits. Not required to exist. Programs can test for its
  existence by checking whether one of the corresponding
macros
  (such as INT8_MAX) have been #defined.
uintleast16_t The smallest unsigned integer type with a width of at
least
  16 bits. Must exist.
intfast32_t The fastest signed integer type with a width of at least
32
  bits. Must exist.
uintmax_t The unsigned integer type with the greatest width. Must
  exist.

Note that any of these typedefs might refer to a non-standard
implementation-specific type, and are required to do so if such a type
exists and is the only one meeting the specifications given.

I don't believe that numeric_limits<> provides anything directly
comparable to these size-named types. numeric_limits<> does provide the
same kind of information that <limits.h> provides, relevant to
determining the exact-width and least-width types, but that information
is not sufficient to correctly implement <inttypes.h> in a portable
fashion. The fast-width types are defined by a characteristic covered
neither by numeric_limits<> nor by <limits.h>. Furthermore, the
requirement that these typedefs use a implementation-specific extended
type, if it is the only one that meets the criteria, absolutely requires
that <inttypes.h> be implementation-specific.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marty Fouts wrote:
>
> Michael Novello pounded silicon into:
>
> > I have a c++ book and in its intro to classes it says:
>
> > "It isn't that holding these numbers is a byproduct of being an
> > unsigned short integer; it is that this is the definition on an
> > unsigned short integer."
>
> > In its context, it is talking about the values that an int can
> > hold. It comes after the statement:
>
> > "For example, if you declare Height and Width to be unsigned short
> > integers, you know that each one can hold a number between 0 and
> > 65,535 ..."
>
> > Can someone give me a metaphor? I don't understand what it is
> > saying.
>
> It's wrong, sort of, since there is no guarentee what size the various
> types can have.  That said, here's your metaphor:

I couldn't find a direct statement of the guarantees in the C++
standard. However, it incorporates some aspects of ISO/IEC 9899:1990 C
standard by referece. One of these is the C header <limits.h>, and the C
standard does specify minimum values for the *_MAX macros and maximum
values for the *_MIN macros defined in that header. An unsigned short
int unambigously can store 65535. Whether it can hold larger values is
implementation-defined.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper pounded silicon into:

> Marty Fouts wrote:
>>  Michael Novello pounded silicon into:
>>
>> > I have a c++ book and in its intro to classes it says:
>>
>> > "It isn't that holding these numbers is a byproduct of being an
>> unsigned short integer; it is that this is the definition on an
>> unsigned short integer."
>>
>> > In its context, it is talking about the values that an int can
>> hold. It comes after the statement:
>>
>> > "For example, if you declare Height and Width to be unsigned
>> short integers, you know that each one can hold a number between 0
>> and 65,535 ..."
>>
>> > Can someone give me a metaphor? I don't understand what it is
>> saying.
>>
>> It's wrong, sort of, since there is no guarentee what size the
>> various types can have.  That said, here's your metaphor:

> I couldn't find a direct statement of the guarantees in the C++
> standard. However, it incorporates some aspects of ISO/IEC 9899:1990
> C standard by referece. One of these is the C header <limits.h>, and
> the C standard does specify minimum values for the *_MAX macros and
> maximum values for the *_MIN macros defined in that header. An
> unsigned short int unambigously can store 65535. Whether it can hold
> larger values is implementation-defined.

Well yes, that was the point of 'sort of', in the above.  IMO, it is
bad practice to teach neophytes to associate particular variable sizes
with specific fixed limits, rather than understanding that the limits
are implementation specific.

--

that is all

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michael Novello pounded silicon into:

> I have a c++ book and in its intro to classes it says:

> "It isn't that holding these numbers is a byproduct of being an
> unsigned short integer; it is that this is the definition on an
> unsigned short integer."

> In its context, it is talking about the values that an int can
> hold. It comes after the statement:

> "For example, if you declare Height and Width to be unsigned short
> integers, you know that each one can hold a number between 0 and
> 65,535 ..."

> Can someone give me a metaphor? I don't understand what it is
> saying.

It's wrong, sort of, since there is no guarentee what size the various
types can have.  That said, here's your metaphor:

various types such as char, short, int, and long, can be thought of as
containers of a fixed size.  They can only hold numbers that are
'small enough' to fit.  'unsigned' means that the numbers range from 0
to some positive value.

--

that is all

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]