Prev: invalid initialization of non-const 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.tu-berlin.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 bit-pattern-conserving 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 signed-magnitude,
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 non-const reference of type
Next: Summary of C++0x Feature Availability