automatic byte conversion?
-
I was working on some image filtering when I saw a problem in my output. After a little while I noticed two possible problems with the code after fixing one of them the output was, strangely enough, correct. Here's a part of the code: public struct Pixel { public byte r; public byte g; public byte b; public static bool operator >(Pixel p1,Pixel p2) { return p1.r + p1.g + p1.b > p2.r + p2.g + p2.b; } } Now my thought here was that since the r,g and b values are bytes, adding them could cause an overflow of the byte. For example: 128,128,128 would add up to 128 and would cause 64+64+64 to be greater then the second example since it adds up to 192 (192>128). However this does not seem to be the case, 128,128,128 seems to add up to 384 which would be impossible with a byte, so is the + operator actually changing my byte to a (u)long, (u)int or (u)short internally. Has anyone found any documentation on this issue, and can I expect this to work on any implementation of c#?
-
I was working on some image filtering when I saw a problem in my output. After a little while I noticed two possible problems with the code after fixing one of them the output was, strangely enough, correct. Here's a part of the code: public struct Pixel { public byte r; public byte g; public byte b; public static bool operator >(Pixel p1,Pixel p2) { return p1.r + p1.g + p1.b > p2.r + p2.g + p2.b; } } Now my thought here was that since the r,g and b values are bytes, adding them could cause an overflow of the byte. For example: 128,128,128 would add up to 128 and would cause 64+64+64 to be greater then the second example since it adds up to 192 (192>128). However this does not seem to be the case, 128,128,128 seems to add up to 384 which would be impossible with a byte, so is the + operator actually changing my byte to a (u)long, (u)int or (u)short internally. Has anyone found any documentation on this issue, and can I expect this to work on any implementation of c#?
Hi, expressions involving 8-bit or 16-bit integer variables (such as the bytes in a pixel) get computed using 32-bit integers, so there is an automatic promotion from byte to int, and the sum is an int. In your case, overflow is not possible. BTW: this is not only true for C#, it holds true for all C-like languages such as C, C++, Java :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
Hi, expressions involving 8-bit or 16-bit integer variables (such as the bytes in a pixel) get computed using 32-bit integers, so there is an automatic promotion from byte to int, and the sum is an int. In your case, overflow is not possible. BTW: this is not only true for C#, it holds true for all C-like languages such as C, C++, Java :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
Thanks for your input! I expected the byte to still behave as a true (8 bits) byte, does this also mean that ints work faster on a 32-bit machine then bytes do since a byte has to be processed to behave as a byte, example: byte b = (byte)0x04 + (byte)0x10; would be roughly translated to: int b = 0xff &((byte)0x04+(byte)0x10); And would a byte[12] take up the same amount of memory as an int[12] would, or would a byte array simply be a pointer to a field thats of the size int[3]
-
Thanks for your input! I expected the byte to still behave as a true (8 bits) byte, does this also mean that ints work faster on a 32-bit machine then bytes do since a byte has to be processed to behave as a byte, example: byte b = (byte)0x04 + (byte)0x10; would be roughly translated to: int b = 0xff &((byte)0x04+(byte)0x10); And would a byte[12] take up the same amount of memory as an int[12] would, or would a byte array simply be a pointer to a field thats of the size int[3]
That is a lot of questions. 1. speed Smaller variables typically don't get processed any faster or slower. Modern CPUs are capable of dealing with them very well. And storing the lowest byte or short of an integer is exactly the same as storing a byte or short, i.e. there are instructions that deal with the lower part of a register. 2. memory cost For single variables, the size is not really important. It only becomes important when you have a lot of them, as in large arrays. In general an array takes a number of bytes equal to the number of elements times the size (in bytes) of a single element. So int[12] is four times larger than byte[12]. Conclusion: don't bother choosing byte/short/int until it becomes relevant, e.g. because: - you want the overflow to occur (a value that should wrap from 255 to 0 can best be a byte) - you want to preserve memory (as in images that may hold thousands or millions of pixels) :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
That is a lot of questions. 1. speed Smaller variables typically don't get processed any faster or slower. Modern CPUs are capable of dealing with them very well. And storing the lowest byte or short of an integer is exactly the same as storing a byte or short, i.e. there are instructions that deal with the lower part of a register. 2. memory cost For single variables, the size is not really important. It only becomes important when you have a lot of them, as in large arrays. In general an array takes a number of bytes equal to the number of elements times the size (in bytes) of a single element. So int[12] is four times larger than byte[12]. Conclusion: don't bother choosing byte/short/int until it becomes relevant, e.g. because: - you want the overflow to occur (a value that should wrap from 255 to 0 can best be a byte) - you want to preserve memory (as in images that may hold thousands or millions of pixels) :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
Thanks a lot! Since the size of the pictures I'm dealing with is fairly large (up to 5MP on current devices) and the ammount of memory and CPU power is generally low (PPC's are not that fast), I have had to really keep down on the CPU load and memory usage. I've found your comments to be very helpful.
-
Thanks a lot! Since the size of the pictures I'm dealing with is fairly large (up to 5MP on current devices) and the ammount of memory and CPU power is generally low (PPC's are not that fast), I have had to really keep down on the CPU load and memory usage. I've found your comments to be very helpful.
you're welcome. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.