Byte Array into a string of hex values?

[Lord Banshee]

i have a byte array as:

array<System::Byte> ^buf = gcnew array<System::Byte>(8);

Now i would like to know is there anyway to to turn all the 8 bytes into a string without using a for/loop? Is the an array function built in?

for example if:
buf[0] = 0xFF;
buf[1] = 0xAA;
buf[2] = 0xAA;
buf[3] = 0xAA;
buf[4] = 0xAA;
buf[5] = 0xAA;
buf[6] = 0xAA;
buf[7] = 0xFF;

and i want to do something like this

if ((buf.ToString("X") = "FFAAAAAAAAAAAAFF" )
// do something
else
// do something else

right now i am concatenated the bytes one by one with buf.ToString("X")

thanks

 

[aCynic2]

You can't do it directly. The 0xFF is numerical representation and the "FF" is a conceptual, textual representation. They don't coincide w/o some mathematical conversion.

Thus 0xFF != "0xFF".

Now, if you separate the nibbles using shifts and masking, then you can convert from that.

hinibb = buf >> 4;
lonibb = buf & 0x0F;

NOTE: you may need to mask the hibyte too. I haven't done this in years.

 

[Lord Banshee]

Actually the ToString("X") does make a single array value into a string that represents a hexadecimal value.

buf[0] = 0xFF;

if i do buf[0].ToString("X") it does make it into "FF". I wonder if i use a character array instead of byte array if such an option will exist.

Alternatively, i am sure this will work but i just want to learn more of the built in .Net stuff for learning purpose.

*edit this works*
array<System::Byte> ^buf = gcnew array<System::Byte>(8);
String ^myString = "";
String ^hexString = this->DeBug_txtSend->Text->ToString();
convert_String2Hex(hexString, &buf); // function i made
for (int i = 0; i <8; i++)
{
myString+= buf.ToString("X");
}

 

[sao123]

managed memory does not guarantee that the array will even be in memory as one piece... there is no guarantee that this will ever work...

now if you do it unmanaged like with new & delete...
then yes its easy.

 

[Lord Banshee]

What?

Are you saying the code with the for loop will not work? I could see what you are saying if i was using pointers but i am using the index of an array. Is there a managed way to get the individual values of an array? If so mind posting that

I am about to buy a MC++ book as this new stuff as nice as it is, is getting confusing.

Was thinking of either the first book or both

(1) http://www.amazon.com/C-CLI-Vi...&qid=1186671360&sr=8-2

(2)
http://www.amazon.com/Pro-Visu...&qid=1186671360&sr=8-2

or maybe this one
(3)
http://www.amazon.com/Ivor-Hor...&qid=1186671360&sr=8-2

 

[sao123]

Originally posted by: Lord Banshee
What?

Are you saying the code with the for loop will not work? I could see what you are saying if i was using pointers but i am using the index of an array. Is there a managed way to get the individual values of an array? If so mind posting that

I am about to buy a MC++ book as this new stuff as nice as it is, is getting confusing.

Was thinking of either the first book or both

(1) http://www.amazon.com/C-CLI-Vi...&qid=1186671360&sr=8-2

(2)
http://www.amazon.com/Pro-Visu...&qid=1186671360&sr=8-2

or maybe this one
(3)
http://www.amazon.com/Ivor-Hor...&qid=1186671360&sr=8-2

yes, I was thinking of you doing it with pointers. Pointers and managed memory do not mix well. Though at some point, arrays became a built in type...

I have this one...
Pro Visual C++/CLI and the .NET 2.0 Platform (Hardcover)
Its pretty in depth and thorough.

but I also generally use Deitel's books.
www.deitel.com

Regardless you need to make sure you buy the book for the current version of Visual Studio you are using... because MS C++ has changed through the years.
6.0, 2002.net, 2003.net, 2005.net

 

[smack Down]

Originally posted by: sao123
managed memory does not guarantee that the array will even be in memory as one piece... there is no guarantee that this will ever work...

now if you do it unmanaged like with new & delete...
then yes its easy.

Wait did you just say that there is no guarantee that an array will be in one piece of virtual memory, or are you talking about physical memory. Because if your talking about virtual memory either your an idiot for think that or MS is an idiot for designing it that way. That would make the system so slow.

 

[sao123]

Originally posted by: smack Down

Originally posted by: sao123
managed memory does not guarantee that the array will even be in memory as one piece... there is no guarantee that this will ever work...

now if you do it unmanaged like with new & delete...
then yes its easy.

Wait did you just say that there is no guarantee that an array will be in one piece of virtual memory, or are you talking about physical memory. Because if your talking about virtual memory either your an idiot for think that or MS is an idiot for designing it that way. That would make the system so slow.

under (.net 2.0) C++/CLI managed memory is not allocated the way it used to be...

whether you like it or not, managed memory runs from a virtual workspace. Pointers have been replaced by handles... A handle works like a pointer except that a)it cannot be converted to an integer, and b)you cannot do handle arithmatic...

