How to Convert uint64 to uint32

[Explore_Imagination]

Hi All !!!

I am learning C++. Can any one guide me how we can efficiently convert
uint64 to unint32 ...

I am looking for an efficient way. E.g:

Let say I have a variable :

uint64 num = 6294967296;
Now I want to store value of "num" into two separate uint32
variables ???

Looking forward to hear from you guys.

/Hassan

 

[S S]

Hi All !!!

I am learning C++. Can any one guide me how we can efficiently convert
uint64 to unint32 ...

I am looking for an efficient way. E.g:

Let say I have a variable :

                                        uint64 num = 6294967296;
Now I want to store value of "num" into two separate uint32
variables ???

Looking forward to hear from you  guys.

/Hassan

uint64 num = 6294967296;
uint32 lsb = num & 0xffffffff;
uint32 msb = num >> 32;

 

[Andrey Tarasevich]

I am learning C++. Can any one guide me how we can efficiently convert
uint64 to unint32 ...

I am looking for an efficient way. E.g:

Let say I have a variable :

uint64 num = 6294967296;
Now I want to store value of "num" into two separate uint32
variables ???

Assuming that 'uint64' and 'uint32' are just names for some integral
types... well, just store it

uint64 num = 6294967296;

uint32 a, b;
a = num;
b = num;

That's it. The value of 'num' is now stored in two two separate uint32
variables (assuming that it fits).

 

[red floyd]

Hi All !!!

I am learning C++. Can any one guide me how we can efficiently convert
uint64 to unint32 ...

I am looking for an efficient way. E.g:

If you are learning C++, then to hell with "efficiency". Learn to
write programs that are correct, and then PROFILE before optimizing.

 

[Vaclav Haisman]

Explore_Imagination wrote, On 10.12.2008 17:16:

Hi All !!!

I am learning C++. Can any one guide me how we can efficiently convert
uint64 to unint32 ...

I am looking for an efficient way. E.g:

Let say I have a variable :

uint64 num = 6294967296;
Now I want to store value of "num" into two separate uint32
variables ???

uint64 num = 6294967296;
uint32 hi, lo;
hi = num >> 32;
lo = num & 0xFFFFFFFF;

Looking forward to hear from you guys.

/Hassan

--
VH


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAklACs4ACgkQhQBMvHf/WHkhOADeK9+J6tDbFcPOtSVdDiyiVyVv
XuvyKRh3zxGBLwDdHcHjD39e7XhCoOs2A1RlWpx7y7OQwygpgCwPAQ==
=ENJB
-----END PGP SIGNATURE-----

 

[S S]

Explore_Imagination wrote, On 10.12.2008 17:16:> Hi All !!!





uint64 num = 6294967296;
uint32 hi, lo;
hi = num >> 32;
lo = num & 0xFFFFFFFF;





--
VH

 signature.asc
< 1KViewDownload

I thought the same but why not just,
lo = num
it will truncate itself the lower part?

 

[Explore_Imagination]

Explore_Imagination wrote, On 10.12.2008 17:16:> Hi All !!!





uint64 num = 6294967296;
uint32 hi, lo;
hi = num >> 32;
lo = num & 0xFFFFFFFF;





--
VH

 signature.asc
< 1KViewDownload

Can you explain each step ... what you are doing here ... why you have
used 0xFFFFFFFF ...
Also i have tried this solution but inorder to verify when I added lo
+hi it should be
equal to num like

lo+hi = num ... but your solution doesn't satisfy it

 

[Per]

It's to extract the low 32 bits, even if uint32 is larger than that.

I would also have used the and-approach to really know what I get. I
don't see how it can harm in any way. Better safe than sorry.

/Per

 

[Juha Nieminen]

Also i have tried this solution but inorder to verify when I added lo
+hi it should be
equal to num like

lo+hi = num ... but your solution doesn't satisfy it

You don't get a 64-bit number by *adding* together two 32-bit numbers.
Adding two 32-bit numbers could at most get you a 33-bit number.

If you want to recombine the value:

uint64 value = (uint64(hi) << 32) | uint64(lo);

 

[Juha Nieminen]

uint64 num = 6294967296;
uint32 hi, lo;
hi = num >> 32;
lo = num & 0xFFFFFFFF;

I really can't understand what the "& 0xFFFFFFFF" is for. For all
intents and purposes it's a no-op (and if the compiler is smart enough,
it will completely remove it from the generated code).

In fact, you will probably get a compiler warning from those
assignments, so the better way to do it is using a cast:

