On 05/09/2017 08:30 PM, H. S. Teoh via Digitalmars-d wrote:
In this sense I agree with Walter that warnings are basically useless, because they're not enforced. Either something is correct and compiles, or it should be an error that stops compilation. Anything else, and you start having people ignore warnings.
Not 100% useless. I'd much rather risk a warning getting ignored that NOT be informed of something the compiler noticed but decided "Nah, some people ignore warnings so I'll just look the other way and keep my mouth shut". (Hogan's Compiler Heroes: "I see NUH-TING!!")
And then the flip side is that some code smells are just to pedantic to justify breaking the build while the programmer is in the middle of some debugging or refactoring or some such.
That puts me strongly in the philosophy of "Code containing warnings: Allowed while compiling, disallowed when committing (with allowances for mitigating circumstances)."
C/C++ doesn't demonstrate that warnings are doomed to be useless and "always" ignored. What it demonstrates is that warnings are NOT an appropriate strategy for fixing language problems.
As for avoiding de-facto-deprecated functions, I've already said it: *everybody* knows strcat is bad, and strcpy is bad, and so on and so forth. So how come I still see new C code being written almost every day that continues to use these functions? It's not that the coders refuse to cooperate... I've seen a lot of code in my project where people meticulously use strncpy instead of strcat / strcpy -- I presume out of the awareness that they are "bad". But when push comes to shove and there's a looming deadline, all scruples are thrown to the winds and people just take the path of least resistance. The mere fact that strcat and strcpy exist means that somebody, sometime, will use them, and usually to disastrous consequences.
The moral of this story: Sometimes, breaking people's code is GOOD! ;)
And *that's* the fundamental problem with C (and in the same principle, C++): the correct way to write code is also a very onerous, fragile, error-prone, and verbose way of writing code. The "obvious" and "easy" way to write C code is almost always the wrong way. The incentives are all wrong, and so there's a big temptation for people to cut corners and take the easy way out.
Damn straight :)
(Nevermind the elephant in the room that 80-90% of the "optimizations" C/C++ coders -- including myself -- have programmed into their finger reflexes are actually irrelevant at best, because either compilers already do those optimizations for you, or the hot spot simply isn't where we'd like to believe it is; or outright de-optimizing at worst, because we've successfully defeated the compiler's optimizer by writing inscrutable code.)
C++'s fundamental paradigm has always been "Premature-optimization oriented programming". C++ promotes POOP.
That's another fundamental problem with the C/C++ world: coding by convention. We all know all too well that *if* we'd only abide by such-and-such coding guidelines and recommendations, our code would actually stand a chance of being correct, safe, non-leaking, etc..
Luckily, there IS a way to enforce that proper coding conventions are actually adhered to: It's called "compile-time error". :)
