Jump to content


why bother with int char etc.


3 replies to this topic

#1 JapigeMan

    New Member

  • Members
  • PipPip
  • 15 posts

Posted 17 October 2005 - 07:53 PM

I was just wondering: why did they start all the fuss by making the length of int, char etc. dependant on the architecture?

Especially with the new 64 bit thing, I read that the length of some of the 64-bit primitives vary from compiler to compiler...

Just wondering...

thanks.

Oh, and does someone have some good link that deals with asm-izing a function? I have a copy-and-shift function that could maybe be optimized with asm/intrinsics and whatnot and I don't know much about it.
I never did any asm programming for those nice new big expensive PC CPUs...

#2 Rydinare

    New Member

  • Members
  • PipPip
  • 24 posts

Posted 17 October 2005 - 09:07 PM

JapigeMan said:

I was just wondering: why did they start all the fuss by making the length of int, char etc. dependant on the architecture?

Especially with the new 64 bit thing, I read that the length of some of the 64-bit primitives vary from compiler to compiler...

Has to do with speed. A 64-bit aligned type is faster on a 64-bit processor, a 32-bit aligned type is faster on a 32-bit processor, etc...

That's one (though not the only) reason why you may encounter code padding all structures to a 32-bit boundary (for example). Many compilers do this for you automatically, nowadays, though. However, it has its uses.

#3 Ed Mack

    Senior Member

  • Members
  • PipPipPipPip
  • 1239 posts

Posted 17 October 2005 - 09:12 PM

They are all sizes that provide the programmer sufficient storage, and will be efficiently processed on the target machine. We are not meant to think about the number of bits.

#4 Rydinare

    New Member

  • Members
  • PipPip
  • 24 posts

Posted 17 October 2005 - 09:41 PM

Ed Mack said:

They are all sizes that provide the programmer sufficient storage, and will be efficiently processed on the target machine. We are not meant to think about the number of bits.

In certain instances, the size does matter. For, example, when sending across the ethernet. In those cases, it's common to typedef in a header file things like:

uint8, uint16, uint32, etc...

and for each operating system you port to, you'll set the typedefs differently.

This is useful for things like sending across the ethernet, where in many cases, you don't want to waste any space (thus bandwith), if you don't have to, and you don't get a speed advantage from packing into larger padded structures.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users