Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #80563 > unrolled thread

dynamic_cast

Back to article view | Back to comp.lang.c++

Contents

  dynamic_cast Mr Flibble <flibble@reddwarf.jmc> - 2021-06-27 22:51 +0100
    Re: dynamic_cast Öö Tiib <ootiib@hot.ee> - 2021-06-27 15:01 -0700
    Re: dynamic_cast Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-06-27 22:30 +0000
    Re: dynamic_cast "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-27 16:35 -0700
    Re: dynamic_cast Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-28 08:44 +0200
      Re: dynamic_cast Vir Campestris <vir.campestris@invalid.invalid> - 2021-07-01 21:14 +0100
        Re: dynamic_cast Öö Tiib <ootiib@hot.ee> - 2021-07-01 14:16 -0700
        Re: dynamic_cast red floyd <no.spam.here@its.invalid> - 2021-07-01 17:48 -0700
        Re: dynamic_cast Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-03 14:45 +0200
          Re: dynamic_cast Richard Damon <Richard@Damon-Family.org> - 2021-07-03 09:39 -0400
            Re: dynamic_cast Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-03 15:53 +0200
              Re: dynamic_cast Richard Damon <Richard@Damon-Family.org> - 2021-07-03 09:59 -0400
                Re: dynamic_cast Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-03 17:01 +0200
                  Re: dynamic_cast Richard Damon <Richard@Damon-Family.org> - 2021-07-03 11:42 -0400
                    Re: dynamic_cast Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-03 18:04 +0200
                      Re: dynamic_cast Richard Damon <Richard@Damon-Family.org> - 2021-07-03 13:59 -0400
                        Re: dynamic_cast Mr Flibble <flibble@reddwarf.jmc> - 2021-07-03 20:06 +0100
                        Re: dynamic_cast Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-04 07:06 +0200
                      Re: dynamic_cast Richard Damon <Richard@Damon-Family.org> - 2021-07-03 14:03 -0400
                    Re: dynamic_cast Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 13:06 -0700

#80563 — dynamic_cast

every time you use dynamic_cast an angel gets fucked in the arse by a
demon.

[toc] | [next] | [standalone]

#80564

On Monday, 28 June 2021 at 00:51:51 UTC+3, Mr Flibble wrote:
> every time you use dynamic_cast an angel gets fucked in the arse by a 
> demon.

WTF? Missing Rick, aren't you?

[toc] | [prev] | [next] | [standalone]

#80565

On 2021-06-27, Mr Flibble <flibble@reddwarf.jmc> wrote:
> every time you use dynamic_cast an angel gets fucked in the arse by a
> demon.
It was at least 10 years ago when I used it last time...
>

[toc] | [prev] | [next] | [standalone]

#80566

On 6/27/2021 2:51 PM, Mr Flibble wrote:
> every time you use dynamic_cast an angel gets fucked in the arse by a
> demon.
> 

Holy Shit!

[toc] | [prev] | [next] | [standalone]

#80567

> every time you use dynamic_cast an angel gets fucked in the arse by a
> demon.

dynamic_cast<> is slow and mostly the things you do with
it could be done faster through a virtual function call.

[toc] | [prev] | [next] | [standalone]

#80611

On 28/06/2021 07:44, Bonita Montero wrote:
>> every time you use dynamic_cast an angel gets fucked in the arse by a
>> demon.
> 
> dynamic_cast<> is slow and mostly the things you do with
> it could be done faster through a virtual function call.

Mostly.

I just did a line count on our codebase; we have about 1 dynamic cast 
for every 10k lines. Compare with static_cast - 1 in 300.

(This is over several million lines of cpp files.)

I don't know what all the calls are, but the pattern I am most familiar 
with is: This pointer from my database points to an interface. It might 
be a type 1 object, in which case do ONE(). It might be a type 2, in 
which case do TWO().

Andy

[toc] | [prev] | [next] | [standalone]

#80612

On Thursday, 1 July 2021 at 23:14:24 UTC+3, Vir Campestris wrote:
> On 28/06/2021 07:44, Bonita Montero wrote: 
> >> every time you use dynamic_cast an angel gets fucked in the arse by a 
> >> demon. 
> > 
> > dynamic_cast<> is slow and mostly the things you do with 
> > it could be done faster through a virtual function call.
> Mostly. 
> 
> I just did a line count on our codebase; we have about 1 dynamic cast 
> for every 10k lines. Compare with static_cast - 1 in 300. 
> 
> (This is over several million lines of cpp files.) 
> 
> I don't know what all the calls are, but the pattern I am most familiar 
> with is: This pointer from my database points to an interface. It might 
> be a type 1 object, in which case do ONE(). It might be a type 2, in 
> which case do TWO(). 

In some circumstances one can use typeid check and static_cast
or just dynamic_cast alone but making it with something else 
will result with more code and likely be less efficient too. 

