phalpern@truffle.ma.ultranet.com (Pablo Halpern) writes:

|>  James Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:
|>
|>  >I'll bet that you are concerned about the MINIMUM size.  The above
|>  >program is only defined because the standard guarantees INT_MAX >=
|>  >32755, and would fail badly if int's could only have 8 bits.
|>
|>  I believe you mean 32767, no?

Of course.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze wrote:
> ... Since this
> varies from machine to machine, you end up with what one person
> suggested: a templated integer.

Wouldn't templated integers be a really bad idea?  This would mean
that (almost) every single function that took a generic int, would
have to become a template function!

Unless, of course, int was the base class for all int<>'s! (just
kidding :-)


Regards,
Marcelo Cantos
--
__________________________________________________
Multimedia Database Systems Group, RMIT, Australia
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  James Kanze wrote:

|>  > With regards to the original question, however: it is certainly true
|>  > that you don't care about the EXACT size, only the minium size.  (And I
|>  > suspect that Valentin actually slipped up, and didn't mean to say
|>  > exact.)
|>
|>  No, no I really mean exact even if most of the time the program just
|>  guess the minimum maximum size of an int is 32 bits.

First, I never guess this.  It's wrong of course (but the real reason
may be that I have extensive experience on 16 bit systems:-).

|>  I wrote for known or UNKNOWN reasons. You never know what will appen
|>  when you change a detail somewhere in a program :-(

If you don't know what will happen when you change a detail, you have
very poorly written programs.  As long as the
function/class/etc. maintains its contract, nothing should happen.  In
my experience, it rarely does.

More to the point, for this particular question: even without paying
attention, most code (at least on 32 bit machines) is written "as if"
int's had infinite range.  The only change that increasing the range
will make is to increase the robustness of the program.  (For example:
most Unix kernals suppose long has an infinite range.  Those with 32 bit
longs are in for a dreadful surprise in the year 2038.  Those with 64
bit longs are more robust; the universe will probably have ceased to
exist before they stumble on the problem.)

|>  But anyway programs that break when data types become larger will
|>  probably break one day for annother reason.

That's for sure.

Note that there is one definite exception: the format of external data.
Thus, for example, my hash function uses the modulo 2^n implicit in
unsigned arithmetic; changing n (the number of bits) changes the
function.  If I use this function to hash for a disk file, the file
cannot be read from an implementation with a different number of bits.
(Although all of the current uses are for internal hashing, I recently
changed my hash function to ensure modulo 2^32 in every case.  The
problem with reusable code is that people reuse it in ways you didn't
think of:-).)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:

>I'll bet that you are concerned about the MINIMUM size.  The above
>program is only defined because the standard guarantees INT_MAX >=
>32755, and would fail badly if int's could only have 8 bits.

I believe you mean 32767, no?

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage wrote:
>The C and C++ standards already require a "wide character" type called
>wchar_t. The size and encoding are up to the implementation, but
>Unicode is a popular choice.

To quote from ANSI/ISO 9899-1990 (Standard C):

    7.1.6  Common definitions <stddef.h>

    The following types and macros are defined in the standard header
    <stddef.h>.  ...

        wchar_t

    which is an integral type whose range of values can represent distinct
    code for all members of the largest extended character set specified
    among the supported locales; the null character shall have the code value
    zero and each member of the basic character set defined in 5.2.1 shall
    have a code value equal to its value when used as the lone character in
    an integer constant.

To quote from the Unicode standard revision 2.0:

    5.1  ANSI/ISO C wchar_t

    With the wchar_t wide character type, ANSI/ISO C provides for inclusion
    of fixed width, wide characters.  ...

    The width of wchar_t is compiler-specific and can be as little as 8 bits.
    Because of this, programs that need to be portable across and C or C++
    compiler should not use wchar_t for storing Unicode text.  The wchar_t
    type is intended for storing compiler-defined wide characters, which can
    be Unicode characters on some compilers.  However, programmers can use
    a macro or typedef (for example, UNICHAR) which can be compiled as
    unsigned short or wchar_t depending on the target compielr and platform.

So the Unicode Consortium recommends avoiding wchar_t for Unicode character
data.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David R Tribble <david.tribble@central.beasys.com> writes:

|>  Steve Clamage wrote:
|>  >The C and C++ standards already require a "wide character" type called
|>  >wchar_t. The size and encoding are up to the implementation, but
|>  >Unicode is a popular choice.
|>
|>  To quote from ANSI/ISO 9899-1990 (Standard C):
|>
|>      7.1.6  Common definitions <stddef.h>
|>
|>      The following types and macros are defined in the standard header
|>      <stddef.h>.  ...
|>
|>          wchar_t
|>
|>      which is an integral type whose range of values can represent distinct
|>      code for all members of the largest extended character set specified
|>      among the supported locales; the null character shall have the code value
|>      zero and each member of the basic character set defined in 5.2.1 shall
|>      have a code value equal to its value when used as the lone character in
|>      an integer constant.
|>
|>  To quote from the Unicode standard revision 2.0:
|>
|>      5.1  ANSI/ISO C wchar_t
|>
|>      With the wchar_t wide character type, ANSI/ISO C provides for inclusion
|>      of fixed width, wide characters.  ...
|>
|>      The width of wchar_t is compiler-specific and can be as little as 8 bits.
|>      Because of this, programs that need to be portable across and C or C++
|>      compiler should not use wchar_t for storing Unicode text.  The wchar_t
|>      type is intended for storing compiler-defined wide characters, which can
|>      be Unicode characters on some compilers.  However, programmers can use
|>      a macro or typedef (for example, UNICHAR) which can be compiled as
|>      unsigned short or wchar_t depending on the target compielr and platform.
|>
|>  So the Unicode Consortium recommends avoiding wchar_t for Unicode character
|>  data.

The key here is in the expression "largest extended charater set
specified among the supported locales" in the C standard.  The only
locale a compiler is required to support is "C", and 7 bit ASCII is
fully sufficient here.

What this means in practice is that either your implementation supports
a locale which uses Unicode, and you can (and should) use wchar_t, or
your implementation doesn't, in which case, not only can you not use
wchar_t, but you cannot use any of the library routines, either.

When implementers ANSI-ized their compilers, they did it as simply as
possible to begin with, and most of the initial ANSI C compilers only
supported locale "C".  Recently, I've noticed, most compilers seem to
support some western European locales; it's worth mentioning that ANSI
made this particularly easy for the implementor (but not the programmer)
by NOT requiring that all characters in the extended character set be
non-negative.  I believe that there are also a number of complers which
support a Japanese locale of some sort, although generally not with
Unicode.

