446,332 Members | 1,506 Online
Need help? Post your question and get tips & solutions from a community of 446,332 IT Pros & Developers. It's quick & easy.

# Value bits as compile-time constant!

 P: n/a Over on comp.lang.c, Hallvard B Furuseth devised a compile-time constant representing the amount of value representation bits in an unsigned integer type. In true C fashion, here it is as a macro: /* Number of bits in inttype_MAX, or in any (1< struct IMaxBits { template struct AllOnes { static unsigned const val = m /(m%0x3fffffffL+1) /0x3fffffffL %0x3fffffffL *30 + m%0x3fffffffL /(m%31+1)/31%31*5 + 4-12/(m%31+3); }; }; template struct AmountValueBits { static unsigned const val = IMaxBits::template AllOnes<-1>::val; }; #include #include #include #include template inline const char* CenterHoriz( const char * const p ) { using std::memset; using std::strlen; using std::size_t; static char spaces[width + 1]; memset( spaces, ' ', width ); size_t const len = strlen( p ); assert( width >= len ); char * const pos = spaces + ( width / 2 - len / 2 ); memcpy( pos, p, len ); return spaces; } #include extern char const str_uchar[] = "unsigned char"; extern char const str_ushort[] = "unsigned short"; extern char const str_uint[] = "unsigned int"; extern char const str_ulong[] = "unsigned long"; template void PrintRow() { using std::cout; unsigned const total_bits = sizeof(T) * AmountValueBits::val; unsigned const val_bits = AmountValueBits::val; unsigned const pad_bits = total_bits - val_bits; const char * const spaces_val = val_bits > 99 ? "" : ( val_bits > 9 ? " " : " " ); const char * const spaces_pad = pad_bits > 99 ? "" : ( pad_bits > 9 ? " " : " " ); const char * const spaces_total = total_bits > 99 ? "" : ( total_bits > 9 ? " " : " " ); cout << "||" << CenterHoriz<21>(str) << "|| " << spaces_val << val_bits << " || " << spaces_pad << pad_bits << " || " << spaces_total << total_bits << " ||\n" "--------------------------------------------------------------------- \n"; } int main() { using std::cout; cout << " ==============================================\n" " || Value bits || Padding Bits || Total Bits ||\n" "================================================= ==================== \n"; PrintRow(); PrintRow(); PrintRow(); PrintRow(); cout << "\n\n\n"; std::system( "PAUSE" ); } I'd be interested to hear if anyone gets some "interesting" values. -- Frederick Gotham Jun 25 '06 #1
12 Replies

 P: n/a * Frederick Gotham: Over on comp.lang.c, Hallvard B Furuseth devised a compile-time constant representing the amount of value representation bits in an unsigned integer type. In true C fashion, here it is as a macro: /* Number of bits in inttype_MAX, or in any (1<

 P: n/a "Frederick Gotham" wrote in message news:Xn***************************@194.125.133.14. .. Over on comp.lang.c, Hallvard B Furuseth devised a compile-time constant representing the amount of value representation bits in an unsigned integer type. In true C fashion, here it is as a macro: What does this mean: "the amount of value representation bits"? -Howard Jun 26 '06 #3

 P: n/a Howard wrote: "Frederick Gotham" wrote in message news:Xn***************************@194.125.133.14. .. Over on comp.lang.c, Hallvard B Furuseth devised a compile-time constant representing the amount of value representation bits in an unsigned integer type. In true C fashion, here it is as a macro: What does this mean: "the amount of value representation bits"? Substitute 'amount' with 'number', does it make it simpler? If not, substitue 'value representation' with 'value-representing'. If after that it's not clear, then the definition is probably "the number of bits involved in representing the value". V -- Please remove capital 'A's when replying by e-mail I do not respond to top-posted replies, please don't ask Jun 26 '06 #4

 P: n/a Howard posted: What does this mean: "the amount of value representation bits"? I'll work off an example. Let's say that a byte is 8-Bit, and that sizeof(unsigned short) == 4. Therefore, an "unsigned short" takes up 32 bits in memory. But that doesn't mean an unsigned short can use 32 bits to store its value. It might only use 30 of those bits; the rest are padding bits. The macro yields a compile time constant telling us how many bits take part in the "value representation" of the unsigned integer type. -- Frederick Gotham Jun 26 '06 #5

 P: n/a "Frederick Gotham" wrote in message news:Xn***************************@194.125.133.14. .. Howard posted: What does this mean: "the amount of value representation bits"? I'll work off an example. Let's say that a byte is 8-Bit, and that sizeof(unsigned short) == 4. Therefore, an "unsigned short" takes up 32 bits in memory. But that doesn't mean an unsigned short can use 32 bits to store its value. It might only use 30 of those bits; the rest are padding bits. The macro yields a compile time constant telling us how many bits take part in the "value representation" of the unsigned integer type. Interesting. I don't recall ever hearing of padding bits in a stored integer before (except perhaps way back in my old 60-bit Cyber mainframe days...but those memories are fading). Do any modern machines actually have them? All the machines I've worked with in recent years allow you to use (for example) all 32 bits of a 32-bit integer. The CPU may contain extra "flag" bits, but those don't reduce the amount useable in stored memory. -Howard Jun 26 '06 #6

 P: n/a Howard posted: Interesting. I don't recall ever hearing of padding bits in a stored integer before (except perhaps way back in my old 60-bit Cyber mainframe days...but those memories are fading). I think super-computers do it, something to do with "emphasizing floating-point arithmetic"... All the machines I've worked with in recent years allow you to use (for example) all 32 bits of a 32-bit integer. All the bits in memory belong to you, and they're yours to play around with, e.g.: unsigned short i; unsigned char *p = reinterpret_cast( &i ); unsigned char * const p_over = reinterpret_cast( &i + 1 ); do { *p++ = 0; } while( p != p_over ); But if you store a value as an unsigned short, then you don't have 2^32 unqiue values, but rather 2^30... even though it takes up 32 bits in memory. It's all about range really: 0 through ( 2^(amount value bits) ) - 1 -- Frederick Gotham Jun 26 '06 #7

 P: n/a "Frederick Gotham" wrote in message news:Xn***************************@194.125.133.14. .. Howard posted: Interesting. I don't recall ever hearing of padding bits in a stored integer before (except perhaps way back in my old 60-bit Cyber mainframe days...but those memories are fading). I think super-computers do it, something to do with "emphasizing floating-point arithmetic"... All the machines I've worked with in recent years allow you to use (for example) all 32 bits of a 32-bit integer. All the bits in memory belong to you, and they're yours to play around with, e.g.: unsigned short i; unsigned char *p = reinterpret_cast( &i ); unsigned char * const p_over = reinterpret_cast( &i + 1 ); do { *p++ = 0; } while( p != p_over ); But if you store a value as an unsigned short, then you don't have 2^32 unqiue values, but rather 2^30... even though it takes up 32 bits in memory. It's all about range really: 0 through ( 2^(amount value bits) ) - 1 (Assuming unsigned short is 30 bits, I guess. On my PC, it's 16 bits, and I think on my Mac as well.) Thanks, -Howard Jun 26 '06 #8

 P: n/a * Howard: (Assuming unsigned short is 30 bits, I guess. On my PC, it's 16 bits, and I think on my Mac as well.) Go back up the thread to find the context for the example. -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? Jun 26 '06 #9

 P: n/a In article , al*****@hotmail.com says... [ ... ] Interesting. I don't recall ever hearing of padding bits in a stored integer before (except perhaps way back in my old 60-bit Cyber mainframe days... Yup -- 40 significant bits and 20 padding bits. but those memories are fading). If you ever want to look at it, _Design of a Computer: The Control Data 6600_, by James Thornton has been scanned in and is available for download a number of places around the 'net. If you're ever struck with a _reallY_ serious bout of nostalgia, check out: http://members.iinet.net.au/~tom-hunter/ the "Desktop Cyber emulator home." It's almost even close to topical, being written in portable C. Do any modern machines actually have them? All the machines I've worked with in recent years allow you to use (for example) all 32 bits of a 32-bit integer. The CPU may contain extra "flag" bits, but those don't reduce the amount useable in stored memory. I've seen a compiler for a 12-bit DSP that stored char as 8 significant bits with 4 padding bits. That was a few years ago though. In the last few years, DSPs have started to look quite a bit more like mainstream CPUs (while CPUs have started to look a bit more like DSPs). -- Later, Jerry. The universe is a figment of its own imagination. Jun 26 '06 #10

 P: n/a * Jerry Coffin: I've seen a compiler for a 12-bit DSP that stored char as 8 significant bits with 4 padding bits. That would be a non-conforming compiler. For char all bits participate in the value representation. Per the standard. -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? Jun 26 '06 #11

 P: n/a In article <4g*************@individual.net>, al***@start.no says... * Jerry Coffin: I've seen a compiler for a 12-bit DSP that stored char as 8 significant bits with 4 padding bits. That would be a non-conforming compiler. For char all bits participate in the value representation. Per the standard. I should have pointed out that this was a C (89/90) compiler, which didn't have that requirement, if memory serves. OTOH, I'm not sure how conforming code could see the difference, so it might still be able to sneak in under the as-if rule. -- Later, Jerry. The universe is a figment of its own imagination. Jun 26 '06 #12

 P: n/a Jerry Coffin posted: In article <4g*************@individual.net>, al***@start.no says... * Jerry Coffin: > > I've seen a compiler for a 12-bit DSP that stored char as 8 > significant bits with 4 padding bits. That would be a non-conforming compiler. For char all bits participate in the value representation. Per the standard. I should have pointed out that this was a C (89/90) compiler, which didn't have that requirement, if memory serves. OTOH, I'm not sure how conforming code could see the difference, so it might still be able to sneak in under the as-if rule. In C++, only the following three types are guaranteed to contain no padding: char signed char unsigned char In C, only the following type is guaranteed to contain no padding: unsigned char -- Frederick Gotham Jun 26 '06 #13

### This discussion thread is closed

Replies have been disabled for this discussion.