[toc] | [prev] | [next] | [standalone]

#80613

On 7/1/2021 1:14 PM, Vir Campestris wrote:
> 
> I don't know what all the calls are, but the pattern I am most familiar 
> with is: This pointer from my database points to an interface. It might 
> be a type 1 object, in which case do ONE(). It might be a type 2, in 
> which case do TWO().

Why can't you use a virtual member function for this?  Or is it to cast
the pointer from the database to one of two different hierarchies?

[toc] | [prev] | [next] | [standalone]

#80634

> I just did a line count on our codebase; we have about 1 dynamic
> cast for every 10k lines. Compare with static_cast - 1 in 300.

Using dynamic_cast instead of a virtual function call is bad coding.

[toc] | [prev] | [next] | [standalone]

#80637

On 7/3/21 8:45 AM, Bonita Montero wrote:
>> I just did a line count on our codebase; we have about 1 dynamic
>> cast for every 10k lines. Compare with static_cast - 1 in 300.
> 
> Using dynamic_cast instead of a virtual function call is bad coding.

Incorrect, often to add the virtual function call to get around the need
for the dynamic_cast requires injecting into a class concepts that it
should not be dealing with.

As an example, say you have a collection of animals, and you want to
extract all the dogs out of it. You could add to Animal and Dog an isDog
function, (and then need to change Animal again for each new type of
thing you might want get, lousy encapsulation) or you can use a
dynamic_cast to check if this animal is a Dog.

[toc] | [prev] | [next] | [standalone]

#80638

>> Using dynamic_cast instead of a virtual function call is bad coding.

> Incorrect, often to add the virtual function call to get around the need
> for the dynamic_cast requires injecting into a class concepts that it
> should not be dealing with.

If you're doing a dynamic_cast you're switching upon the type of the
class. This switching should be better done inside the class with class
-dependent code - with a virtual function call.

> As an example, say you have a collection of animals, and you want to
> extract all the dogs out of it. You could add to Animal and Dog an isDog
> function, (and then need to change Animal again for each new type of
> thing you might want get, lousy encapsulation) or you can use a
> dynamic_cast to check if this animal is a Dog.

the isDog-function would be faster.

[toc] | [prev] | [next] | [standalone]

#80639

On 7/3/21 9:53 AM, Bonita Montero wrote:
>>> Using dynamic_cast instead of a virtual function call is bad coding.
> 
>> Incorrect, often to add the virtual function call to get around the need
>> for the dynamic_cast requires injecting into a class concepts that it
>> should not be dealing with.
> 
> If you're doing a dynamic_cast you're switching upon the type of the
> class. This switching should be better done inside the class with class
> -dependent code - with a virtual function call.

Wrong. Application level logic should stay in the application level
code. That is the only scalable option.

> 
>> As an example, say you have a collection of animals, and you want to
>> extract all the dogs out of it. You could add to Animal and Dog an isDog
>> function, (and then need to change Animal again for each new type of
>> thing you might want get, lousy encapsulation) or you can use a
>> dynamic_cast to check if this animal is a Dog.
> 
> the isDog-function would be faster.
> 

But then  it also needs isCat, isHorse, isSnake, isMammel, isReptile,
and so on.

The virtual function method says that you need to change Animal EVERY
TIME you define a new type of animal for the system. This breaks
encapsulation, and binary compatibility, as adding a virtual function to
the base class changes the definition of EVERY subclass to that class.

[toc] | [prev] | [next] | [standalone]

#80641

>> If you're doing a dynamic_cast you're switching upon the type of the
>> class. This switching should be better done inside the class with class
>> -dependent code - with a virtual function call.

> Wrong. Application level logic should stay in the application level
> code. That is the only scalable option.

Virtual function calls are more scalable.

>>> As an example, say you have a collection of animals, and you want to
>>> extract all the dogs out of it. You could add to Animal and Dog an isDog
>>> function, (and then need to change Animal again for each new type of
>>> thing you might want get, lousy encapsulation) or you can use a
>>> dynamic_cast to check if this animal is a Dog.

>> the isDog-function would be faster.

> But then  it also needs isCat, isHorse, isSnake, isMammel, isReptile,
> and so on.

Maybe, but that's much faster. Dynamic downcasts are slower.

> The virtual function method says that you need to change Animal EVERY
> TIME you define a new type of animal for the system. This breaks
> encapsulation, ...

No, it is encapsulation.

[toc] | [prev] | [next] | [standalone]

#80643

On 7/3/21 11:01 AM, Bonita Montero wrote:
>>> If you're doing a dynamic_cast you're switching upon the type of the
>>> class. This switching should be better done inside the class with class
>>> -dependent code - with a virtual function call.
> 
>> Wrong. Application level logic should stay in the application level
>> code. That is the only scalable option.
> 
> Virtual function calls are more scalable.