The result of this is that when using Unicode, you are on your own; you
have no real support from the implementation.  And the Unicode
Consortium's recommendation holds: use unsigned short (although most
implementations define wchar_t to be at least a short, even if they
don't support Unicode directly in a locale).

This is, at least, my interpretation of the situation in C, and the
current situation in C++.  From statements by people involved in the
standardization of these parts of the library (Bill Plauger, Nathan
Myers), I judge that it is the *intent* of the C++ standards committee
that, where reasonably, standard C++ do somewhat better.  For various
reasons, I don't think that the C++ standard could or should impose
Unicode, or even support for a real wchar_t locale.  I do wonder,
however, if there couldn't be some sort of non-normative appendix with a
recommended practice (i.e.: define what a Unicode locale should look
like, for those implementations that want to support Unicode).

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Michael Hudson <sorry.no.email@nowhere.com> writes:

|>  Valentin Bonnard wrote:
|>  > Anyway I'd like to know how many programs do not count on the exact
|>  > size of integers types (for known or unknown reasons).
|>  >
|>  > Only real programs count (no Hello world nor test programs).
|>
|>  I don't know if this counts, but when I write:
|>
|>  for (int i = 0; i < 1256; i++) {
|>      ... do some stuff ...
|>  }
|>
|>  I don't care what size i is, but I'd appreciate it if the operations on
|>  i (assignment, compare and increment) all happened as quickly as is
|>  possible.

I'll bet that you are concerned about the MINIMUM size.  The above
program is only defined because the standard guarantees INT_MAX >=
32755, and would fail badly if int's could only have 8 bits.

With regards to the original question, however: it is certainly true
that you don't care about the EXACT size, only the minium size.  (And I
suspect that Valentin actually slipped up, and didn't mean to say
exact.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <rf5wwt87caa.fsf@vx.cit.alcatel.fr>, James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
|> I rather suspect that programs counting on the exact size of integer
|> types are rather the exception.  In most cases, as long as there is no
|> overflow, there is no problem.  The only exception I can think of off
|> hand is calculating hash-codes (which usually do an implicit mod 2^N,
|> where N is the number of bits).

Anybody who *relies* on overflow for this is asking for trouble.
Portability already requires that one use either a masking or the
modulus operator to do this.

--
swf@elsegundoca.ncr.com  sarima@ix.netcom.com

The peace of God be with you.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze wrote:
>
> Valentin Bonnard <bonnardv@pratique.fr> writes:
>
> |>  char should absolutly stay 8 bits (or the minimum addressable unit
> |>  of memory).
> |>
> |>  Others type could stay where they are if a new type (long long) was
> |>  added.
> |>
> |>  char  short    long    long long
> |>   8     16       32         64
> |>          ^        ^         ^
> |>          ------- int --------
>
> Correctly, this table should read:
>
>     char >= 8
>     short >= 16
>     int >= 16
>     long >= 32
>     long long >= 64

What does 'Correctly' mean ?

How the standard should define them or how the implementation choose
them ? I was talking about implementation: while 64 bits char could be
a conforming implementation, it would be a bad idea on a byte (= 8
bits) addressable machine.

> |>  The problem I see with long long is: how to order the integers types:
> |>
> |>  char |> short -> int -> long
> |>
> |>  One could add long long at the end:
> |>
> |>  char |> short -> int -> long -> long long
> |>
> |>  But int may need to be long long if it's faster than long:
> |>
> |>  char |> short -> long -> int -> long long
>
> If int needs to be long long, then long should also be long long.

Why ? long could be 32 bits (for compatibillity, I think you must have
a 32 bits type)

> An
> implementation which has 8 bit char's and all other types 64 bits is
> certainly conforming.

Yep

> |>  But you break:
> |>  - current overloading
> |>  - current assumption sizeof (int) <= sizeof (long)
> |>
> |>  Also what about char_t, short_t, int_t, long_t, long_long_t ?
           ^^^^^^^^^^
> |>  (The same as float_t, double_t: the fastest type with this precision.)
>
> What are char_t, et al.?  I've never heard of them.

'what about': does anyone want ot have them ?
              they work as ..... float_t ......

> |>  Anyway I'd like to know how many programs do not count on the exact
> |>  size of integers types (for known or unknown reasons).
>
> I rather suspect that programs counting on the exact size of integer
> types are rather the exception.  In most cases, as long as there is no
> overflow, there is no problem.  The only exception I can think of off
> hand is calculating hash-codes (which usually do an implicit mod 2^N,
> where N is the number of bits).

Are you optimistic or did you moved larges pieces of software to
differents machines (written by differents programmers - not you) ?

--
Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Damian Conway wrote:
> Well, an obvious solution is to (conceptually) make int a templated
> type with an integer parameter which has a default value suitable for
> each machine (within the constraints imposed by the standard). Hence:
>
>         int a;        // WHATEVER THE COMPILER CHOOSES FOR THIS ARCHITECTURE
>         int<16> b;    // AT LEAST 16 BITS
>         int<64> c;    // AT LEAST 64 BITS
>         int<27> d;    // AT LEAST 27 BITS, PROBABLY 32 OR 64.
>         int<1000> z;  // _BIG_ ints :-)
>                       // ETC.

And don't pass an int by pointer/reference to a function (if you
didn't wrote it yourseft) again.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard wrote:
>
> Damian Conway wrote:
> > Well, an obvious solution is to (conceptually) make int a templated
> > type with an integer parameter which has a default value suitable for
> > each machine (within the constraints imposed by the standard). Hence:
> >
> >         int a;        // WHATEVER THE COMPILER CHOOSES FOR THIS ARCHITECTURE
> >         int<16> b;    // AT LEAST 16 BITS
> >         int<64> c;    // AT LEAST 64 BITS
> >         int<27> d;    // AT LEAST 27 BITS, PROBABLY 32 OR 64.
> >         int<1000> z;  // _BIG_ ints :-)
> >                       // ETC.
>
> And don't pass an int by pointer/reference to a function (if you
> didn't wrote it yourseft) again.
>

or the int is of the default type...
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

swf@elsegundoca.ncr.com (Stan Friesen) writes:

|>  In article <rf5wwt87caa.fsf@vx.cit.alcatel.fr>, James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
|>  |> I rather suspect that programs counting on the exact size of integer
|>  |> types are rather the exception.  In most cases, as long as there is no
|>  |> overflow, there is no problem.  The only exception I can think of off
|>  |> hand is calculating hash-codes (which usually do an implicit mod 2^N,
|>  |> where N is the number of bits).
|>
|>  Anybody who *relies* on overflow for this is asking for trouble.
|>  Portability already requires that one use either a masking or the
|>  modulus operator to do this.

