Prev: invalid initialization of non-const reference of type
Next: Summary of C++0x Feature Availability
From: Falk Tannhäuser on 14 Mar 2010 11:14
Am 14.03.2010 10:38, schrieb Daniel Kr�gler:
> 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.
[...]
> [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 ]"

In my understanding, this paragraph concerns the mapping of the source
expression (here: int lvalue v1) to the destination type
(here: unsigned int&), but not the object that the result of the cast (here: an
lvalue of type unsigned int) refers to. The
Standard appears largely silent about the representation of references anyway,
except that [dcl.ref]/4 says: "It is unspecified
whether or not a reference requires storage".
The most relevant paragraph in our case is [expr.reinterpret.cast]/11:
"An lvalue expression of type T1 can be cast to the type �reference to T2� if an
expression of type �pointer to T1� can be
explicitly converted to the type �pointer to T2� using a reinterpret_cast. That
is, a reference cast reinterpret_cast<T&>(x) has
the same effect as the conversion *reinterpret_cast<T*>(&x) with the built-in &
and * operators [...] The result refers to the
same object as the source lvalue, but with a different type. The result is an
lvalue for lvalue references [...] No temporary is
created, no copy is made, and constructors or conversion functions are not called."
According to [basic.fundamental]/3, the types int and unsigned int occupy the
same amount of storage and have the same alignment
requirements (furthermore the non-negative values of int have the same value
representation than the corresponding unsigned
values). This means that the pointer cast [expr.reinterpret.cast]/7 mentioned in
[expr.reinterpret.cast]/11 is rather well-behaved.
Consequently, according to the Standard, v1 and v2 are lvalues referring to the
same object and have necessarily the same bit
pattern.

Falk


--
[ 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 14 Mar 2010 11:14
On 14 Mrz., 10:38, Daniel Kr�gler <daniel.krueg...(a)googlemail.com>
wrote:
[..]
> 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.

[..]

> [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 ]"

My reference regarding producing a possible
different representation here, is misleading.
reinterpret_cast *may* produce a different
representation in some of the described
conversion situations, but it seems it seems
to guarantee representation conservation for
above type pun situation as described in
[expr.reinterpret.cast]/10:

"The result is an lvalue that refers to the same
object as the source lvalue, but with a different
type. No temporary is created, no copy is made,
and constructors (12.1) or conversion functions
(12.3) are not called."

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: red floyd on 15 Mar 2010 08:04
On Mar 6, 6:58 am, Olaf Klein <olaf.klei...(a)googlemail.com> wrote:
> Dear group,
>
> is it possible to initialize an unsigned variable with its maximum
> value with the following lines?
>
> unsigned u = -1;
> std::size_t s = -1;

If you're trying to get all 1's, may I suggest

unsigned u = ~0;



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Herb Sutter on 15 Mar 2010 13:28
On Sat, 6 Mar 2010 07:58:22 CST, Olaf Klein
<olaf.klein81(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;

Since I didn't see anyone else mention it: If your question is "what's
the right way to do it," use numeric_limits<>::max. In this case,

unsigned u = numeric_limits<unsigned>::max();
size_t s = numeric_limits<size_t>::max();

In C++0x these are even compile-time constant expressions.

Herb

---
Herb Sutter (herbsutter.wordpress.com) (www.gotw.ca)

Convener, ISO/IEC JTC1/SC22/WG21 (C++) (www.gotw.ca/iso)
Architect, Microsoft Visual C++ (www.gotw.ca/microsoft)

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Johannes Schaub (litb) on 15 Mar 2010 13:27
red floyd wrote:

> On Mar 6, 6:58 am, Olaf Klein <olaf.klei...(a)googlemail.com> wrote:
>> Dear group,
>>
>> is it possible to initialize an unsigned variable with its maximum
>> value with the following lines?
>>
>> unsigned u = -1;
>> std::size_t s = -1;
>
> If you're trying to get all 1's, may I suggest
>
> unsigned u = ~0;
>

That's a bad idea. It only works on two's complement (on one's complement,
this can have the opposite effect of initializing "u" to all-zero bits). The
following one is more reliable:

unsinged u = ~0U;

But's prone to errors when you change the type of "u" to, say, unsigned
long. Initializing with "-1" will do the right thing in both cases.

The reason it works on two's complement is that "~0" has the value -1. You
do "~0" to get the value -1, that's weird and platform dependent. Best write
-1 straight into the code and be portable.

--
[ 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