float vs double / int vs long

[MarkZWEERS]

Hi there!

I have some doubts about the issue "float vs double". I've heard people telling me that the 'double' type should be preferred over a 'float' type, since this is platform independent.

On "derkeiler" I've read this:

Type float is subject to "the default argument promotions".
Type double, isn't.

I've also followed a discussion about long vs int : that a 'long' is transparant to a 64-bit / 32-bit machine whereas 'int' isn't.

To short-cut once and for all my questions, could anyone enlighten me on this topic? Or give me a good information source on this topic? The standard seems not to treat this topic.

Thanks a lot in advance!

Mark

[matsp]

This is definitely not straight-forward. float takes up less space [generally and in practice - theoretically, and perhaps there are examples in real systems somewhere, the standard has nothing saying that a double and float CAN NOT be the same size - as long as doublle >= float, it's fine].

Float does indeed get converted when passed to functions that haven't got a float prototype. Also, variable arguments functions (such as printf) converts all floats to doubles.

Mixed expressions of float and double will also require conversion, and many standard functions (e.g. sin, sqrt) return double values, and at least in some cases, there are no float variants in C, in C++ there may be (but it could involve conversions).

For basic operations, on x86 at least, double and float take the same amount of time or so close that it's unlikely to make much difference (e.g. 22 vs 24 clock cycles for float vs double).

So the real benefit of float over double is if you have LOTS (100k+) of them, and as a consequence, fitting twice as many in the processor cache will lead to better performance.

As to long vs. int, there are many factors. The size of long may change when moving to 64-bit OS, it does in Linux, but it is still 32-bit on Windows, for example. There is likely to be no advantage in using 64-bit integers in general integer math on a 64-bit processor, as 32-bit operations are at least the same speed, and the code size [again, on x86 at least] is smaller.

And again, using long (if it is bigger than int) will use up more cache-space, meaning fewer elements of large arrays (etc) in the cache at any given time, meaning less performance.

Bear in mind tho', that different processors behave differently, and there may be situations where there is a benefit on some processors.

--
Mats

[Meldreth]

double vs float: double is the default floating type. if you say 123.456 it's a double until you cast to float or suffix it with f or F. that's why i prefer double. i haven't been in a situation where the size matters enough to justify a loss of precision.

int vs long: i work on windows, and they're both the same size. but int is the default integer type so i use int. if my code has to be portable and i expect numbers larger than the smallest portable range of -32,767 to 32,767, i use long. like double vs float i haven't had to worry about any size difference yet. it's all about the supported range of values.

[matsp]

int vs long: i work on windows, and they're both the same size. but int is the default integer type so i use int. if my code has to be portable and i expect numbers larger than the smallest portable range of -32,767 to 32,767, i use long. like double vs float i haven't had to worry about any size difference yet. it's all about the supported range of values.

But you are making assumptions that your code will always be in a particular environment. It could cause you to get 64-bit integers when you only really need 32-bit integers - no disaster, but a waste of space.

If you want portable code, you should use typedefs such as "uint32" or "int32" that are defined to the relevant int, long or whatever is right for that particular environment.

--
Mats

[Meldreth]

But you are making assumptions that your code will always be in a particular environment.

the only assumption i'm making is that there's always have enough room for the range of values i need. and it's not really an assumption because i guarantee it with my choice of types.

If you want portable code, you should use typedefs

what you mean is if i want a variable to have the same number of bits regardless of the environment. my way is still portable, i don't need typedefs unless i want to force an exact size.

[matsp]

Actually, long is only guranteed to be AT LEAST as big as int, so a machine CAN have a type long that is equal in size to int, and int is allowed to be 16 bits. So you are not actually guaranteed to fulfill your promise here.

And if you know you are using Windows [with a 32-bit compiler], there is no point AT ALL with using long.

However, if long turns into a 64-bit variable, it takes up twice as much space, which will affect performance, which is what MarkZWEERS was asking about (I think). That's no great deal if the variable is a single local variable, but in a large array or some such, having twice as large a memory foot print for no good reason is a bad idea.

You do not necessarily have to use names that imply a certain size, you could for exa, but using typedef makes it easy to change the code where there may be a need to change a type throughout the code.

--
Mats

[laserlight]

Actually, long is only guranteed to be AT LEAST as big as int, so a machine CAN have a type long that is equal in size to int, and int is allowed to be 16 bits. So you are not actually guaranteed to fulfill your promise here.

It is true that sizeof(int) <= sizeof(long), but it is also true that the range of int is at least [-32767,32767] and the range of long is at least [-2147483647,2147483647].

[matsp]

It is true that sizeof(int) <= sizeof(long), but it is also true that the range of int is at least [-32767,32767] and the range of long is at least [-2147483647,2147483647].

Ok, I didn't know that part of the standard.

--
Mats

[Meldreth]

Actually, long is only guranteed to be AT LEAST as big as int, so a machine CAN have a type long that is equal in size to int, and int is allowed to be 16 bits. So you are not actually guaranteed to fulfill your promise here.

that's not right. int is at least 16 bits and long is at least 32 bits. on 32 bit windows both int and long are 32 bits so the guarantee is still there.
[edit]laserlight beat me to it[/edit]

And if you know you are using Windows [with a 32-bit compiler], there is no point AT ALL with using long.

if i'm only going to use 32 bit windows, sure. but since you're the one harping about portability, you should understand why i treat them as different.

However, if long turns into a 64-bit variable, it takes up twice as much space, which will affect performance, which is what MarkZWEERS was asking about (I think).

it might affect performance, or it might not. you don't know and neither do i, until we measure.

That's no great deal if the variable is a single local variable, but in a large array or some such, having twice as large a memory foot print for no good reason is a bad idea.

now you're the one making assumptions. how do you know what i was thinking about when i explained my preferences? why do you think i always make the same choice regardless of the circumstances?

[matsp]

that's not right. int is at least 16 bits and long is at least 32 bits. on 32 bit windows both int and long are 32 bits so the guarantee is still there.
[edit]laserlight beat me to it[/edit]

Agreed, and I think we agree on the rest as well, aside from the fact that I prefer a typedef, so that you can easily change what a particular type actually compiles as, depending on the environment (compiler, processor, OS, etc). That way, there's no need to worry about whether long means 32 or 64, int means 16 or 32 (or 64) bits, etc.

Nearly always, using the right size variable is the right thing to do for optimal performance, so that comes out by itself.

--
Mats