uint32 hi = uint32(num >> 32);
uint32 lo = uint32(num);

 

[Joe Smith]

Agreed. This is an excellent point.

The largest exception here is efficency of algorithm (the asymptotic
complexity of an algorithm). It is often (but far from always) possible to
tell beforehand if a naive algorithm will cause problems, due to the size of
the relevent dataset(s).

However, except when it is obvious, even with algorithms, avoiding
pre-mature optimization can be useful. (If the code works only on a small
dataset, and has no need to scale, there is a good possibility the naive
algorithm could be more efficent than a "better" algorithm).

Of course, this is all second nature to most people who post here, but it is
worth repeating for the sake of everybody else.

 

[James Kanze]

On 2008-12-10 14:54:22 -0500, Paavo Helde <[email protected]> said:

No, it's not. The result is well defined (assuming the 'u' in
uint32 stands for "unsigned"). The result is "the least
unsigned integer congruent to the source integer (modulo 2^n,
where n is the number of bits used to represent the unsigned
type)". And if uint32 is signed the resulting value is
implementation defined.

I hope not. That's not a valid implementation-defined value.

In this case, C++ has simply adopted the C policy. (At least, I
hope that there is no intentional difference between how C and
C++ treat integers.) In C90, it apparently wasn't considered
clear what was meant by "implementation defined results": is a
core dump a "result"? C99 clarified the issue, and at the same
time, added some restrictions: it restrains the "results" to an
implementation defined value, or an implementation defined
signal. I would expect the next version of the C++ standard to
do likewise. (The wording in the current version has a couple
of errors, and needs reworking anyway, since it makes at least
on legal C implementation illegal, and makes it impossible to
implement C++ on at least one platform.)

 

[James Kanze]

I would also have used the and-approach to really know what I
get. I don't see how it can harm in any way. Better safe than
sorry.

It also has the advantage of making it visible that I'm
intentionally only taking the low order 32 bits. I regularly
and with 0xFF when I'm assigning to an unsigned char (which, of
course, might be more than 8 bits, but isn't on the platforms I
generally target).

 

[Explore_Imagination]

Its working fine

I really appreciate all of you for your positive feedback ... One more
thing that if we can
write a more generic code which should work on both little-endian and
big-endian architectures

Now I want to write a function which could map unit64 value to both
little and big endian architecture

 

[Juha Nieminen]

Why the explicit conversion?

Some C/C++ programming style guides suggest using explicit conversion
when assigning from a larger type to a smaller one so that the
conversion acts like self-documentation: By writing the conversion
explicitly you are documenting that "yes, I am intentionally assigning
from a larger type to a smaller one, even though it means that the
highest bits will be lost, this is not an oversight or bug".

Some compilers, such as gcc, will issue a warning in such a situation
if an explicit cast is not used (at least if enough warning flags have
been turned on). The explicit cast tells the compiler that the
assignment from a larger type to a smaller one is intentional and not a
mistake.

If the goal is to make the conversion
ugly, wouldn't static_cast be better?

The goal is not to make it ugly. The goal is to make it
self-documenting. I suppose using static_cast does the job equally well.

 

[Sana]

Its working fine

I really appreciate all of you for your positive feedback ... One more
thing that if we can
write a more generic code which should work on both little-endian and
big-endian architectures

Now I want to write a function which could map unit64 value to both
little and big endian architecture

The code, as is, works on both little and big endian architectures;
that is lo will always hold the least significant bits and hi will
always hold the most significant bits.

--sanatakos

 

[Juha Nieminen]

Hmmm, does an explicit cast differ from a cast (and is there such thing as
an implicit cast)?

Well, if you give eg. a char to a function taking an int, without
using any explicit casting, there's an implicit cast from char to int.

 

[Rolf Magnus]

Well, if you give eg. a char to a function taking an int, without
using any explicit casting, there's an implicit cast from char to int.

No, there isn't. Your example describes an implicit _conversion_. A cast is
what you write down if you want to explicitly convert something to another
type.

 

[Juha Nieminen]

No, there isn't. Your example describes an implicit _conversion_. A cast is
what you write down if you want to explicitly convert something to another
type.

Ok, well, if you give a non-const pointer to a function taking a const
pointer as parameter, is there an implicit cast from non-const to const
there?

 

[Triple-DES]

  Ok, well, if you give a non-const pointer to a function taking a const
pointer as parameter, is there an implicit cast from non-const to const
there?

Well, that would be still be an implicit conversion sequence
consisting of a qualification adjustment, or I guess, a qualification
_conversion_. But see my other post.