Use int or long keyword?

[Bryan Parkoff]

int has two bytes or four bytes. long has four bytes or eight bytes. I
can't be sure to choose int or long keyword because I don't trust to get the
wrong size. I always check by using sizeof(...).
I always use "short int" to show two bytes and "long int" to show four
bytes. It may not be accurate when I port my code from Microsoft C/C++
Compiler to other C/C++ Compiler such as Linux, Unix, Mac, etc. I always
trust Microsoft's keyword such as __int8, __int16, __int32, and __int64, but
I try to work around int and long keywords.
Someone does not recommend to use C/C++ Compiler's keywords so they
recommend to use typedef such as char to CHAR, bool to BOOL, etc. Why can't
programmers prefer BOOL instead of bool? Which it is important to have one
byte for bool and four bytes for BOOL?
If my code is written to use 64 bits CPU arch, it would be "long long"
to handle 8 bytes.
Please advise.

Bryan Parkoff

 

[Neelesh Bodas]

int has two bytes or four bytes. long has four bytes or eight bytes.

No.
3.9.1p2
There are four signed integer types: "signed char", "short
int", "int", and "long int." In this
list, each type provides at least as much storage as those preceding it
in the list. Plain ints have the natural size suggested by the
architecture of the execution environment39) ; the other signed integer
types are provided to meet special needs.

I always use "short int" to show two bytes and "long int" to show four
bytes.

resulting in a non-portable code.

If my code is written to use 64 bits CPU arch, it would be "long long"
to handle 8 bytes.
Please advise.

Not clear about what exact advice you want. Most of the
portable-applications need not worry about exact size of int etc. In
case you need to relie on the exact sizes, you could define new types
like int32 or int64 etc and define them in terms of C++ types as per
your platform.

 

[Victor Bazarov]

int has two bytes or four bytes.

Or one. Or more than four. There is no guarantee except that it has at
least 16 bits. You're probably using the term "byte" where you ought to
use the term "octet". They are not the same in C++, you know.

> long has four bytes or eight bytes.

Or two, or one. There is no guarantee except that it has at least 32
bits. "Byte" is not the same as "octet".

> I
can't be sure to choose int or long keyword because I don't trust to get the
wrong size. I always check by using sizeof(...).
OK.

I always use "short int" to show two bytes

Two octets, probably.

> and "long int" to show four
bytes.
Octets.

> It may not be accurate when I port my code from Microsoft C/C++
Compiler to other C/C++ Compiler such as Linux, Unix, Mac, etc. I always
trust Microsoft's keyword such as __int8, __int16, __int32, and __int64, but
I try to work around int and long keywords.

OK. Yes. If you use some compiler-specific types in your code, you will
need to adjust those to possibly different compiler-specific types when
you move to another compiler.

Someone does not recommend to use C/C++ Compiler's keywords so they
recommend to use typedef such as char to CHAR, bool to BOOL, etc. Why can't
programmers prefer BOOL instead of bool?

Because 'BOOL' is compiler-specific. 'bool' is a standard type.

> Which it is important to have one
byte for bool and four bytes for BOOL?

I don't understand the question. You're not providing any context where
some context is due.

If my code is written to use 64 bits CPU arch, it would be "long long"
to handle 8 bytes.

There is no [yet] standard type 'long long'. There is no standard C++
integral type that has at least 64 bits. But check out C99's types of
fixed sizes: int8_t, int16_t, etc.

Please advise.

Not sure what you'd like to know...

V

 

[Bryan Parkoff]

Or one. Or more than four. There is no guarantee except that it has at
least 16 bits. You're probably using the term "byte" where you ought to
use the term "octet". They are not the same in C++, you know.


Or two, or one. There is no guarantee except that it has at least 32
bits. "Byte" is not the same as "octet".


Two octets, probably.


OK. Yes. If you use some compiler-specific types in your code, you will
need to adjust those to possibly different compiler-specific types when
you move to another compiler.


Because 'BOOL' is compiler-specific. 'bool' is a standard type.

No, BOOL is not Microsoft's compiler-specific. It is the same as
"typedef int BOOL" You can find from winnt.h and windef.h I mean bool is
one byte and BOOL as int is 4 bytes. Why do people prefer BOOL instead of
bool when they write source code for Microsoft platform. bool is best
choice to port from Microsoft C/C++ Compiler to other C/C++ Compilers. bool
is 0x00 or 0x01 which it has only one bit in 8-bit width as one byte. Why
do Microsoft wants BOOL as 4 bytes like 32 bits. It may have wrong data
type when bool is converted to BOOL. What if you put "2" value instead of
"1" in BOOL? C/C++ Compiler will give an error or warning if greater than
"1" using bool (Not BOOL).

Bryan Parkoff

Which it is important to have one
byte for bool and four bytes for BOOL?

I don't understand the question. You're not providing any context where
some context is due.

If my code is written to use 64 bits CPU arch, it would be "long
long" to handle 8 bytes.

There is no [yet] standard type 'long long'. There is no standard C++
integral type that has at least 64 bits. But check out C99's types of
fixed sizes: int8_t, int16_t, etc.

Please advise.

Not sure what you'd like to know...

V

 

[Victor Bazarov]

No, BOOL is not Microsoft's compiler-specific. It is the same as

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

"typedef int BOOL" You can find from winnt.h and windef.h

What 'winnt.h'? What 'windef.h'? I know of no such standard headers.