under the old system, static variables came from the stack, and dynamic memory came from the Win32 heap. This is no longer the case. Everything comes from the .net framework managed heap, in an isolated workspace. Part of the reason this was done, is to make buffer overflow attacks more difficult. Regardless... arrays are not guaranteed to be linear in memory anymore, and pointer arithmatic has been eliminated.


I'm not saying that managed memory is faster or better... it is just a fact of life.

 

[aCynic2]

Originally posted by: sao123
whether you like it or not, managed memory runs from a virtual workspace. Pointers have been replaced by handles... A handle works like a pointer except that a)it cannot be converted to an integer, and b)you cannot do handle arithmatic...

That is why I will not use .NET or anything "managed" by MS. Their idea does not jive with mine. I'm more under the hood and I don't need MS hiding things from me.

Their C#, .NET and whatever else they're making, it's all going to sh*t.

This thread isn't about the pros and cons of C# and .NET, it's about the OP question. Another thread crap like this will have you posting elsewhere for a few days.
Anandtech Moderator - bsobel

 

[smack Down]

Originally posted by: sao123

Originally posted by: smack Down

Originally posted by: sao123
managed memory does not guarantee that the array will even be in memory as one piece... there is no guarantee that this will ever work...

now if you do it unmanaged like with new & delete...
then yes its easy.

Wait did you just say that there is no guarantee that an array will be in one piece of virtual memory, or are you talking about physical memory. Because if your talking about virtual memory either your an idiot for think that or MS is an idiot for designing it that way. That would make the system so slow.

under (.net 2.0) C++/CLI managed memory is not allocated the way it used to be...

whether you like it or not, managed memory runs from a virtual workspace. Pointers have been replaced by handles... A handle works like a pointer except that a)it cannot be converted to an integer, and b)you cannot do handle arithmatic...

under the old system, static variables came from the stack, and dynamic memory came from the Win32 heap. This is no longer the case. Everything comes from the .net framework managed heap, in an isolated workspace. Part of the reason this was done, is to make buffer overflow attacks more difficult. Regardless... arrays are not guaranteed to be linear in memory anymore, and pointer arithmatic has been eliminated.


I'm not saying that managed memory is faster or better... it is just a fact of life.

Weather the memory comes from the heap, or the stack has nothing to do with if arrays are linear in memory. Nor does being able to do pointer arithmetic. I just can' imagine that MS would be willing to take such a massive performance hit as to make an array into a linked list or hash table.

 

[sao123]

Originally posted by: smack Down

Originally posted by: sao123

Originally posted by: smack Down

Originally posted by: sao123
managed memory does not guarantee that the array will even be in memory as one piece... there is no guarantee that this will ever work...

now if you do it unmanaged like with new & delete...
then yes its easy.

Wait did you just say that there is no guarantee that an array will be in one piece of virtual memory, or are you talking about physical memory. Because if your talking about virtual memory either your an idiot for think that or MS is an idiot for designing it that way. That would make the system so slow.

under (.net 2.0) C++/CLI managed memory is not allocated the way it used to be...

whether you like it or not, managed memory runs from a virtual workspace. Pointers have been replaced by handles... A handle works like a pointer except that a)it cannot be converted to an integer, and b)you cannot do handle arithmatic...

under the old system, static variables came from the stack, and dynamic memory came from the Win32 heap. This is no longer the case. Everything comes from the .net framework managed heap, in an isolated workspace. Part of the reason this was done, is to make buffer overflow attacks more difficult. Regardless... arrays are not guaranteed to be linear in memory anymore, and pointer arithmatic has been eliminated.


