Hello, I am sure that this question has a quick and easy answer but
it's driving me nuts.

I need to to store 19 9's in an integer, so i need an unsigned 64 bit
int.  In windows vsc++ compiler the code would be:
_int64 test = 9999999999999999999;

I am now using g++ version 3.3.5(Suse 9.2's)

I have tried both:

unsigned long long test = 9999999999999999999;

and:
#include<stdint.h>

uint64_t test = 9999999999999999999;

both  get the following when i run "g++ test.cpp"

test.cpp:5:37: warning: integer constant is so large that it is
unsigned
test.cpp: In function `int main()':
test.cpp:5: warning: this decimal constant is unsigned only in ISO C90
test.cpp:5: error: integer constant is too large for "long" type

am I forgeting to include something or missing a option to g++?

Thanks for the Help


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

i got it, I just forgot the LLU on the end of the non-int constant


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"BackslashZero" <Costellj@gmail.com> wrote:
> I need to to store 19 9's in an integer, so i need an unsigned 64 bit
> int.  In windows vsc++ compiler the code would be:
> _int64 test = 9999999999999999999;
>
> I am now using g++ version 3.3.5(Suse 9.2's)
>
> I have tried both:
>
> unsigned long long test = 9999999999999999999;

Try 9999999999999999999ULL instead so that the compiler knows it is an
unsigned long long.

-- 
Catalin

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

BackslashZero wrote:
> Hello, I am sure that this question has a quick and easy answer but
> it's driving me nuts.
> 
> I need to to store 19 9's in an integer, so i need an unsigned 64 bit
> int.  In windows vsc++ compiler the code would be:
> _int64 test = 9999999999999999999;

Ironically...  Isn't this a *bug* in MS VC++ ?  (or is an integer
overflow in a literal integer undefined behaviour?  Still ironically,
it would be funny if it's not a bug *because* it is UB)

Carlos
--

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 2005-12-07 18:37:32 -0500, Carlos Moreno
<moreno_at_mochima_dot_com@mailinator.com> said:

> BackslashZero wrote:
>> Hello, I am sure that this question has a quick and easy answer but
>> it's driving me nuts.
>>
>> I need to to store 19 9's in an integer, so i need an unsigned 64 bit
>> int.  In windows vsc++ compiler the code would be:
>> _int64 test = 9999999999999999999;
>
> Ironically...  Isn't this a *bug* in MS VC++ ?

It's not a bug at all. From the standard:
--------------------------
The type of an integer literal depends on its form, value, and suffix.
If it is decimal and has no suffix, it has the first of these types in
which its value can be represented:int, long int; if the value cannot
be represented as along int, the behavior is undefined. If it is octal
or hexadecimal and has no suffix, it has the first of these types in
which its value can be represented: int, unsigned int, long int,
unsigned long int. If it is suffixed by u or U, its type is the first
of these types in which its value can be represented: unsigned int,
unsigned long int. If it is suffixed by l or L, its type is the first
of these types in which its value can be represented: long int,
unsigned long int. If it is suffixed by ul, lu, uL, Lu, Ul, lU, UL, or
LU, its type isunsigned long int.
--------------------------

So, if the value 9999999999999999999 cannot be represented as a long
int, then the behavior is undefined

>   (or is an integer
> overflow in a literal integer undefined behaviour?  Still ironically,
> it would be funny if it's not a bug *because* it is UB)
>
> Carlos


-- 
Clark S. Cox, III
clarkcox3@gmail.com


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Carlos Moreno" <moreno_at_mochima_dot_com@mailinator.com> wrote in message
news:bjIlf.101990$qI6.1477752@weber.videotron.net...
> BackslashZero wrote:
>> Hello, I am sure that this question has a quick and easy answer but
>> it's driving me nuts.
>>
>> I need to to store 19 9's in an integer, so i need an unsigned 64 bit
>> int.  In windows vsc++ compiler the code would be:
>> _int64 test = 9999999999999999999;
>
> Ironically...  Isn't this a *bug* in MS VC++ ?  (or is an integer
> overflow in a literal integer undefined behaviour?  Still ironically,
> it would be funny if it's not a bug *because* it is UB)


It's an extension to the standard, as well as gcc's ULL is an extension. The
standard doesn't allow for ULL suffix, it only allows for UL (and its
modifications.)
2.13.1/2 seems to assume that the largest integer value should be long int, so
any literal that doesn't fit into long int causes undefined behavior.  And in
2.13.1/3 it is said that both VC++ and gcc extensions make the program
ill-formed.

-- Gene Bushuyev
----------------------------------------------------------------
There is no greatness where there is no simplicity, goodness and truth. ~ Leo
Tolstoy


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Carlos Moreno wrote:
> BackslashZero wrote:
> > Hello, I am sure that this question has a quick and easy
> > answer but it's driving me nuts.

> > I need to to store 19 9's in an integer, so i need an unsigned 64 bit
> > int.  In windows vsc++ compiler the code would be:
> > _int64 test = 9999999999999999999;

> Ironically...  Isn't this a *bug* in MS VC++ ?  (or is an
> integer overflow in a literal integer undefined behaviour?
> Still ironically, it would be funny if it's not a bug
> *because* it is UB)

It's undefined behavior, so MS behavior is conform.  Of course,
the fact that it didn't complain that _int64 was an undefined
symbol is not conform.  Ditto the fact that g++ didn't complain
about long long.  (The fact that g++ doesn't complain about long
long, nor this constant when suffixed with ULL, when the option
-std=c++98 is given probably is a bug.  Personally, however, I'm
happier with the bug than I would be if they corrected it.)

There is another interesting point, however, supposing a
32 bit machine.  The above may be undefined behavior, but in:

    _int64 test = 1000000 * (1000000 * 9999999 + 999999) + 999999 ;

a compiler diagnostic is required.  Stranger yet: if I'm on a
machine with 64 bit longs (but 32 bit int's -- as I am, in
fact), and I declare the above as a long, a diagnostic is still
required, although using the original literal is fully defined
and conformant.

--
James Kanze                                           GABI Software
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


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

kanze wrote:
> Carlos Moreno wrote:
> > BackslashZero wrote:

> > > I need to to store 19 9's in an integer, so i need an unsigned 64 bit
> > > int.  In windows vsc++ compiler the code would be:
> > > _int64 test = 9999999999999999999;
>
> > Ironically...  Isn't this a *bug* in MS VC++ ?  (or is an
> > integer overflow in a literal integer undefined behaviour?
> > Still ironically, it would be funny if it's not a bug
> > *because* it is UB)
>
> It's undefined behavior, so MS behavior is conform.  Of course,
> the fact that it didn't complain that _int64 was an undefined
> symbol is not conform.  Ditto the fact that g++ didn't complain
> about long long.

Well, if that symbol is defined somewhere then isn't the implementation
conformant if it doesn't issue a diagnostic no matter if that symbol is
actually in the standard??  Plus 17.4.3.1.2 allows them (MS) to use the
__int64 identifier for whatever.  Is there some other part of the
standard that says an implementation cannot supply types not specified
in the standard?

It might seem a nono for g++ to use "long long".  Is this really a
violation of std though?


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

roberts.noah@gmail.com wrote:
> kanze wrote:
> > Carlos Moreno wrote:
> > > BackslashZero wrote:
> > > > I need to to store 19 9's in an integer, so i need an
> > > > unsigned 64 bit int.  In windows vsc++ compiler the code
> > > > would be:

> > > > _int64 test = 9999999999999999999;

> > > Ironically...  Isn't this a *bug* in MS VC++ ?  (or is an
> > > integer overflow in a literal integer undefined behaviour?
> > > Still ironically, it would be funny if it's not a bug
> > > *because* it is UB)

> > It's undefined behavior, so MS behavior is conform.  Of
> > course, the fact that it didn't complain that _int64 was an
> > undefined symbol is not conform.  Ditto the fact that g++
> > didn't complain about long long.

> Well, if that symbol is defined somewhere then isn't the
> implementation conformant if it doesn't issue a diagnostic no
> matter if that symbol is actually in the standard??

That would be true *if* it were defined somewhere, say in a
header.  It was my understanding that the symbol was built into
the compiler, and present even if no headers were included.  And

    int _int64 ;

is a legal program, which a compiler must compile without error.

> Plus 17.4.3.1.2 allows them (MS) to use the __int64 identifier
> for whatever.

If the symbol is __int64, there is no problem what so ever.  Any
program which uses it has undefined behavior (which, of course,
an implementation is free to define however it wants).

As I remember it, the symbol was __int64; I seem to recall
thinking at the time that VC++ did it correctly, where as all of
the Unix compilers had screwed up with their long long.  But
I've not had access to VC++ for a while, and the quoted symbol
was _int64; I trusted the quote more than my own memory.

> Is there some other part of the standard that says an
> implementation cannot supply types not specified in the
> standard?

Not at all.  There is a requirement that an implementation
cannot add symbols which are in the user's namespace.
(Namespace, here, in the general sense, and not in the sense of
the C++ keyword.)

> It might seem a nono for g++ to use "long long".  Is this
> really a violation of std though?

Definitly.  Not because the implementation has added a type, but
because the standard requires a diagnostic for an ill formed
program, and says that multiple specification of long in a
declaration is ill formed.  The correct way to add a new type is
to give it a name starting with __; one may also give it a more
comfortable name by means of a typedef in an include file, but
this name should only be apparent if the include file is
actually included (and it cannot be included by any of the
standard includes).

--
James Kanze                                           GABI Software
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


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

kanze wrote:

> > Well, if that symbol is defined somewhere then isn't the
> > implementation conformant if it doesn't issue a diagnostic no
> > matter if that symbol is actually in the standard??
>
> That would be true *if* it were defined somewhere, say in a
> header.  It was my understanding that the symbol was built into
> the compiler, and present even if no headers were included.

Well, forgive me for keeping on about this, I have just gotten the
standard and am reading it and trying to understand.

Is there a requirement that an implementation defined symbol be
declaired in a header?  Where is that requirement as I can't find it.


> > Plus 17.4.3.1.2 allows them (MS) to use the __int64 identifier
> > for whatever.
>
> If the symbol is __int64, there is no problem what so ever.  Any
> program which uses it has undefined behavior (which, of course,
> an implementation is free to define however it wants).
>
> As I remember it, the symbol was __int64; I seem to recall
> thinking at the time that VC++ did it correctly, where as all of
> the Unix compilers had screwed up with their long long.  But
> I've not had access to VC++ for a while, and the quoted symbol
> was _int64; I trusted the quote more than my own memory.

Well, the same clause states that any name that starts with an
underscore is reserved for the implementation to use in the global
namespace.

Granted I am a bit confused whether this implementation defined type
can be considered a name.

Oh, and the symbol is definately __int64 fyi.  I have the MSDN library
right here:

__int8 nSmall;      // Declares 8-bit integer
__int16 nMedium;    // Declares 16-bit integer
__int32 nLarge;     // Declares 32-bit integer
__int64 nHuge;      // Declares 64-bit integer


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

roberts.noah@gmail.com wrote:

> It might seem a nono for g++ to use "long long".  Is this really a
> violation of std though?

With the -pedantic option g++ will not only issue a diagnosis but will
actually reject the program:

pedant.cpp: In function `int main()':
pedant.cpp:3: error: ISO C++ does not support `long long'
pedant.cpp:3:17: warning: use of C99 long long integer constant

I think VC will do this also with some option.

So the question is, by the standard, is the implementation allowed to
require an option to turn on these diagnostic messages?  On the other
hand, it seems to me that both GNU and VS are only advertizing full
compliance with certain options turned on/off so using them otherwise
wouldn't seem to have to.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <1134133038.904756.222390@g44g2000cwa.googlegroups.com>, 
kanze <kanze@gabi-soft.fr> writes
>> It might seem a nono for g++ to use "long long".  Is this
>> really a violation of std though?
>
>Definitly.  Not because the implementation has added a type, but
>because the standard requires a diagnostic for an ill formed
>program, and says that multiple specification of long in a
>declaration is ill formed.  The correct way to add a new type is
>to give it a name starting with __; one may also give it a more
>comfortable name by means of a typedef in an include file, but
>this name should only be apparent if the include file is
>actually included (and it cannot be included by any of the
>standard includes).

Actually the correct way is for the compiler to issue a diagnostic in 
the form of a self congratulatory message such as:

'Noted that you are using extensions that are provided by the Working 
Draft for the next release of C++'

:-)


-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

roberts.noah@gmail.com wrote:
> kanze wrote:

>>>Well, if that symbol is defined somewhere then isn't the
>>>implementation conformant if it doesn't issue a diagnostic no
>>>matter if that symbol is actually in the standard??

>>That would be true *if* it were defined somewhere, say in a
>>header.  It was my understanding that the symbol was built
>>into the compiler, and present even if no headers were
>>included.

> Well, forgive me for keeping on about this, I have just gotten
> the standard and am reading it and trying to understand.

> Is there a requirement that an implementation defined symbol
> be declaired in a header?  Where is that requirement as I
> can't find it.

An implementation can't just add any symbols it feels like.  I
don't know exactly where to look for this in the standard, but
it seems pretty necessary -- suppose an implementatioin added
the symbol i.  According to the current standard, the following
program is legal, and an implementation is required to accept
it:

     int main()
     {
         int _int64 ;
     }

If the compiler complains, it isn't conform.

>>>Plus 17.4.3.1.2 allows them (MS) to use the __int64 identifier
>>>for whatever.

>>If the symbol is __int64, there is no problem what so ever.
>>Any program which uses it has undefined behavior (which, of
>>course, an implementation is free to define however it wants).

>>As I remember it, the symbol was __int64; I seem to recall
>>thinking at the time that VC++ did it correctly, where as all
>>of the Unix compilers had screwed up with their long long.
>>But I've not had access to VC++ for a while, and the quoted
>>symbol was _int64; I trusted the quote more than my own
>>memory.

> Well, the same clause states that any name that starts with an
> underscore is reserved for the implementation to use in the
> global namespace.

Good point.  If the compiler treats it as a predefined symbol in
global scope, no problem.  If it treats it as a keyword, it's
not conform.  (Both can be made to work within the compiler.)

> Granted I am a bit confused whether this implementation
> defined type can be considered a name.

It depends.  The problem here isn't the type; it's the symbol
(and its visiblility).

> Oh, and the symbol is definately __int64 fyi.  I have the MSDN
> library right here:

> __int8 nSmall;      // Declares 8-bit integer
> __int16 nMedium;    // Declares 16-bit integer
> __int32 nLarge;     // Declares 32-bit integer
> __int64 nHuge;      // Declares 64-bit integer

In which case, the compiler is fully conform (at least in this
respect).

-- 
James Kanze                                 mailto: james.kanze@free.fr
Conseils en informatique orient�e objet/
                        Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre S�mard, 78210 St.-Cyr-l'�cole, France +33 (0)1 30 23 00 34

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

roberts.noah@gmail.com wrote:
> roberts.noah@gmail.com wrote:

>>It might seem a nono for g++ to use "long long".  Is this
>>really a violation of std though?

> With the -pedantic option g++ will not only issue a diagnosis
> but will actually reject the program:

> pedant.cpp: In function `int main()':
> pedant.cpp:3: error: ISO C++ does not support `long long'
> pedant.cpp:3:17: warning: use of C99 long long integer constant

Interesting.  I would have thought that -std=c++98 would have
been sufficient.  I prefer it they way they've done it,
however:-).

> I think VC will do this also with some option.

> So the question is, by the standard, is the implementation
> allowed to require an option to turn on these diagnostic
> messages?

The standard doesn't address the issue of how to invoke the
compiler.  If I put my source code in a file called x.f, g++
doesn't compile it correctly either.  For historical reasons, my
C++ sources are in files which end in .cc -- with VC++, at least
6.0, I needed an /Tp option for the compiler to consider them
C++.

All of which is, as far as I can see, fully conforming, and no
problem for me.  I've yet to use a compiler where I didn't need
a certain number of options to get it to do what I needed.  One
more or less doesn't really bother me.

-- 
James Kanze                                 mailto: james.kanze@free.fr
Conseils en informatique orient�e objet/
                        Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre S�mard, 78210 St.-Cyr-l'�cole, France +33 (0)1 30 23 00 34

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

James Kanze wrote:

> [...]
>          int _int64 ;

>>>[...]  __int64
> [...]

>>__int8 nSmall;      // Declares 8-bit integer
>>__int16 nMedium;    // Declares 16-bit integer
>>__int32 nLarge;     // Declares 32-bit integer
>>__int64 nHuge;      // Declares 64-bit integer

*sigh*

Am I the only one that thinks that the nightmare around having
to declare an integer of exactly a given size is perhaps the
single biggest and most gratuitous embarrasment of C++ ?  (well,
or at least in the top-5 list of embarrasments?)

I just can not believe that after so many years, it is still
not possible to count on something like:

int<16> blah;
int<32> blah2;
int<64> blah3;
int n;  // implementation dependent

And why not also int<128>, int<256>  (at the very least these
two, if not more)

Ok, so not necessarily using template-like syntax, although
this would definitely have the advantage of not breaking a
single line of existing code.

Carlos
--

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

You can easily implement the following:

int<16>::type
int<32>::type
etc...

You may need a platform specific header file to "#define" the proper
typedefs/specializations.  You could use bootstrapping (the technique
of having one program generate code used to compile a later phase of
the program) to generate a platform specific header file for any
platform.

While it might be nice to require 'std::int<16>::type' in the standard
library, it certainly is not necessary and can be implemented without
any language enhancements.

joshua lehrer
http://www.lehrerfamily.com/


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Carlos Moreno wrote:
> James Kanze wrote:

> > [...]
> >          int _int64 ;

> >>>[...]  __int64
> > [...]

> >>__int8 nSmall;      // Declares 8-bit integer
> >>__int16 nMedium;    // Declares 16-bit integer
> >>__int32 nLarge;     // Declares 32-bit integer
> >>__int64 nHuge;      // Declares 64-bit integer

> *sigh*

> Am I the only one that thinks that the nightmare around having
> to declare an integer of exactly a given size is perhaps the
> single biggest and most gratuitous embarrasment of C++ ?
> (well, or at least in the top-5 list of embarrasments?)

In theory or in practice?  There are really very few times I'm
concerned about the size of an integer:

 -- when formatting for the Internet: must be 8 bits,
 -- in CRC's: must be either 16 or 32 bits,
 -- for hash digests, like MD5, SHA-1, etc., must be either 32
    or 64 bits.

And that about covers it.

What is missing is that I cannot specify a range, and have the
compiler choose the type, or even enforce the range.

> I just can not believe that after so many years, it is still
> not possible to count on something like:

> int<16> blah;
> int<32> blah2;
> int<64> blah3;
> int n;  // implementation dependent

> And why not also int<128>, int<256>  (at the very least these
> two, if not more)

> Ok, so not necessarily using template-like syntax, although
> this would definitely have the advantage of not breaking a
> single line of existing code.

Except for the syntax, what you're proposing is pretty much
stdint.h.  In other words, standard C, and soon standard C++.

--
James Kanze                                           GABI Software
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


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

kanze wrote:
> Carlos Moreno wrote:
> 
>>James Kanze wrote:
> 
> 
>>>[...]
>>>         int _int64 ;
> 
> 
>>>>>[...]  __int64
>>>
>>>[...]
> 
> 
>>>>__int8 nSmall;      // Declares 8-bit integer
>>>>__int16 nMedium;    // Declares 16-bit integer
>>>>__int32 nLarge;     // Declares 32-bit integer
>>>>__int64 nHuge;      // Declares 64-bit integer
> 
> 
>>*sigh*
> 
> 
>>Am I the only one that thinks that the nightmare around having
>>to declare an integer of exactly a given size is perhaps the
>>single biggest and most gratuitous embarrasment of C++ ?
>>(well, or at least in the top-5 list of embarrasments?)
> 
> 
> In theory or in practice?  There are really very few times I'm
> concerned about the size of an integer:
> 
>  -- when formatting for the Internet: must be 8 bits,
>  -- in CRC's: must be either 16 or 32 bits,
>  -- for hash digests, like MD5, SHA-1, etc., must be either 32
>     or 64 bits.
> 
> And that about covers it.

Any form of encryption as well -- Substitution-permutation ciphers
usually require known size.  Same thing with PK encryption;  in
many other applications in telecommunications, data compression,
embedded systems in general, known sizes are often required.

> What is missing is that I cannot specify a range, and have the
> compiler choose the type, or even enforce the range.

Right.  But the thing is, at least the lack of these is not
really gratuitous...  What bothers me from the lack of *exact*
sizes for integral types is how gratuitous it is.

>>int<16> blah;
>>int<32> blah2;
>>int<64> blah3;
>>int n;  // implementation dependent
> 
> 
>>And why not also int<128>, int<256>  (at the very least these
>>two, if not more)
> 
> 
>>Ok, so not necessarily using template-like syntax, although
>>this would definitely have the advantage of not breaking a
>>single line of existing code.
> 
> 
> Except for the syntax, what you're proposing is pretty much
> stdint.h.  In other words, standard C, and soon standard C++.

Huh...  Nice to hear!

One comment (after a quick Google look-up on stdint.h);  what's
the rationale for having uint types?  Seems silly to me -- we
don't have a uint type;  int is the type;  unsigned is a
modifier;  seems to me that to be consistent with that philosophy,
we could have simply had:  int8_t, int16_t, int32_t, int64_t, and
then place unsigned in front if we need them unsigned -- right?

I wonder if that's a side-effect of those being standard library
facilities (typedefs?) -- why not making them built-in types?

Carlos
--

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Carlos Moreno wrote:
> kanze wrote:
> > Carlos Moreno wrote:

> >>James Kanze wrote:

> >>>[...]
> >>>         int _int64 ;

> >>>>>[...]  __int64

> >>>[...]

> >>>>__int8 nSmall;      // Declares 8-bit integer
> >>>>__int16 nMedium;    // Declares 16-bit integer
> >>>>__int32 nLarge;     // Declares 32-bit integer
> >>>>__int64 nHuge;      // Declares 64-bit integer

> >>*sigh*

> >>Am I the only one that thinks that the nightmare around
> >>having to declare an integer of exactly a given size is
> >>perhaps the single biggest and most gratuitous embarrasment
> >>of C++ ?  (well, or at least in the top-5 list of
> >>embarrasments?)

> > In theory or in practice?  There are really very few times
> > I'm concerned about the size of an integer:

> >  -- when formatting for the Internet: must be 8 bits,
> >  -- in CRC's: must be either 16 or 32 bits,
> >  -- for hash digests, like MD5, SHA-1, etc., must be either 32
> >     or 64 bits.

> > And that about covers it.

> Any form of encryption as well -- Substitution-permutation
> ciphers usually require known size.

You mean fixed size, don't you?  But I'm not that familiar with
cryptologic techniques.

In practice, the key is that whenever more than one machine is
involved, all of the machines must agree on the size.  I
mentionned the Internet, but of course, the requirement stands
for any network.  (It's just that I don't know of any networks
today which don't use IP at level 3.  There are some in
telecom's, but they aren't very widespread.)

Note that this is largely the constraint behind the requirements
for CRC's and hash digests as well.  It would be fairly straight
forward to define a CRC for 18 bits, for example.  But the
"standard" CRC's are all 16 or 32 bits -- no other machine or
application could do anything with your CRC.

> Same thing with PK encryption;  in many other applications in
> telecommunications, data compression, embedded systems in
> general, known sizes are often required.

The classical LZW compression doesn't require them.  In fact, it
actually does use variable lengths, at least in the
implementations I've seen, and requires special routines to read
and write n bits (with n varying between 9 and 16).

> > What is missing is that I cannot specify a range, and have
> > the compiler choose the type, or even enforce the range.

> Right.  But the thing is, at least the lack of these is not
> really gratuitous...  What bothers me from the lack of *exact*
> sizes for integral types is how gratuitous it is.

I'm not sure what you mean by that.  C definitly exists for
machines with no hardware support for 8, 16 or 32 bits; I
suspect that it is probable that C++ do as well.  Most of the
time, what I know is the needed range for my integral type, not
the number of bits.  And whether I supply one information or the
the other to the compiler, it should have no problem choosing
the optimal type of integer at the hardware level.

> >>int<16> blah;
> >>int<32> blah2;
> >>int<64> blah3;
> >>int n;  // implementation dependent

> >>And why not also int<128>, int<256>  (at the very least
> >>these two, if not more)

> >>Ok, so not necessarily using template-like syntax, although
> >>this would definitely have the advantage of not breaking a
> >>single line of existing code.

> > Except for the syntax, what you're proposing is pretty much
> > stdint.h.  In other words, standard C, and soon standard
> > C++.

> Huh...  Nice to hear!

Note that exact sized types are *not* guaranteed to be present.
An implementation is only required to support what the hardward
supports.  Thus, for example, concerning intN_t and uintN_t,
"These types are optional.  However, if an implementation
provides integer types with widths of 8, 16, 32 or 64 bits, it
shall define the corresponding typedef names."

Note that it's very hard to imagine a case where one really
needs exact width, instead of minimum width; you can always
simulate exact width by masking.  Exact width is just easier to
code, because you can ignore the need to mask.  And of course, a
lot of us don't have a machine handy which doesn't support a 32
bit integral type, in order to test, so there's probably a lot
of code out there which unwittingly doesn't work if integers
are, say, 36 bits.

> One comment (after a quick Google look-up on stdint.h); what's
> the rationale for having uint types?  Seems silly to me -- we
> don't have a uint type;  int is the type;  unsigned is a
> modifier;  seems to me that to be consistent with that
> philosophy, we could have simply had:  int8_t, int16_t,
> int32_t, int64_t, and then place unsigned in front if we need
> them unsigned -- right?

Because they aren't types, but type names, defined by a typedef.
And while we say unsigned int, instead of uint, you can't use
unsigned to modify a typedef name.

> I wonder if that's a side-effect of those being standard
> library facilities (typedefs?) -- why not making them built-in
> types?

I can think of several reasons.  One of the most important is
backwards compatibility -- the names aren't defined unless you
include <stdint.h>.  And they obey scope; they aren't keywords.
Also, they may or may not be present, depending on the
underlying hardware -- don't expect to find int32_t on a Unisys
2200, or a PDP-10, or any number of older processors.  And there
is no concept in C/C++ of optional keywords.  (You can test
whether they exist in the preprocessor, e.g.:

    #include <stdint.h>
    #ifndef INT32_MAX
    #error This code requires a 32 bit integer type
    #endif

..  I suspect that a lot of code will just use the types, and let
the user figure out what is wrong if that results in a compiler
error.)

--
James Kanze                                           GABI Software
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


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]