The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
[Programming] C# - converting bytes to uints and other fun stuff
(this is not homework, or an assignment. I program for a living and I am converting C++ code to C#, which is new to me)
I have a function which sends a command to some hardware. The command is a string. Prior to sending the command, I convert it to ASCII - it returns as a byte[] array:
Next, the data is handled by a function which checks that the byte array can be divided by 4. The byte array is then converted into a uint[] array (of 4 words) so that it can be copied into a memory register.
My problem is this - I need to rewrite the ASCII encoding function to handle byte arrays which may not necessarily be divisible by 4 without losing data... and I can't wrap my head around how to do this? I was thinking that when I do the encode, I should just take the byte array and break it into words, but I would need to pad out any 'empty' space in the words, if I didn't have byte data there?
I don't think there'd be a reliable way to take an array that has something like:
[4 bytes][4 bytes][4 bytes][2 bytes(zero space)][2 bytes][4 bytes] since they're sequential. How do you know those 2 sets of 2 bytes don't belong to a single 4 byte int? How do you know parts of the last 4 bytes aren't part of the 2nd 2 bytes? Maybe you should've 0 padded the 4 byte one at the end and taken 2 bytes?
Now if your array is just a collection of bytes always evenly divisible by 4, working your way down the array is the best way to do it.
If I'm understanding you right. Let me know if I misinterpreted what you're saying.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
You should probably be asking someone at your work about this because I feel like you need to understand the entire system to answer this question. You do need to pad somewhere, but to understand where and why you need to also understand what the input string is, how it's suppose to be stored in the register, and what the register is used for. To solve this problem I think it would be easiest to work backwards starting with whoever is using the memory register and what does it expect if the starting input is not divisible by 4 and then work from there.
In the C++ implementation, they sprintf the string command into a uint[100] array, so that when you split it into words which can be written to memory, the result is always divisible by 4. My supervisor does not want me to ape this approach in C# - he wants a smarter solution.
So far, I have the idea that i will calculate the number of full words from the byte array length, then calculate how many pads if any I will need at the end. (I think if I ever DO need to pad, it will always be at the end of the array, since I know I'll have complete words up until the end). Once I have created my list of full words, I will amend the list's last few elements with null values to make up the full word. This would seem to copy the c++ approach
Oh I think I get what you're saying. Yeah you'll want to pad it at the end.
Make sure you're using UInt32 too, and not just uint. Then you'll just use BitConverter.ToUInt32() to take those bytes and convert them into uint32s. The only reason I say this is I don't think "uint" guarantees you a 32 bit unsigned integer.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Posts
[4 bytes][4 bytes][4 bytes][2 bytes(zero space)][2 bytes][4 bytes] since they're sequential. How do you know those 2 sets of 2 bytes don't belong to a single 4 byte int? How do you know parts of the last 4 bytes aren't part of the 2nd 2 bytes? Maybe you should've 0 padded the 4 byte one at the end and taken 2 bytes?
Now if your array is just a collection of bytes always evenly divisible by 4, working your way down the array is the best way to do it.
If I'm understanding you right. Let me know if I misinterpreted what you're saying.
So far, I have the idea that i will calculate the number of full words from the byte array length, then calculate how many pads if any I will need at the end. (I think if I ever DO need to pad, it will always be at the end of the array, since I know I'll have complete words up until the end). Once I have created my list of full words, I will amend the list's last few elements with null values to make up the full word. This would seem to copy the c++ approach
Make sure you're using UInt32 too, and not just uint. Then you'll just use BitConverter.ToUInt32() to take those bytes and convert them into uint32s. The only reason I say this is I don't think "uint" guarantees you a 32 bit unsigned integer.