I'm not saying that managed memory is faster or better... it is just a fact of life.

Weather the memory comes from the heap, or the stack has nothing to do with if arrays are linear in memory. Nor does being able to do pointer arithmetic. I just can' imagine that MS would be willing to take such a massive performance hit as to make an array into a linked list or hash table.

Weather? Is it storming there too?

Indeed it does matter. Only the managed heap is garbage collected... garbage collection means fragmented memory. Under C style memory allocation a new would simply just fail. Now garbage collection occurs and allocation may occur in fragments. This does not mean that arrays cant or wont be linearly allocated... just that because of fragmentation, they are not necessarily done so.

Also you have to remember now, arrays are now objects... not just a simple allocation of memory.

 

[Venix]

Originally posted by: sao123

Weather? Is it storming there too?

Indeed it does matter. Only the managed heap is garbage collected... garbage collection means fragmented memory. Under C style memory allocation a new would simply just fail. Now garbage collection occurs and allocation may occur in fragments. This does not mean that arrays cant or wont be linearly allocated... just that because of fragmentation, they are not necessarily done so.

Also you have to remember now, arrays are now objects... not just a simple allocation of memory.

In fact, .NET arrays are guaranteed to be contiguous.

Unsafe C# code can access a byte array with a pointer in exactly the same way C code can. Microsoft even provides an example of this.

 

[sao123]

Originally posted by: Venix

Originally posted by: sao123

Weather? Is it storming there too?

Indeed it does matter. Only the managed heap is garbage collected... garbage collection means fragmented memory. Under C style memory allocation a new would simply just fail. Now garbage collection occurs and allocation may occur in fragments. This does not mean that arrays cant or wont be linearly allocated... just that because of fragmentation, they are not necessarily done so.

Also you have to remember now, arrays are now objects... not just a simple allocation of memory.

In fact, .NET arrays are guaranteed to be contiguous.

Unsafe C# code can access a byte array with a pointer in exactly the same way C code can. Microsoft even provides an example of this.

Yes, there are special types of a pointers called a pin pointers and interior pointers, they prevent the structure they point to from being garbage collected and/or compacted. It didnt exist in C++.net 2002 or 2003 (framework 1.0,1.1) and to my knowledge isnt available in C++.net 2005 (.net 2.0). You can do this in C# however.


also I just stumbled upon something interesting... C# uses system::array while according to one of the microsoft books i have, C++ uses system::collections::Arraylist

Arraylist is a dynamically resizable array which is actually an indexable linked list...

I'm going to have to do some more reading.

 

[Venix]

Originally posted by: sao123
Yes, there are special types of a pointers called a pin pointers and interior pointers, they prevent the structure they point to from being garbage collected and/or compacted. It didnt exist in C++.net 2002 or 2003 (framework 1.0,1.1) and to my knowledge isnt available in C++.net 2005 (.net 2.0). You can do this in C# however.

? The entire purpose of Managed C++ and C++/CLI is simplified native interop, which would be rather difficult without pinning pointers.

If you use the horrible old Managed C++ syntax, declaring a pinning pointer is something more like "type __pin* var". The C++/CLI way is much nicer.

also I just stumbled upon something interesting... C# uses system::array while according to one of the microsoft books i have, C++ uses system::collections::Arraylist

Arraylist is a dynamically resizable array which is actually an indexable linked list...

I'm going to have to do some more reading.

No, C++/CLI's arrays are the same type as C#'s arrays. You can easily test this by calling a C++/CLI DLL from a C# project. An array<Byte>^ variable will appear as byte[] in the C# object browser.

Anyway, ArrayList, like arrays, is also guaranteed to store elements in contiguous memory. This primer on .NET data types should answer any questions you have.

 

[bsobel]

HexEncoding.ToString(byte[])

 

[sao123]

Originally posted by: Venix

Originally posted by: sao123
Yes, there are special types of a pointers called a pin pointers and interior pointers, they prevent the structure they point to from being garbage collected and/or compacted. It didnt exist in C++.net 2002 or 2003 (framework 1.0,1.1) and to my knowledge isnt available in C++.net 2005 (.net 2.0). You can do this in C# however.

? The entire purpose of Managed C++ and C++/CLI is simplified native interop, which would be rather difficult without pinning pointers.

