I don’t think that casting a range of bits as some other arbitrary type “is a bug nobody sees coming”.
C++ compilers also warn you that this is likely an issue and will fail to compile if configured to do so. But it will let you do it if you really want to.
That’s why I love C++
“C++ compilers also warn you…”
Ok, quick question here for people who work in C++ with other people (not personal projects). How many warnings does the code produce when it’s compiled?
I’ve written a little bit of C++ decades ago, and since then I’ve worked alongside devs who worked on C++ projects. I’ve never seen a codebase that didn’t produce hundreds if not thousands of lines of warnings when compiling.
A production code should never have any warning left. This is a simple rule that will save a lot of headaches.
I put -Werror at the end of my makefile cflags so it actually treats warnings as errors now.
0 in our case, but we are pretty strict. Same at the first place I worked too. Big tech companies.
I mostly see warnings when compiling source code of other projects. If you get a warning as a dev, it’s your responsibility to deal with it. But also your risk, if you don’t. I made it a habit to fix every warning in my own projects. For prototyping I might ignore them temporarily. Some types of warnings are unavoidable sometimes.
If you want to make yourself not ignore warnings, you can compile with
-Werrorif using GCC/G++ to make the compiler a pedantic asshole that doesn’t compile until you fix every fucking warning. Not advisable for drafting code, but definitely if you want to ship it.You shouldn’t have any warnings. They can be totally benign, but when you get used to seeing warnings, you will not see the one that does matter.
Ideally? Zero. I’m sure some teams require “warnings as errors” as a compiler setting for all work to pass muster.
In reality, there’s going to be odd corner-cases where some non-type-safe stuff is needed, which will make your compiler unhappy. I’ve seen this a bunch in 3rd party library headers, sadly. So it ultimately doesn’t matter how good my code is.
There’s also a shedload of legacy things going on a lot of the time, like having to just let all warnings through because of the handful of places that will never be warning free. IMO its a way better practice to turn a warning off for a specific line.. Sad thing is, it’s newer than C++ itself and is implementation dependent, so it probably doesn’t get used as much.
Depends on the age of the codebase, the age of the compiler and the culture of the team.
I’ve arrived into a team with 1000+ warnings, no const correctness (code had been ported from a C codebase) and nothing but C style casts. Within 6 months, we had it all cleaned up but my least favourite memory from that time was “I’ll just make this const correct; ah, right, and then this; and now I have to do this” etc etc. A right pain.
So, did you get it down to 0 warnings and manage to keep it there? Or did it eventually start creeping up again?
Once we were at zero warnings, we enabled warnings as errors, despite the protestation of the grognards on the team.