Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

dynamic_cast

95 views
Skip to first unread message

Mr Flibble

unread,
Jun 27, 2021, 5:51:51 PM6/27/21
to
every time you use dynamic_cast an angel gets fucked in the arse by a
demon.

Öö Tiib

unread,
Jun 27, 2021, 6:01:35 PM6/27/21
to
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?

Branimir Maksimovic

unread,
Jun 27, 2021, 6:30:55 PM6/27/21
to
On 2021-06-27, Mr Flibble <fli...@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...
>

Chris M. Thomasson

unread,
Jun 27, 2021, 7:35:15 PM6/27/21
to
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!

Bonita Montero

unread,
Jun 28, 2021, 2:44:29 AM6/28/21
to
> 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.

Vir Campestris

unread,
Jul 1, 2021, 4:14:24 PM7/1/21
to
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

Öö Tiib

unread,
Jul 1, 2021, 5:16:30 PM7/1/21
to
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.

red floyd

unread,
Jul 1, 2021, 8:49:04 PM7/1/21
to
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?



Bonita Montero

unread,
Jul 3, 2021, 8:45:43 AM7/3/21
to
> 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.

Richard Damon

unread,
Jul 3, 2021, 9:39:48 AM7/3/21
to
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.

Bonita Montero

unread,
Jul 3, 2021, 9:53:39 AM7/3/21
to
>> 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.

Richard Damon

unread,
Jul 3, 2021, 9:59:58 AM7/3/21
to
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.

Bonita Montero

unread,
Jul 3, 2021, 11:01:28 AM7/3/21
to
>> 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.

Richard Damon

unread,
Jul 3, 2021, 11:43:00 AM7/3/21
to
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.

Bonita Montero

unread,
Jul 3, 2021, 12:05:03 PM7/3/21
to
> 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.

Richard Damon

unread,
Jul 3, 2021, 1:59:29 PM7/3/21
to
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.

Richard Damon

unread,
Jul 3, 2021, 2:03:19 PM7/3/21
to
On 7/3/21 12:04 PM, Bonita Montero wrote:
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.

Mr Flibble

unread,
Jul 3, 2021, 3:07:14 PM7/3/21
to
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

Bonita Montero

unread,
Jul 4, 2021, 1:06:40 AM7/4/21
to
>> 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.

Tim Rentsch

unread,
Aug 7, 2021, 4:07:13 PM8/7/21
to
Richard Damon <Ric...@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.
0 new messages