Re: Turning off C++ casting?

Re: Turning off C++ casting?

[Paolo Bonzini]

> But if I'm iterating over lots of
> objects, I'd like to get rid off the cost of dynamic_cast when I know
> for sure the objects will always be of this type.

assert and the pointer version of dynamic_cast are your friends if you don't 
want #ifdefs.

  assert (dynamic_cast<ExtendedObject*>(&baseObj) != NULL);
  ExtendedObject& obj = *reinterpret_cast<ExtendedObject*>(&baseObj);

> What I want to know is whether GCC allows you to optimize
> 'dynamic_cast'ing: gcc -fno_dynamic_cast ....  I don't think gcc has
> such a switch.

Maybe -fno-rtti (along with disabling much more)?

Paolo

Re: Turning off C++ casting?

[Gabriel Dos Reis]

Paolo Bonzini <paolo.bonzini@polimi.it> writes:

| s> But if I'm iterating over lots of
| > objects, I'd like to get rid off the cost of dynamic_cast when I know
| > for sure the objects will always be of this type.
| 
| assert and the pointer version of dynamic_cast are your friends if you don't 
| want #ifdefs.
| 
|   assert (dynamic_cast<ExtendedObject*>(&baseObj) != NULL);
|   ExtendedObject& obj = *reinterpret_cast<ExtendedObject*>(&baseObj);

Please write the last line as

   ExtendedObject& obj = *dynamic_cast<ExtendedObject*>(&baseObj);

-- Gaby

Re: Turning off C++ casting?

[Paolo Bonzini]

> |   assert (dynamic_cast<ExtendedObject*>(&baseObj) != NULL);
> |   ExtendedObject& obj = *reinterpret_cast<ExtendedObject*>(&baseObj);
>
> Please write the last line as
>
>    ExtendedObject& obj = *dynamic_cast<ExtendedObject*>(&baseObj);

Why?  The point was to avoid the performance impact (assuming there is) of 
dynamic_cast in non-debugging releases.  After the dynamic_cast has been 
checked to be valid, you can use the faster reinterpret_cast safely, can't 
you?

Paolo

Re: Turning off C++ casting?

[Vladimir Merzliakov]

>> |   assert (dynamic_cast<ExtendedObject*>(&baseObj) != NULL);
>> |   ExtendedObject& obj = *reinterpret_cast<ExtendedObject*>(&baseObj);
>>
>> Please write the last line as
>>
>>    ExtendedObject& obj = *dynamic_cast<ExtendedObject*>(&baseObj);
>
>Why?  The point was to avoid the performance impact (assuming there is) of
>dynamic_cast in non-debugging releases.  After the dynamic_cast has been
>checked to be valid, you can use the faster reinterpret_cast safely, can't
>you?

I think expression:

(dynamic_cast<T*>(v)==0 || dynamic_cast<T*>(v)==reinterpret_cast<T*>(v))

can be false in case multiply inheritance and virtual inheritance.


Vladimir

Re: Turning off C++ casting?

[Gabriel Dos Reis]

Paolo Bonzini <paolo.bonzini@polimi.it> writes:

| > |   assert (dynamic_cast<ExtendedObject*>(&baseObj) != NULL);
| > |   ExtendedObject& obj = *reinterpret_cast<ExtendedObject*>(&baseObj);
| >
| > Please write the last line as
| >
| >    ExtendedObject& obj = *dynamic_cast<ExtendedObject*>(&baseObj);
| 
| Why?

Because you don't know what reinterpret_cast<> will do.  Do you?

|  The point was to avoid the performance impact (assuming there is) of 
| dynamic_cast in non-debugging releases.

If you know for sure that the derivation actually holds, then use
static_cast<>, -not- reinterpret_cast<>.  


|  After the dynamic_cast has been 
| checked to be valid, you can use the faster reinterpret_cast safely, can't 
| you?

Maybe it is faster (as usual with wrong answers); but safely certainly not.

-- Gaby

Re: Turning off C++ casting?

[Paolo Bonzini]

> (dynamic_cast<T*>(v)==0 || dynamic_cast<T*>(v)==reinterpret_cast<T*>(v))
>
> can be false in case multiply inheritance and virtual inheritance.

Ooh, right.  But the OP was using

(T*) (void *) (&baseObj)

which is an even uglier version of the reinterpret_cast.

Paolo

Re: Turning off C++ casting?

[Paolo Bonzini]

