Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> byte order doesn't matter.

> Let's say your data stream has a little-endian-encoded 32-bit integer. Here's how to extract it (assuming unsigned bytes):

    i = (data[0]<<0) | (data[1]<<8) | (data[2]<<16) | (data[3]<<24);
Wait, if byte order doesn't matter, why do I need to do byte-level array lookups when i'm processing a stream of integers? Oh yeah, because byte order does matter. If byte order wouldn't matter (say, if all computers were 32-bit, had the same byte order and the same endianness), I could just cast the stream to int* and be done with it. I can't, because of byte order. It matters.

Whether you deal with it using byte-array lookups and math or #ifdefs and bitmasks, well, whatever rocks your boat man! Good that you're taking it into account, because byte order matters!



Did you bother to read the article? He writes that native byte order doesn't matter, not, as you botched the quote "byte order doesn't matter".

The byte order of the input data obviously matters, and nothing you've said here disagrees with anything he wrote.


I think that skrebel is trying to say that doing as the article suggests comes with an unnecessary performance penalty hit if your CPU has the same endianness as the data stream.


Why should there be a any performance penalty? A good compiler (and I've worked with at least one that could) would know the machine's endianness and could optimize away that sequence of selections, shifts and ors when it isn't needed.


Ok, but the performance penalty is then at compile time...


Lots of downvotes... Do you disagree? If so, why? Or do you think it is insignificant?

I've sat and watch C++ compile for 5 hours... Compile time performance is important too!


wtf? I didn't botch any quote. It's the last words of the article.


"...the computer's byte order shouldn't matter to you one bit. Notice the phrase "computer's byte order". What does matter is the byte order of a peripheral or encoded data stream"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: