By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,797 Members | 1,836 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,797 IT Pros & Developers. It's quick & easy.

More of a raw kind of cast

P: n/a

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
Share this Question
Share on Google+
5 Replies


P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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.