const_cast, reinterpret_cast

J

johny smith

Can someone please give me some good reference site/information for
understanding when and why I would use

1.) const_cast
Don't know why you would do this?

2.) reinterpret_cast.
I have used this a little when I converted a primitive to a class, but
would like to see other applications.

Yes, I have looked on the web, but want to know what some of the experts
know about this.

Thanks alot for your help,

John
 
J

Julie

johny said:
Can someone please give me some good reference site/information for
understanding when and why I would use

1.) const_cast
Don't know why you would do this?

I've had need to use this to cast away constness when interfacing w/ poorly
written interfaces that treat a parameter as const, but don't qualify it as
const in the parameter list.
 
D

David White

johny smith said:
Can someone please give me some good reference site/information for
understanding when and why I would use

1.) const_cast
Don't know why you would do this?

It's for casting from const to non-const.
2.) reinterpret_cast.
I have used this a little when I converted a primitive to a class, but
would like to see other applications.

You use it to convert between incompatible types, e.g.,
unsigned char buffer[20];
if(read_message_from_com_port(buffer))
{
double x = *reinterpret_cast<double*>(buffer);
//...
}

As a rule of thumb, use reinterpret_cast if there is no implicit conversion
and static_cast is rejected by the compiler - and you are really sure that
it's the conversion you need.

If you are unable to find uses for these casts, then count your blessings.
No one _wants_ to use them. They should be used as little as possible, but
sometimes you have to use to use them.

DW
 
S

Siemel Naran

johny smith said:
1.) const_cast
Don't know why you would do this?

If you implement the const function, you can implement the nonconst function
in terms of the nonconst one.

const T& Foo::stuff() const {
/* lots of code */
}

T& Foo::stuff() {
const Foo * cthis = this;
return const_cast<T&>(cthis->stuff);
}

Also, you need const_cast to add 2nd level const. Though this is rarely
used.

int main(int argc, char * * argv) {
char const *const * cargv = const_cast<char const *const *>(argv);
};

And you also need const_cast to deal with interfaces that aren't const
correct, for example using a variable as const by not declaring it const, as
Julie points out.
2.) reinterpret_cast.
I have used this a little when I converted a primitive to a class, but
would like to see other applications.

One can use it to convert an int, double, etc to a stream of bytes, suitable
for a call to write.

int i = 3;
cout.write(reinterpret_cast<const char *>(&i), sizeof(i));

In pool allocator schemes, we allocate space to store N elements, say N =
100. You can treat the space of element as either an element or a pointer
to the next element, provided that the sizeof the space is >= the space of a
pointer to the element.

There are lots of other domain specific examples.
 
D

David White

David White said:
It's for casting from const to non-const.

I guess now that you already knew that. I'm struggling to come up with
necessary uses for it, or uses that don't indicate a flawed design.
Stroustrup's "The C++ Programming Language" gives an example of a class
member used to cache a value. Even in a const member function you might want
to change the value of the cache, since the cache only affects performance
and not the logical state of the object. Changing a class member in a const
member function requires const_cast. However, I don't think this is a good
example because the member used as the cache would be better declared
'mutable', obviating the need for the const_cast. I did manage to find this
rather unsual case in my own code that uses both const_cast and
reinterpret_cast:

class ParamDB
{
// A database class
};

// A handle used to access the database across a C interface
typedef struct DBHandleStruct_{} *DBHandle;

DBHandle asDBHandle(const ParamDB *pDB)
{
return reinterpret_cast<DBHandle>(const_cast<ParamDB*>(pDB));
}

I suppose I could have (or should have) made DBHandle const struct
DBHandleStruct_{} * and I still wouldn't have needed the const_cast.

DW
 
J

John Harrison

David White said:
I guess now that you already knew that. I'm struggling to come up with
necessary uses for it, or uses that don't indicate a flawed design.

Suppose you are writing an STL container class

class MyIntContainer
{
iterator find(int x)
{
// some complex function
}

const_iterator find(int x) const
{
return const_cast<MyIntContainer*>(this)->find(x);
}

...

const_cast avoids repeating a whole lot of code. (Possibly this indicates
the iterator/const_iterator concept in the STL is flawed design but there
you go).

john
 
O

Owen Jacobson

John said:
Suppose you are writing an STL container class

class MyIntContainer
{
iterator find(int x)
{
// some complex function
}

const_iterator find(int x) const
{
return const_cast<MyIntContainer*>(this)->find(x);
}

...

const_cast avoids repeating a whole lot of code. (Possibly this indicates
the iterator/const_iterator concept in the STL is flawed design but there
you go).

Or possibly that the first should be

iterator find (int x) const

Is there a particular reason this isn't the case?
 
J

John Harrison

Owen Jacobson said:
Or possibly that the first should be

iterator find (int x) const

Is there a particular reason this isn't the case?

Yes its by design. If it we're not the case you would be able to write code
like this

const MyIntContainer c = ...;
iterator i = c.find(1);
*i = 2;

in other words you would be able to use an iterator to modify a const
object.

john
 
M

Mats Weber

Siemel Naran said:
If you implement the const function, you can implement the nonconst function
in terms of the nonconst one.

const T& Foo::stuff() const {
/* lots of code */
}

T& Foo::stuff() {
const Foo * cthis = this;
return const_cast<T&>(cthis->stuff);
}

Is there a clean (without a cast) way to do this, implementing the
non-const version first ?
 
T

tom_usenet

Or possibly that the first should be

iterator find (int x) const

Is there a particular reason this isn't the case?

Since you could then modify a const container. e.g.

*myconstlist.find(0) = 10;

Tom
 
U

Unforgiven

johny smith said:
Can someone please give me some good reference site/information for
understanding when and why I would use

1.) const_cast
Don't know why you would do this?

2.) reinterpret_cast.
I have used this a little when I converted a primitive to a class, but
would like to see other applications.