Wrong, the NUMBER of functions needed grows way to fast to be scalable.
It also requires GLOBAL changes in API to implement local algorithms.

The act of adding the function could well require recompiling millions
of lines of code over many applications if the base class is commonly use.

Imagine what would happen if someone decided that string needed a new
function that made ALL code that uses it to need to be recompiled. This
is an X.0.0 type of change.

> 
>>>> As an example, say you have a collection of animals, and you want to
>>>> extract all the dogs out of it. You could add to Animal and Dog an
>>>> isDog
>>>> function, (and then need to change Animal again for each new type of
>>>> thing you might want get, lousy encapsulation) or you can use a
>>>> dynamic_cast to check if this animal is a Dog.
> 
>>> the isDog-function would be faster.
> 
>> But then  it also needs isCat, isHorse, isSnake, isMammel, isReptile,
>> and so on.
> 
> Maybe, but that's much faster. Dynamic downcasts are slower.
> 
>> The virtual function method says that you need to change Animal EVERY
>> TIME you define a new type of animal for the system. This breaks
>> encapsulation, ...
> 
> No, it is encapsulation.

No, it BREAKS encapsulation. If adding a new type of animal requires a
change in the animal base, the base is not properly encapsulated.

Note, the RTTI interface that is provided built into C++ provides that
encapsulated interface that allows you to detect this without needing to
make these changes.

[toc] | [prev] | [next] | [standalone]

#80645

> Wrong, the NUMBER of functions needed grows way to fast to be scalable.

Use an enum and return an enum-value in _one_ function.
That's faster than a dynamical downcast.

[toc] | [prev] | [next] | [standalone]

#80654

On 7/3/21 12:04 PM, Bonita Montero wrote:
>> Wrong, the NUMBER of functions needed grows way to fast to be scalable.
> 
> Use an enum and return an enum-value in _one_ function.
> That's faster than a dynamical downcast.

Doesn't handle the Animal -> Mammel -> Canine -> Dog -> Poodle case
without a big lookup table to say that Poodles are also Dogs and
Canines, and Mammels.

You STILL need to edit the Animal.h file every time you add new derived
class. Lack of Encapsulation.

[toc] | [prev] | [next] | [standalone]

#80659

On Sat, 3 Jul 2021 13:59:14 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 7/3/21 12:04 PM, Bonita Montero wrote:
> >> Wrong, the NUMBER of functions needed grows way to fast to be
> >> scalable.  
> > 
> > Use an enum and return an enum-value in _one_ function.
> > That's faster than a dynamical downcast.  
> 
> Doesn't handle the Animal -> Mammel -> Canine -> Dog -> Poodle case
> without a big lookup table to say that Poodles are also Dogs and
> Canines, and Mammels.
> 
> You STILL need to edit the Animal.h file every time you add new
> derived class. Lack of Encapsulation.

You are both wrong; if you are using dynamic_casts or isDog() then that
suggests you animal abstraction isn't elaborate enough, animal class
should include a list of behaviours as child objects (i.e. composition
instead of inheritance) and one such behaviour might be barking,
canBark(), and could be used together with the visitor pattern, for
example.

/Flibble

[toc] | [prev] | [next] | [standalone]

#80665

>> Use an enum and return an enum-value in _one_ function.
>> That's faster than a dynamical downcast.

> Doesn't handle the Animal -> Mammel -> Canine -> Dog -> Poodle case
> without a big lookup table to say that Poodles are also Dogs and
> Canines, and Mammels.

It wasn't my idea to handle animal-specific behaviour outside the
specific animal class. But if you do it what I suggested is the
most efficient way.

[toc] | [prev] | [next] | [standalone]

#80656

On 7/3/21 12:04 PM, Bonita Montero wrote:
>> Wrong, the NUMBER of functions needed grows way to fast to be scalable.
> 
> Use an enum and return an enum-value in _one_ function.
> That's faster than a dynamical downcast.

And why add a function like that when you could just use typeid(). You
still need the table to handle types that might  be sub-classed.
dynamic_cast provides all that capability as built in functionality.

[toc] | [prev] | [next] | [standalone]

#80792

Richard Damon <Richard@Damon-Family.org> writes:

> On 7/3/21 11:01 AM, Bonita Montero wrote:
>
>>>> If you're doing a dynamic_cast you're switching upon the type of the
>>>> class.  This switching should be better done inside the class with class
>>>> -dependent code - with a virtual function call.
>>>
>>> Wrong.  Application level logic should stay in the application level
>>> code.  That is the only scalable option.
>>
>> Virtual function calls are more scalable.
>
> Wrong, the NUMBER of functions needed grows way to fast to be scalable.

It might, but it doesn't have to.  The number of functions
needed depends on the class hierarchy.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web