const_cast, reinterpret_cas t

[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_cas t.
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

[Julie]

johny smith wrote:

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.

[David White]

"johny smith" <pr************ **@charter.net> wrote in message
news:10******** *****@corp.supe rnews.com...

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_cas t.
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_ca st<double*>(buf fer);
//...
}

As a rule of thumb, use reinterpret_cas t 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

[Siemel Naran]

"johny smith" <pr************ **@charter.net> wrote in message

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_cas t.
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(rein terpret_cast<co nst 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.

[David White]

"David White" <[e-mail] ded> wrote in message
news:sL******** ***********@nas al.pacific.net. au...

"johny smith" <pr************ **@charter.net> wrote in message
news:10******** *****@corp.supe rnews.com...

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.

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_cas t:

class ParamDB
{
// A database class
};

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

DBHandle asDBHandle(cons t ParamDB *pDB)
{
return reinterpret_cas t<DBHandle>(con st_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

[John Harrison]

"David White" <[e-mail] ded> wrote in message
news:cx******** ***********@nas al.pacific.net. au...

"David White" <[e-mail] ded> wrote in message
news:sL******** ***********@nas al.pacific.net. au...

"johny smith" <pr************ **@charter.net> wrote in message
news:10******** *****@corp.supe rnews.com...

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.

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<MyIn tContainer*>(th is)->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

[Owen Jacobson]

John Harrison wrote:

David White wrote:

johny smith wrote:

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.

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<MyIn tContainer*>(th is)->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?

--
Some say the Wired doesn't have political borders like the real world,
but there are far too many nonsense-spouting anarchists or idiots who
think that pranks are a revolution.

[John Harrison]

"Owen Jacobson" <an******@lions anctuary.net> wrote in message
news:pa******** *************** *****@lionsanct uary.net...

John Harrison wrote:

David White wrote:

johny smith wrote:
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.

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<MyIn tContainer*>(th is)->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?

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

[Mats Weber]

In article <o8************ ********@bgtnsc 04-news.ops.worldn et.att.net>,
"Siemel Naran" <Si*********@RE MOVE.att.net> wrote:

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 ?

[tom_usenet]

On Thu, 24 Jun 2004 07:19:28 GMT, Owen Jacobson
<an******@lions anctuary.net> wrote:

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.fi nd(0) = 10;

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html