This is a very good article about reinterpret_cast:
http://msdn.microsoft.com/library/en-us/dndeepc/html/deep06012000.asp

Don't worry about the fact that it's on MSDN, it's not in the least
Microsoft specific. Robert Schmidt (the author) is a very standards-oriented
guy.
There's an article about static_cast too, but not about const_cast,
unfortunately.
 
S

Siemel Naran

class MyIntContainer
{
iterator find(int x)
{
// some complex function
}

const_iterator find(int x) const
{
return const_cast<MyIntContainer*>(this)->find(x);
}

Coming to think of it, shouldn't you implement the const version, and
nonconst one in terms of the const one. Because the original object may
have been const. I didn't realize this until formulating my reply to Mats
Weber.
 
S

Siemel Naran

Mats Weber said:
Is there a clean (without a cast) way to do this, implementing the
non-const version first ?

No. In this second approach example you need a const_cast to cast away the
constness of this. So either way you need a const_cast.

const T& Foo::stuff() const {
Foo * ncthis = const_cast<Foo *>(this);
return ncthis->stuff();
}

The advantage of the first way I posted is that the original object may have
been declared const as in

int main() {
const Foo foo;
foo.stuff();
}

so it's not safe to cast away the constness of this. So we implement the
const version. The nonconst version will call the const version, then cast
away the constness of the returned reference or iterator or pointer -- which
should be OK because the original pointer, presumably a pointer to some part
of the object, was originally non-const.
 
R

Rob Williscroft

Siemel Naran wrote in
in
comp.lang.c++:
Coming to think of it, shouldn't you implement the const version, and
nonconst one in terms of the const one. Because the original object
may have been const. I didn't realize this until formulating my reply
to Mats Weber.

Well should you be able to make an iterator from a const_iterator ?

Ofcourse calling the non-const find on a const object is fine as
long as we know that it doesen't modify the object, and in this
case why would it ?

Rob.
 
S

Siemel Naran

Rob Williscroft said:
Ofcourse calling the non-const find on a const object is fine as
long as we know that it doesen't modify the object, and in this
case why would it ?

Note in the example we are returning an iterator to the caller. There's no
saying what they'll do with it.

Also, the standard says casting away the constness of an object that was
originally const, even if only for read purposes, is undefined. Maybe some
implementations out there have read only pointers builtin into the system, I
don't know. I suggested recently in a post that to get a "char *" from
string.c_str() you could practically do "const_cast<char*>(string. c_str())"
which would work on all implementations I know, but someone correctly
pointed out it is still undefined behavior if the original string were
const.
 
R

Rob Williscroft

Siemel Naran wrote in
in
comp.lang.c++:
Note in the example we are returning an iterator to the caller.
There's no saying what they'll do with it.

I was refering to the const_cast in the const member function,
and then calling the non-const find on it.
Also, the standard says casting away the constness of an object that
was originally const, even if only for read purposes, is undefined.

Do you have a reference ?
Maybe some implementations out there have read only pointers builtin
into the system, I don't know. I suggested recently in a post that to
get a "char *" from string.c_str() you could practically do
"const_cast<char*>(string. c_str())" which would work on all
implementations I know, but someone correctly pointed out it is still
undefined behavior if the original string were const.

Its UB anyway, we've no idea where the char const * returned by
c_str() comes from.


Rob.
 
D

DaKoadMunky

class MyIntContainer
Coming to think of it, shouldn't you implement the const version, and
nonconst one in terms of the const one. Because the original object may
have been const. I didn't realize this until formulating my reply to Mats
Weber.

In this case you probably can't implement the non-const version in terms of the
const version.

The return type of the const version is most likely not convertible to the
return type of the non-const version.

It seems reasonble that one shouldn't be able to convert a constant iterator
into a non-constant iterator.

The reverse of course is quite reasonable.
 
O

Old Wolf

David White said:
It's for casting from const to non-const.

Also for casting from non-const to const, and volatile to non-volatile,
and non-volatile to volatile, and any combinations of those.
For example:

void foo(const char **ptr);
char *x;

foo(const_cast<const char **>(&x));
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top