Extracting the final 8 bits of a 64 bit integer.

Paul

unread,

Jul 24, 2015, 12:46:14 PM7/24/15

to

My code to extract the final 8 bits of a 64 bit integer is below:
I can't believe there isn't something more elegant and concise, perhaps by using bitset? Any ideas? Or is the below just fine?

Thanks,

Paul

const int bitShift = 8;
auto extractFinalBits = [bitShift](uint64_t y)->uint8_t{int result = 0; for(int i = 0; i < bitShift; ++i) if( (1 << i ) & y) result += (1 << i); return result;};

Victor Bazarov

unread,

Jul 24, 2015, 1:06:20 PM7/24/15

to

On 7/24/2015 12:45 PM, Paul wrote:
> My code to extract the final 8 bits of a 64 bit integer is below:

Which ones are "the final"? Lower or upper ones?

> I can't believe there isn't something more elegant and concise, perhaps by using bitset? Any ideas? Or is the below just fine?
>
> Thanks,
>
> Paul
>
> const int bitShift = 8;
> auto extractFinalBits = [bitShift](uint64_t y)->uint8_t{int result = 0; for(int i = 0; i < bitShift; ++i) if( (1 << i ) & y) result += (1 << i); return result;};
>

Do you think it's possible for you to wrap your lines and indent so the
code is actually readable?

And what is your test? To post a question on code (whether it works or
doesn't) you ought to post a complete (preferably compilable) program...

Back to your question, doesn't shift to the right 56 bits, then bitwise
AND with 0xff, work?

uint8_t res = uint8_t((y >> 56) & 0xff);

maybe?

V
--
I do not respond to top-posted replies, please don't ask

Scott Lurndal

unread,

Jul 24, 2015, 1:56:57 PM7/24/15

to

long long data64bit;

least significant 8 bits = data64bit & 0xff;
most significant 8 bits = data64bit >> 56;

Marcel Mueller

unread,

Jul 24, 2015, 3:02:56 PM7/24/15

to

On 24.07.15 19.56, Scott Lurndal wrote:
> long long data64bit;
>
> least significant 8 bits = data64bit & 0xff;
> most significant 8 bits = data64bit >> 56;

The latter might give unexpected results because of the signed shift if
assigned to something with more than 8 bits.

Marcel

Robert Wessel

unread,

Jul 24, 2015, 4:07:03 PM7/24/15

to

The OP's original code was shifting signed integers as well.

Victor Bazarov

unread,

Jul 24, 2015, 4:52:44 PM7/24/15

to

And it likely had undefined behavior if the 'int' was smaller than 64
bits...

Richard

unread,

Jul 26, 2015, 4:47:38 PM7/26/15

to

[Please do not mail me a copy of your followup]

Robert Wessel <robert...@yahoo.com> spake the secret code
<9m65ra901mfme5aok...@4ax.com> thusly:

>The OP's original code was shifting signed integers as well.

The formatting made it pretty hard to read, but the input variable was
of type 'uint64_t y'. The problem was that they didn't use this
directly and instead went through some crazy loopping over int's that
were shifted around.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

Juha Nieminen

unread,

Aug 3, 2015, 4:25:06 AM8/3/15

to

(data64bit >> 56) & 0xFF

It shouldn't even result in any additional opcodes if the compiler is
smart enough.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---