If you use the horrible old Managed C++ syntax, declaring a pinning pointer is something more like "type __pin* var". The C++/CLI way is much nicer.

also I just stumbled upon something interesting... C# uses system::array while according to one of the microsoft books i have, C++ uses system::collections::Arraylist

Arraylist is a dynamically resizable array which is actually an indexable linked list...

I'm going to have to do some more reading.

No, C++/CLI's arrays are the same type as C#'s arrays. You can easily test this by calling a C++/CLI DLL from a C# project. An array<Byte>^ variable will appear as byte[] in the C# object browser.

Anyway, ArrayList, like arrays, is also guaranteed to store elements in contiguous memory. This primer on .NET data types should answer any questions you have.

Actually the text at the bottom of your article says exactly otherwise...



The ArrayList: a Heterogeneous, Self-Redimensioning Array
...

While the ArrayList provides added flexibility over the standard array, this flexibility comes at the cost of performance, especially when storing value types in an ArrayList. Recall that an array of a value type?such as a System.Int32, System.Double, System.Boolean, and so on?is stored contiguously in the managed heap in its unboxed form. The ArrayList's internal array, however, is an array of object references. Therefore, even if you have an ArrayList that stores nothing but value types, each ArrayList element is a reference to a boxed value type, as shown in Figure 3.

Diagram
Figure 3. The ArrayList contains a contiguous block of object references

The boxing and unboxing, along with the extra level of indirection that comes with using value types in an ArrayList, can hamper the performance of your application when using large ArrayLists with many reads and writes. As Figure 3 illustrates, the same memory layout occurs for reference types in both ArrayLists and arrays.

 

[Venix]

Originally posted by: sao123

Originally posted by: Venix

Originally posted by: sao123
Yes, there are special types of a pointers called a pin pointers and interior pointers, they prevent the structure they point to from being garbage collected and/or compacted. It didnt exist in C++.net 2002 or 2003 (framework 1.0,1.1) and to my knowledge isnt available in C++.net 2005 (.net 2.0). You can do this in C# however.

? The entire purpose of Managed C++ and C++/CLI is simplified native interop, which would be rather difficult without pinning pointers.

If you use the horrible old Managed C++ syntax, declaring a pinning pointer is something more like "type __pin* var". The C++/CLI way is much nicer.

also I just stumbled upon something interesting... C# uses system::array while according to one of the microsoft books i have, C++ uses system::collections::Arraylist

Arraylist is a dynamically resizable array which is actually an indexable linked list...

I'm going to have to do some more reading.

No, C++/CLI's arrays are the same type as C#'s arrays. You can easily test this by calling a C++/CLI DLL from a C# project. An array<Byte>^ variable will appear as byte[] in the C# object browser.

Anyway, ArrayList, like arrays, is also guaranteed to store elements in contiguous memory. This primer on .NET data types should answer any questions you have.

Actually the text at the bottom of your article says exactly otherwise...



The ArrayList: a Heterogeneous, Self-Redimensioning Array
...

While the ArrayList provides added flexibility over the standard array, this flexibility comes at the cost of performance, especially when storing value types in an ArrayList. Recall that an array of a value type?such as a System.Int32, System.Double, System.Boolean, and so on?is stored contiguously in the managed heap in its unboxed form. The ArrayList's internal array, however, is an array of object references. Therefore, even if you have an ArrayList that stores nothing but value types, each ArrayList element is a reference to a boxed value type, as shown in Figure 3.

Diagram
Figure 3. The ArrayList contains a contiguous block of object references

The boxing and unboxing, along with the extra level of indirection that comes with using value types in an ArrayList, can hamper the performance of your application when using large ArrayLists with many reads and writes. As Figure 3 illustrates, the same memory layout occurs for reference types in both ArrayLists and arrays.

"The ArrayList contains a contiguous block of object references." "Like the ArrayList, both the Queue and Stack classes store a contiguous collection of data and are data structures available in the .NET Framework Base Class Library."

I'm not sure what your point is. You incorrectly claimed that an ArrayList is a linked list. I countered by noting that it stores its elements contiguously like an array (in fact, it is implemented with an object[]), which is absolutely true. I never said anything even close to "An ArrayList stores unboxed value types directly."

In any case, it should now be abundantly clear that arrays and ArrayLists can not be fragmented.

 