On Thursday 20 February 2003 13:17, Gabriel Dos Reis wrote:
> Paolo Bonzini <paolo.bonzini@polimi.it> writes:
> |  The point was to avoid the performance impact (assuming there is) of
> | dynamic_cast in non-debugging releases.
>
> If you know for sure that the derivation actually holds, then use
> static_cast<>, -not- reinterpret_cast<>.

You do because of the assert.  So the correct answer to the poster's question 
is to use

assert (dynamic_cast<ExtendedObject*>(&baseObj) != NULL);
ExtendedObject& obj = *static_cast<ExtendedObject*>(&baseObj);

Paolo

Re: Turning off C++ casting?

[Gabriel Dos Reis]

Paolo Bonzini <paolo.bonzini@polimi.it> writes:

| On Thursday 20 February 2003 13:17, Gabriel Dos Reis wrote:
| > Paolo Bonzini <paolo.bonzini@polimi.it> writes:
| > |  The point was to avoid the performance impact (assuming there is) of
| > | dynamic_cast in non-debugging releases.
| >
| > If you know for sure that the derivation actually holds, then use
| > static_cast<>, -not- reinterpret_cast<>.
| 
| You do because of the assert.

That is funny because you previously stated that you wanted to avoid
the dyanmic_cast<>.  Now, you're telling me that you are going to do it
anyway.  That is an *inconsistent* position.

|  So the correct answer to the poster's question 
| is to use
| 
| assert (dynamic_cast<ExtendedObject*>(&baseObj) != NULL);
| ExtendedObject& obj = *static_cast<ExtendedObject*>(&baseObj);

If you're going to do the dynamic_cast<>, then reuse the result:

  ExtendedObject* ptr = dynamic_cast<ExtendedObject*>(&baseObj);

  assert (ptr != 0);

  // use ptr

All this has nothing to do with GCC.

-- Gaby

Re: Turning off C++ casting?

[Mongryong]

On Thu, 2003-02-20 at 07:54, Gabriel Dos Reis wrote:
> All this has nothing to do with GCC.
> 
> -- Gaby

Actually it does.  Each compiler vendor may implement the C++ spec
differently for what 'they believe' is best.  The dynamic_cast interface
actually takes a 'hint' value that helps in speeding up dynamic_casts. 
Some special values for this hint parameter are:
-1: no hint
-2: src is not a public base of dst
-3: src is a multiple public base type but never a virtual base type

This is taken directly from ABI doc at
http://www.codesourcery.com/cxx-abi/abi.html

That's why I was curious if GCC had a switch that when turned on
"assumes all dynamic casts will work" as oppose to "doing a unnecessary
checking algorithm". 

Re: Turning off C++ casting?

[Jack Lloyd]

On Thu, 20 Feb 2003, Vladimir Merzliakov wrote:

> I think expression:
>
> (dynamic_cast<T*>(v)==0 || dynamic_cast<T*>(v)==reinterpret_cast<T*>(v))
>
> can be false in case multiply inheritance and virtual inheritance.

Yes, I've run into this before, where dynamic_cast works and a normal
C-style cast or static_cast does not (which can be exceptionally confusing
the first time you run into it).
 -Jack

Re: Turning off C++ casting?

[Paolo Bonzini]

> That is funny because you previously stated that you wanted to avoid
> the dyanmic_cast<>.  Now, you're telling me that you are going to do it
> anyway.  That is an *inconsistent* position.

The original poster wants to do the dynamic_cast only in debug versions, not 
release versions.  He asked for a flag to do so and it was pointed out that 
it is not feasible to implement it.

> All this has nothing to do with GCC.

Yes, it really belongs in gcc-help.

Paolo

Re: Turning off C++ casting??

[Vladimir Merzliakov]

I use:

template<class T1, class T2>
inline T1& castRef(T2& t) { 
  assert(dynamic_cast<T1*>(&t)!=0);
  return static_cast<T1&>(t);
}

template<class T1, class T2>
inline T1* castPtr(T2* t) { 
  assert(t==0||dynamic_cast<T1*>(t)!=0);
  return static_cast<T1*>(t);
}

Vladimir

Re: Turning off C++ casting??

[Mongryong]

On Wed, 2003-02-19 at 20:42, Joe Buck wrote:
> On Wed, Feb 19, 2003 at 07:01:43PM -0500, Mongryong wrote:
> > What I want to know is whether GCC allows you to optimize
> > 'dynamic_cast'ing: gcc -fno_dynamic_cast ....  I don't think gcc has
> > such a switch.
> 
> It doesn't.  Also, optimizations must preserve semantics, as in returning
> null if the object isn't of the right type, adjusting the pointer value
> in the case of multiple inheritance, etc.

