While perfectly fine, this comment unironically reinforces the GP's assertion of "how [C++] as a whole the language is basically a gigantic ball of special cases"
In a language designed for humans, the simplest expression of a loop (e.g. `for (auto paths : m) {}`) would use references not value copying. You'd have to go out of your way to do the it the dumb way, which you would only do when you have a specific reason to do so.
C++, on the other hand, is only really an effective language in the hands of people who have either fully internalized the 1,000 page specification, or wasted a depressing number of synaptic connections on memorizing minute trivia about what constructs to use under what circumstances.
I say this as someone who works with C++ on a daily basis :(
No. You use profiling tools and optimize hotspots. Pareto principle applies here so you look at 20% of program tops.
Rest is irrelevant and can be executed as inefficiently as you please as long as you got your big O complexity right.
Pick the right language.
I'll take my RAII and destructors, thank you very much.
And with Python you use heavily optimized native libraries (Numpy & co.) where it matters.
And in regard to the first draft of a C++ program being slow until you spend lots of time optimizing it, when comparing to say Haskell, that is not at all my experience. I'm generally able to write clean and efficient programs in C++ on the first draft, and they are invariably more performant than if I had written it in a slower language, without a significantly greater amount of effort.
In case you want to state that a VM is like a language runtime in that case, C++ also needs one for handling exceptions, RTTI, global constructors/destructors, floating point emulation,...
In C++ values are first class, making 'auto x' an implicit reference would be surprising for anybody with experience with the language model. It is also consistent[1] with the template deduction rules. I strongly believe that not not having first class values in a language with mutation is a design mistake [2].
[1] IIRC the ill designed initialization_list has special rules for auto. [2] C++ references are not first class which is also a mistake.
But I would expect
auto x = y;
for(auto x : y)
for(auto& x : y)
Of course you may now say that one should have done it right from the start, but this is then an argument about the initial decisions in the late 80s, not about the use of auto in C++11.
Regarding the specification, I am incredibly happy that there is a specification I can trust and nowadays a series of different compilers which largely implement this specification instead of some "model-implementation" which implicitly defines the language and may look entirely different next week.
Why would you expect that? There are plenty of examples of other referentially transparent languages where "x = y" means x and y refer to the same thing, not different things (one newly created) initialized to the same value. Maybe you expect it to work the way it does because that more closely resembles how C++ has worked for you in the past, which is a bit of a circular argument.
> Of course you may now say that one should have done it right from the start, but this is then an argument about the initial decisions in the late 80s, not about the use of auto in C++11.
Yes, that's exactly the point I am making.
If they could do anything more stupid as introducing a galling difference and a special case to variable initialisation with auto, it would be to do exactly that, but because “some other languages work more like that”.