static_cast vs reinterpert_cas t

[Rahul]

Hi,

I have a
class A : public B {...member functions...... data members};

and am doing the following
A *p=new A();
void *p=static_cast< void *>(p);
factory_instanc e->process(p);

Here p is passed to a function, which accepts void ptr. That function
need to cast it back
A *pp=static_cast <A *>(p);

The function is in the factory which accepts void *p only, the specific
implementations need to cast the pointer back to the expected class
and use it.

Question:Though both works fine, yet I want to know what is more
appropriate in this situation static_cast OR reinterpert_cas t

The books suggests
static_cast= "For "well-behaved" and "reasonably
well-behaved" casts,including things you might now do without a cast
reinterpret_cas t=To cast to a completely different meaning. The key
is that you'll need to cast back to the original type to use it
safely.

But I am not able to interpret the sentences in this context :-)

[Ian Collins]

Frederick Gotham wrote:

dio posted:

>>Frederick Gotham <fg*******@SPAM .comwrote:

>>>The major drawback of the new-style casts is that they take up far too
much horizontal screen space.

Yes, which should serve as a visual reminder that a design that relies
heavily on casts is perhaps not ideal.

I'm out of nappies now though, and I can judge sensibly as to when I should
use what kind of cast. Would you prefer:

int *p = reinterpret_cas t<int*>(
const_cast<char *>(pcc)
);

or:

int *p = (char*)pcc;

Very much the former. The horrible code emphasises the horrible action!

And,
size_t i = static_cast<siz e_t>(-1);

or:

size_t i = (size_t)-1;

The former.

--
Ian Collins.

[Jim Langston]

"Frederick Gotham" <fg*******@SPAM .comwrote in message
news:fO******** ***********@new s.indigo.ie...

dio posted:

>Frederick Gotham <fg*******@SPAM .comwrote:

>>The major drawback of the new-style casts is that they take up far too
much horizontal screen space.

Yes, which should serve as a visual reminder that a design that relies
heavily on casts is perhaps not ideal.

I'm out of nappies now though, and I can judge sensibly as to when I
should
use what kind of cast. Would you prefer:

int *p = reinterpret_cas t<int*>(
const_cast<char *>(pcc)
);

This one. It spells out exactly what is going on.

>
or:

int *p = (char*)pcc;
And,
size_t i = static_cast<siz e_t>(-1);

This one.

or:

size_t i = (size_t)-1;
(Second example is intended to supress a compiler warning)
--

Frederick Gotham

[Rolf Magnus]

Frederick Gotham wrote:

Victor Bazarov posted:

>Frederick Gotham wrote:

>>I have a simple rule-of-thumb:

If you can use static_cast, then use static_cast.

If you can't use static_cast, then use reinterpret_cas t.

I have a simple preceding rule:

If you can do it without a cast, do not use any cast.

Naturally ; )
I tend to use the old-style casts now and again too, e.g.:

enum { len = 64U };

int array[len];

for(size_t i = len - 1; (size_t)-1 != i; --i)

I tend to use constructor-style casts in such a situation:

for(size_t i = len - 1; size_t(-1) != i; --i)

But I think that's just because C style casts look so old-style to me
now ;-)

Or if I need a reinterpret_cas t and a const_cast at the same time:

char const *pc = 0;

int *pi = (int*)pc;

/* A very contrived example, I realise! */

That's an example of a situation where I would definitely go with the C++
style casts. One important advantage is that someone reading the code will
immediately see that I really intended to cast away the constness and
didn't just get it in by accident.

[Ron Natalie]

Rolf Magnus wrote:

>
I tend to use constructor-style casts in such a situation:

for(size_t i = len - 1; size_t(-1) != i; --i)

But I think that's just because C style casts look so old-style to me
now ;-)

But a single arg function-style cast is identical in meaning to the
C-style cast. You're back to it possibly meaning static, const,
reinterpret or combinations of the above (as well as busting access
control which there is no C++-style equivelent to).

