Spliting up an int?

#1 Google is your friend
www.google.com/search?hl=en&lr=&safe=off&q=split+int+into+bytes&btnG=Search

Most relevant result IMHO
www.digitalmars.com/d/archives/digitalmars/D/13217.html

#2 Use bitshifts and masks:

eg. for 32 bit integer value:

byte1 = intVal >> 24;
byte2 = (intVal >> 16) & 0xFF;
byte3 = (intVal >> 8) & 0xFF;
byte4 = intVal & 0xFF;

#3 ROFLMAO whoops!, my most relevant refference isn't for the C++ programming language... Oh well, sometimes I forget that there ARE other languages out there that can give you bit and byte level control.

#4 I'm not real solid on the whole "endianness" thing, but won't Chris's code behave differently on intel/amd vs PPC CPUs?

Or is this an endian-independant way of doing this?

#5 If you specify your integer to be 32 bits then you will have no problem. There are currently efforts to bring Torque to a 64bit stable version.. however, all stable versions are 32 bit, and hence that will work just fine.

#6 Mark is correct, due to the difference in byte order on i386 and PPC, Chris' code, although it would work and behave the same, the bytes would be in a different order. Its pretty easy to knock up a macro that returns the correct results based on a define for the CPU architecture.

#7 The easiest way is probably to get them into network byte order (AKA Big Endian) with the standard htonl()/ntonl() macros and work from there.

#8 .

#9 Man that's some mightly inefficient code

#10 @Thc-03,

Holy crap. Thats incredibly bizzare and inefficient. A much better solution, using the suggestions above, is:

unsigned int intVal = htonl(intToSplit);

byte1 = intVal >> 24;
byte2 = (intVal >> 16) & 0xFF;
byte3 = (intVal >> 8) & 0xFF;
byte4 = intVal & 0xFF;

Note: Not tested, but should work.

T.

#11 @Thc Hey man don't feel too bad about it, my code usually looks alot like that too... Did we go to the same school or something :)

#12 Using Tom's code is 2 orders of magnitude more efficent than THC's, and cross platform. In "Big O" notation, where 'n' is the number of bytes:

Tom's code: O(n) (one "step" per byte)

THC's: O(n^3 + n^2) -> O(n^3). (though it could be argued that the bottom loop is only O(n), due to the fixed size of the inner loops)

And that's just execution time... though admittedly, I have no idea how long htonl() takes. In terms of memory use, Tom's uses 4 "bytes" (though it's not clear whether they're chars, ints, or what. Assuming char's: 4 bytes), while THC's uses 39x4-byte variables. Tom's code will create and discard various temporaries (at most 2 ints: 8 bytes). THC's code creates a whole pile of stuff for the lifetime of his function, and has several temporaries as well (if((yourInt%temp) != 0): 1 temp, finalbyte[blah] *= blah * power(blah,blah): 2 (3?) temps)

Bottom line:
Don't loop when you can bit-shift.

#13 Mark,

Thanks for the walk through. I was going to post something similar but went to get dinner and when i got back you'd already posted it, and in a better way then I would of put it :)

A quick note on htonl() ... on some systems its implemented as a macro and on others its a function, so the speed varies. There's usually not much to it, though, and "my" function still runs in O(n). Also, on windows you have to link to WinSock to use it (or at least, use the headers. it may be a macro on windows, i forget). Personally, I would do the whole thing using macros, but using htonl() fitted with the above posts and it works regardless of the OS and is easier to explain.

T.

#14 I poked around google to see if I couldn't find a decent description of "Big O Notation" in the likely event that some of you don't have the foggiest idea of what the heck I'm talking about... but the only description I found confused ME. And I know the stuff already.

So I'm going to start my own thread to describe it... here:

www.garagegames.com/mg/forums/result.thread.php?qt=29748