[bsobel]

Originally posted by: bsobel
HexEncoding.ToString(byte[])

Back to the OP's question.... Hint ^^^^^^^

 

[Lord Banshee]

lol will try that as that is a lot simpler than using a for loop, less prone to mistakes.

 

[sao123]

Originally posted by: Venix

Originally posted by: sao123

Originally posted by: Venix

Originally posted by: sao123
Yes, there are special types of a pointers called a pin pointers and interior pointers, they prevent the structure they point to from being garbage collected and/or compacted. It didnt exist in C++.net 2002 or 2003 (framework 1.0,1.1) and to my knowledge isnt available in C++.net 2005 (.net 2.0). You can do this in C# however.

? The entire purpose of Managed C++ and C++/CLI is simplified native interop, which would be rather difficult without pinning pointers.

If you use the horrible old Managed C++ syntax, declaring a pinning pointer is something more like "type __pin* var". The C++/CLI way is much nicer.

also I just stumbled upon something interesting... C# uses system::array while according to one of the microsoft books i have, C++ uses system::collections::Arraylist

Arraylist is a dynamically resizable array which is actually an indexable linked list...

I'm going to have to do some more reading.

No, C++/CLI's arrays are the same type as C#'s arrays. You can easily test this by calling a C++/CLI DLL from a C# project. An array<Byte>^ variable will appear as byte[] in the C# object browser.

Anyway, ArrayList, like arrays, is also guaranteed to store elements in contiguous memory. This primer on .NET data types should answer any questions you have.

Actually the text at the bottom of your article says exactly otherwise...



The ArrayList: a Heterogeneous, Self-Redimensioning Array
...

While the ArrayList provides added flexibility over the standard array, this flexibility comes at the cost of performance, especially when storing value types in an ArrayList. Recall that an array of a value type?such as a System.Int32, System.Double, System.Boolean, and so on?is stored contiguously in the managed heap in its unboxed form. The ArrayList's internal array, however, is an array of object references. Therefore, even if you have an ArrayList that stores nothing but value types, each ArrayList element is a reference to a boxed value type, as shown in Figure 3.

Diagram
Figure 3. The ArrayList contains a contiguous block of object references

The boxing and unboxing, along with the extra level of indirection that comes with using value types in an ArrayList, can hamper the performance of your application when using large ArrayLists with many reads and writes. As Figure 3 illustrates, the same memory layout occurs for reference types in both ArrayLists and arrays.

"The ArrayList contains a contiguous block of object references." "Like the ArrayList, both the Queue and Stack classes store a contiguous collection of data and are data structures available in the .NET Framework Base Class Library."

I'm not sure what your point is. You incorrectly claimed that an ArrayList is a linked list. I countered by noting that it stores its elements contiguously like an array (in fact, it is implemented with an object[]), which is absolutely true. I never said anything even close to "An ArrayList stores unboxed value types directly."

In any case, it should now be abundantly clear that arrays and ArrayLists can not be fragmented.

The arraylist is merely an array of pointers (obviously the pointers are contiguous)... the actual "data" is fragmented... did you look at the picture? All those Boxed Int32s are the actual data...

 

[Venix]

Originally posted by: sao123
The arraylist is merely an array of pointers (obviously the pointers are contiguous)... the actual "data" is fragmented... did you look at the picture? All those Boxed Int32s are the actual data...

Duh! How else would an array of polymorphic types be implemented?

Using this brilliant "logic", SomeObject*[] in native C++ is also a "fragmented" array, which completely contradicts your earlier nonsense about garbage collection being the cause of fragmentation.

 

[smack Down]

Originally posted by: Venix

Originally posted by: sao123
The arraylist is merely an array of pointers (obviously the pointers are contiguous)... the actual "data" is fragmented... did you look at the picture? All those Boxed Int32s are the actual data...

Duh! How else would an array of polymorphic types be implemented?

Using this brilliant "logic", SomeObject*[] in native C++ is also a "fragmented" array, which completely contradicts your earlier nonsense about garbage collection being the cause of fragmentation.

Agreed the performance penalty from the fragmentation sao123 is talking about is almost zero compared to implementing an array as a linked list. Although there is a real penalty due to the extra dereference needed and more importantly there is no cache locality which creates lots of extra cache misses.