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.
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.
I know, that’s why it bothered me that it seemed to be “policy” to just ignore them.
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.
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.
Yeah, I’ve seen that too. The problem is that once the library starts spitting out warnings it’s hard to spot your own warnings.
Yuuup. Makes me wonder if there’s a viable “diaper pattern” for this kind of thing. I’m sure someone has solved that, just not with the usual old-school packaging tools (e.g. automake).
A production code should never have any warning left. This is a simple rule that will save a lot of headaches.
My team uses the -Werror flag, so our code won’t compile if there are any warnings at all.
Ignoring warnings is really not a good way to deal with it. If a compiler is bitching about something there is a reason to.
A lot of times the devs are too overworked or a little underloaded in the supply of fucks to give, so they ignore them.
In some really high quality codebases, they turn on “treat warnings as errors” to ensure better code.
I know that should be the philosophy, but is it? In my experience it seems to be normal to ignore warnings.