> I mean bool is
one byte and BOOL as int is 4 bytes.

Says who?

> Why do people prefer BOOL instead of
bool when they write source code for Microsoft platform.

Because Microsoft Platform SDK has that type, I suppose.

> bool is best
choice to port from Microsoft C/C++ Compiler to other C/C++ Compilers.

I don't think so. Besides, where are you porting it to? What's the
platform? AFAIK, Microsoft doesn't really make compilers for UNIX or for
AIX or for System 390...

> bool
is 0x00 or 0x01

No, bool is 'false' or 'true'. How they are implemented internally is of
no consequence. 'sizeof(bool)' yields an implementation-defined value.
For all we know it _can_ be 128. Nothing in the language says it can't.

> which it has only one bit in 8-bit width as one byte. Why
do Microsoft wants BOOL as 4 bytes like 32 bits.

If that's a question, why don't you ask Microsoft that?

> It may have wrong data
type when bool is converted to BOOL. What if you put "2" value instead of
"1" in BOOL? C/C++ Compiler will give an error or warning if greater than
"1" using bool (Not BOOL).

WHAT? What error? If I use a non-zero integral value where 'bool' is
expected, the conversion should be to 'true'. There can be no error.
And warnings are not standard, so we cannot discuss them here.

V

 

[Marcus Kwok]

No, BOOL is not Microsoft's compiler-specific. It is the same as
"typedef int BOOL" You can find from winnt.h and windef.h I mean bool is
one byte and BOOL as int is 4 bytes. Why do people prefer BOOL instead of
bool when they write source code for Microsoft platform. bool is best
choice to port from Microsoft C/C++ Compiler to other C/C++ Compilers. bool
is 0x00 or 0x01 which it has only one bit in 8-bit width as one byte. Why
do Microsoft wants BOOL as 4 bytes like 32 bits. It may have wrong data
type when bool is converted to BOOL. What if you put "2" value instead of
"1" in BOOL? C/C++ Compiler will give an error or warning if greater than
"1" using bool (Not BOOL).

IIRC, "typedef int BOOL" is an old trick used in C that was used before
there was a proper "bool" type, and I guess MS keeps it in to maintain
compatibility with older code. Prefer the use of standard types when
possible.

 

[Niklas Norrthon]

int has two bytes or four bytes. long has four bytes or eight bytes. I
can't be sure to choose int or long keyword because I don't trust to get the
wrong size. I always check by using sizeof(...).
I always use "short int" to show two bytes and "long int" to show four
bytes. It may not be accurate when I port my code from Microsoft C/C++
Compiler to other C/C++ Compiler such as Linux, Unix, Mac, etc. I always
trust Microsoft's keyword such as __int8, __int16, __int32, and __int64, but
I try to work around int and long keywords.
Someone does not recommend to use C/C++ Compiler's keywords so they
recommend to use typedef such as char to CHAR, bool to BOOL, etc. Why can't
programmers prefer BOOL instead of bool? Which it is important to have one
byte for bool and four bytes for BOOL?
If my code is written to use 64 bits CPU arch, it would be "long long"
to handle 8 bytes.
Please advise.

Ok, first some facts:

The smallest integral type in C++ is char, (together with
signed char, and unsigned char). sizeof(char) is always 1 (one).
So it is common to say that a char variable takes up 1 byte.

But a byte most not necessarily mean 8 bits. I have worked with
platforms with 9 bit chars (a long time ago), and 16 bit chars
seems to be more and more common with the 64 bit platforms coming.

The C++ standard defines the macro CHAR_BIT in <climits> to
expand to the number of bits of a char in the current implementation.

The following ordering is also defined by the standard:

sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long),

and finally there is a requirement that short must be at least
16 bits wide.

Different platforms uses different sizes for the different types.
In most cases there is no need to know the exact sizes of types,
but sometimes such information is necessary.

In those cases I usually do something like:

// platform.h

#ifndef H_PLATFORM
#define H_PLATFORM

#if defined(SOME_PLATFORM)

typedef unsigned char uint8;
typedef unsigned short uint16;
typedef unsigned long uint32;

#elif defined (SOME_OTHER_PLATFORM)

typedef unsigned char uint8;
typedef unsigned short uint16;
typedef unsigned int uint32;

#else
#error "platform unknown"
#endif

(I rarely need to know the exact size of signed types, so
I don't bother to give them aliases).

These together with size_t and container<T>::size_type take
care of most of my problems related to choosing integral types
of variables.

The reason why sizeof (bool) isn't 1 is probably because
the processor works faster with a wider type. Usually you
just have a handful of bool variables anyway, so the wasted
space is neglectable.

/Niklas Norrthon

 

[Michiel.Salters]

IIRC, "typedef int BOOL" is an old trick used in C that was used before
there was a proper "bool" type, and I guess MS keeps it in to maintain
compatibility with older code.

Quite likely, since MS doesn't actually ship a C99 compiler. That means
their headers must use a common subset of C90 and C++98, and
BOOL fits the bill.

HTH,
Michiel Salters

 

[red floyd]

Marcus Kwok wrote:




Quite likely, since MS doesn't actually ship a C99 compiler. That means
their headers must use a common subset of C90 and C++98, and
BOOL fits the bill.

HTH,
Michiel Salters

I prefer

#ifndef __cplusplus
typedef enum { false = 0, true = 1 } bool;
#endif