[Rolf Magnus]

Ron Natalie wrote:

Rolf Magnus wrote:

>>
I tend to use constructor-style casts in such a situation:

for(size_t i = len - 1; size_t(-1) != i; --i)

But I think that's just because C style casts look so old-style to me
now ;-)

But a single arg function-style cast is identical in meaning to the
C-style cast. You're back to it possibly meaning static, const,
reinterpret or combinations of the above (as well as busting access
control which there is no C++-style equivelent to).

I know. As I wrote, it's just that the C style cast looks more C'is than the
constructor style. Also note that none of the things you mentioned are an
issue in the above code example.

[Jim Langston]

"Ron Natalie" <ro*@spamcop.ne twrote in message
news:44******** *************** @news.newshosti ng.com...

Rolf Magnus wrote:

>>
I tend to use constructor-style casts in such a situation:

for(size_t i = len - 1; size_t(-1) != i; --i)

But I think that's just because C style casts look so old-style to me
now ;-)

But a single arg function-style cast is identical in meaning to the
C-style cast. You're back to it possibly meaning static, const,
reinterpret or combinations of the above (as well as busting access
control which there is no C++-style equivelent to).

Actually, not at all. size_t(-1) tells me exactly what is going on. This
is a size_t variable that is being initialized to -1. There is no ambiguity
at all. It is not techinically a cast, I don't think.

[Rolf Magnus]

Jim Langston wrote:

"Ron Natalie" <ro*@spamcop.ne twrote in message
news:44******** *************** @news.newshosti ng.com...

>Rolf Magnus wrote:

>>>
I tend to use constructor-style casts in such a situation:

for(size_t i = len - 1; size_t(-1) != i; --i)

But I think that's just because C style casts look so old-style to me
now ;-)

But a single arg function-style cast is identical in meaning to the
C-style cast. You're back to it possibly meaning static, const,
reinterpret or combinations of the above (as well as busting access
control which there is no C++-style equivelent to).

Actually, not at all. size_t(-1) tells me exactly what is going on. This
is a size_t variable that is being initialized to -1. There is no
ambiguity at all. It is not techinically a cast, I don't think.

size_t is unsigned and can't have negative values. size_t(-1) tells the
compiler that you want -1 converted to size_t, IOW, it's a cast.

[Richard Herring]

In message <e9************ *@news.t-online.com>, Rolf Magnus
<ra******@t-online.dewrites

>
I tend to use constructor-style casts in such a situation:

for(size_t i = len - 1; size_t(-1) != i; --i)

I'd lose the -1 altogether ;-)

for (size_t i = len; i-- != 0; )
--
Richard Herring

[Frederick Gotham]

Richard Herring posted:

> for(size_t i = len - 1; size_t(-1) != i; --i)

I'd lose the -1 altogether ;-)

for (size_t i = len; i-- != 0; )

Yes but this has re-arranged the natural order of the loop.

I like my "for" loops to have four phases:

(1) The "initialisa tion stuff" is executed first of all.

(2) The condition is tested.

(3) The body is executed.

(4) The "prepare for next iteration" stuff is executed.
Your example mixes (2) and (4), which I don't like.

--

Frederick Gotham

[Frederick Gotham]

Rolf Magnus posted:

size_t is unsigned and can't have negative values. size_t(-1) tells the
compiler that you want -1 converted to size_t, IOW, it's a cast.

There's an implicit conversion from int to size_t, so no cast is required.

When dealing with intrinsic types, the following are exactly equivalent:

short(5)

(short)5

I myself prefer the latter, for two reasons:

(1) You can have types which consist of more than one word, e.g.
"unsigned short".
(2) It resembles a cast.

I dislike the former because:

(1) It looks like the construction of a user-defined class type.
(2) It doesn't resemble a cast at all.
(3) You can't use types which consist of more than one word.
--

Frederick Gotham