You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
best practices: enabling warnings ... in practice: External dependencies, controlling warnings for each TU with build systems, what about external header only libraries? What about c-libaries? Or worse: header only c-libaries?
A lot of code out there is compiled with -Wall -Wextra, but most of it not with -Wconversion and -Wsign-conversion (just for example) which are important. If you enable these, you will likely be met with a flood of warnings. Just trying to address the ones in your own code is a somewhat laborious task, but it is made harder by the ones from included dependencies, to the point where you can't see the wood for the trees.
Ideally: Solutions for "firewalling off / compartmentalising" warnings from external dependencies in each of the above cases. Compiler switches to "ignore certain headers or apply lesser warnings", do they exist?
What about taming warnings from clang-tidy/clangd in these scenarios, so that not only is your actual compile clean, but also your IDE is happy.
Seems like an important topic if the eco-system is going to make progress towards higher adherence to best practices overall?
Even if your own project is greenfield, and you start with lots of warnings enabled, the chance that all the dependencies you choose will also have them enabled is near nil?
Length
could be done in < 10mins I think, but it depends on how far you want to take it.
The text was updated successfully, but these errors were encountered:
Channel
"C++Weekly"
Topics
best practices: enabling warnings ... in practice: External dependencies, controlling warnings for each TU with build systems, what about external header only libraries? What about c-libaries? Or worse: header only c-libaries?
A lot of code out there is compiled with -Wall -Wextra, but most of it not with -Wconversion and -Wsign-conversion (just for example) which are important. If you enable these, you will likely be met with a flood of warnings. Just trying to address the ones in your own code is a somewhat laborious task, but it is made harder by the ones from included dependencies, to the point where you can't see the wood for the trees.
Ideally: Solutions for "firewalling off / compartmentalising" warnings from external dependencies in each of the above cases. Compiler switches to "ignore certain headers or apply lesser warnings", do they exist?
What about taming warnings from clang-tidy/clangd in these scenarios, so that not only is your actual compile clean, but also your IDE is happy.
Seems like an important topic if the eco-system is going to make progress towards higher adherence to best practices overall?
Even if your own project is greenfield, and you start with lots of warnings enabled, the chance that all the dependencies you choose will also have them enabled is near nil?
Length
could be done in < 10mins I think, but it depends on how far you want to take it.
The text was updated successfully, but these errors were encountered: