Fantastic exchange from DConf

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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". :)