It depends.  With regards to using overflow to implement modulo 2^32 (or
whatever), you are certainly correct.  For an internal linear congruent
hash code, however, you really aren't that concerned with the modulo
used on each individual operation, as long as it has no common factors
with your multiplier.

There are several important points to take into consideration, of course:

1. The standard only guarantees modulo arithmetic for unsigned integral
types.  Relying on modulo arithmetic (or even anything sensible) for
signed values is definitly asking for trouble.

2. You are perfectly correct in pointing out that the actual modulo used
is NOT defined by the standard (although I think that an implementation
in which it is not a power of 2 will fail to conform somewhere else).
Thus, you CANNOT use this technique for hashing disk based data, or
anything else where the hash code may potentially be calculated by
several different machines.

All things considered, however, I think I will add the additional
masking to my hash routine.  Given that the routine exists, some day
someone will use it for disk hashing, regardless of the warnings I write
in the documentation.

(For those who are not too clear concerning the problem...  I normally
use the following function in calculating hashcodes:

    inline unsigned long
    hashElement( unsigned long currentHash , unsigned long element )
    {
     return 2047 * currentHash + element ;
    }

Note that there is an implicit modulo 2^N due to overflow in this
routine.  The actual hash value returned depends on the number of bits
in an unsigned long.  A corrected version would be:

    inline unsigned long
    hashElement( unsigned long currentHash , unsigned long element )
    {
    #if ULONG_MAX == 4294967295
     static unsigned long const hashMask = ~ 0L ;
    #else
     static unsigned long const hashMask = ~ (~0 << 32) ;
    #endif
     return (2047 * currentHash + element) & hashMask ;
    }

The conditional compilation is necessary, since the operation "<< 32"
results in undefined behavior if an unsigned long only contains 32
bits.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  James Kanze wrote:
|>  >
|>  > Valentin Bonnard <bonnardv@pratique.fr> writes:
|>  >
|>  > |>  char should absolutly stay 8 bits (or the minimum addressable unit
|>  > |>  of memory).
|>  > |>
|>  > |>  Others type could stay where they are if a new type (long long) was
|>  > |>  added.
|>  > |>
|>  > |>  char  short    long    long long
|>  > |>   8     16       32         64
|>  > |>          ^        ^         ^
|>  > |>          ------- int --------
|>  >
|>  > Correctly, this table should read:
|>  >
|>  >     char >= 8
|>  >     short >= 16
|>  >     int >= 16
|>  >     long >= 32
|>  >     long long >= 64
|>
|>  What does 'Correctly' mean ?

According to the standard.

|>  How the standard should define them or how the implementation choose
|>  them ? I was talking about implementation: while 64 bits char could be
|>  a conforming implementation, it would be a bad idea on a byte (= 8
|>  bits) addressable machine.
|>
|>  > |>  The problem I see with long long is: how to order the integers
|>  > |>  types:
|>  > |>
|>  > |>  char |> short -> int -> long
|>  > |>
|>  > |>  One could add long long at the end:
|>  > |>
|>  > |>  char |> short -> int -> long -> long long
|>  > |>
|>  > |>  But int may need to be long long if it's faster than long:
|>  > |>
|>  > |>  char |> short -> long -> int -> long long
|>  >
|>  > If int needs to be long long, then long should also be long long.
|>
|>  Why ?

Because the standard says so.  Long must be at least as big as an int.

|>  long could be 32 bits (for compatibillity, I think you must have
|>  a 32 bits type)

Why?  There are currently implementations which don't have a 32 bit
type.  While I can see the need of a very small integral type (char),
and maybe the need of a moderately small one (short), beyond that, I'm
less convinced.  Taken to its extreme, you need an integer for every
number of bits that would be accessible on your machine.  Since this
varies from machine to machine, you end up with what one person
suggested: a templated integer.

In this case, you might as well go all the way, and create several types
of templated integer: "Integer< n >" (the fastest type of at least n
bits), "PackedInteger< n >" (the smallest type of at least n bits) and
"ExactInteger< n >" (exactly n bits, which is likely to be significantly
slower than the other two if n is not equal to a word size on the target
hardware).

|>  > An
|>  > implementation which has 8 bit char's and all other types 64 bits is
|>  > certainly conforming.
|>
|>  Yep
|>
|>  > |>  But you break:
|>  > |>  - current overloading
|>  > |>  - current assumption sizeof (int) <= sizeof (long)
|>  > |>
|>  > |>  Also what about char_t, short_t, int_t, long_t, long_long_t ?
|>             ^^^^^^^^^^
|>  > |>  (The same as float_t, double_t: the fastest type with this
|>  > |>  precision.)
|>  >
|>  > What are char_t, et al.?  I've never heard of them.
|>
|>  'what about': does anyone want ot have them ?
|>                they work as ..... float_t ......

I've never heard of them.  What are they supposed to be?

|>  > |>  Anyway I'd like to know how many programs do not count on the exact
|>  > |>  size of integers types (for known or unknown reasons).
|>  >
|>  > I rather suspect that programs counting on the exact size of integer
|>  > types are rather the exception.  In most cases, as long as there is no
|>  > overflow, there is no problem.  The only exception I can think of off
|>  > hand is calculating hash-codes (which usually do an implicit mod 2^N,
|>  > where N is the number of bits).
|>
|>  Are you optimistic or did you moved larges pieces of software to
|>  differents machines (written by differents programmers - not you) ?

Quite a lot.  In practice, the only time I had a problem with the size
of an integer was when moving from a 32 bit machine to a 16 bit one.
And the problem was, in fact, linked to an error in the code, which just
happened to work if sizeof( int ) == sizeof( long ).  At no time did I
encounter any code which depended upon long being exactly 32 bits, for
example.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze wrote:
>
> Michael Hudson <sorry.no.email@nowhere.com> writes:
>
> |>  Valentin Bonnard wrote:
> |>  > Anyway I'd like to know how many programs do not count on the exact
> |>  > size of integers types (for known or unknown reasons).
> |>  >
> |>  > Only real programs count (no Hello world nor test programs).
> |>
> |>  I don't know if this counts, but when I write:
> |>
> |>  for (int i = 0; i < 1256; i++) {
> |>      ... do some stuff ...
> |>  }

What's that ? That's not a complete program, not even a function (and
certainly not a non-trivial program).

And yes it doesn't depend on the size of int, I have never said the
contrary (that such functions didn't exist).

> |>  I don't care what size i is, but I'd appreciate it if the operations on
> |>  i (assignment, compare and increment) all happened as quickly as is
> |>  possible.
>
> I'll bet that you are concerned about the MINIMUM size.  The above
> program is only defined because the standard guarantees INT_MAX >=
> 32755, and would fail badly if int's could only have 8 bits.
>
> With regards to the original question, however: it is certainly true
> that you don't care about the EXACT size, only the minium size.  (And I
> suspect that Valentin actually slipped up, and didn't mean to say
> exact.)

No, no I really mean exact even if most of the time the program just
guess the minimum maximum size of an int is 32 bits.

I wrote for known or UNKNOWN reasons. You never know what will appen
when you change a detail somewhere in a program :-(

But anyway programs that break when data types become larger will
probably break one day for annother reason.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

hpa@transmeta.com (H. Peter Anvin) writes:

>It seems to me that the standards folks should stop pretending to be
>system-independent and bite the bullet, and define a syntax like
>"int:32" to allocate a 32-bit integer; probably defining the semantics
>as "a[n un]signed integer able to accurately represent all values
>between -2^(N-1) and 2^(N-1)-1 [0 and 2^N-1]" as a nod of acceptance
>to the 36-bit (or ternary, or decimal...) machines that still are out
>there; that definition does not prevent a machine with 36-bit words to
>allocate a full 36-bit unit for an "int:32".

The ANSI/ISO C committee considered a proposal such as this for C9X,
but I think they decided that it would complicate the language too much.
Instead, they are adding a new <inttypes.h> header, which provides
macros with similar functionality.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

hpa@transmeta.com (H. Peter Anvin) writes:

>It seems to me that the standards folks should stop pretending to be
>system-independent and bite the bullet, and define a syntax like
>"int:32" to allocate a 32-bit integer; probably defining the semantics
>as "a[n un]signed integer able to accurately represent all values
>between -2^(N-1) and 2^(N-1)-1 [0 and 2^N-1]" as a nod of acceptance
>to the 36-bit (or ternary, or decimal...) machines that still are out
>there; that definition does not prevent a machine with 36-bit words to
>allocate a full 36-bit unit for an "int:32".

Well, an obvious solution is to (conceptually) make int a templated type
with an integer parameter which has a default value suitable for each machine
(within the constraints imposed by the standard). Hence:

 int a;  // WHATEVER THE COMPILER CHOOSES FOR THIS ARCHITECTURE
 int<16> b; // AT LEAST 16 BITS
 int<64> c; // AT LEAST 64 BITS
 int<27> d; // AT LEAST 27 BITS, PROBABLY 32 OR 64.
 int<1000> z; // _BIG_ ints :-)
   // ETC.

Damian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  who: Damian Conway                 email: damian@cs.monash.edu.au
where: Computer Science Dept.          web: http://www.cs.monash.edu.au/~damian
       Monash University             phone: +61-3-9905-5184
       Clayton 3168                    fax: +61-3-9905-5146
       AUSTRALIA                     quote: "A pessimist is never disappointed."


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <5bn2c5$qao@mulga.cs.mu.OZ.AU>, fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
|> hpa@transmeta.com (H. Peter Anvin) writes:
|>
|> >It seems to me that the standards folks should stop pretending to be
|> >system-independent and bite the bullet, and define a syntax like
|> >"int:32" to allocate a 32-bit integer; probably defining the semantics
|> >as "a[n un]signed integer able to accurately represent all values
|> >between -2^(N-1) and 2^(N-1)-1 [0 and 2^N-1]" as a nod of acceptance
|> >to the 36-bit (or ternary, or decimal...) machines that still are out
|> >there; that definition does not prevent a machine with 36-bit words to
|> >allocate a full 36-bit unit for an "int:32".
|>
|> The ANSI/ISO C committee considered a proposal such as this for C9X,
|> but I think they decided that it would complicate the language too much.
|> Instead, they are adding a new <inttypes.h> header, which provides
|> macros with similar functionality.

Bizarre.  Truly bizarre.

This is trivial to do for yourself, by:

#include <limits.h>
#if UINT_MAX < 4294967295U
    #define unsigned long uint_32
#else
    #define unsigned int uint_32
#fi

Note the use of UINT_MAX to protect against 1's complement and signed
magnitude integers with the spare value reserved by hardware :-)

The problems with this are (a) printf/scanf (as has been discussed to
death), (b) a few other library calls, (c) conversion to or from half
defined integer types (like size_t or even uid_t) and (d) when handling
external 32-bit data structures.  Plus possibly some I have forgotten.

If <inttypes.h> deals with problems (a), (b) and (c), then it will be
very useful.  Otherwise it will be a waste of time.

For (d), you need an exact 32-bit data type.  In practice, sane people
unpick the data as bytes to avoid endianness problems.  But that merely
reduces the problem to needing a real 8-bit byte.  And (for certain
serial communications code) a byte with its bits in a known order.

[ Obscenities about <float.h> and its Intel brain damage removed on
the grounds of good order and public decency. ]


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Richard Krehbiel <rich@kastle.com> writes:

>Colin Rafferty <craffert@spssunp.spspme.ml.com> writes:

>> What this means for all of us is twofold:
>>
>> 1. We can always count on integer arithmetic being fast.
>>
>> 2. We cannot count on BITS(char) == 8, nor sizeof(int) == 4, and
>>    especially not that BITS(int) == 32.
>>
>> In other words, use <values>, and program in the future tense.

>Those of us writing network software can therefore count on remaining
>outside of standard C looking in.  Sigh.

I think a more accurate statement is that you cannot count on
general-purpose languages like C and C++ having special features
that apply only to restricted programming domains.

Java has mandated data sizes. If you want to run Java on a machine
that has 9-bit bytes, you are going to have severe performance
penalties. If you have pre-defined 8 and 16-bit data sizes, it
might make YOUR network programming easier, but won't be any
help at all to someone who needs to work with that 9-bit machine.

If you have to interface to externally-imposed data formats, C
and C++ provide the mechanisms (structs, bit-fields, etc) to
let you do so. Details (word size, byte order, bit order) vary
from system to system (even for the same CPU), so you will always
have pieces of code that are system-specific. You can usually write
a tiny amount of interface code that is specific to the system,
and the vast majority of the code works unchanged with any system.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Marcelo Cantos <marcelo@mds.rmit.edu.au> wrote in article
<32DDD024.CEE@mds.rmit.edu.au>...
> Something I'm curious about:
>
> Currently, compilers have a very convenient set of integer
> sizes:
>     char       8 bits
>     short      16 bits
>     int/long   32 bits
>     long       64 bits (where available)
>
> What's going to happen when 128 and 256 bits come along,
> 'long long', as in gcc? Or int128, int256? Or are the
> compiler vendors just going to start skipping sizes to
> maintain ANSI/ISO conformance?
>
> Maybe chars will become 16 bits!  :-O  !!
>
> IMHO: char, short and int should stop where they are (with
> int possibly going as far as 64 bits). And long should be
> the machine's word size. Any opinions? Does anyone even
> care?

IMHO: ANSI should define _MINIMUM_ widths for short, int and long. For
example:

 short  minimal 16 bits
 int  minimal 16 bits
 long  minimal 32 bits

or even 16/32/64. It should be free to the implementers to use wider
short/int/longs, but not smaller. So a 24-bits DSP could implement short
and int as 24 bits, and a long as 48 bits using a special run-time library.

As it is now, it is very hard to choose what you need, in a portable
fashion. You never know what type is large enough (except by using the
preprocessor to do typedefs depending on the implementation)

And for the character issue:

To avoid porting problems, one could make a new type, e.g. 'unichar', that
can hold a Unicode character. To support Unicode constant strings, the
single quote character could be redefined to define a Unicode constant
string, with constant casts to unichars or normal chars.

Frank.

--------------------------------------------------------------------
Frank van Leeuwen                                       fvl@iaehv.nl
"Any advertisments mailed to me can and will be used against you..."
--------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <5bn2c5$qao@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>hpa@transmeta.com (H. Peter Anvin) writes:
>>It seems to me that the standards folks should stop pretending to be
>>system-independent and bite the bullet, and define a syntax like
>>"int:32" to allocate a 32-bit integer; ...
>The ANSI/ISO C committee considered a proposal such as this for C9X,
>but I think they decided that it would complicate the language too much.
>Instead, they are adding a new <inttypes.h> header, which provides
>macros with similar functionality.

That's oversimplified.  What actually happened was that there were
competing proposals to solve the perceived "64-bit integer problem",
and some of us noted that they amounted to adding in one more kludge
just for this conceptually tiny extension of functionality, in a way
that was not able to solve more general issues involving sizes of
integral types (such as supporting 128-bit integers when they start
to be an issue in the foreseeable future).  The relatively simple
proposal int:32 was not directly voted on, so far as I can recall.
However, in preparing a proposal along those lines, Frank Farance
realized that there were other improvements that could be made,
for example the ability to specify whether what was wanted by the
programmer was "at least 32 bits", "exactly 32 bits", "fastest
type having at least 32 bits", alignment, packing, endianness, etc.
So his proposal covered the wider picture and, naturally enough in
retrospect, seems to have scared some members who might have
supported a simple int:32 solution.  Frank, seeing that his initial
proposal was encountering opposition, solicited input on how to
rework it to make it more acceptable, and presented a revised
proposal that was reduced in scope and met several of the expressed
objections.  However, it still did not attain a consensus, and
the C committee(s) voted to not entertain such a proposal any
further.  I am not sure that a simple int:32 proposal has been
prohibited, but in any event if it is not introduced by the end
of the imminent Kona meeting (14 Feb. 1997) then there is little
chance it will make it into C9x.

Meanwhile, two of the original proposals aimed at solving just the
"64-bit integer problem" were merged into one, shepherded by John
Kwan.  The outcome of that path was adoption of <inttypes.h> for
C9x.  To further complicate matters, at the Copenhagen meeting
"long long" was added in order to have some Standard type available
to be used by the <inttypes.h> macros.  (The issue was that the
semantics of a non-Standard type would be unspecified, which is
definitely a Bad Thing that gets in the way of reliable use of
<inttypes.h>.)  My opinion is that if "long long" (or some other
way to declare a 64-bit type) is Standardized, most of the
motivation for <inttypes.h> evaporates.

I would much rather see "int:64" than "long long".

The main outstanding technical objection to something like int:32
is that it would complicate the language's type system.  While
this was true of some of the earlier proposals, I'm not convinced
that it has to add complication if it is made to mean just that
the representation must provide at least that many bits of
significance (including sign bit as appropriate), but that the
actual significance is that of the "whole word" chosen to hold
the type by the implementation.  (Loosely speaking.  What I mean
is that "int:10" might be mapped into a 32-bit representation, e.g.
the one used for "long", and we could specify that it would have
exactly the same combinatorial/representational properties as if
it had been declared "long" to start with.)  There are issues
involving C's decidedly warty type promotion rules, but I would
argue that these need to be fixed anyway (the way "long long"
enters into the promotion rules is horrible), and the right way
to fix them would be to make all lengths of integer combine in a
consistent manner.

The complications previously alluded to arise as a natural issue
once one has what appears to be a parameterized precision for
integer representation:
 <int:10> + <int:10> --> <int:11> ??
While I am a big fan of parameterized integers (especially to
support packed representation for int:1), I don't think there is
any chance the C committee(s) will buy into anything like this.
That is why if we are to consider int:32 it ought to map into a
potentially longer representation and have the properties of
what it is mapped onto.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Marcelo Cantos <marcelo@mds.rmit.edu.au> wrote:

>Something I'm curious about:
>
>Currently, compilers have a very convenient set of integer
>sizes:
>    char       8 bits
>    short      16 bits
>    int/long   32 bits
>    long       64 bits (where available)
>
>What's going to happen when 128 and 256 bits come along,
>'long long', as in gcc? Or int128, int256? Or are the
>compiler vendors just going to start skipping sizes to
>maintain ANSI/ISO conformance?
>
>Maybe chars will become 16 bits!  :-O  !!

One never knows. It's already happened in Java.



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <5bo4qs$djf@lyra.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren)
writes:

