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

# Max value of an integer type?

 P: n/a I'm writing a template, and I need to know the maximum value of a given integer type at compile time. something like: template class Arb { public: static NumType const max = /* maximum value */; }; If the template were only to be used with unsigned integer types, then I'd do the following: template class Arb { public: static NumType const max = -1; }; I need a compile-time constant which evaluates to the maximum value of an integer type. Any ideas? If it weren't undefined behaviour to overflow a signed integer, I could use a metaprogramming technique such as the following: template struct MaxIntVal { private: static T const internal = 1 + MaxIntVal
35 Replies

 P: n/a * Frederick Gotham: I'm writing a template, and I need to know the maximum value of a given integer type at compile time. template< typename T struct Max; template{ static int const value = INT_MAX; }; and so on -- 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? Jul 4 '06 #2

 P: n/a Frederick Gotham wrote: > I need a compile-time constant which evaluates to the maximum value of an integer type. Are you sure it has to be compile time? If not just use std::numeric_limits::max() -- Ian Collins. Jul 4 '06 #3

 P: n/a I have a solution (although I intend on making it more compile-time- efficient as I can assume that "digits" is at least 7). #include template< class T, T shift_by = 0, bool no_more_digits = shift_by == std::numeric_limits ::digits > struct IntMax { private: static T const one = 1; public: static T const val = (one << shift_by) | IntMax::val; }; template struct IntMax int main() { std::cout << "Max values\n" "============\n\n" " Signed char: " << (int)IntMax::val << "\nSigned short: " << IntMax::val << "\n Signed int: " << IntMax::val << "\n Signed long: " << IntMax::val; } -- Frederick Gotham Jul 4 '06 #4

 P: n/a Frederick Gotham posted: > I have a solution (although I intend on making it more compile-time- efficient as I can assume that "digits" is at least 7). Here's the more efficient version: #include template< class T, T shift_by, bool no_more_digits = shift_by == std::numeric_limits ::digits > struct IntMax_Internal { private: static T const one = 1; public: static T const val = (one << shift_by) | IntMax_Internal::val; }; template struct IntMax_Internal struct IntMax { private: static T const one_two_seven = 127; public: static T const val = one_two_seven | IntMax_Internal::val; }; #include int main() { std::cout << "Max values\n" "==========\n\n" " Unsigned char: " << (int)IntMax::val << "\nUnsigned short: " << IntMax::val << "\n Unsigned int: " << IntMax::val << "\n Unsigned long: " << IntMax::val << "\n\n Signed char: " << (int)IntMax::val << "\n Signed short: " << IntMax::val << "\n Signed int: " << IntMax::val << "\n Signed long: " << IntMax::val; } -- Frederick Gotham Jul 5 '06 #5

 P: n/a Frederick Gotham wrote: template< class T, T shift_by, bool no_more_digits = shift_by == std::numeric_limits ::digits > .... Although this would probably work 99% of the time, I think technically that the standard does not require 2s compliment arithmetic (or whatever it is called) - ie you can't assume setting all bits to 1 gives you the largest value. As mentioned earlier, I think you would be better using INT_MAX, etc in a bunch of specializations. If you wanted to get really perverse, you might be able to do something somehow similar to using bits - recursively double the value until it doesn't get bigger, then (restore last largest value and) start adding half as much, then 1/4, etc until you are not adding anything. eg if max is 20 (strange max!) search = 1; try adding 2? =search = 3; + 4 ? =search = 7; + 8 ? =search = 15; + 16 ? =overflow!! - back off! + 8 ? =overflow!! + 4 ? =search = 19 + 2 ? =overflow! + 1 ? =search = 20. stop because you are at 1. If there was 'room' to add another 1, then + 2 would have worked. Anyhow, perserve, and not really understandable by the next coder who looks at it - even if that is you 2 years from now. But I suspect it could be coded with templates. Of course, I don't know what the standard says will happen when compile time constants 'overflow'.... - Tony Jul 5 '06 #6

 P: n/a Frederick Gotham wrote: I have a solution (although I intend on making it more compile-time- efficient as I can assume that "digits" is at least 7). #include template< class T, T shift_by = 0, bool no_more_digits = shift_by == std::numeric_limits ::digits > struct IntMax { private: static T const one = 1; public: static T const val = (one << shift_by) | IntMax::val; }; template struct IntMax struct intinfo { static const T max = (static_cast(1) << std::numeric_limits::digits - 1) - 1 << 1 | 1; }; Or are there some special cases this doesn't handle correctly? Jul 5 '06 #7

 P: n/a Ian Collins wrote: Frederick Gotham wrote: >>I need a compile-time constant which evaluates to the maximum value of aninteger type. Are you sure it has to be compile time? If not just use std::numeric_limits::max() I guess there must be a good reason why this is not a compile-time constant, but a function. I don't think that there could be an implementation where those values change during runtime, so what is the reason to make it a function? Jul 5 '06 #8

 P: n/a posted: > Frederick Gotham wrote: >template< class T, T shift_by, bool no_more_digits = shift_by == std::numeric_limits::digits > > ... Although this would probably work 99% of the time, I think technically that the standard does not require 2s compliment arithmetic (or whatever it is called) - ie you can't assume setting all bits to 1 gives you the largest value. "digits" gives you the amount of value bits, excluding the sign bit. If the sign bit (if any) is zero, and if all the rest of the bits are 1, then you have the max value. -- Frederick Gotham Jul 5 '06 #9

 P: n/a =?utf-8?B?SGFyYWxkIHZhbiBExLNr?= posted: If you can use numeric_limits::digits, wouldn't this be simpler? template struct intinfo { static const T max = (static_cast(1) << std::numeric_limits::digits - 1) - 1 << 1 | 1; }; Or are there some special cases this doesn't handle correctly? That's brilliant. Here's the updated code: #include template struct IntMax { private: static T const MSBOnly = static_cast(1) << std::numeric_limits ::digits - 1; public: static T const val = MSBOnly | MSBOnly - 1; }; #include int main() { std::cout << "Max values\n" "==========\n\n" " Unsigned char: " << (int)IntMax::val << "\nUnsigned short: " << IntMax::val << "\n Unsigned int: " << IntMax::val << "\n Unsigned long: " << IntMax::val << "\n\n Signed char: " << (int)IntMax::val << "\n Signed short: " << IntMax::val << "\n Signed int: " << IntMax::val << "\n Signed long: " << IntMax::val; } -- Frederick Gotham Jul 5 '06 #10

 P: n/a "Frederick Gotham" >Frederick Gotham wrote: >>template< class T, T shift_by, bool no_more_digits = shift_by == std::numeric_limits::digits > ...Although this would probably work 99% of the time, I thinktechnicallythat the standard does not require 2s compliment arithmetic (orwhatever it is called) - ie you can't assume setting all bits to 1gives you the largest value. "digits" gives you the amount of value bits, excluding the sign bit. If the sign bit (if any) is zero, and if all the rest of the bits are 1, then you have the max value. This of course assumes that all the bits take part in the value representation. Not a requirement. You are now at 99.5% mark, I guess. :-) There is a reason for the seemingly redundant values in numeric_limits - implementations are allowed to have unusual values for some of them. Bo Persson Jul 5 '06 #11

 P: n/a Bo Persson posted: This of course assumes that all the bits take part in the value representation. Not a requirement. 18.2.1.2 numeric_limits members static const int digits; 6 Number of radix digits that can be represented without change. 7 For built-in integer types, the number of non-sign bits in the representation. -- Frederick Gotham Jul 5 '06 #12

 P: n/a Bo Persson wrote: >"digits" gives you the amount of value bits, excluding the sign bit.If the sign bit (if any) is zero, and if all the rest of the bitsare 1,then you have the max value. This of course assumes that all the bits take part in the value representation. AFAICS, it doesn't. As Frederick wrote, "digits" gives you the amount of _value bits_, not the total amount of bits. Jul 5 '06 #13

 P: n/a * Frederick Gotham: =?utf-8?B?SGFyYWxkIHZhbiBExLNr?= posted: >If you can use numeric_limits::digits, wouldn't this be simpler?template struct intinfo { static const T max = (static_cast(1) <::digits - 1) - 1 << 1 | 1;};Or are there some special cases this doesn't handle correctly? That's brilliant. Here's the updated code: #include template struct IntMax { private: static T const MSBOnly = static_cast(1) << std::numeric_limits ::digits - 1; public: static T const val = MSBOnly | MSBOnly - 1; }; It's good fun to throw academic spanners into practical wheels, so, where does the standard exclude a grey-code representation? ;-) -- 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? Jul 5 '06 #14

 P: n/a Alf P. Steinbach posted: It's good fun to throw academic spanners into practical wheels, so, where does the standard exclude a grey-code representation? ;-) Only caveat that comes to mind is negative zero... but that shouldn't be an issue here. Unless you're talking about left-shifting a signed integer type... ? (Not quite sure what you mean by "exclude a grey-code representation") -- Frederick Gotham Jul 5 '06 #15

 P: n/a * Frederick Gotham: Alf P. Steinbach posted: >It's good fun to throw academic spanners into practical wheels, so,where does the standard exclude a grey-code representation? ;-) Only caveat that comes to mind is negative zero... but that shouldn't be an issue here. Unless you're talking about left-shifting a signed integer type... ? (Not quite sure what you mean by "exclude a grey-code representation") Frederick, I give you also (as I gave Protoman)... WIKIPEDIA! Note the bit pattern for the highest value when using a given number of bits. Sorry for the typo. Coming from a whaling country, I naturally prefer Earl Grey tea... -- 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? Jul 5 '06 #16

 P: n/a Alf P. Steinbach posted: Note the bit pattern for the highest value when using a given number of bits. I was under the assumption that C++ had to store positive values as follows: 0: 0000 1: 0001 2: 0010 3: 0011 4: 0100 5: 0101 6: 0110 7: 0111 8: 1000 9: 1001 10: 1010 11: 1011 12: 1100 13: 1101 14: 1110 15: 1111 Are you saying that: (A) The machine could use another method such as "Gray code". and (B) My code could break on other systems, and thus isn't trully portable? -- Frederick Gotham Jul 5 '06 #17

 P: n/a Alf P. Steinbach wrote: It's good fun to throw academic spanners into practical wheels, so, where does the standard exclude a grey-code representation? ;-) Hmm, I would have said 3.9.1/7, but after reading it again, it seems that this actually doesn't prohibit a grey-code representation. Jul 5 '06 #18

 P: n/a Rolf Magnus wrote: Alf P. Steinbach wrote: >It's good fun to throw academic spanners into practical wheels, so,where does the standard exclude a grey-code representation? ;-) Hmm, I would have said 3.9.1/7, but after reading it again, it seems that this actually doesn't prohibit a grey-code representation. Ok, now I have one: 5.8/2. Jul 5 '06 #19

 P: n/a Rolf Magnus posted: Ok, now I have one: 5.8/2. The value of E1 << E2 is E1 (interpreted as a bit pattern) left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned type, the value of the result is E1 multiplied by the quantity 2 raised to the power E2, reduced modulo ULONG_MAX+1 if E1 has type unsigned long, UINT_MAX+1 otherwise. Is it the "vacated bits are zero-filled" part that you're talking about? -- Frederick Gotham Jul 5 '06 #20

 P: n/a * Frederick Gotham: Alf P. Steinbach posted: >Note the bit pattern for the highest value when using a given number ofbits. I was under the assumption that C++ had to store positive values as follows: 0: 0000 1: 0001 2: 0010 3: 0011 4: 0100 5: 0101 6: 0110 7: 0111 8: 1000 9: 1001 10: 1010 11: 1011 12: 1100 13: 1101 14: 1110 15: 1111 Are you saying that: (A) The machine could use another method such as "Gray code". and (B) My code could break on other systems, and thus isn't trully portable? It's just academic, but yes. §5.8/2 defines the result of << as a bit-level operation, and as a value only for unsigned types. §5.8/3 defines the result of >as a bit-level operation and as a value both for signed and unsigned types (the latter only for non-negative values). The cases excluded from these definitions are, AFAICT, exactly those where the definitions would otherwise be incompatible with grey-code... -- 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? Jul 5 '06 #21

 P: n/a * Rolf Magnus: Rolf Magnus wrote: >Alf P. Steinbach wrote: >>It's good fun to throw academic spanners into practical wheels, so,where does the standard exclude a grey-code representation? ;-) Hmm, I would have said 3.9.1/7, but after reading it again, it seems thatthis actually doesn't prohibit a grey-code representation. Ok, now I have one: 5.8/2. Nope, not as far as I can see: it's /very/ ingeniously worded so that the cases that could be incompatible are simply not defined. -- 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? Jul 5 '06 #22

 P: n/a * Alf P. Steinbach: grey-code Sorry, again: _gray code_. -- 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? Jul 5 '06 #23

 P: n/a Frederick Gotham wrote: Rolf Magnus posted: >Ok, now I have one: 5.8/2. The value of E1 << E2 is E1 (interpreted as a bit pattern) left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned type, the value of the result is E1 multiplied by the quantity 2 raised to the power E2, reduced modulo ULONG_MAX+1 if E1 has type unsigned long, UINT_MAX+1 otherwise. Is it the "vacated bits are zero-filled" part that you're talking about? No, it's the "(interpreted as a bit pattern) left-shifted E2 bit positions" in combination with the "multiplied by the quantity 2 raised to the power E2". If your values are represented in gray code, a left-shift of the bit pattern doesn't necessarily result in a mulitplication by 2. Jul 5 '06 #24

 P: n/a * Rolf Magnus: Frederick Gotham wrote: >Rolf Magnus posted: >>Ok, now I have one: 5.8/2. The value of E1 << E2 is E1 (interpreted as a bit pattern) left-shifted E2bit positions; vacated bits are zero-filled. If E1 has an unsigned type,the value of the result is E1 multiplied by the quantity 2 raised to thepower E2, reduced modulo ULONG_MAX+1 if E1 has type unsigned long,UINT_MAX+1 otherwise. Is it the "vacated bits are zero-filled" part that you're talking about? No, it's the "(interpreted as a bit pattern) left-shifted E2 bit positions" in combination with the "multiplied by the quantity 2 raised to the power E2". If your values are represented in gray code, a left-shift of the bit pattern doesn't necessarily result in a mulitplication by 2. That's only for unsigned types. C++ unsigned integers are pure binary. For signed integers there's much more leeway (formally). -- 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? Jul 5 '06 #25

 P: n/a Alf P. Steinbach wrote: * Rolf Magnus: >Rolf Magnus wrote: >>Alf P. Steinbach wrote:It's good fun to throw academic spanners into practical wheels, so,where does the standard exclude a grey-code representation? ;-)Hmm, I would have said 3.9.1/7, but after reading it again, it seemsthat this actually doesn't prohibit a grey-code representation. Ok, now I have one: 5.8/2. Nope, not as far as I can see: it's /very/ ingeniously worded so that the cases that could be incompatible are simply not defined. What's not defined? It says clearly that the bit pattern is shifted left by the specified number of bits and that this will (for unsigned types) result in a multiplication by 2 raised to the value of the rhs. That's not possible with Gray code, so unsigned types cannot use Gray code. Since a bit pattern for a signed value must be the same as for the corresponding unsigned value, signed types neither can use Gray code. Jul 5 '06 #26

 P: n/a Alf P. Steinbach wrote: * Rolf Magnus: >Frederick Gotham wrote: >>Rolf Magnus posted: Ok, now I have one: 5.8/2.The value of E1 << E2 is E1 (interpreted as a bit pattern) left-shiftedE2 bit positions; vacated bits are zero-filled. If E1 has an unsignedtype, the value of the result is E1 multiplied by the quantity 2 raisedto the power E2, reduced modulo ULONG_MAX+1 if E1 has type unsignedlong, UINT_MAX+1 otherwise. Is it the "vacated bits are zero-filled" part that you're talking about? No, it's the "(interpreted as a bit pattern) left-shifted E2 bitpositions" in combination with the "multiplied by the quantity 2 raisedto the power E2". If your values are represented in gray code, aleft-shift of the bit pattern doesn't necessarily result in amulitplication by 2. That's only for unsigned types. C++ unsigned integers are pure binary. For signed integers there's much more leeway (formally). Only for the negative values. So I guess a signed integer could use Gray code for the negative part. That would be extremely odd, but seems to be allowed by the standard. Jul 5 '06 #27

 P: n/a * Rolf Magnus: Alf P. Steinbach wrote: >* Rolf Magnus: >>Frederick Gotham wrote:Rolf Magnus posted: Ok, now I have one: 5.8/2.The value of E1 << E2 is E1 (interpreted as a bit pattern) left-shiftedE2 bit positions; vacated bits are zero-filled. If E1 has an unsignedtype, the value of the result is E1 multiplied by the quantity 2 raisedto the power E2, reduced modulo ULONG_MAX+1 if E1 has type unsignedlong, UINT_MAX+1 otherwise. Is it the "vacated bits are zero-filled" part that you're talking about?No, it's the "(interpreted as a bit pattern) left-shifted E2 bitpositions" in combination with the "multiplied by the quantity 2 raisedto the power E2". If your values are represented in gray code, aleft-shift of the bit pattern doesn't necessarily result in amulitplication by 2. That's only for unsigned types. C++ unsigned integers are pure binary. For signed integers there's much more leeway (formally). Only for the negative values. So I guess a signed integer could use Gray code for the negative part. That would be extremely odd, but seems to be allowed by the standard. No, it's for any (signed) value. Left shift doesn't define the numeric value. And right shift >does define the value but is all OK. -- 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? Jul 5 '06 #28

 P: n/a * Rolf Magnus: Alf P. Steinbach wrote: >* Rolf Magnus: >>Rolf Magnus wrote:Alf P. Steinbach wrote:It's good fun to throw academic spanners into practical wheels, so,where does the standard exclude a grey-code representation? ;-)Hmm, I would have said 3.9.1/7, but after reading it again, it seemsthat this actually doesn't prohibit a grey-code representation.Ok, now I have one: 5.8/2. Nope, not as far as I can see: it's /very/ ingeniously worded so thatthe cases that could be incompatible are simply not defined. What's not defined? It says clearly that the bit pattern is shifted left by the specified number of bits and that this will (for unsigned types) result in a multiplication by 2 raised to the value of the rhs. That's not possible with Gray code, so unsigned types cannot use Gray code. Since a bit pattern for a signed value must be the same as for the corresponding unsigned value, signed types neither can use Gray code. No, the bit pattern for a signed value must not necessarily be the same as for the corresponding unsigned value. In particular, that very obviously doesn't hold for negative values. And by extension, it doesn't hold for non-negative values either (if you're looking at the same paragraph which has been discussed to death in this connection before [the solution, if it may be called that, is then to look at the definitions of terms] ;-)). -- 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? Jul 5 '06 #29

 P: n/a Alf P. Steinbach wrote: * Rolf Magnus: >Alf P. Steinbach wrote: >>* Rolf Magnus:Rolf Magnus wrote:Alf P. Steinbach wrote:>>It's good fun to throw academic spanners into practical wheels, so,>where does the standard exclude a grey-code representation? ;-)Hmm, I would have said 3.9.1/7, but after reading it again, it seemsthat this actually doesn't prohibit a grey-code representation.Ok, now I have one: 5.8/2.Nope, not as far as I can see: it's /very/ ingeniously worded so thatthe cases that could be incompatible are simply not defined. What's not defined? It says clearly that the bit pattern is shifted leftby the specified number of bits and that this will (for unsigned types)result in a multiplication by 2 raised to the value of the rhs. That'snot possible with Gray code, so unsigned types cannot use Gray code.Since a bit pattern for a signed value must be the same as for thecorresponding unsigned value, signed types neither can use Gray code. No, the bit pattern for a signed value must not necessarily be the same as for the corresponding unsigned value. In particular, that very obviously doesn't hold for negative values. And by extension, it doesn't hold for non-negative values either (if you're looking at the same paragraph which has been discussed to death in this connection before [the solution, if it may be called that, is then to look at the definitions of terms] ;-)). You must be talking about: "The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the value representation of each corresponding signed/unsigned type shall be the same." Not sure what's wrong about that, though. Doesn't it mean that the same value in a corresponding signed and unsigned type must have the same bit pattern? Obviously, that's only possible for the subrange that is covered by both. Jul 5 '06 #30

 P: n/a * Rolf Magnus -Alf P. Steinbach: > You must be talking about: "The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the value representation of each corresponding signed/unsigned type shall be the same." Yep. Not sure what's wrong about that, though. Doesn't it mean that the same value in a corresponding signed and unsigned type must have the same bit pattern? Nope, partly because: Obviously, that's only possible for the subrange that is covered by both. and partly because of earlier definition of "value representation". -- 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? Jul 5 '06 #31

 P: n/a "Rolf Magnus" >"digits" gives you the amount of value bits, excluding the signbit.If the sign bit (if any) is zero, and if all the rest of the bitsare 1,then you have the max value. This of course assumes that all the bits take part in the valuerepresentation. AFAICS, it doesn't. As Frederick wrote, "digits" gives you the amount of _value bits_, not the total amount of bits. Does too! :-) How do we know exactly what bits of the object takes part in the value representation? Is the sign bit always the first bit? Where are the pad bits? If we always assume 32 bits, two's complement, and no pad bits, we can skip all this. If we want to be totally portable, we cannot assume any of it. Part of the reason for me being so picky, is that on my CS courses we used a Univac 1100 - 36 bit, one's complement. Compatible machines still exist! Bo Persson Jul 6 '06 #32

 P: n/a Bo Persson posted: Does too! :-) How do we know exactly what bits of the object takes part in the value representation? Is the sign bit always the first bit? Where are the pad bits? That's the compiler's job to worry about. We just give it the value of the bit we want, rather than the bit index, and it works out the rest. Furthermore, the Standard guarantees that: x << 1 is equal to: x * 2 -- Frederick Gotham Jul 6 '06 #33

 P: n/a Alf P. Steinbach wrote: the bit pattern for a signed value must not necessarily be the same as for the corresponding unsigned value. In particular, that very obviously doesn't hold for negative values. And by extension, it doesn't hold for non-negative values either I don't agree with your extension. Take a simple 16 bit int. The common value subrange is [0,32767], for which bits 0-15 are defined by the unsigned int representation. For this range, and this range only, the representation of int and unsigned int must match. The fact that the ranges [-32768,-1] for int and [32768,65536] for unsigned are not common means the bit patterns for these ranges may overlap (must, if only 16 bits are available) but that only says something about bit patterns where bit 15 is set. Jul 6 '06 #34

 P: n/a I have a better solution. The highest value is equal to: (radix ^ digits) - 1 (I thought it might work for floating point types aswell, but it doesn't.) First I start off with a metaprogramming template to raise a number to a positive integer power, and work from there: #include template struct IntPow { static T const val = base * IntPow::val; }; template struct IntPow struct IntMax { typedef std::numeric_limits::val - 1; }; #include int main() { std::cout << "Max values\n" "==========\n\n" " unsigned char: " << (int)IntMax::val << "\nunsigned short: " << IntMax::val << "\n unsigned int: " << IntMax::val << "\n unsigned long: " << IntMax::val << "\n\n signed char: " << (int)IntMax::val << "\n signed short: " << IntMax::val << "\n signed int: " << IntMax::val << "\n signed long: " << IntMax::val; /* std::cout << "\n float: " << IntMax::val << "\n double: " << IntMax::val << "\n long double: " << IntMax::val; */ } -- Frederick Gotham Jul 6 '06 #35

 P: n/a * Mi*************@tomtom.com: Alf P. Steinbach wrote: the bit pattern for a signed value must not necessarily be the same >as for the corresponding unsigned value. In particular, that veryobviously doesn't hold for negative values. And by extension, itdoesn't hold for non-negative values either I don't agree with your extension. Take a simple 16 bit int. The common value subrange is [0,32767], for which bits 0-15 are defined by the unsigned int representation. For this range, and this range only, the representation of int and unsigned int must match. What is the argument? -- 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? Jul 6 '06 #36

### This discussion thread is closed

Replies have been disabled for this discussion. 