I don't get what's bad about rule 7. And I haven't really programmed in C++ for a decade. When you are calling derived object through a base class pointer you have a choice if you want to call the function of the base class or the function of the derived class. If you don't make it virtual it's called by pointer type, if you do, it's called by pointee type. Same goes for the destructors with only difference being that in case of virtual destructor the deatructor of a base class will be called automatically after the destructor of the derived class. So basically if you want to override methods or the destructor make your functions virtual, including the destructor.

Does it lead to problems? Surely. Should all metods be virtual by default? Probably. Should there be some keyword that indicates in derived class that a method intentionally shadows a non virtual method from the base class? Yes.

It's not a great human oriented design but it's consistent.

▲

chuckadams a day ago | parent [-]

Apologies, I was referring to a "Rule of 7", but I more or less hallucinated it, since I'd heard the old "rule of 3" then "rule of 5" had been revised again, and thought they were maybe going with prime numbers?

https://en.cppreference.com/w/cpp/language/rule_of_three.htm...

The confusion kind of speaks for itself. The language is a construction set where the primary building block is razor blades.

	▲	quuxplusone a day ago \| parent \| next [-]
		Ten years ago I gave a C++ conference talk titled "The Rule of Seven (Plus or Minus Two)" — a reference to the "magic number seven" meme https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus... and alluding to the fact that besides the well-established "Rule of 5" (copy construction and assignment, move construction and assignment, and destruction) a C++ class author also needs to at least think about whether to provide: default constructor, ADL swap, equality comparison operator, and/or specialized std::hash. And maybe a few more I'm forgetting right now. In hindsight (without rewatching it right now) I remember my thesis in that talk as erring too much on the side of "isn't this confusing? how exciting! be worried about the state of things!" These days I'd try harder to convey "it's not really that hard; yes there are a lot of customization knobs, but boring rules of thumb generally suffice; newbies shouldn't actually lose sleep over this stuff; just remember these simple guidelines."
	▲	scotty79 10 hours ago \| parent \| prev \| next [-]
		I remeber that while learning Rust and writing fairly complex programs I had so many times when compiler was in my way, but once I finally figured out how to satisfy it, I saw that if I was writing in C++ I would just shoot myself in the foot in subtle hard to debug ways if I did what I tried to do and C++ compiler would happily let me.
	▲	einpoklum a day ago \| parent \| prev [-]
		It's important to notice that you can keep well out of trouble by sticking to the rule of _zero_, i.e. relying on the defaults for copy&move ctors, assignment operators and destructor. So, the best advice is: Don't mess with the razor blades. And these days, C++ gives you enough in the standard library to avoid messing with them yourself. But since this is C++, you _can_ always open up the safety casing and messing with things, if you really want to.