470,586 Members | 1,297 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,586 developers. It's quick & easy.

More of a raw kind of cast


Before I begin, here's a list of assumptions for this particular example:

(1) unsigned int has no padding bits, and therefore no invalid bit-
patterns or trap representations.
(2) All types have the same alignment requirements.
(3) sizeof(double) >= sizeof(unsigned)

=====================================

We can cast from double to unsigned int as follows:

int main()
{
double d = 672.23;

unsigned i = d;
}
However, if we want a raw kind of cast, i.e. simply access the double's
data in memory as if it were an unsigned int, then we can write:

int main()
{
double d = 672.23;

unsigned i = *reinterpret_cast<unsigned*>( &d );
}

However, my question is this:

Do we have to bother with pointers as in the previous snippet, or can
we use references?

int main()
{
double d = 672.23;

unsigned i = reinterpret_cast<unsigned&>( d );
}

--

Frederick Gotham
Jun 29 '06 #1
5 2101
On Thu, 29 Jun 2006 19:15:52 GMT, Frederick Gotham
<fg*******@SPAM.com> wrote in comp.lang.c++:

Before I begin, here's a list of assumptions for this particular example:

(1) unsigned int has no padding bits, and therefore no invalid bit-
patterns or trap representations.
(2) All types have the same alignment requirements.
(3) sizeof(double) >= sizeof(unsigned)

=====================================

We can cast from double to unsigned int as follows:
No, you can't. A cast is ONLY performed by a cast operator, either
the original C cast, or one of the new cast operators defined in C++.
int main()
{
double d = 672.23;

unsigned i = d;
}
The code above performs a conversion, specifically an automatic
conversion on assignment. There is no cast involved. A cast is an
EXPLICIT conversion, defined as such by both C and C++. Some
conversions occur automatically in expressions, others require a cast
operator.

We CAN cast from double to unsigned like this:

int main()
{
double d = 672.23;
unsigned i = (double)d; // other C++ casts could be used
}

This shows that you can use a cast operator to specifically perform a
conversion that would occur automatically in the expression anyway.
However, if we want a raw kind of cast, i.e. simply access the double's
data in memory as if it were an unsigned int, then we can write:
This is not a cast either. What you are doing is trying to access the
raw underlying bits of an object, with an lvalue of a different type.
int main()
{
double d = 672.23;

unsigned i = *reinterpret_cast<unsigned*>( &d );
}

However, my question is this:

Do we have to bother with pointers as in the previous snippet, or can
we use references?
First, the answer is no.

Second, you are not actually having to "bother with pointers", you are
bothering with addresses, which is the name of the type of value held
by a pointer.

The unary '&' operator generates the address of its operand. The cast
takes that address rvalue, which has the type "address of double", and
convert it to an rvalue which has the type "address of unsigned int".
Most likely, there is no change in the bitwise representation of the
address, merely in the number of bits read from memory during the
lvalue to rvalue conversion and how they are interpreted.

No actual pointer exists or is created.
int main()
{
double d = 672.23;

unsigned i = reinterpret_cast<unsigned&>( d );
}


This is trying to cast a double to a reference to int, which quite
impossible.

I don't know what you think the overhead of the pointer cast is. You
are only changing how the address is used to access memory, not
actually create a pointer.

Consider this variation on your second and third examples:

int main()
{
double d1 = 672.23, d2 = 666.89;
unsigned i1 = d1;
unsigned i2 = *reinterpret_cast<unsigned*>(&d2);
}

Do you think the compiler will generate more machine instructions for
the second than it does for the first?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Jun 29 '06 #2
Jack Klein posted:

What you are doing is trying to access the raw underlying bits of an
object, with an lvalue of a different type.

Indeed.

My question is very simple. If we have an object like as follows:

double d;

Then are the following two expressions equivalent?

(1) *reinterpret_cast<unsigned*>( &d )

(2) reinterpret_cast<unsigned&>( d )

--

Frederick Gotham
Jun 29 '06 #3
Frederick Gotham wrote:
...
My question is very simple. If we have an object like as follows:

double d;

Then are the following two expressions equivalent?

(1) *reinterpret_cast<unsigned*>( &d )

(2) reinterpret_cast<unsigned&>( d )
...


Yes, they are. The equivalence of the two is explicitly stated in 5.2.10/10.

I don't know why Jack is saying that the second one is an attempt to
cast a 'double' value to reference type. When an lvalue is used as an
argument for an 'reinterpret_cast' to reference type, the argument is
interpreted as a "reference" value (as a 'double&' in your example, not
as a 'double' rvalue), which is then converted to the target reference type.

--
Best regards,
Andrey Tarasevich
Jun 29 '06 #4
Jack Klein wrote:
On Thu, 29 Jun 2006 19:15:52 GMT, Frederick Gotham
<fg*******@SPAM.com> wrote in comp.lang.c++:
int main()
{
double d = 672.23;

unsigned i = d;
}


The code above performs a conversion, specifically an automatic
conversion on assignment.


Surely you mean on initialization?

Luke

Jun 30 '06 #5
Luke Meyers posted:
Jack Klein wrote:
On Thu, 29 Jun 2006 19:15:52 GMT, Frederick Gotham
<fg*******@SPAM.com> wrote in comp.lang.c++:
> int main()
> {
> double d = 672.23;
>
> unsigned i = d;
> }


The code above performs a conversion, specifically an automatic
conversion on assignment.


Surely you mean on initialization?

Indeed I do.

However we're dealing with intrinsic POD's, so there's no difference.

Notheless, yes, I should have said "initialisation".
--

Frederick Gotham
Jun 30 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

303 posts views Thread by mike420 | last post: by
24 posts views Thread by Kari Laitinen | last post: by
3 posts views Thread by Lionel B | last post: by
reply views Thread by Aaron W. West | last post: by
7 posts views Thread by ma740988 | last post: by
17 posts views Thread by Chen Shusheng | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.