int versus long

Programming, for all ages and all languages.
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

Zacariaz wrote: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).
User avatar
Zacariaz
Member
Member
Posts: 1069
Joined: Tue May 22, 2007 2:36 pm
Contact:

Post by 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
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

Zacariaz wrote: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.
User avatar
Zacariaz
Member
Member
Posts: 1069
Joined: Tue May 22, 2007 2:36 pm
Contact:

Post by Zacariaz »

pcmattman wrote:
Zacariaz wrote: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.
User avatar
Alboin
Member
Member
Posts: 1466
Joined: Thu Jan 04, 2007 3:29 pm
Location: Noricum and Pannonia

Post by Alboin »

Zacariaz wrote:
pcmattman wrote:
Zacariaz wrote: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. ;)
C8H10N4O2 | #446691 | Trust the nodes.
User avatar
Zacariaz
Member
Member
Posts: 1069
Joined: Tue May 22, 2007 2:36 pm
Contact:

Post by 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
Member
Member
Posts: 514
Joined: Tue Nov 07, 2006 7:37 am
Location: York, England

Post by Tyler »

Zacariaz wrote: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?
User avatar
Zacariaz
Member
Member
Posts: 1069
Joined: Tue May 22, 2007 2:36 pm
Contact:

Post by 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.
User avatar
os64dev
Member
Member
Posts: 553
Joined: Sat Jan 27, 2007 3:21 pm
Location: Best, Netherlands

Post by os64dev »

Zacariaz wrote: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.
Author of COBOS
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by 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 :roll:, and just reduced the cutoff block count :oops: .

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?).
User avatar
bluecode
Member
Member
Posts: 202
Joined: Wed Nov 17, 2004 12:00 am
Location: Germany
Contact:

Post by 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
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by 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.
User avatar
bluecode
Member
Member
Posts: 202
Joined: Wed Nov 17, 2004 12:00 am
Location: Germany
Contact:

Post by bluecode »

pcmattman wrote: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 :evil:
User avatar
Zacariaz
Member
Member
Posts: 1069
Joined: Tue May 22, 2007 2:36 pm
Contact:

Post by 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.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Post by 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.
Every good solution is obvious once you've found it.
Post Reply