Finally Final
The book "A Tour of C++" is kind of difficult reading. A programming book that is written like essays, I cannot imagine how B.S. was able to implement such a class of writing. It is as dense as a piece of Python code, where keywords are highlighted and cross referenced all to LATER CHAPTERS; and the words in between keywords are highly sophisticated as if it is a financial literacy to reinterpret the marginal utility.
Disclaimer: haven't used C++ since 10+ years ago, and haven't read the LATER CHAPTERS.
One paragraph is rather confusing, ch5.2 "Concrete Types". "The defining characteristic of a concrete type is that its representation is part of its definition. For ... class, that representation is present in each object of the concrete class. That allows implementations to be optimally efficient in time and space."
So that's a very philosophical way to say being able to allocate object on the stack; but the text also said (for a container like vector) "that representation is only one or more pointers to data stored elsewhere."
Java made the distinction between interface and abstract class. It does not enforce "override" checking, and interfaces can have default implementations (means representation does not matter.) Python does not have overloads or overrides, so as long as the name is found, it is chosen from the inheritance lattice. Without strict "overloads/overrides", the complexity of code is reduced by a dimension, as one does not have to guess which "version" of method. You would think that makes people use more inheritance because of the simplified approach? Wrong. More code created with Java or Python are essentially "final". I came across some cursed base class code in Python, it calls a method that _should have been pure virtual_ but undeclared in the base class. The code smelled so bad - it is a data access utility, but it requires business logic to inherit from it and do nothing else but to implement the result handling. The only way to refactor the inverted control is to make both the business logic and the data access utility "final", break the inheritance.
I thought inheritance is going to be used less and less. With configurations, or infrastructure, templates are more useful than inheritance. Each unit test has its own occasion that should NOT be shared. The data access is generated and unique to the business logic. The code can be packaged as templates too - as a docker image, and each instance has its own specific resource and configuration. There is no time to read the code to figure out which class in the hierarchy implemented the method - each abstraction level in the hierarchy represents a distinct idea, too many ideas just are too difficult to understand. Eventually all code will be "final", "write once", like a shell script that has no reference to undeclared environment variable or functions.