Comment by lelele
1 day ago
> y'know you can check if an operator has been overloaded
And there lies the problem with C++: to be sure, you have to check. C++ code can't be taken at face value -- the most innocuous-looking code could be a ticking bomb.
Just like any C function without looking into the translation unit, don't say you blindly believe on the function name.
Not really. C++ is on another level altogether: the code could be calling implicit conversion operators, the compiler could have instantiated some template code in an unforeseen way, and so on.
Years ago, I was really proficient in C++, but after a year of programming in C#, I realized that not once had the behavior of my code caught me off guard. In the following years, I only ran into quirky behavior a couple of times. I could finally program without the constant mental overhead of watching out for C++ pitfalls.
I suppose you're aware C# also has implicit conversion operators, operator overloading, reflection, aspect oriented programming, compiler plugins, interceptors.
Seems strange to talk down C++ while praising C#, which incidentally has been getting features to increase its use where Microsoft previously might have used C++ instead.
You catch pitfalls in any language the same way, using static analysis, which C authors introduced right in 1979, acknowledging the issues with language, which they decided to outsource to another tool, instead of improving the language.
A long tradition in computing.
4 replies →
My favorite was the regex engine that was implemented using C++ operator overloading. The author was very proud of it, but you could not tell what code was regex code and what code was math code.
I went to some lengths with D to discourage such abusive operating overloading practice.
Thank you. I don't even use D, but appreciate all efforts to socialize sane programming practices.
Thank you for the kind words! I recently did a presentation at Yale where I felt free to ridicule some insane practices, and how to do a better job.
Slides:
https://walterbright.com/ElegantD.pdf
But isn't this a problem with all code? Looking at a Rust function signature how can you be sure that it does what it says it does? Or python?
To the extent that one doesn't try to suppress compiler warnings & errors / actively break the language, you get what the compiler confirms is true about a function signature.
For Python, it's very little (nothing?). For Rust, you get more than most; lifetimes tell you whether it holds onto a pointer you give it.
See my reply to a similar objection: https://news.ycombinator.com/item?id=48520416
> C++ code can't be taken at face value -- the most innocuous-looking code could be a ticking bomb.
You can't take C code at face value either. The name of a method or type doesn't tell you what it does. It could longjmp for all you know.
See my reply to a similar objection: https://news.ycombinator.com/item?id=48520416