int versus long

[pcmattman]

well i dont think theres anything more to say about this other that i for one think its weird that we have 16, 32 and 64 bit integers but no 8 bit integer. Somewhere along the line, whoever developed c++, though that the 8 bit int should act different that than the others. I really dont see the point.

Do you mean, you can do this:

Code: Select all

short int
int
long int
long long int

But not

Code: Select all

char int

?

A 'char' type is designed for holding characters, hence the name - (following is afaik, someone please correct me if it's wrong) it also generally is not meant to be signed (that'd bring the limit down to 128, iirc).

[Zacariaz]

Well thats one way of putting it, but yes, that is kinda what i mean. I am of course aware that the char type is is designed to hold characters and not ints, that is not the issue, the isue is that there is no type of 8 bit size designet to hold ints.

[pcmattman]

the isue is that there is no type of 8 bit size designet to hold ints.

Because the range of values for an integer (signed) in an 8 bit variable is -128 to 128. Not a lot of space... Unsigned is 0 to 256, still not a lot of room.

[Zacariaz]

the isue is that there is no type of 8 bit size designet to hold ints.

Because the range of values for an integer (signed) in an 8 bit variable is -128 to 128. Not a lot of space... Unsigned is 0 to 256, still not a lot of room.

I dont think thats a very good argument. probably like 50-70% of the vars i define need not hold more that what can be put in a 8 bit type, but i often need alot of them. so, i would like to have the choice between defining 128 16 bit vars (2Kb) and 128 8 bit vars (1KB). The difference in this example may seem small, but its still double/half the size.

[Alboin]

the isue is that there is no type of 8 bit size designet to hold ints.

Because the range of values for an integer (signed) in an 8 bit variable is -128 to 128. Not a lot of space... Unsigned is 0 to 256, still not a lot of room.

I dont think thats a very good argument. probably like 50-70% of the vars i define need not hold more that what can be put in a 8 bit type, but i often need alot of them. so, i would like to have the choice between defining 128 16 bit vars (2Kb) and 128 8 bit vars (1KB). The difference in this example may seem small, but its still double/half the size.

I think if you're trying to save space by restricting the size of your variables, it's time to rethink your program structure.

[Zacariaz]

nah, im just a perfectionist, thats why im working on getting into ASM. Anyway it isnt important, but i do think its weird...
allso i just discovered my math was wrong, just tells something about how experienced i am

[Tyler]

Well thats one way of putting it, but yes, that is kinda what i mean. I am of course aware that the char type is is designed to hold characters and not ints, that is not the issue, the isue is that there is no type of 8 bit size designet to hold ints.

Char is designed to hold 8 bit integers (assuming alot of things, like the fact is is 8-bit here). Just because it can be used to store characters as well makes it no less useful at storing integers. What functionality is it that you believe char lacks?

[Zacariaz]

As i said earlier, there is nothing more to discuss, it is a very tiny unimportant inconvinience. Char does not act like det other integer types, wether wether it is caused by the tools used to work with the char or it is the type itself that is different is not important.

End of subject.

[os64dev]

As i said earlier, there is nothing more to discuss, it is a very tiny unimportant inconvinience. Char does not act like det other integer types, wether wether it is caused by the tools used to work with the char or it is the type itself that is different is not important.

End of subject.

Well that is kind of harsh to say 'End of subject'. I haven't been able to react on the subject yet . char does exactly behave as other integer type albeit with a very limited range. you can multiply, divide and do anything with chars. but the catch is that the C-compiler and i think even ASM promotes the multplies, etc. to the standard integer type. Which in a sence is logical as that is the native data type for you hardware.

Consider the following example

Code: Select all

char * pbyte;
*pbyte = (char)(100 * 3);

You could omit the char cast but that would give a warning or an error and it should because the answer does not fit it the data type. The same problem holds with short and ints but they occurr less frequent. So in short there is no difference.

[pcmattman]

Reminds me of when I was trying to figure out whether or not to use LBA28 or LBA48 on a drive - I was checking a signed int to see if it was higher than "234375000" and the compiler complained. I don't think I thought to use an unsigned int , and just reduced the cutoff block count .

I'm still not 100% sure how to detect if a drive is LBA48 and still use lseek to seek to locations within it (perhaps seek to the limit, then use SEEK_CUR - internally the limits are stored as unsigned long longs?).

[bluecode]

It is about C++ not about C. It is more specifically about the operator overloading of the standard classes (basic_ostream, etc..), type safety and and typedefs being weak.
The overloaded operators for the standard classes treat a (u)int8_t as a (unsigned) char, which results in a character being showed on the screen not a number.

[pcmattman]

Well, that makes much more sense now...

You're meaning,

Code: Select all

uint8_t hi = 123;
cout << hi << endl;

If it was changed to print 'char' as an integer, you couldn't do this:

Code: Select all

cout << 'a' << endl;

Or this:

Code: Select all

char c = getch(); // whatever you use to get key from console
cout << c << endl;

I'd just say cast each call which may be ambiguous.

[bluecode]

I'd just say cast each call which may be ambiguous.

Sure, but I can tell you from my experience that you forget this in perhaps 50% of all the cases.And that makes me

[Zacariaz]

Code: Select all

cout << 'a' << endl;

Code: Select all

char c = getch(); // whatever you use to get key from console
cout << c << endl;

What i am saying:

Code: Select all

char c = 48;
uint8_t i = 48;

std::cout << c;
// or
std::cout << char(i);

Should output 0 and:

Code: Select all

char c = 48;
uint8_t i = 48;

std::cout << int(c);
// or
std::cout << i;

should output 48.

I think it would be easier to have an 8 bit int that actually behaved as such.

[Solar]

uint8_t is defined as a typedef, which are weak by definition. Changing this definition into strong typedefs would break lots of existing code, for example

Code: Select all

typedef void (*sighandler_t)(int);
typedef std::vector<std::string> StringVector;

would result in two new, distinctive types...

Besides, uint8_t is defined in stdint.h, which is a C99 header. That means, it does not even exist in standard C++, making the whole argument academic anyway as printf() couldn't care less about the actual type of its parameters. (And it's the standard we're talking about, not what GCC does.)

The only place I could think of where the "char-ness" of uint8_t actually makes a difference is exactly your cout example. And let's face it, if your application is primitive enough (not using "primitive" to be derogatory) to use cout for output, you can be expected to do those couple of casts instead of turning half the language inside out to "fix" what is a minor nuisance.

IMHO.