| My objection is lot of features are being added as library features in ad-hoc ways. The old "if it can be library, it should be library" fallacy. The classic example is C++ ranges' pipe operator. If it was implemented in language, like OCaml and Elixir do
- There would have been no need to write range adapters
- the error messages and debugging could be much better than 100000 line template implementation.
- debug build would be fast as well
- compile times would not suffer Implemet-it-as-library is often a leaky, brittle abstraction. That's the reason LISP, with its proclaimed magic capabilities, didn't take off. The C++ committee seems quite academic at moment. Last time I read C++ performance report, all I could find was some old advice like "use list if you want insertion"™. They didn't mention difficulties in using realloc in vectors. They didn't mention inefficiencies in stl HashMap implementations due to iterator invalidation constraints. They didn't mention exceptions requiring dynamic storage and RTTI. Note that many of these problems are not yet fully solved with move constructors. At the same time they are also less academic than required. Given how they managed to put pipelines into an ugly template library without any of the considerations I mentioned above. I can't help but I feel similarly towards all standards committees. The JS standards people are still unable to deliver a standard library, and a "use strict"-like flag that enables easy tree-shaking. If anyone here is in C++ standard committee, you owe us an answer. |
The TR18015 (Technical Report on C++ Performance) goes into details on most of the above (and much more) and it was written in 2006. The only thing missing is a discussion of hash_map as it wasn't part of the standard yet.