Is it hidden if it's explained in the standard?
I think Linus's complain was before there was a c++ standard. An updated version of the complaint would be "this shit is doing too much".
Is it hidden if it's explained in the standard?
I think Linus's complain was before there was a c++ standard. An updated version of the complaint would be "this shit is doing too much".
> Is it hidden if it's explained in the standard?
In the context of that particular complaint, yes. From what I understand the gist of it is basically that you should be able to tell what is going on by looking at the code locally (i.e., the code is "explicit").
> I think Linus's complain was before there was a c++ standard.
These emails [0]? IIRC those are the most well-known ones and they are from the mid-2000s
[0]: https://harmful.cat-v.org/software/c++/linus
An empty loop, under some non-obvious conditions, on some compiler flags but not others, silently transforms into a system call. In a systems programming language.
I try to minimize use of destructors for the same reason.
Destructors run predictably at list, and are pervasive everywhere. You know that when you exit a scope, be that a function or whatever it may, the destructors of variables in that scope are called. That is clear and consistent. The transformation mentioned above is not.
Understanding the code requires understanding the destructors of the objects you're using. Since they are invisibly inserted, they are a source difficulty in entirely understanding the code.
I do wonder if any of the language servers that insert implied type annotations would ever also show things like destructor calls in a similar manner. It seems like it would be quite useful.
> Since they are invisibly inserted
They're not, all destructors are explicit. Seems like a skill issue on your end.
Since AFAIK I'm still the only person to write a correct C++ (C++98) compiler from preprocessor to object file, I know all about destructors.
Here's a fun one for your amusement:
The parameters are pass by value. a, b and c are objects that have destructors. Have a look at the code generated for that.It is nice that the compiler does the dirty work for you, but the various paths with exceptions and recovery with invisible code may not be well tested.