Linked by Eugenia Loli on Mon 10th Oct 2005 16:48 UTC, submitted by Shlomi Fish
Permalink for comment 42864
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
Linked by Thom Holwerda on 05/16/13 21:41 UTC
Linked by Thom Holwerda on 05/16/13 17:04 UTC
Linked by Thom Holwerda on 05/16/13 13:17 UTC
Linked by Thom Holwerda on 05/16/13 12:06 UTC
More News »
Sponsored Links



Member since:
2005-07-06
And why on earth would I want to use a language that lets the programmer deal with it instead of doing it itself? I can't think of any situation where as a programmer you would want to have the endianess differences exposed to your programs (not even in drivers).
You're going to want endianess differences exposed whenever you're dealing with a binary encoding. This includes various binary encodings for network protocols, video and audio encodings and even the bytecode which a JVM or .Net runtime needs to decode. If the compiler automatically enforced the endianess of the hardware (and some hardware allows you to change the endianess, what then?) how would you go about encoding or decoding such binary protocols?
Besides encoding and decoding binary protocols, when would a programmer even worry about endian issues anyways? I can't think of one time that I was actually bothered by that in normal application code.