Hacker News Reader

Comment by IshKebab | Hacker News Reader

> Please don't argue about "but I don't need to add a flag in Rust"

Why not? It's a big issue. You say it's "on in any codebase where anyone cares", and I agree with that but in my experience most C++ developers don't care.

I regularly have to work with other people's C++ where they don't have -Wall -Werror. It's never an issue in Rust.

Also I don't buy that they couldn't fix this because it would be a breaking change. That's just an excuse for not bothering. They've made backwards incompatible changes in the past, e.g. removing checked exceptions, changing `auto`, changing the behaviour around operator==. They can just use the standard version, just like Rust uses Editions.

Of course they won't, because the C++ standards committee is still very much "we don't need seatbelts, just drive well like me".

View on HN

> I regularly have to work with other people's C++ where they don't have -Wall -Werror.

To be fair, -Werror is kind of terrible. The set of warnings is very sensitive to the compiler version, so as soon as people work on the project with more than one compiler or even more than one version of the same compiler, it just becomes really impractical.

An acceptable compromise can be that -Werror is enabled in CI, but it really shouldn't be the default at least in open-source projects.

A common trope that is probably ignored or even unknown to uninformed C/C++ programmers, is that -Werr should be used for debug builds (as you use during development) and never for release builds (as otherwise it will most probably break compilation in future releases of the compiler)

> A common trope that is probably ignored or even unknown to uninformed C/C++ programmers, is that -Werr (...)

Not even that. -Wall -Werror should be limited to local builds, and should never touch any build config that is invoked by any pipeline.

No you definitely want to enforce this in CI.

> No you definitely want to enforce this in CI.

No, not really. It makes absolutely no sense to block builds for irrelevant things as passing unused arguments to a function.

-Werror= and you can error on decide which warnings are errors. No reason to enable it globally

> irrelevant things as passing unused arguments to a function.

That's not irrelevant. I have seen many bugs detected by that warning.

Yes that is the standard practice for open source projects (where it happens at all), but again that's another way in which C++ warnings are not even close to Rust errors.

> I regularly have to work with other people's C++ where they don't have -Wall -Werror.

I think you inadvertently showed why this sort of thing: it's simply bad practice and a notorious source of problems. With -Wall -Werror you can turn any optional nit remark into a blocked pipeline requiring urgent maintenance. I know it because I had to work long hours in a C++ project that suddenly failed to build because a moron upstream passed -Wall -Werror as transitive build flags. We're talking about production pipelines being blocked due to things like function arguments being declared but not used.

Sometimes I wonder if these discussions on the virtues of blindly leaning on the compiler are based on solid ground or are instead opinionated junior devs passing off their skinner box as some kind of operational excellence.

Wall Werror is a nice idea that university professors will tell you about that collides at first contact with the real world where you are including 3rdparty headers that then spit 50 pages of incomprehensible GCC "overflow analysis" warnings.

You can use `-Isystem` for that. It isn't particularly well supported by C++ build systems, but also your assertion that third party headers don't compile with `-Wall -Werror` doesn't match my experience. Usually they're fine.

> GCC "overflow analysis" warnings

I think I've seen this with `fmt`, and it was a GCC compiler bug. Not much you can do about that.

Reply on news.ycombinator.com