C/C++ questions...

Started by
8 comments, last by jpetrie 16 years, 5 months ago
Ive started learning C, and I'm wondering if C and C++ data types hold the same amount of values as each other? Also all these appear to be legal but are there any that should be used over each other?

short int b;
short c;
unsigned short int d;
signed short e;
unsigned short f;
signed int g;
int h;
unsigned int i;
signed long int j;
long int k;
long l;
unsigned long int m;
unsigned long n;
signed long o;

except of course the signed ones since by default there signed.
Advertisement
C and C++ have basically the same rules.

A char is one byte, by definition. But a byte does not necessarily have (only) 8 bits.

A short is at least as big as a char, an int is at least as big as a short, and a long is at least as big as an int. But they could all be the same size. There are no specific sizes for any of these things; it depends on where you are compiling.

Signed and unsigned pairs of types will be the same size, but the way the unsigned types work is not specified in any detail. In particular, you are not guaranteed of twos-complement arithmetic.

'short int' and 'short' are equivalent, as are 'long int' and 'long'. It is normal to use the short forms.

'unsigned int' and 'unsigned' are equivalent. It is normal to use the long form. It is normal not to write 'signed', except for char, because that's the default (except for char).

A char is a different type from either a signed char or an unsigned char. It will behave like one of those two, but it is not the same as whichever one it happens to be behaving like. This is a slightly embarrassing thing which happened for historical reasons.

Conclusions:

- Just use 'int' unless you have a specific reason not to.
- If you need something to be a specific size, you better set up some typedefs. Boost has a useful header.
- If you're going to be manipulating the bits of a number, better stick with an unsigned type.
- Don't write 'sizeof(char)' (except implicitly via template code). It's useless.
The C/C++ types doesn’t have a specific size but they have a minimum size.
A short must have at least 16bit. An int must have at least 16bit. A long must have at least 32bit.

Edit:
I have added more emphasis on the words “at least”. As I have said they are only the minimum number of bits guaranteed by the standard.

[Edited by - apatriarca on October 29, 2007 2:46:40 PM]
Quote:
A short must have at least 16bit.

Incorrect.

Quote:
An int must have at least 16bit.

Incorrect.

Quote:
A long must have at least 32bit.

Incorrect.

Zahlman's explaination is accurate. There are no absolute size guarantees, only relative ones.
Quote:Original post by jpetrie
Quote:
A short must have at least 16bit.

Incorrect.

Quote:
An int must have at least 16bit.

Incorrect.

Quote:
A long must have at least 32bit.

Incorrect.

Zahlman's explaination is accurate. There are no absolute size guarantees, only relative ones.


Well, a char needs to have at least 8 bits, if you'd call that an 'absolute' guarantee :)
Quote:Original post by jpetrie
Quote:
A short must have at least 16bit.

Incorrect.

Quote:
An int must have at least 16bit.

Incorrect.

Quote:
A long must have at least 32bit.

Incorrect.

Zahlman's explaination is accurate. There are no absolute size guarantees, only relative ones.


Actually, all those statements about minimum bit sizes are correct. The C++ standard includes, by reference, the C standard library, which specifies minimum absolute values for the maximum value of char, int, short and long, which work out to 8, 16, 16, and 32 bits each.
Quote:Original post by jpetrie
Quote:
A short must have at least 16bit.

Incorrect.

Quote:
An int must have at least 16bit.

Incorrect.

Quote:
A long must have at least 32bit.

Incorrect.

Zahlman's explaination is accurate. There are no absolute size guarantees, only relative ones.

It is correct! See the C99 standard in the section 5.2.4.2.1 “Sizes of integer types <limits.h>”.
That section describes the minimum values of the macros that describes the sizes of the integer types. If you see that values you find what I had said previously.
I know Zahlman explanation is correct, my previous post want to be an addiction.
Quote:
It is correct! See the C99 standard in the section 5.2.4.2.1 “Sizes of integer types <limits.h>”.

Okay, I'll eat that one if the clause is still in the C specification before the C99 specification (I don't have a copy, so I can't check), or if the C++ spec specifically includes the C99 specification (which I imagine it doesn't given the lack of "restrict," et al). All that junk is at home, so I'll return in an hour or so after I've made the trip and dug through the stuff.
The only addition in C99 to this section is the new long long type limits. The rest of the section I think is practically the same. But I can’t verifies because I haven’t the other standard with me.
It seems you're right. I'd thought the values imposed in limits to be information only, I hadn't realized they had lower (and apparently upper) limits which imply specific bit-size ranges.

This strikes me as exceedingly odd, given the extent to which the rest of the (C++) standard goes out of its way to make a few guarantees as possible about type sizes. But I'm not really surprised. Every day I learn something new about those languages, I'm glad I rarely ever have to deal with it.

EDIT: I was totally speeding on I-95.

This topic is closed to new replies.

Advertisement