Zero-cost Abstraction — not exclusive to or invented by C++
Much research is done providing programmers abstractions that are both meaningful and efficient. In fact, abstractions such as arithmetic for both integers and real numbers are built into hardware along with string handling.
Comments on:
Making languages efficient by both design and implementation has been important every since John Backus designed FORTRAN in the early 1950s. It wasn’t suddenly thought about with the arrival of C++.
But zero-cost is a misleading term. Even with hardware handling of these abstractions, there is a cost.
“C++ has a reputation for being a language that grants developers immense control and efficiency.”
The reputation does not reflect the truth. The truth is that C++ (like C) forces programmers to think about things they should not have to. The above quote is just the spin C++ puts on it to fool programmers they have something when they really don’t. It is just the excuse for the extra burden programmers must do.
C++ is just dressing this up with a nice-sounding ‘zero-cost’ principle. Really it is an implementation problem, not a language problem. All languages in their implementations try to make things efficient.
“In many programming languages, abstractions (like classes, virtual functions, and templates) often come with a hidden performance cost.”
C++ making to cost explicit is not a help — it is still there. The fact is, again due to much research and progress in language and compiler development these things can be invisibly optimised.
C++’s making polymorphism explicit with marking functions ‘virtual’ is a case. Compilers in other languages can analyse each call to a feature of a class and determine whether the invocation is polymorphic or not. C++ forces the programmer to think up front if a function might be made polymorphic in subclasses. This can result in calls to the wrong non-polymorphic function.
Templates are C++’s awful implementation of generic classes (C++ also needs generic functions because functions don’t need to be in classes as in true OO languages). C++ templates are really just suped-up macros, generating repetitive copies. That is not particularly efficient or zero cost.
“Runtime overhead: Extra instructions or memory usage needed to manage the abstraction.”
Some abstractions require no overhead. This is not dependent on C++. As I said above, abstractions for numbers and strings and implemented in hardware.
“Indirect access: Needing to jump through hoops to get to the actual data or function.”
In fact, where programmers think they are writing things in an optimal way, they often work against a compiler code generator or optimiser. C++ is full of those kinds of issues where optimisation is not possible because the compiler must accept that something weird the programmer has done must be for some purpose. It is difficult for code generators and optimisers in C and C++ to guarantee that the meaning of a transformation is the same as the original. Hence optimisation is not possible. Virtual functions are an example of that.
The problem with both C and C++ is that programmers are expected to understand how any abstraction or something on the surface syntax is implemented underneath. But the assumptions for one platform might not hold for another. This is the role of a compiler to build the knowledge of those differences into the compiler so the programmer programs in the computational abstractions, not the assumptions about underneath implementations.
That is why C and C++ will never be modern languages, and why comments such as the following are made:
Alan Kay (who coined OO): “I made up the term "object-oriented," and I can tell you I did not have C++ in mind.”
“This is the most pernicious thing about C++ and Java in that they think they’re helping the programmer by looking as much like the old thing as possible but in fact they’re hurting the programmer terribly by making it difficult for the programmer to understand what is really powerful about this new metaphor.”
Ken Thompson (originator of B/C from BCPL) confirms Kay’s assessment: “[C++] certainly has its good points. But by and large I think it's a bad language. It does a lot of things half well and it’s just a garbage heap of ideas that are mutually exclusive.”
https://www.quora.com/Is-c++-is-the-best-programming-language/answer/Ian-Joyner-1
Linus Torvalds: “C++ is a horrible language.”
http://harmful.cat-v.org/software/c++/linus
Bruce Eckel: “The complexity of C++ (even more complexity has been added in the new C++), and the resulting impact on productivity, is no longer justified. All the hoops that the C++ programmer had to jump through in order to use a C-compatible language make no sense anymore -- they're just a waste of time and effort.”
Niklaus Wirth: “Increasingly, people seem to misinterpret complexity as sophistication, which is baffling—the incomprehensible should cause suspicion rather than admiration.”
Niklaus Wirth: “C++ is an insult to the human brain” https://www.azquotes.com/picture-quotes/quote-c-is-an-insult-to-the-human-brain-niklaus-wirth-140-7-0738.jpg
Tony Hoare: “I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.”
Tony. Hoare once remarked: “A language is characterized not only by what it permits programmers to specify, but even more so by what it does not allow.”
C and C++ conform more to the latter, except, that there are many obvious deficiencies in the designs.
https://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus/
https://www.quora.com/Is-C-pure-OOP-or-not/answer/Ian-Joyner-1
