How to convert...

[Michel Racicot]

How can I convert a :

byte [4]

to a

UInt32

?

thank you

[psuedonym]

In my day we did it like this ;-)

UInt32 u = 0;
Byte[] b = new Byte[4] { 0x0A, 0x0B, 0x0C, 0x0D };

u = (UInt32)((b[0] << 24) | (b[1] << 16) | (b[2] << 8) | (b[3] << 0));

Now there's probably a function for it somewhere ..

"Michel Racicot" <mi*********************@cgi.com> wrote in message
news:u8**************@TK2MSFTNGP10.phx.gbl...

How can I convert a :

byte [4]

to a

UInt32

?

thank you

[Nicholas Paldino [.NET/C# MVP]]

Michel,

You can use the BitConverter class to do this, like this:

// Get the value from a byte array.
int pintValue = BitConverter.ToInt32(pbytArray, 0);

This assumes your array is named "pbytArray" and you want to get the
integer from the first four bytes.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Michel Racicot" <mi*********************@cgi.com> wrote in message
news:u8**************@TK2MSFTNGP10.phx.gbl...

How can I convert a :

byte [4]

to a

UInt32

?

thank you

[Juan Gabriel Del Cid]

> How can I convert a byte array (of length 4) to a to a UInt32?

Use this method:

BitConverter.ToInt32(byte []value, int startIndex)

That takes 4 bytes from startIndex and converts it to an integer.

That should do it,
-JG

[Jon Skeet [C# MVP]]

Michel Racicot <mi*********************@cgi.com> wrote:

How can I convert a :

byte [4]
to a
UInt32

?

BitConverter.ToUInt32(data, 0);

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Bret Mulvey [MS]]

"psuedonym" <AN***************@cfl.rr.com> wrote in message
news:u#**************@TK2MSFTNGP11.phx.gbl...

In my day we did it like this ;-)

UInt32 u = 0;
Byte[] b = new Byte[4] { 0x0A, 0x0B, 0x0C, 0x0D };

u = (UInt32)((b[0] << 24) | (b[1] << 16) | (b[2] << 8) | (b[3] << 0));

This is much faster than BitConverter.ToUInt32. Turning optimizing on makes
it about five times faster, whereas BitConverter.ToUInt32 only benefits
slightly from the optimize switch. BitConverter.ToUInt32 puts the first byte
in the least-significant position of the UInt32, whereas with your method
you can control it (you've done the reverse in your example).

Another approach that seems like it might be the fastest but is actually
slower than the above (but still way faster than BitConverter) is to use a
union struct to put the bytes in their position:

[StructLayout(LayoutKind.Explicit)]
struct UInt32Bytes
{
[FieldOffset(0)] public UInt32 u;
[FieldOffset(0)] public byte b0;
[FieldOffset(1)] public byte b1;
[FieldOffset(2)] public byte b2;
[FieldOffset(3)] public byte b3;
}

UInt32Bytes ubytes;
ubytes.u = 0;
ubytes.b0 = b[0];
ubytes.b1 = b[1];
ubytes.b2 = b[2];
ubytes.b3 = b[3];
u = ubytes.u;

This isn't worth doing for byte[4] to uint, but might have potential for
some more complex conversions. It's much less readible, though, and the
behavior varies with the machine endianness.

[Jon Skeet [C# MVP]]

Bret Mulvey [MS] <br***@online.microsoft.com> wrote:

"psuedonym" <AN***************@cfl.rr.com> wrote in message
news:u#**************@TK2MSFTNGP11.phx.gbl...

In my day we did it like this ;-)

UInt32 u = 0;
Byte[] b = new Byte[4] { 0x0A, 0x0B, 0x0C, 0x0D };

u = (UInt32)((b[0] << 24) | (b[1] << 16) | (b[2] << 8) | (b[3] << 0));

This is much faster than BitConverter.ToUInt32. Turning optimizing on makes
it about five times faster, whereas BitConverter.ToUInt32 only benefits
slightly from the optimize switch.

This is very odd - I would have thought the above would be pretty much
exactly what BitConverter.ToUInt32 would do, and that it would all be
inlined. Is it parameter checking which is slowing it down, do you
think?
BitConverter.ToUInt32 puts the first byte
in the least-significant position of the UInt32, whereas with your method
you can control it (you've done the reverse in your example).

It's not even that simple - BitConverter.ToUInt32 will put the first
byte in whichever position it thinks the platform prefers, so you can't
even depend on it doing a single thing across all platforms (if you're
considering non-Windows in the first place, that is). It's always
surprised me that BitConverter doesn't allow you to *set* the
endianness, or that there aren't two separate classes
LittleEndianBitConverter and BigEndianBitConverter.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[news.microsoft.com]

Isnt everything in .NET inline?

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Bret Mulvey [MS] <br***@online.microsoft.com> wrote:

"psuedonym" <AN***************@cfl.rr.com> wrote in message
news:u#**************@TK2MSFTNGP11.phx.gbl...

In my day we did it like this ;-)

UInt32 u = 0;
Byte[] b = new Byte[4] { 0x0A, 0x0B, 0x0C, 0x0D };

u = (UInt32)((b[0] << 24) | (b[1] << 16) | (b[2] << 8) | (b[3] << 0));

This is much faster than BitConverter.ToUInt32. Turning optimizing on makes it about five times faster, whereas BitConverter.ToUInt32 only benefits
slightly from the optimize switch.

This is very odd - I would have thought the above would be pretty much
exactly what BitConverter.ToUInt32 would do, and that it would all be
inlined. Is it parameter checking which is slowing it down, do you
think?

BitConverter.ToUInt32 puts the first byte
in the least-significant position of the UInt32, whereas with your method you can control it (you've done the reverse in your example).

It's not even that simple - BitConverter.ToUInt32 will put the first
byte in whichever position it thinks the platform prefers, so you can't
even depend on it doing a single thing across all platforms (if you're
considering non-Windows in the first place, that is). It's always
surprised me that BitConverter doesn't allow you to *set* the
endianness, or that there aren't two separate classes
LittleEndianBitConverter and BigEndianBitConverter.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[news.microsoft.com]

Roll yer own.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Bret Mulvey [MS] <br***@online.microsoft.com> wrote:

"psuedonym" <AN***************@cfl.rr.com> wrote in message
news:u#**************@TK2MSFTNGP11.phx.gbl...

In my day we did it like this ;-)

UInt32 u = 0;
Byte[] b = new Byte[4] { 0x0A, 0x0B, 0x0C, 0x0D };

u = (UInt32)((b[0] << 24) | (b[1] << 16) | (b[2] << 8) | (b[3] << 0));

This is much faster than BitConverter.ToUInt32. Turning optimizing on makes it about five times faster, whereas BitConverter.ToUInt32 only benefits
slightly from the optimize switch.

This is very odd - I would have thought the above would be pretty much
exactly what BitConverter.ToUInt32 would do, and that it would all be
inlined. Is it parameter checking which is slowing it down, do you
think?

BitConverter.ToUInt32 puts the first byte
in the least-significant position of the UInt32, whereas with your method you can control it (you've done the reverse in your example).

It's not even that simple - BitConverter.ToUInt32 will put the first
byte in whichever position it thinks the platform prefers, so you can't
even depend on it doing a single thing across all platforms (if you're
considering non-Windows in the first place, that is). It's always
surprised me that BitConverter doesn't allow you to *set* the
endianness, or that there aren't two separate classes
LittleEndianBitConverter and BigEndianBitConverter.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

news.microsoft.com <di********@discussion.microsoft.com> wrote:

Isnt everything in .NET inline?

No - I don't think you're talking about "inline" in the same way I am.
I'm talking about the JIT inlining some method/property calls by
replacing the call with the code itself (so that, say, simple access to
a field by way of a property is no less efficient than accessing the
field directly).

The JIT doesn't inline methods over a certain size, or which violate
certain conditions (things like try/catch, throwing exceptions, loops,
conditionals - I can't remember exactly now).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

news.microsoft.com <di********@discussion.microsoft.com> wrote:

Roll yer own.

I could certainly do that - but it seems daft for everyone to do that
when MS could perfectly easily do it themselves, once, and everyone
could use that. They clearly recognise the need for this kind of
functionality, but haven't recognised the need for it to be specific in
terms of endianness.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[news.microsoft.com]

I think you will find alot of Daft things in the libraries., its nice to see
some rich classes but what I actually find NECESSARY, just isnt there and am
dropping back to DllImport. So, I spend ALOT of my time doing things they
SHOULD have done in the first place.

The more you look the more you will find that the libraries are a swiss
cheese of funcationality.

In some cases there is gaps so large Darth Vader could pilot the Death Star
through after a binge on a saturday night.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

news.microsoft.com <di********@discussion.microsoft.com> wrote:

Roll yer own.

I could certainly do that - but it seems daft for everyone to do that
when MS could perfectly easily do it themselves, once, and everyone
could use that. They clearly recognise the need for this kind of
functionality, but haven't recognised the need for it to be specific in
terms of endianness.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

news.microsoft.com <di********@discussion.microsoft.com> wrote:

I think you will find alot of Daft things in the libraries., its nice to see
some rich classes but what I actually find NECESSARY, just isnt there and am
dropping back to DllImport. So, I spend ALOT of my time doing things they
SHOULD have done in the first place.

The more you look the more you will find that the libraries are a swiss
cheese of funcationality.

In some cases there is gaps so large Darth Vader could pilot the Death Star
through after a binge on a saturday night.

I agree there are some holes, although I wouldn't put it as strongly as
you. The one I've banged my head against is the lack of real timezone
support - it's *almost* there, but only if you only want the system
timezone! I would imagine this will be fixed in the next version
though, as many people have been asking for it. (I know there are third
party libraries around to fix this, of course.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[news.microsoft.com]

I would.

Serial communication for one.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

news.microsoft.com <di********@discussion.microsoft.com> wrote:

I think you will find alot of Daft things in the libraries., its nice to see some rich classes but what I actually find NECESSARY, just isnt there and am dropping back to DllImport. So, I spend ALOT of my time doing things they SHOULD have done in the first place.

The more you look the more you will find that the libraries are a swiss
cheese of funcationality.

In some cases there is gaps so large Darth Vader could pilot the Death Star through after a binge on a saturday night.

I agree there are some holes, although I wouldn't put it as strongly as
you. The one I've banged my head against is the lack of real timezone
support - it's *almost* there, but only if you only want the system
timezone! I would imagine this will be fixed in the next version
though, as many people have been asking for it. (I know there are third
party libraries around to fix this, of course.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[psuedonym]

"Bret Mulvey [MS]" <br***@online.microsoft.com> wrote in message
news:kvIlb.1560$9E1.12727@attbi_s52...

"psuedonym" <AN***************@cfl.rr.com> wrote in message
news:u#**************@TK2MSFTNGP11.phx.gbl...

In my day we did it like this ;-)

UInt32 u = 0;
Byte[] b = new Byte[4] { 0x0A, 0x0B, 0x0C, 0x0D };

u = (UInt32)((b[0] << 24) | (b[1] << 16) | (b[2] << 8) | (b[3] << 0));

This is much faster than BitConverter.ToUInt32. Turning optimizing on

makes it about five times faster, whereas BitConverter.ToUInt32 only benefits
slightly from the optimize switch. BitConverter.ToUInt32 puts the first byte in the least-significant position of the UInt32, whereas with your method
you can control it (you've done the reverse in your example).

[snip]

It wouldn't surprise me if BitConverter is multiplying by powers of 2
instead of using shift/or. That'd slow it down some.

[Bret Mulvey [MS]]

"psuedonym" <AN***************@cfl.rr.com> wrote in message
news:us**************@TK2MSFTNGP12.phx.gbl...

It wouldn't surprise me if BitConverter is multiplying by powers of 2
instead of using shift/or. That'd slow it down some.

You mean like

u = b[0] + b[1] * 0x100U + b[2] * 0x10000U + b[3] * 0x1000000U;

This is actually almost as fast as shifting. In debug mode it's even a
smidge faster.

No, BitConverter is "extern" so I wonder if it's popping out to an unmanaged
code layer. Even if you do all the parameter checking and the whole thing in
C#, it's still only 3x slower than above, instead of 5x or 6x slower like
BitConverter.

[psuedonym]

"Bret Mulvey [MS]" <br***@online.microsoft.com> wrote in message
news:p3%lb.5311$mZ5.27788@attbi_s54...

[snip] You mean like

u = b[0] + b[1] * 0x100U + b[2] * 0x10000U + b[3] * 0x1000000U;

This is actually almost as fast as shifting. In debug mode it's even a
smidge faster.

No, BitConverter is "extern" so I wonder if it's popping out to an unmanaged code layer. Even if you do all the parameter checking and the whole thing in C#, it's still only 3x slower than above, instead of 5x or 6x slower like
BitConverter.

Actually I was thinking more of something like this:

// equates to BitConverter params
Byte[] b = new Byte[4] { 0x0A, 0x0B, 0x0C, 0x0D };
int n = 0; // start index

// local vars
int x = 0; // exponent
UInt32 u = 0; // result

for(int i = 0; i < 4; i++)
{
u += (UInt32)(b[n++] * (2 ^ x));
x += 8;
}