>#if UINT_MAX < 4294967295U
>    #define unsigned long uint_32
>#else
>    #define unsigned int uint_32
>#fi

I catch myself doing this kind of thing.  I suspect you've confused Borne
shell commands (if .. fi) and C preprocessor statements (#if .. #endif)

--
Roger Wells (speaking only for myself)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <5boke5$r82@mpscomm.usin.com> rwells@usin.com (Roger Wells) writes:
>In article <5bo4qs$djf@lyra.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren)

>writes:
>>#if UINT_MAX < 4294967295U
>>    #define unsigned long uint_32
>>#else
>>    #define unsigned int uint_32
>>#fi
>I catch myself doing this kind of thing.  I suspect you've confused Borne
>shell commands (if .. fi) and C preprocessor statements (#if .. #endif)

Well, so long as we're commenting on it anyway...  The whole thing is wrong.
Another immediately obvious problem is that he's defining just "unsigned".
Presumably these were meant to be typedefs.  In any event, <inttypes.h>
was subjected to considerable discussion and refinement by people who
were aware of every valid point Maclaren was trying to make, plus some
points he did not mention.  Whatever deficiencies it has are not due to
ignorance.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 714697c2@fvl.iaehv.nl, "Frank van Leeuwen" <fvl@iaehv.nl> writes:
>
>IMHO: ANSI should define _MINIMUM_ widths for short, int and long. For
>example:
>
> short  minimal 16 bits
> int  minimal 16 bits
> long  minimal 32 bits

The C and C++ standards do define minimum widths, and those are in
fact the sizes. (The standards specify the numeric ranges, but since
the values are required to be represented in binary, the effect
is the same.)

>It should be free to the implementers to use wider
>short/int/longs, but not smaller.

That is in fact the case.

> So a 24-bits DSP could implement short
>and int as 24 bits, and a long as 48 bits using a special run-time library.

Yes, that is allowed.

>As it is now, it is very hard to choose what you need, in a portable
>fashion.

Without using bitfields in structs, there is no way to specify an
exact bit size, but you can always get the minimum sizes noted above.
That is, an int must have at least 16 bits; a long must have at least
32 bits.

>And for the character issue:
>
>To avoid porting problems, one could make a new type, e.g. 'unichar', that
>can hold a Unicode character.

The C and C++ standards already require a "wide character" type called
wchar_t. The size and encoding are up to the implementation, but
Unicode is a popular choice.

> To support Unicode constant strings, the
>single quote character could be redefined to define a Unicode constant
>string, with constant casts to unichars or normal chars.

To create a wide character or string you use a prefix L:
 L'a'     // wide-character version of 'a'
 L"hello" // array of 5 wide characters plus a null terminator

These features have been in the C standard since before 1989 and are
included in C++.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Frank van Leeuwen" <fvl@iaehv.nl> writes:

>IMHO: ANSI should define _MINIMUM_ widths for short, int and long. For
>example:
>
> short  minimal 16 bits
> int  minimal 16 bits
> long  minimal 32 bits

The ANSI/ISO C standard and the draft C++ standard already define
minimum ranges for char, short, int, and long.  The minimum ranges
defined by C/C++ imply the minimum widths you suggest above.

>As it is now, it is very hard to choose what you need, in a portable
>fashion. You never know what type is large enough (except by using the
>preprocessor to do typedefs depending on the implementation)

Funny that you should say it is very hard, while in another post
Nick Maclaren describes it as "trivial" ;-)
The truth is probably somewhere in between.
But in any case, it will be trivial in C9X using <inttypes.h>.

