Challenging C.153 "Prefer virtual function to casting" about cppcoreguidelines HOT 4 OPEN

@jwakely : About suggestion 4: It was the right link, but on second thought I agree that this is not a well-enough-baked idiom to suggest in the guidelines. I didn't mean the static-reflection-based idea, I meant the manual vtable approach. There is the dyno library for that, mentioned in the video as well, but - yeah, on second thought I wouldn't recommend it in a "core guidelines" document.

from cppcoreguidelines.

filling classes up with functionality which isn't inherently part of the class.

Do you have an example of this? It's not a problem I think I've encountered.

a polymorphic base class becomes a kitchen sink pulling in the code of everything which uses that class.

This seems like a slippery slope fallacy. Do you have an example of how following the guideline leads to this?

implement the three methods:

This approach seems to be solving a different problem. If you have the concrete classes, that is, you have objects of static types A, B, and C, why would you be using a virtual function A::foo() or casting from A to B or C in the first place? The guideline is talking about code which has a parameter of type A& and wants to use features of the derived types. It's not saying that when you already have the derived types you should discard all that type information and push everything into a virtual function and call it through a reference to the base type. It's talking about cases when you don't have the derived types. In those cases, it says you should use virtual functions instead of assuming/guessing/detecting the derived types and casting to them.

If the suggestion is that code should not take A& and should just work directly with concrete types, that's a very different approach, but not really in scope for this C.153 guideline. Duplicating every API for every concrete derived type is not practical, and sometimes not even possible (not all derived types are known initially). But if you know the concrete types and want to access functionality of those types, sure, go ahead and access it directly. The guideline is not saying you can't do that.

Maybe this C.153 guideline should be prefixed by saying "when using OOP-style class hierarchies..." whereas your challenge seems to be more like "don't use OOP hierarchies". That seems far broader than C.153 and needs more than a single example with three overloads to demonstrate it.

from cppcoreguidelines.

4. Consider suggesting value-semantics-maintaining dynamic 'hand-crafted' dynamic polymorphism, as in This CppCon 2023 talk.

Did you paste the right link? That's from 2020 and to quote the video:

"It's a lot, of course you can do a bunch of stuff with macros of clever templates to make this easier, but the point is I don't want to have to do this for every class. [...] It's a lot of work, it's a lot of things to get wrong. And because it's kind of weird code, it's easy to get wrong."

And then the rest of the talk is about how it might be done better in a hypothetical future version of C++.

I don't think that is suitable for the Core Guidelines. These are supposed to be tried and tested techniques that can be applied to most code bases by most developers. Not advanced techniques for experts from leading edge conferences, and certainly not things that aren't even in C++ today.

Value semantics and dynamic polymorphism without virtual are certainly powerful and useful, but I don't think they're sufficiently well understood to say "stop writing classic OOP-style code and do this instead". At least not in this document, yet.

from cppcoreguidelines.

filling classes up with functionality which isn't inherently part of the class.

Do you have an example of this? It's not a problem I think I've encountered.

a polymorphic base class becomes a kitchen sink pulling in the code of everything which uses that class.

This seems like a slippery slope fallacy. Do you have an example of how following the guideline leads to this?

Think of one of the quintessential class hierarchy example: Geometric shapes or UI widgets. You need to paint them, you need to move them, you need to serialize them (possibly in more than one way, e.g. for debug-printing and for persistence when shutting down an app), you may need to check whether they cover a given point, whether they intersect another shape or widget, you may need to compute the union of shapes, you need to compute the convex hull of shapes, you need to apply a certain style to them given a style rule object, etc. That's already quite a lot of stuff, and (almost) none of it is inherent to the class.

But regardless - even doing this once breaks C.4 . I was just taking this to the extreme to emphasize that point.

from cppcoreguidelines.