which *int* ?

[Troy Martin]

char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned long.

Portability is a waste of time for me. I don't plan on it at all.

I'm an x86 freak

[Brynet-Inc]

char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned long.

Portability is a waste of time for me. I don't plan on it at all.

I'm an x86 freak

And then you realize that even C compilers on the x86 can be inconsistent with integer sizes.

[Troy Martin]

Okay, then, I'm a GCC-i586 freak. Fixed!

[Solar]

...in its current version. (Yes, I admit, it is unlikely they'll change it, but...)

This ain't about portability. IMHO, this goes much, much deeper.

You need an integer of exactly 32 bits. If you are the type that will simply check if int or long is good enough and then uses that deserves every bit of pain buggy code ever inflicts on him. And some more.

"int" might be 32 bit, but it does neither guarantee nor say so. "int" says "a whatever-sized integer value, I don't really care". Whereas int32_t says "a 32bit integer, and make it exactly 32 bits because it's important".

And as for using standards vs. rolling your own... sure there might be some advantages in driving on the wrong side of the road (such as, no-one in front of you to slow you down), but in the long run you aren't making friends that way...

Edit: That paragraph above about "saying so" refers to the documentation value of "int32_t" vs. "int", of course.

[Troy Martin]

I don't like pain, can I change my vote?

Thanks, Solar, for that. I think I'm going to start #including <stdint.h> from now on and using whatevar's defined in thar.

[spere]

Being a C# developer, it would be
uint
or
System.UInt32
didn't expect that one, did you?

Then again in masm i would use
VarName dw

[earlz]

Being a C# developer, it would be
uint
or
System.UInt32
didn't expect that one, did you?

Then again in masm i would use
VarName dw

ugh.. I hate C# in that respect.. Uint32. Just look at it. What an ugly name. It's inconsistent with every other language, and itself(where core types are lower case, such as int, float, object, string) Microsoft should've thought a little harder about that...

[NickJohnson]

...in its current version. (Yes, I admit, it is unlikely they'll change it, but...)

This ain't about portability. IMHO, this goes much, much deeper.

You need an integer of exactly 32 bits. If you are the type that will simply check if int or long is good enough and then uses that deserves every bit of pain buggy code ever inflicts on him. And some more.

"int" might be 32 bit, but it does neither guarantee nor say so. "int" says "a whatever-sized integer value, I don't really care". Whereas int32_t says "a 32bit integer, and make it exactly 32 bits because it's important".

And as for using standards vs. rolling your own... sure there might be some advantages in driving on the wrong side of the road (such as, no-one in front of you to slow you down), but in the long run you aren't making friends that way...

Edit: That paragraph above about "saying so" refers to the documentation value of "int32_t" vs. "int", of course.

If you think about it, why do compilers even have the types "int", "short", etc. anymore? It's not any faster, and it's not any simpler. Plus, I rarely have a circumstance where I don't care exactly how many bits I can use in an integer. If you want to make any remotely portable code, you're going to end up using int32_t and int16_t, or at least intmax_t, and that requires including an extra header.

Why doesn't the C standard simply force the compiler to have those types as builtins, instead of the normal integer types? Then people would write correct code *from the beginning*, without the argument of laziness for using normal types.

If I ever write a C compiler (and I'm planning to... eventually), I would more than happily throw "int" out the window.

[earlz]

...in its current version. (Yes, I admit, it is unlikely they'll change it, but...)

This ain't about portability. IMHO, this goes much, much deeper.

You need an integer of exactly 32 bits. If you are the type that will simply check if int or long is good enough and then uses that deserves every bit of pain buggy code ever inflicts on him. And some more.

"int" might be 32 bit, but it does neither guarantee nor say so. "int" says "a whatever-sized integer value, I don't really care". Whereas int32_t says "a 32bit integer, and make it exactly 32 bits because it's important".

And as for using standards vs. rolling your own... sure there might be some advantages in driving on the wrong side of the road (such as, no-one in front of you to slow you down), but in the long run you aren't making friends that way...

Edit: That paragraph above about "saying so" refers to the documentation value of "int32_t" vs. "int", of course.

If you think about it, why do compilers even have the types "int", "short", etc. anymore? It's not any faster, and it's not any simpler. Plus, I rarely have a circumstance where I don't care exactly how many bits I can use in an integer. If you want to make any remotely portable code, you're going to end up using int32_t and int16_t, or at least intmax_t, and that requires including an extra header.

Why doesn't the C standard simply force the compiler to have those types as builtins, instead of the normal integer types? Then people would write correct code *from the beginning*, without the argument of laziness for using normal types.

If I ever write a C compiler (and I'm planning to... eventually), I would more than happily throw "int" out the window.

This is very true.. Why do they have int?

Well, I have one reason, is the speed for trivial small things like cycling through a loop that should never grow to more than 200. For it, you would of course want the fastest integer possible, which presumably is int. And to cycle through such a list should not involve a design decision as to if your going to limit this to 16 bits or 32 bits or 64 bits..

I think the int32_fast_t or whatever they are called types need to be utilized more often(possibly by a better and shorter naming scheme)

Other than the speed and memory issue and the pain of typing intptr_t, I have no problem with int forever being gone as a generic unknown type of death.

[Troy Martin]

This is very true.. Why do they have int?

Cause generally, programmers that don't have a f**king clue about 32-bit integers versus 16-bit integers versus 64-bit ones etc. just use int in all their code cause "it's easier". Well, if I were a programmer that didn't need to deal with low-level stuffs like uint32_t and friends I'd just slap int everywhere without thinking about the bytes I could be saving by using short or char or the appropriate ?int*_t type.

[earlz]

This is very true.. Why do they have int?

Cause generally, programmers that don't have a f**king clue about 32-bit integers versus 16-bit integers versus 64-bit ones etc. just use int in all their code cause "it's easier". Well, if I were a programmer that didn't need to deal with low-level stuffs like uint32_t and friends I'd just slap int everywhere without thinking about the bytes I could be saving by using short or char or the appropriate ?int*_t type.

Well well... maybe programmers should be made more aware..

and when people make something like

Code: Select all

char *longstring;

...
int i;
for(i=0;i<strlen(longstring);i++){
   putc(longstring[i]);
}

and when they have "long" strings that take up 2gb of space(I'm sure it'll be possible and plausible one day) on their 64bit computer running Windows(where int is still 32bit) and wonder why their code either doesn't print the whole string or just utterly fails, and they wonder why it isn't working.. then They will finally realize it and suddenly it's Y2K all over again..

This could be much less of a problem though if we could safely assume sizeof(int)==sizeof(void*)

[pcmattman]

Code: Select all

for(i=0;i<strlen(longstring);i++){
   putc(longstring[i]);
}

Any decent compiler (MSVC's, and GCC, in the least) will throw a warning about the conversion from unsigned to signed (strlen returns a size_t). So your example is invalid, because programmers are made aware that their code is faulty.

Cause generally, programmers that don't have a f**king clue about 32-bit integers versus 16-bit integers versus 64-bit ones etc. just use int in all their code cause "it's easier"

Actually, the reason why we "still have" int is for backwards compatibility (with the current standard, too). If you'd like to make a variant of C that doesn't have int, short, etc... - go ahead. But it's non-standard C. Just use stdint.h, which was introduced in C99.

The names of each types worked fine when C was first created, because you would be targeting a specific hardware platform with your code. Once portability became a concern steps were taken to make it possible to write portable code without breaking old code.

[Troy Martin]

Looks like what we need to do is tell the world that int and friends are deprecated and we should all use the wonders of platform independent variable types.

[earlz]

Looks like what we need to do is tell the world that int and friends are deprecated and we should all use the wonders of platform independent variable types.

I still want to implement a language where you do

Code: Select all

int:8 byte;
int:16 word;
int:21 wtf;

so you can have any size you want.. lol

edit:
Anyone know how to specify a 16bit number in C where int and long are 64 bits? (presumably short would be 32)

And any hope of getting a uint128_t anytime soon?

[Troy Martin]

Anyone know how to specify a 16bit number in C where int and long are 64 bits? (presumably short would be 32)

Oh come on earlz, read through the topic again! Use uint16_t!

And any hope of getting a uint128_t anytime soon?

I think it's an unofficial extension on some compilers (likely MSVC) but as far as I know it's nonstandard. Might be standard in C1x, but as of the latest draft, I couldn't find anything about it. Googling it displays something about GCC 3.1 on the PowerPC having uint128_t.