I feel like Werror is in conflict with having a pedantically high set of warnings enabled. I'd rather have the strict warnings not stop me from working on code while i figure out the best way to deal with it. Take promotion and conversion warnings. If those are made herd errors, it becomes way too tempting to silence them with a cast instead of thinking through why they are showing up and what needs to be done about it. I'd rather turn off the warnings at that point as I can reenable them to see where concerning parts of my code are at any time. The moment the cast is there, it becomes way more painful to find them again. I do strive for zero warnings in my code, and I have selectively made particular warnings errors where I feel there is zero excuse for it.
Does anyone have a reason why it still is a warning, along with the "not all paths return a value" in non void functions generating invalid code? If one wants to produce such a construct, explicitly enable these in the command line, do it in assembly or use compiler specific attributes or something like that. Warnings about relevant UB that unexpectedly optimizes stuff away might also be appreciated.
I wonder why that hasn't been an error all along. Is there any legit reason on some niche architecture why anyone would want to return a reference to a temporary?
I guess the reason is that it allows simple implementations without dataflow analysis capabilities to be written. Determining if a program will/might return a reference to a temporary requires such analysis.
-Werror is a great idea in theory but when doing cross-platform development it becomes quite tedious to satisfy multiple compilers’ whims about what to issue warnings on.
Excellent idea to have this be an error. And I still don't like "-Werror". I've seen cases where my compiler had "this is potentially confusing" warnings on stuff that was perfectly legal and well-defined. But I couldn't build that code because (I think) there is no way to tell CMake not to use "-Werror".
Depending how `-Werror` is added to the compiler command line in the CMake project it can be disabled. If the project uses the CMAKE_COMPILE_WARNING_AS_ERROR (or sets the COMPILE_WARNING_AS_ERROR on individual targets), then it can be temporarily disabled by using `cmake --compile-no-warning-as-error` when configuring the project. If someone hardcoded `-Werror` in a toolchain file or a `compile_options` call then you're indeed out of luck. But that is not a problem with `-Werror` per se, but rather the problem that some developers force their preferred settings onto consumers.
If its not an error, just annotate the code to ignore the warning. I use this all the time with -Wall -Werror -Wno-unknown-warning-option -Wno- #pragma gcc diagnostics push #pragma gcc diagnostics ignored "-Wsome-error" ...code the triggered the false positive... #pragma gcc diagnostics pop This has the added benefit that during code traces its both an aknowledgement that the error has been consider, and a code smell if there happens to be an observed bug that appears related to the code in case the compilers warning was actually correct. If its 3rd party code, then make sure that its set to ignore errors in 3rd party headers, eg -Wno-system-headers and make sure system headers are properly defined and included using angled brackets.
@@DaphnePfister That's such a headache if it's a code that I download. If a new version comes out I want my install script to work just the same. So I actually have install scripts that run an inline "sed" to patch the code before or after installation.
I agree with Werror= for specific warnings that are egregious and must be addressed, but the blanket Werror for all warnings enabled is opening a project up to build errors resulting from pedantic warnings that didn't exist at the time of writing.
This. Moving to a new major compiler version usually means I have to patch out Werror from any libs that have it, because there is a new warning, and the old code obviously didn't yet fix the warning just introduced by the new compiler. So my approach: don't make Werror the default in your CMake build, but enable it in your dev environments and CI, for your own code only.
Werror is definitely annoying when you are writing new code. You can disable --Werror for development, and just use it in CI (to block merging), release builds or on demand.
So you upgrade your compiler. Your compiler finds new issues with your code. And your reaction is to complain about that rather than fixing those issues?
@mina86 I said pedantic warnings. For example, my coding style often avoids using the default case in a switch on purpose, instead letting all non-matching values be handled by code after the switch case (this makes more sense when using early returns rather than breaks). However, one day Wswitch-enum cropped up and started emitting warnings for my common and well-handled coding style. Should my builds have stopped building because the compiler had an opinion about my valid coding style? No. Pedantic warnings should not be errors.
Is it possible to enable -Werror for a specific type of warning? I think most people who are reluctant to use -Werror do so because of a few warning types that are outside of their control and would ruin the whole compilation if -Werror was enabled. In other words, 99% of warnings can be treated as errors and fixed but because of 1% of warnings that are known not be real bugs but for some reason cannot be fixed all the warnings are ignored. If there is a way to enable Werror for the 99% of the warning types and let the other 1% still be warnings this would help weed out the unnecessary warnings. Of course, 99% and 1% are arbitrary numbers that I chose. Maybe in real life it's more like 90/10 or 80/20 or something like that.
Not sure, but also: Not necessary. What you do instead is, you enable warning-as-error in general, and then (in those places where the warning is a false positive) you use pragma to disable the warning.
My only problem with Werror is it slows me down too much when I'm trying to quickly get the skeleton of my idea onto the screen. I would definitely use it for production code.
Looking at this from a different angle, most large-scale project will never switch to modern C++ versions, because fixing all of those warnings will be considered too expensive/unnecessary.
This is a step in the right direction, but still not enough: you can still disable the error via -Wno-. Which people who don't use -Werror will do. Compiler developers get a huge pushback on any type of hard error that cannot be disabled due to backwards compatibility.
Returning a reference to a temporary is not "bad practice", it's a bug.
I love -Werror, except in that 20 year old code base with 35,000 warnings.
Yeah that's what happens after procrastinating for 20 years. An expensive piper to pay.
I feel like Werror is in conflict with having a pedantically high set of warnings enabled. I'd rather have the strict warnings not stop me from working on code while i figure out the best way to deal with it.
Take promotion and conversion warnings. If those are made herd errors, it becomes way too tempting to silence them with a cast instead of thinking through why they are showing up and what needs to be done about it. I'd rather turn off the warnings at that point as I can reenable them to see where concerning parts of my code are at any time. The moment the cast is there, it becomes way more painful to find them again.
I do strive for zero warnings in my code, and I have selectively made particular warnings errors where I feel there is zero excuse for it.
Should be an error even in c++98 imo.
Along with "control reaches end of non-void function"
I wonder how many codebases still use -std=c++98 even on modern compilers
Does anyone have a reason why it still is a warning, along with the "not all paths return a value" in non void functions generating invalid code? If one wants to produce such a construct, explicitly enable these in the command line, do it in assembly or use compiler specific attributes or something like that.
Warnings about relevant UB that unexpectedly optimizes stuff away might also be appreciated.
I wonder why that hasn't been an error all along. Is there any legit reason on some niche architecture why anyone would want to return a reference to a temporary?
To preserve backwards compatibility to the point where it hindersnthe progress of the language... I guess?
I guess the reason is that it allows simple implementations without dataflow analysis capabilities to be written. Determining if a program will/might return a reference to a temporary requires such analysis.
I put -Werror for no return in a returning function, will do it for this too.
-Werror is a great idea in theory but when doing cross-platform development it becomes quite tedious to satisfy multiple compilers’ whims about what to issue warnings on.
And that's why you can specify specific warnings which should be treated as errors (or the other way around).
@ Just try to get those warnings into a cmake setup from some package you've downloaded and which should "just" install.
Excellent idea to have this be an error. And I still don't like "-Werror". I've seen cases where my compiler had "this is potentially confusing" warnings on stuff that was perfectly legal and well-defined. But I couldn't build that code because (I think) there is no way to tell CMake not to use "-Werror".
Depending how `-Werror` is added to the compiler command line in the CMake project it can be disabled. If the project uses the CMAKE_COMPILE_WARNING_AS_ERROR (or sets the COMPILE_WARNING_AS_ERROR on individual targets), then it can be temporarily disabled by using `cmake --compile-no-warning-as-error` when configuring the project. If someone hardcoded `-Werror` in a toolchain file or a `compile_options` call then you're indeed out of luck. But that is not a problem with `-Werror` per se, but rather the problem that some developers force their preferred settings onto consumers.
If its not an error, just annotate the code to ignore the warning. I use this all the time with -Wall -Werror -Wno-unknown-warning-option -Wno-
#pragma gcc diagnostics push
#pragma gcc diagnostics ignored "-Wsome-error"
...code the triggered the false positive...
#pragma gcc diagnostics pop
This has the added benefit that during code traces its both an aknowledgement that the error has been consider, and a code smell if there happens to be an observed bug that appears related to the code in case the compilers warning was actually correct.
If its 3rd party code, then make sure that its set to ignore errors in 3rd party headers, eg -Wno-system-headers and make sure system headers are properly defined and included using angled brackets.
@@DaphnePfister That's such a headache if it's a code that I download. If a new version comes out I want my install script to work just the same. So I actually have install scripts that run an inline "sed" to patch the code before or after installation.
@@manuelbergler6884 Oh absolutely. I blame those developers. I'll remember that commandline option for next time. Thanks.
I'm going to be honest, but Im going to be very blunt... CMake is garbage.
Will you join the upcoming event in Haggenberg, Austria this week?
I agree with Werror= for specific warnings that are egregious and must be addressed, but the blanket Werror for all warnings enabled is opening a project up to build errors resulting from pedantic warnings that didn't exist at the time of writing.
This. Moving to a new major compiler version usually means I have to patch out Werror from any libs that have it, because there is a new warning, and the old code obviously didn't yet fix the warning just introduced by the new compiler. So my approach: don't make Werror the default in your CMake build, but enable it in your dev environments and CI, for your own code only.
That's the same point I was making in my toplevel comment. Thank you.
Werror is definitely annoying when you are writing new code.
You can disable --Werror for development, and just use it in CI (to block merging), release builds or on demand.
So you upgrade your compiler. Your compiler finds new issues with your code. And your reaction is to complain about that rather than fixing those issues?
@mina86 I said pedantic warnings. For example, my coding style often avoids using the default case in a switch on purpose, instead letting all non-matching values be handled by code after the switch case (this makes more sense when using early returns rather than breaks). However, one day Wswitch-enum cropped up and started emitting warnings for my common and well-handled coding style. Should my builds have stopped building because the compiler had an opinion about my valid coding style? No. Pedantic warnings should not be errors.
Is it possible to enable -Werror for a specific type of warning?
I think most people who are reluctant to use -Werror do so because of a few warning types that are outside of their control and would ruin the whole compilation if -Werror was enabled. In other words, 99% of warnings can be treated as errors and fixed but because of 1% of warnings that are known not be real bugs but for some reason cannot be fixed all the warnings are ignored. If there is a way to enable Werror for the 99% of the warning types and let the other 1% still be warnings this would help weed out the unnecessary warnings. Of course, 99% and 1% are arbitrary numbers that I chose. Maybe in real life it's more like 90/10 or 80/20 or something like that.
Not sure, but also: Not necessary. What you do instead is, you enable warning-as-error in general, and then (in those places where the warning is a false positive) you use pragma to disable the warning.
My only problem with Werror is it slows me down too much when I'm trying to quickly get the skeleton of my idea onto the screen. I would definitely use it for production code.
Don't you just start writing the correct thing the first time after a while. Sorta like any other kind of compilation error
notice how this formatting style hides the fact it’s a reference being returned ;) (i.e. compare with “const int& get…” )
You mean, compared to:
auto get() -> const int &
:)
@ or the one we actually see on the screen xD
Looking at this from a different angle, most large-scale project will never switch to modern C++ versions, because fixing all of those warnings will be considered too expensive/unnecessary.
This is a step in the right direction, but still not enough: you can still disable the error via -Wno-. Which people who don't use -Werror will do.
Compiler developers get a huge pushback on any type of hard error that cannot be disabled due to backwards compatibility.
But how else will I impement my random number generator function that uses garbage on the stack for entropy? /s
@@Minty_Meeo Typically this is done with -f flags, like -fwrapv. Having this as an error that behaves like a warning is confusing :/
Do we really need that much hand holding? The whole "make it safe" fanaticism is becoming tiresome.
@ What is wrong with something you should absolutely never under any circumstances do being turned into an error?
After a year of Rust, I hope I never have to use C or C++ ever again.
So why are you still here? Don't let the door hit ya'.
Why would anyone return a reference to a temporary anyway? It makes no sense.
I wonder about returning references to local variables. That, I think, is just as bad.