>And for the character issue:
>
>To avoid porting problems, one could make a new type, e.g. 'unichar', that
>can hold a Unicode character. To support Unicode constant strings, the
>single quote character could be redefined to define a Unicode constant
>string, with constant casts to unichars or normal chars.

C already supports a "wide character" type `wchar_t'.
(Personally, I think it should have been spelt `long char'...)
You can write wide character constants and wide character string
literals by prefixing them with `L':

 wchar_t wide_char = L'c';
 wchar_t *wide_string = L"c";

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Frank van Leeuwen wrote:
>
> Marcelo Cantos <marcelo@mds.rmit.edu.au> wrote in article
> <32DDD024.CEE@mds.rmit.edu.au>...
> > Something I'm curious about:
> >
> > Currently, compilers have a very convenient set of integer
> > sizes:
> >     char       8 bits
> >     short      16 bits
> >     int/long   32 bits
> >     long       64 bits (where available)
> >
> > What's going to happen when 128 and 256 bits come along,
> > 'long long', as in gcc? Or int128, int256? Or are the
> > compiler vendors just going to start skipping sizes to
> > maintain ANSI/ISO conformance?
> >
> > Maybe chars will become 16 bits!  :-O  !!
> >
> > IMHO: char, short and int should stop where they are (with
> > int possibly going as far as 64 bits). And long should be
> > the machine's word size. Any opinions? Does anyone even
> > care?

I think this is right, and yes, everybody care (see how this thread is
growing) ;-)

> IMHO: ANSI should define _MINIMUM_ widths for short, int and long. For
> example:
>
>         short           minimal 16 bits
>         int             minimal 16 bits
>         long            minimal 32 bits

It's exactly the case. Add:

          char            minimal  8 bits

> or even 16/32/64. It should be free to the implementers to use wider
> short/int/longs, but not smaller. So a 24-bits DSP could implement short
> and int as 24 bits, and a long as 48 bits using a special run-time library.
>
> As it is now, it is very hard to choose what you need, in a portable
> fashion. You never know what type is large enough (except by using the
> preprocessor to do typedefs depending on the implementation)
>
> And for the character issue:
>
> To avoid porting problems, one could make a new type, e.g. 'unichar', that
> can hold a Unicode character. To support Unicode constant strings, the
> single quote character could be redefined to define a Unicode constant
> string, with constant casts to unichars or normal chars.

Why aren't you happy with wchar_t and L"toto" ?

IMO:

char should absolutly stay 8 bits (or the minimum addressable unit
of memory).

Others type could stay where they are if a new type (long long) was
added.

char  short    long    long long
 8     16       32         64
        ^        ^         ^
        ------- int --------

The problem I see with long long is: how to order the integers types:

char |> short -> int -> long

One could add long long at the end:

char |> short -> int -> long -> long long

But int may need to be long long if it's faster than long:

char |> short -> long -> int -> long long

But you break:
- current overloading
- current assumption sizeof (int) <= sizeof (long)

Also what about char_t, short_t, int_t, long_t, long_long_t ?
(The same as float_t, double_t: the fastest type with this precision.)

             wn reasons).

Only real programs count (no Hello world nor test programs).

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

[At the request of the author, this article was cancelled and reposted
to correct an error in the original which caused the second-last paragraph
to be mangled on some news systems.  Apologies if you see it twice.  -mod.]

Frank van Leeuwen wrote:
>
> Marcelo Cantos <marcelo@mds.rmit.edu.au> wrote in article
> <32DDD024.CEE@mds.rmit.edu.au>...
> > Something I'm curious about:
> >
> > Currently, compilers have a very convenient set of integer
> > sizes:
> >     char       8 bits
> >     short      16 bits
> >     int/long   32 bits
> >     long       64 bits (where available)
> >
> > What's going to happen when 128 and 256 bits come along,
> > 'long long', as in gcc? Or int128, int256? Or are the
> > compiler vendors just going to start skipping sizes to
> > maintain ANSI/ISO conformance?
> >
> > Maybe chars will become 16 bits!  :-O  !!
> >
> > IMHO: char, short and int should stop where they are (with
> > int possibly going as far as 64 bits). And long should be
> > the machine's word size. Any opinions? Does anyone even
> > care?

I think this is right, and yes, everybody care (see how this thread is
growing) ;-)

> IMHO: ANSI should define _MINIMUM_ widths for short, int and long. For
> example:
>
>         short           minimal 16 bits
>         int             minimal 16 bits
>         long            minimal 32 bits

It's exactly the case. Add:

          char            minimal  8 bits

> or even 16/32/64. It should be free to the implementers to use wider
> short/int/longs, but not smaller. So a 24-bits DSP could implement short
> and int as 24 bits, and a long as 48 bits using a special run-time library.
>
> As it is now, it is very hard to choose what you need, in a portable
> fashion. You never know what type is large enough (except by using the
> preprocessor to do typedefs depending on the implementation)
>
> And for the character issue:
>
> To avoid porting problems, one could make a new type, e.g. 'unichar', that
> can hold a Unicode character. To support Unicode constant strings, the
> single quote character could be redefined to define a Unicode constant
> string, with constant casts to unichars or normal chars.

Why aren't you happy with wchar_t and L"toto" ?

IMO:

char should absolutly stay 8 bits (or the minimum addressable unit
of memory).

Others type could stay where they are if a new type (long long) was
added.

char  short    long    long long
 8     16       32         64
        ^        ^         ^
        ------- int --------

The problem I see with long long is: how to order the integers types:

char |> short -> int -> long

One could add long long at the end:

char |> short -> int -> long -> long long

But int may need to be long long if it's faster than long:

char |> short -> long -> int -> long long

But you break:
- current overloading
- current assumption sizeof (int) <= sizeof (long)

Also what about char_t, short_t, int_t, long_t, long_long_t ?
(The same as float_t, double_t: the fastest type with this precision.)

Anyway I'd like to know how many programs do not count on the exact
size of integers types (for known or unknown reasons).

Only real programs count (no Hello world nor test programs).

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <9701172338.aa27862@SMOKEY.ARL.MIL>,
Doug Gwyn  <gwyn@arl.mil> wrote:
>
>Well, so long as we're commenting on it anyway...  The whole thing is wrong.
>Another immediately obvious problem is that he's defining just "unsigned".
>Presumably these were meant to be typedefs.  In any event, <inttypes.h>
>was subjected to considerable discussion and refinement by people who
>were aware of every valid point Maclaren was trying to make, plus some
>points he did not mention.  Whatever deficiencies it has are not due to
>ignorance.

Er, hum.  I need to apologise for posting such an abominably incorrect
code fragment!  Yes, I had had a brainstorm and managed to confuse the
C pre-processor, the other C syntax and Bourne shell - why I didn't
bring in awk and Fortran 90 as well is a mystery :-)  I plead overwork,
old age and general decrepitude.

I stand by the rest of my points - there just ISN'T any point in just an
extra typedef or type syntax.  The hard parts are how such things relate
to the rest of the language, and I shall be interested to see how the
<inttypes.h> header deals with them.  While some of my code does handle
them, I can't do it cleanly and portably.

I don't suppose that there is any chance of fixing <float.h>?  And I DO
mean "fixing" - the current one is of little use except for checking
that your own version corresponds with the compiler's idea of reality.


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Richard Krehbiel <rich@kastle.com> writes:

|>  Colin Rafferty <craffert@spssunp.spspme.ml.com> writes:
|>
|>  > What this means for all of us is twofold:
|>  >
|>  > 1. We can always count on integer arithmetic being fast.
|>  >
|>  > 2. We cannot count on BITS(char) == 8, nor sizeof(int) == 4, and
|>  >    especially not that BITS(int) == 32.
|>  >
|>  > In other words, use <values>, and program in the future tense.
|>
|>  Those of us writing network software can therefore count on remaining
|>  outside of standard C looking in.  Sigh.

Those of us writing network software have to deal with several sets of
standards, of which the C/C++ standard is just one.  If you are writing
portable network software, however, you may very well have to deal with
the fact that the size of a character on the network does not correspond
to the size of any data type physically available on your machine.  You
also have to cope with a wealth of other differences.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Nick Maclaren wrote:
...
> I don't suppose that there is any chance of fixing <float.h>?  And I DO
> mean "fixing" - the current one is of little use except for checking
> that your own version corresponds with the compiler's idea of reality.
...
Could you expand on that? What doesn't it do right?
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

damian@molly.cs.monash.edu.au (Damian Conway) wrote:

>
>Well, an obvious solution is to (conceptually) make int a templated type
>with an integer parameter which has a default value suitable for each machine
>(within the constraints imposed by the standard). Hence:

I am 80% finished with an implementation of just such a template (except
that it does not have a default template parameter). I am doing this in
my very limited free time, so it may be some months until it is done,
but I will put the code in the public domain at that time.  The usage
will be something like:

VeryLong<64> x; // Integer with at least 64-bit 2's complement precision

I am also planning to create a variation that truncates the results to
the exact number of bits specified.

BitInt<12> y; // Integer with *exactly* 12-bits 2's complement precision

Finally, I will extend the package with a class that can store any
reasonably-sized integer (by reasonably sized, I mean somthing with less
than INT_MAX times the precision of a long):

BigInt z;  // Will grow to hold any size value.

I'll post on comp.lang.c++ when each piece becomes available.

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Valentin Bonnard wrote:
> Anyway I'd like to know how many programs do not count on the exact
> size of integers types (for known or unknown reasons).
>
> Only real programs count (no Hello world nor test programs).

I don't know if this counts, but when I write:

for (int i = 0; i < 1256; i++) {
    ... do some stuff ...
}

I don't care what size i is, but I'd appreciate it if the operations on
i (assignment, compare and increment) all happened as quickly as is
possible.

--
Regards,
    Michael Hudson

Please don't email this address - it's not mine.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  char should absolutly stay 8 bits (or the minimum addressable unit
|>  of memory).
|>
|>  Others type could stay where they are if a new type (long long) was
|>  added.
|>
|>  char  short    long    long long
|>   8     16       32         64
|>          ^        ^         ^
|>          ------- int --------

Correctly, this table should read:

    char >= 8
    short >= 16
    int >= 16
    long >= 32
    long long >= 64

|>  The problem I see with long long is: how to order the integers types:
|>
|>  char |> short -> int -> long
|>
|>  One could add long long at the end:
|>
|>  char |> short -> int -> long -> long long
|>
|>  But int may need to be long long if it's faster than long:
|>
|>  char |> short -> long -> int -> long long

If int needs to be long long, then long should also be long long.  An
implementation which has 8 bit char's and all other types 64 bits is
certainly conforming.

|>  But you break:
|>  - current overloading
|>  - current assumption sizeof (int) <= sizeof (long)
|>
|>  Also what about char_t, short_t, int_t, long_t, long_long_t ?
|>  (The same as float_t, double_t: the fastest type with this precision.)

What are char_t, et al.?  I've never heard of them.

|>  Anyway I'd like to know how many programs do not count on the exact
|>  size of integers types (for known or unknown reasons).

I rather suspect that programs counting on the exact size of integer
types are rather the exception.  In most cases, as long as there is no
overflow, there is no problem.  The only exception I can think of off
hand is calculating hash-codes (which usually do an implicit mod 2^N,
where N is the number of bits).

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Something I'm curious about:

Currently, compilers have a very convenient set of integer
sizes:
    char       8 bits
    short      16 bits
    int/long   32 bits
    long       64 bits (where available)

What's going to happen when 128 and 256 bits come along,
'long long', as in gcc? Or int128, int256? Or are the
compiler vendors just going to start skipping sizes to
maintain ANSI/ISO conformance?

Maybe chars will become 16 bits!  :-O  !!

IMHO: char, short and int should stop where they are (with
int possibly going as far as 64 bits). And long should be
the machine's word size. Any opinions? Does anyone even
care?

--
Marcelo Cantos
__________________________________________________
Multimedia Database Systems Group, RMIT, Australia


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

> What's going to happen when 128 and 256 bits come along,
> 'long long', as in gcc? Or int128, int256? Or are the
> compiler vendors just going to start skipping sizes to
> maintain ANSI/ISO conformance?

I personally doubt that we'll ever see CPUs with more than 64 bits (just
how big a number do you need?  64 bits is 18 quintillion after all), but
it could happen.  What is currently the case with 64-bit CPUs will probably
hold for 256-bit CPUs, namely, that you will still have only three sizes of
integers at most:

    Type      | CPU Bit Size
              |  16    32    64    256
    ----------+------------------------
    short int |  16    16    16    16
    plain int |  16    32   32/64 32/64
    long  int |  16   32/64  64    256

For example, the DEC Alpha has three sizes: 16, 32, and 64 bit.  It is
prudent, and typical, to choose a size for plain int that is very efficient
for the CPU.  Short and long integers usually incur a little overhead.
(The opposite is true of the Alpha since long int is the most efficient,
but DEC was concerned about upward compatibility with existing code.)

If you consider 'char' as another integer type, it will continue to be
7, 8, or 9 bits, since ANSI defines the smallest addressable unit of
memory in terms of 'char'.  Thus, 'char' is usually synonymous with 'byte'.

However, other languages, notably Java, do not consider 'char' to be an
integer type - it only holds characters and is used as a fundemental unit
of string data types.  If 'char' is divorced from 'byte', it could then
become a 16-bit type (for Unicode).  For this to happen in C/C++ would
probably entail the creation of another type, say 'byte', that explicitly
defines 'smallest addressable unit of memory'.

-- David R. Tribble, david.tribble@central.beasys.com --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>>>>>>>  "MC" == Marcelo Cantos <marcelo@mds.rmit.edu.au> writes:

MC> Currently, compilers have a very convenient set of integer
MC> sizes:

I think that this one sentence could set off a a month long flamewar in
comp.lang.c++.  I will just say that not everyone would agree with you.

MC> What's going to happen when 128 and 256 bits come along,
MC> 'long long', as in gcc? Or int128, int256? Or are the
MC> compiler vendors just going to start skipping sizes to
MC> maintain ANSI/ISO conformance?

See below for more details, but ANSI/ISO conformance says nothing about
actual sizes.

MC> IMHO: char, short and int should stop where they are (with
MC> int possibly going as far as 64 bits). And long should be
MC> the machine's word size. Any opinions? Does anyone even
MC> care?

As far as opinions go, I would look at the draft standard.  I do not
imagine that the December WP has changed any of the fundamentals since
the April WP, so I will refer to that.

>>>>>>>> "WP" == April Working Paper writes:

WP> [basic.fundamental]

WP> 2 Objects  declared  as  characters char) shall be large enough to store
WP>   any member of the implementation's basic character set.

WP> 4 There  are  four  signed  integer  types:  "signed char", "short int",
WP>   "int", and "long int." In this list, each type provides  at  least  as
WP>   much storage as those preceding it in the list, but the implementation
WP>   can otherwise make any of them equal in storage size.  Plain ints have
WP>   the  natural  size  suggested  by  the machine architecture; the other
WP>   signed integer types are provided to meet special needs.

The ARM (1990 edition) says basically the same thing.  In other words,
the actual sizes are implementation dependent, with the constraint that:
sizeof(char) <= sizeof(short int) <= sizeof(int) <= sizeof(long int).

In fact, it specifically suggests that sizeof(int) increase as machine
sizes grow.

What this means for all of us is twofold:

1. We can always count on integer arithmetic being fast.

2. We cannot count on BITS(char) == 8, nor sizeof(int) == 4, and
   especially not that BITS(int) == 32.

In other words, use <values>, and program in the future tense.

--
Colin


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Followup to:  <32DDD024.CEE@mds.rmit.edu.au>
By author:    Marcelo Cantos <marcelo@mds.rmit.edu.au>
In newsgroup: comp.std.c++
>
> Something I'm curious about:
>
> Currently, compilers have a very convenient set of integer
> sizes:
>     char       8 bits
>     short      16 bits
>     int/long   32 bits
>     long       64 bits (where available)
>
> What's going to happen when 128 and 256 bits come along,
> 'long long', as in gcc? Or int128, int256? Or are the
> compiler vendors just going to start skipping sizes to
> maintain ANSI/ISO conformance?
>

It seems to me that the standards folks should stop pretending to be
system-independent and bite the bullet, and define a syntax like
"int:32" to allocate a 32-bit integer; probably defining the semantics
as "a[n un]signed integer able to accurately represent all values
between -2^(N-1) and 2^(N-1)-1 [0 and 2^N-1]" as a nod of acceptance
to the 36-bit (or ternary, or decimal...) machines that still are out
there; that definition does not prevent a machine with 36-bit words to
allocate a full 36-bit unit for an "int:32".

 -hpa
--
This space intentionally has nothing but text explaining why this
space has nothing but text explaining that this space would otherwise
have been left blank, and would otherwise have been left blank.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Colin Rafferty <craffert@spssunp.spspme.ml.com> writes:

> What this means for all of us is twofold:
>
> 1. We can always count on integer arithmetic being fast.
>
> 2. We cannot count on BITS(char) == 8, nor sizeof(int) == 4, and
>    especially not that BITS(int) == 32.
>
> In other words, use <values>, and program in the future tense.

Those of us writing network software can therefore count on remaining
outside of standard C looking in.  Sigh.

--
Richard Krehbiel, Kastle Systems, Arlington, VA, USA
rich@kastle.com (work) or richk@mnsinc.com (personal)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]