I guess what I would like is the notion of a 'assert cast' - just like
assert is the DEBUG version of 'throwing an exception'.

#ifdef NDEBUG
template<typename RET, typename RES>
inline RET& assert_cast(SRC& arg) {
  return *((RET*)((void*)&arg));
}
#else
template<typename RET, typename RES>
inline RET& assert_cast(SRC& arg) {
  return dynamic_cast<RET&>(arg);
}
#endif

ExtendedObject& obj = assert_cast<ExtendedObject, BaseObject>(baseObj);

Does anyone see any problems with this implementation (from a GCC point
of view)?

Re: Turning off C++ casting??

[Mongryong]

On Wed, 2003-02-19 at 18:48, Mike Stump wrote:
> On Wednesday, February 19, 2003, at 02:51 PM, Mongryong wrote:
> > Is there a way to disable C++ casting?
> 
> #define and #ifdef, but only if you are really sure you want to do this 
> and your application spends 30% or more of its time in this code.  We 
> aren't going to help you hang yourself here, but the method should be 
> fairly obvious.  If it isn't, maybe you shouldn't consider doing it.
> 
Are you talking about #ifdef the code where I dynamic_cast takes place?

ie.
#ifndef NDEBUG
  ExtendedObject& obj = dynamic_cast<ExtendedObject&>(baseObj);
#else
  ExtendedObject& obj = *((ExtenedObject*)((void*)&baseObj));
#endif

What I want to know is whether GCC allows you to optimize
'dynamic_cast'ing: gcc -fno_dynamic_cast ....  I don't think gcc has
such a switch.

Does GCC allow you to override built in C++ casts?  If so, how do I do
it?

Re: Turning off C++ casting??

[Mongryong]

On Wed, 2003-02-19 at 18:17, Jack Lloyd wrote:
> In the case of dynamic_cast, this would be a tremendously bad idea. The
> reason dynamic_cast is so useful is because it allows you to do a cast even
> when you're not sure that the cast is correct; the dynamic_cast will test
> it for you. Replacing dynamic_cast with a static cast would cause all sorts
> of messes, given most uses of dynamic_cast. The other cast operations are
> just as cheap as a C-style cast, so it's a non-issue.
> 
 Sure, it's generally a bad idea.  But if I'm iterating over lots of
objects, I'd like to get rid off the cost of dynamic_cast when I know
for sure the objects will always be of this type.  Dynamic casting is
expensive when iterating lots of objects!  I can manually do it using my
own dynamic_cast, but I would like to know if there's a nicer way to do
by simply 'telling' dynamic cast to always perform the cast.

Maybe a better question would be:  "Can I override the C++ dynamic_casts
like I can the new and delete operators?"

Re: Turning off C++ casting??

[Jack Lloyd]

In the case of dynamic_cast, this would be a tremendously bad idea. The
reason dynamic_cast is so useful is because it allows you to do a cast even
when you're not sure that the cast is correct; the dynamic_cast will test
it for you. Replacing dynamic_cast with a static cast would cause all sorts
of messes, given most uses of dynamic_cast. The other cast operations are
just as cheap as a C-style cast, so it's a non-issue.

-Jack

On 19 Feb 2003, Mongryong wrote:

> Is there a way to disable C++ casting?  That is, during
> development/debugging I like using C++ casts like dynamic_cast to ensure
> my parameters are correct.  However, for a release build where I'm
> confident 'all down-casting' is safe, I would like the casting to be
> turn off - that is, something similar to 'C' type casting:
>
> // Debug build
> void func(BaseObject& obj) {
>   ExtendedObject& obj = dynamic_cast<ExtendObject&>(obj);
> //...
> }
>
> // Release build
> void func(BaseObject& obj) {
>   ExtendedObject& obj = *((ExtendObject*)((void*)arg)); // release build
> //...
> }
>
> Correct me if I'm wrong, but I believe the release build is faster.
>
>
>

Turning off C++ casting??

[Mongryong]

Is there a way to disable C++ casting?  That is, during
development/debugging I like using C++ casts like dynamic_cast to ensure
my parameters are correct.  However, for a release build where I'm
confident 'all down-casting' is safe, I would like the casting to be
turn off - that is, something similar to 'C' type casting:

// Debug build
void func(BaseObject& obj) {
  ExtendedObject& obj = dynamic_cast<ExtendObject&>(obj);   
//...
}

// Release build
void func(BaseObject& obj) {  
  ExtendedObject& obj = *((ExtendObject*)((void*)arg)); // release build
//...
}

Correct me if I'm wrong, but I believe the release build is faster.