Prev: invalid initialization of nonconst reference of type
Next: Summary of C++0x Feature Availability
From: Daniel Krügler on 7 Mar 2010 08:34 On 7 Mrz., 23:01, Thomas Richter <t...(a)math.tuberlin.de> wrote: > Daniel Kr gler wrote: > > On 6 Mrz., 14:58, Olaf Klein <olaf.klei...(a)googlemail.com> wrote: > >> is it possible to initialize an unsigned variable with its maximum > >> value with the following lines? > > >> unsigned u = 1; > >> std::size_t s = 1; > > >> I am asking because the standard does not guarantee overflow behavior > >> of signed types while it does for unsigned types. What applies here? > > > This is clearly expressed in [basic.fundamental]/4 > > > "Unsigned integers, declared unsigned, shall obey the laws > > of arithmetic modulo 2n where n is the number of bits in > > the value representation of that particular size of integer.45" > > Is this really the right argument? After all, this is an implicit > conversion from an int to an unsigned integral type, thus the arithmetic > of unsigned types should not really matter here. After all, two types > are involved here, not just one. Thanks for pointing that out, Thomas. In fact, [conv.integral]/2 applies here (There is no promotion involved): "If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type). [ Note: In a two�s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). �end note ]" The result is the same as the model explained in my original posting. Greetings from Bremen, Daniel Kr�gler  [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Olaf Klein on 12 Mar 2010 05:52 Dear usegroup, > Thanks for pointing that out, Thomas. In fact, > [conv.integral]/2 applies here (There is no > promotion involved): > > "If the destination type is unsigned, the resulting > value is the least unsigned integer congruent to > the source integer (modulo 2n where n is the number > of bits used to represent the unsigned type). [ Note: > In a two�s complement representation, this conversion > is conceptual and there is no change in the bit > pattern (if there is no truncation). �end note ]" > > The result is the same as the model explained in > my original posting. But what about the guarantees for the representation of 1 (read: there are none)? AFAIK the bit pattern "1000....01" may also represent 1 (sign bit instead of two's complement). In this case the unsigned variable would not be initialized with its maximum value. Olaf Klein  [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bo Persson on 13 Mar 2010 16:35 Olaf Klein wrote: > Dear usegroup, > >> Thanks for pointing that out, Thomas. In fact, >> [conv.integral]/2 applies here (There is no >> promotion involved): >> >> "If the destination type is unsigned, the resulting >> value is the least unsigned integer congruent to >> the source integer (modulo 2n where n is the number >> of bits used to represent the unsigned type). [ Note: >> In a two�s complement representation, this conversion >> is conceptual and there is no change in the bit >> pattern (if there is no truncation). �end note ]" >> >> The result is the same as the model explained in >> my original posting. > > But what about the guarantees for the representation of 1 (read: > there are none)? AFAIK the bit pattern "1000....01" may also > represent 1 (sign bit instead of two's complement). In this case > the unsigned variable would not be initialized with its maximum > value. > The standard requires this to be done modulo 2n, but doesn't say anything about how this affects bit patterns. For 2's complement systems, the bit patterns are unchanged, but for other representations they are not. When using bit fiddling, you must make some assumptions on the underlying representation. Limiting portability to 2's complement hardware might be justified for some applications. Bo Persson  [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Seungbeom Kim on 13 Mar 2010 16:35 Olaf Klein wrote: > Dear usegroup, > >> Thanks for pointing that out, Thomas. In fact, >> [conv.integral]/2 applies here (There is no >> promotion involved): >> >> "If the destination type is unsigned, the resulting >> value is the least unsigned integer congruent to >> the source integer (modulo 2n where n is the number >> of bits used to represent the unsigned type). [ Note: >> In a two�s complement representation, this conversion >> is conceptual and there is no change in the bit >> pattern (if there is no truncation). �end note ]" >> >> The result is the same as the model explained in >> my original posting. > > But what about the guarantees for the representation of 1 (read: > there are none)? AFAIK the bit pattern "1000....01" may also represent > 1 (sign bit instead of two's complement). In this case the unsigned > variable would not be initialized with its maximum value. The standard defines the conversion in terms of the values, not in terms of the bit patterns. Regardless of the bit pattern of the signed integer, "the resulting value is the least unsigned integer congruent to the source integer (modulo 2^n where n is the number of bits used to represent the unsigned type)." If the value of the source integer is 1, the resulting value should be 2^n  1. The note says that under the two's complement representation the bit pattern need not change. Under other representations, the bit pattern may need to change, in which case the compiler has to generate code that produces the specified value.  Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel Krügler on 13 Mar 2010 16:38 On 12 Mrz., 23:52, Olaf Klein <olaf.klei...(a)googlemail.com> wrote: > Dear usegroup, > > > Thanks for pointing that out, Thomas. In fact, > > [conv.integral]/2 applies here (There is no > > promotion involved): > > > "If the destination type is unsigned, the resulting > > value is the least unsigned integer congruent to > > the source integer (modulo 2n where n is the number > > of bits used to represent the unsigned type). [ Note: > > In a two s complement representation, this conversion > > is conceptual and there is no change in the bit > > pattern (if there is no truncation). end note ]" > > > The result is the same as the model explained in > > my original posting. > > But what about the guarantees for the representation of 1 (read: > there are none)? AFAIK the bit pattern "1000....01" may also represent > 1 (sign bit instead of two's complement). In this case the unsigned > variable would not be initialized with its maximum value. You are mixing up different things. *Reinterpreting* a signed value of 1 to a unsigned type is outside the scope of the standard. So, if you want to perform a bitpatternconserving transformation, you could try to do this via reinterpret_cast, so in the example int v1 = 1; unsigned int& v2 = reinterpret_cast<unsigned int&>(v1); It would be a rather probably (but also not guaranteed [1]) behaviour, that v2 has the same bit pattern as v1. This would have the effect that v2 (assuming an 8 bit representation for simplicity of this discussion) is either of 129, 254, or 255, depending on one of three supported integer representations signedmagnitude, one's complement, or two's complement. But this does not happen during the converting initialization: unsigned int v = 1; The quoted wording in my former quote ensures that v has *always* the value std::numeric_limits<unsigned>::max() for *all* supported representation types. It is the same what happens, if you did a static_cast like so int v1 = 1; unsigned int v2 = static_cast<unsigned int>(v1); HTH & Greetings from Bremen, Daniel Kr�gler [1] According to [expr.reinterpret.cast]/3: "[ Note: The mapping performed by reinterpret_cast might, or might not, produce a representation different from the original value. �end note ]"  [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
First

Prev

Next

Last
Pages: 1 2 3 4 Prev: invalid initialization of nonconst reference of type Next: Summary of C++0x Feature Availability 