C++ Weekly - Ep 350 - The Right Way to Write C++ Code in 2022
Vložit
- čas přidán 13. 11. 2022
- ☟☟ Awesome T-Shirts! Sponsors! Books! ☟☟
Upcoming Workshop: Understanding Object Lifetime, C++ On Sea, July 2, 2024
► cpponsea.uk/2024/sessions/und...
Upcoming Workshop: C++ Best Practices, NDC TechTown, Sept 9-10, 2024
► ndctechtown.com/workshops/c-b...
Notes for this episode: github.com/lefticus/cpp_weekl...
Ep 347 - This PlayStation Jailbreak NEVER SHOULD HAVE HAPPENED - • C++ Weekly - Ep 347 - ...
T-SHIRTS AVAILABLE!
► The best C++ T-Shirts anywhere! my-store-d16a2f.creator-sprin...
WANT MORE JASON?
► My Training Classes: emptycrate.com/training.html
► Follow me on twitter: / lefticus
SUPPORT THE CHANNEL
► Patreon: / lefticus
► Github Sponsors: github.com/sponsors/lefticus
► Paypal Donation: www.paypal.com/donate/?hosted...
GET INVOLVED
► Video Idea List: github.com/lefticus/cpp_weekl...
JASON'S BOOKS
► C++23 Best Practices
Leanpub Ebook: leanpub.com/cpp23_best_practi...
► C++ Best Practices
Amazon Paperback: amzn.to/3wpAU3Z
Leanpub Ebook: leanpub.com/cppbestpractices
JASON'S PUZZLE BOOKS
► Object Lifetime Puzzlers Book 1
Amazon Paperback: amzn.to/3g6Ervj
Leanpub Ebook: leanpub.com/objectlifetimepuz...
► Object Lifetime Puzzlers Book 2
Amazon Paperback: amzn.to/3whdUDU
Leanpub Ebook: leanpub.com/objectlifetimepuz...
► Object Lifetime Puzzlers Book 3
Leanpub Ebook: leanpub.com/objectlifetimepuz...
► Copy and Reference Puzzlers Book 1
Amazon Paperback: amzn.to/3g7ZVb9
Leanpub Ebook: leanpub.com/copyandreferencep...
► Copy and Reference Puzzlers Book 2
Amazon Paperback: amzn.to/3X1LOIx
Leanpub Ebook: leanpub.com/copyandreferencep...
► Copy and Reference Puzzlers Book 3
Leanpub Ebook: leanpub.com/copyandreferencep...
► OpCode Puzzlers Book 1
Amazon Paperback: amzn.to/3KCNJg6
Leanpub Ebook: leanpub.com/opcodepuzzlers_book1
RECOMMENDED BOOKS
► Bjarne Stroustrup's A Tour of C++ (now with C++20/23!): amzn.to/3X4Wypr
AWESOME PROJECTS
► The C++ Starter Project - Gets you started with Best Practices Quickly - github.com/cpp-best-practices...
► C++ Best Practices Forkable Coding Standards - github.com/cpp-best-practices...
O'Reilly VIDEOS
► Inheritance and Polymorphism in C++ - www.oreilly.com/library/view/...
► Learning C++ Best Practices - www.oreilly.com/library/view/... - Věda a technologie
I'm the maintainer of GCC's -fanalyzer option. Thanks for the shout out in the static analysis section, but please note that it's still really only for C at this time. I'm hoping to address C++ support in GCC 14, but you're unlikely to get useful results running it on C++ code at the moment (and lots of false positives, on the constructs that it doesn't fully grok yet).
Thank you for the work you've done so far!
GCC is a virus
Thank you so much for your videos.
As i just start with C++ a lot goes above my head... but still i learn and get a better view on things.
Big thanks!
What about auto formatters? I find having a way to easily conform to a specific style very helpful, so you don't have to constantly remove white space, handle lines > 100,120 chars, etc.
Ooops! Did I leave those out? Totally should have mentioned clang-format.
Formatters suck. I want to use the eiffel notation of
class Name {
public: //--- Feature section
public: //--- Feature section
private: // Implementation
};
@@llothar68 ReSharper.
For libraries that are not doing I/O and not specific to a narrow context (so for most C++ libraries) I like to add Emscripten as toolchain (you said compiler here but it's really toolchain) to build for, as there is no reason a C++ library not doing I/O (which have to be handled differently on WebAssembly) and being "generic" would fail to build and be usable on WebAssembly.
To everyone complaining about -Werror + third-party libraries -> you need to include them as "system headers". Compilers will ignore all warnings coming out from them.
Unfortunately this doesn't work with macros if they're defined in the header, but meant to be used in your own code. As an example, I have enabled the warning for C style casts and used GTK, but one of the macros (G_OBJECT) uses a C style cast in its expansion. I had to disable this warning for all the files dealing with GTK.
@@michaelmahn4373 Yes, this is a tricky edge case. In that case one might need to create a thin wrapper of the problematic code, and suppress the warning via pragmas. I added support to Clang to be able to selectively disable warnings in system macros for each particular warning. More specifically, the C-style cast warning is disabled in system macros in Clang.
In "vi" with hand-written Makefiles like a real man. 🤣😉
Predictably lots of hate for -Werror. I don't use it, but I also treat warnings as problems I need to fix and my goal is 0 warnings. I have -Werror enabled in my mind. I don't push anything beyond a personal WIP branch if it has any warnings. If CI shows warnings, they need to be fixed asap (but an actual broken build or urgent bug or major test failure would be higher priority.) Fixing little problems uncovered by compiler or linter warnings are always easier to do as you write the code rather than putting them off for later.
Maybe a more pragmatic recommendation could be "Try using -Werror; if it becomes a problem at some point, consider workarounds like `#pragma warning disable` wrappers around 3rd party headers, but if that's going to be more trouble than it's worth, maybe you can remove -Werror but don't ignore warnings in your own code." )
Use -Werror for CI. Don't accept merge requests which produce warnings (or fail CI in some other way). But if you're working on an open source project, do *not* use -Werror in the default build configuration. I'm probably running a more modern compiler than you are. If you use -Werror together with, say, -Wextra, my compiler is gonna warn on stuff which your compiler doesn't. Don't force me to hunt down your -Werror option deep inside of your build system configuration to remove it.
Memory sanitizer on Windows: Application Verifier - it enables the debug heap features (which you can also enable programmatically, but App Verifier is a much more convenient way).
damn, I thought I was fancy with getting the hang of writing makefiles. It turns out I have a very long way to go
I was waiting for stuff like smart pointers, concepts and TDD/BDD. This is more about the building process than about writing code. I don't see the recommendations in the video that are actually about writing the code: what to type in the header and source files, in what order, how to organize the files, etc.
Clazy is a very useful static analysis tool for Qt based projects.
Need to mention crazy reports things others miss
Thank you for mentioning DrMemory, I also feel that almost nobody knows about it. I found & fixed many bugs thanks to it. I would also add Application Verifier dynamic analysis tool on Windows to the list.
I mention Application Verifier to students, but I've never used it personally.
Also mentioning `project_options` for CMake that automatically sets up many of these tools in a cross-platform way.
I'm in the middle of adopting Drone and using HashiCorp vault for managing secrets. It's a lot easier to set up than Jenkins and one benefit is the ability to run it locally, which I plan to pair with git hooks to catch the obvious stuff locally before pushing changes.
Jenkins totally suck. A simple job runner like Jenkins shouldn't be specialized like it. Its a total wrong design and unfixable. Written my own CI job runner in a few thousand lines of ruby. As no other works well when providing a run node on an Android/iOS design (also had to write the whole test runner as there is no useful C++ test runner in the Android world that supports C++ assert crashs).
@@llothar68 I ran into issues with Drone and wasn't able to use the local execution features, and support was silent for months, so I've also resorted to writing my own CI solution which is basically just a configuration tool and a docker / python script runner...
I was facing problems with secret management and signing of releases. I was going to roll my own solution but when I searched for if a product already did it I found Vault as well. Only in the last 3 weeks.
I think to setup all these stuff will take quite some time. Unfortunately, personally I have never setup these. But the effort really worth it, because at some point you'll gain the benefits from it, although initially you might think that you're spending too much time on the preparation.
I'm using a self hosted Woodpecker (Fork of Drone) for CI/CD
For continuous build/integration (CI) …. Better yet something at its core that does continuous deployment (CD) - concourse and GoCD are both full CI/CD. They are very flexible and capable.
CppDepend is another nice and comprehensive static analysis tool.
I have to say that for the last two or three years using both clang and GCC has brought fewer and fewer benefits but still occasional trouble with compiler errors that one has and the other doesn't. It used to be different, but they converged a lot.
One thing that wasn't mentioned: use valgrind's cachegrind (and callgrind if so inclined) to do performance testing. Very few people guard themselves against performance regressions, even though these can be serious problems. Cachegrind's iref count is a very good means to keep accidental performance regressions from happening. (I stole this idea from SQLite, it's very helpful.)
I often use cachegrind for that purpose. I've intended to make videos about it, but don't think I ever did... you can add requests here: github.com/lefticus/cpp_weekly/issues
Would love to hear about good coverage tools. Have tried a bit with gcov but it's a bit tricky to use with CMake, for example.
Great idea, please make sure to put a request in the list: github.com/lefticus/cpp_weekly/issues
thank you for video
You are welcome
I'm actually 6 months into writing a template exactly for this purpose.
It's a github template, on download you run a simple script the first time you use it (if you use it again for a different project, no need to run the script again)
It does a lot of setup for you
- build env
- using multiple compilers
- static anaylsis (clang-tidy)
- formatting (clang-format)
- unit tests (catch2)
The goal is to habe a quick setup for a C++ project with all tools already in place, you just have to write the code, the rest gets done for you and you can customise it in any way you want.
I'm writing my own standard library as well so you don't use different stl implementations across compilers, this is of course optional to the user
In my opinion, codebases are becoming very complex, making it harder to write clean, performant and safe code, so I was setting up a toolchain to set up tools that would make my life easier, I then started abstracting that and making it a github template so other people could benefit from it as well
IMO it's kinda a cpp specific problem, because that setup is actually quite hard. Jason lists like 10 steps here, and you are talking about 6 months of writing of the template. C# or Rust are much more streamlined in that regard.
@@GonziHere true, it could be easier, the 6 months is mainly the standard library because they vary per compiler.
The actual template I've only been developing for a month, but it's true it's more work than it should be, but I made my peace with that when it comes to C++, it's a complex language and so is the setup
Jason has a template started project with many of these things set up already on his github
@@kippers12isOG I know about Jason's template, but that uses CMAKE, which from my experience, doesn't scale well for bigger projects. (when you want to change something)
I use Sharpmake instead, which is C#, easier to debug (and imo also easier to use). I've used it for bigger projects and it was a lot friendlier towards the user.
I do use Jason's template as a reference, but I try to extend it where I can as well
TeamCity for CI and ut for unit testing
I didn't get any of that. I was so distracted by that update notification in the lower left corner of the screen. Why won't you click it?
Was interesting to see that every time you said something would annoy me it didnt and vice versa 😂
i find gtest kinda amazing among the organized test framework
Are good old gcov and CUnit omitted from this list as they are more C oriented or because they are in any way "outperformed" (in any meaning of the word) by the other tools mentioned?
Either could have been mentioned really, but I focused on the tools that I am familiar with and consider to be best-in-class.
I am shocked that package managers are not mentioned here. Conan, Vcpkg etc. is must have if using external libraries.
Or CMake's FetchContent, even
Fair comments. I was trying to focus on the code quality analysis itself, specifically.
-Wconversion would have saved me quite a bit of debugging recently.
You missed static_assert() (compile time) and assert() (run time, debug only)
I'm a little spoiled where I work. Pretty much all of this is set up for free for me.
I’d love to do all of these but there’s like months of learning required for each of these tools which could have been spent on actual C++ development. It’s also getting harder to keep up with the latest C++ features whilst simultaneously learning how to use CMake, CI/CD, testing frameworks, etc. If only C++ would simplify all of these tasks so that I could catch up on concepts, concurrency, maybe learn to offload some processing to GPUs.
It doesn't need months, but even if it did, learning is a long term process. You don't become fluent in C++ (and possibly any other language) before a few years, that doesn't mean that you can't do actual development while you're still learning and improve your skills. Plus, if you do "actual development" -- as in a business environment -- you're required already to have an idea of many of these tools
@@joesilver75 You'll be surprised to hear then that the vast majority of C++ devs aren't in the sort of formal software development industry. A lot of them use C++ with 30 libraries then act like C++ is a scripting language. I was in such environment and all the tools had to be learned in my spare time. There was even a 30 year period in the company I work in before they started using version control systems. They were just copy pasting the "latest" code into renamed folders. Nobody knows what a compiler is or what linking is. All they know is they press play on Visual Studio and the code runs. No CI/CD, no CMake, no GTest or any unit tests in that regard, no dockers no package managers, nothing. What time they didn't spend on the software tools they made up for by being hardware experts. As this company is in the semiconductor industry that makes the chips that go into your mobile gadgets. Like I've said, for people like me, everything has to be learned in their spare time. Time that we don't always have. I have to choose between getting better at generic library development or learning about Jenkins. Not to mention that as time passes by, there are more things to learn about C++ so it's an arms race of self learning.
@@blablabla7796 I'm not surprised because at the moment I actually work in a place, in a project, where there are no unit tests, for example, and no notions of static analysis, let alone openness to modern sensible guidelines (and 'auto' is banned as considered harmful...) About 95% of what I learnt about C++ development I did it in my spare time. I'm a bit in despair, actually, because I loathe having to shut up my concerns in every code review, letting sloppy code enter an already messy code base. But then, what can I say, if you happen to work in such a place, you don't need to learn more than what you strictly need, or more than those who have already stopped learning 2 decades ago... If you want to move somewhere else, there are companies which value the adoption of new technologies, and actually require them.
But my point stands, wherever you are today, professionally and not, is the outcome of a long process of learning and making experiences. You will never learn everything. The good news is that you don't need to. But instead of letting yourself be paralysed thinking about the mountain to climb, you can just start step by step. Honestly, many of the things suggested here are pretty straightforward: enabling warnings in the compiler, running a static analyser, setting up a basic CI, starting to adopt better practices, you don't need months for these, I can assure you.
@@joesilver75 I guess we're sort of in the same boat then. Of course it's impossible to be an expert in everything. But I think at some point we should "delegate" some things to others. I work on silicon, so the amount of time I actually spend on C++ is probably half of what you spend on it. I have written a library for the other engineers in my company to use so that they don't have to manually manage memory for libraries they use, that was written in C++17. I am now working on a new library and I'm trying to catch up to C++20 before C++23 becomes the hot new thing. It may actually take months for me to setup the things you've mentioned because odds are, at the start things won't work out of the box, or that some things might _break._ I think at some point C++ should adopt a few things from Rust to reduce the "concept count" that Herb Sutter mentioned.
I'm just the messenger here. there's lots that could have been changed if we started from scratch today, but here's we are right now.
I would also add: use the latest stable version of your compiler of choice and use the latest version of C++ supported by your compiler. We are stuck with GCC 4.8.5, which was released in 2015, which is painful. Looking forward to using nix, which will improve our ability to incorporate new and newer tools into our development process.
When talking to students, I suggest that the CI keep the compiler they require + add the latest computer. So they can get the advantage of the latest analysis, plus prove they meet the requirements.
If I have a constexpr function, that I only test with static_assert, I do not get any runtime coverage. Should I bother to use both static_assert and EXPECT_EQ (or similar), when testing?
yes, constexpr functions should be tested at both compile time and runtime.
What's the benefit besides guarding against a potential compiler error, euch i don't think it's something unit tests are meant for. (The basic assumption is always that your compiler creates correct objects.)
@@christophclear1438 some functions actually have completely different control paths for compile-time vs run-time, eg by using std::is_constant_evaluated. This could be considered a case of whitebox testing, where you choose to implement both constexpr and runtime tests for functions you know have these control path differences.
SonarQube (dashboard, history, coverage, etc.)...
favourite CB = gitlab
favourite test = catch2
I would have actually listed git / source version control as the first item.
I am sure i missed it, but Coverity is free for open source code and has caught tons of issues for GDAL and its dependencies.
There's just a lot to keep up with! Sorry I missed it.
What about depreciation warnings... And /w4 I need to support windows XP still some time but vs2019 shows me some of the warnings that win xp is soon going to be not supported anymore. Yes I know... It should soon(tm) vanish....
Teamcity...
Lint...
Clang static analysis
What are the opinions on using bazel as the primary make tool?
Whatever works for you! But you might have a harder time finding answers to problems, since it is less commonly used.
I fuzz C++ code with AFL++. I'd like to know how to use it to fuzz Rust and Haskell too.
Test code on Intel or AMD, ARM, and big-endian Power.
Test code on Linux with GNU libc, Linux with musl libc, BSD, and illumos.
When I have enough money, I'm going to buy a Raptor Talos box and load it with Adélie Linux (musl and big-endian) and probably FreeBSD (big-endian).
As I see it, this episode is relevent only for new, starting, projects.
Im working on a legacy. Trying to intraduce a static analysis or a test coverage was a nightmare.
For example:
1. trying to move to c++20 has taking me so much time due to new warnings introduced in the newer version. I had to "Pragrma Disable" allmost all of them. im on `\W4`, it was beyond repair.
2. Doxygen, for static analysis, exploded with "Criticals".
3. UT is not an option on old code, only for new, starting from "now-on". so total coverage is "mission-imposible" by Tom Cruse :).
4. auto-formatting tool will mess up everything. obviously.
Jason, is it realistic to even try to integrate those tools ?
Yes, slowly and one at a time. I have worked with teams on this. You enable *globally* the warnings you can. Fix them, then enable the next one, fix them, enable the next one. Etc.
It takes dedication, but it is worth it. You'll find a LOT of bugs. See talks from Victor Ciura about this as well.
Buildbot for continuous integration
The thumbnail looks corrupted for me on this video
It was semi-intentional. It's a very specific frame from the intro transition.
I got you to click, right? :D
Cppcheck is good but unfortunately version 2.9 has a bug
Why most software sources use autoconf, but not cmake? I do not understand
I see very few projects these days that use autoconf, so it's probably just the package you happen to use.
Opinion. Add a build option with -Werror disabled AND no warnings disabled. Why? So that you can flush out the warnings that have been swept under the carpet. A lot of the guys simply turn off annoying warnings because -Werror is enabled. If you add this build option you can track how things are going.
You must add warning disabling to your code review process. In my experience even *1* warning that's in the build results in developers simply ignoring all warnings. This is why I say it needs to be warnings as errors!
godbolt as fast and easy way to check code and conformance on multiple compiler setups
Hah! My first attempt at adding "/WX" failed the build... because Microsoft's "SimConnect.h" initializes a lot of "DWORD" muck with integers. That said, they should stop using DWORDs; SimConnect is a dinosaur from the previous millennium... Sorry, programming for MSFS or Prepar3D in C++ breaks a lot of good intentions. ;-)
If I ever get -Werror when building a dependency, I lose all respect of you.
Emacs & Make. My "continuous build environment" is cron.
Here's the thing, i want PlayStations and phones to be able to be rooted or jail broken...
I don't know much about Rust, only one thing - safer than C++. So if we use Rust can we skip Static/Runtime analysis tools?
No is the short answer. Clippy is the recommended linter for rust for example. You can still write bugs in Rust , it’s not a magic language, so you will still need to analyse runtime performance etc. but some of the checks and tooling for ub, address sanitizer etc maybe redundant in rust unless you mark code as unsafe.
C++ with static analysis is more safe than just Rust.
@@keshkek I would honestly love to live in a world where this was true.
MS test is actually good, I love it with Visual Studio proper.
I been doing everything all wrong, all this time.
I will NOT watch this video so I don't need to rant about whatever "right" thing I think is... not so right :P Have fun.
-Wconversion is impossible if you're working with APIs that interchangeably use int and unsinged int as size.
Not impossible. You write a couple of helper functions so it's clearly documented what you need to do, and you then have the opportunity to also add in checks for overflow if desired.
And here I was thinking we'd need anaglyph glasses to read the code. So disappointed ;)
I think using -Werror is not a good idea. Because when you update the compiler, you'll probably have a bunch of new warnings you need to fix. And that will be each time you update the compiler.
Even more problems, if you are using header only library or dependency you have to compile with -Werror, you will have a problem: you can't fix the warnings, because the code is not yours.
you know, you can disable warnings for your dependencies and not your code.. (with pragmas around the include)
and when you get new warnings from updating your compiler you should say thank you.. those issues were there before the update and the compiler is helping write better safer code
That’s kind of the point. More warnings going off indicate more potential bugs and Issues. It’s precisely why to use them - Werror just adds incentive to fix them quickly
The reason to update the compiler because you want to generate more performant and safer code and use the latest language constructs (many of which are also aimed at allowing us to write safer code). There's little point updating the compiler if you're going to ignore a lot of the advantages that upgrading it brings you. A new compiler may help you find pre-existing issues in your code that are causing problems for your users, but only if you listen to what its telling you.
The right way to waste your time:
- enable the highest warning level (/W4)
- enable the "Treats all compiler warnings as errors" flag (/WX)
- have fun, because all the third party libraries you use have a lot of warnings in header and hpp files
That's why the files that compile my third-party dependencies all have a line like this:
#pragma warning(disable : 4146 4702 4706 6001 6011 6262 6308 6330 6387 26051 26408 26409 26429 26432 26433 26434 26435 26438 26440 26443 26444 26447 26448 26451 26455 26456 26459 26460 26461 26466 26472 26475 26477 26481 26482 26485 26488 26498 26490 26493 26494 26495 26496 26497 26812 26814 26818 26819 28182)
@@DougTanner I had something similar.
I just can't take it as "the right way to write c++ code". If this is the right way to write c++ code, then there's something wrong with c++.
Just use -Isystem
Vulkan...
@@DougTanner What is wrong with you?
The only things I agree with are static analysis and source control. Testing can be done in a much simpler way than the wacky testing frameworks by just making a function that calls a function and knows what kind of exception to expect. Checking for memory leaks is a good idea for your tooling, but your application code should be written in a way where pointers are never used at all (including smart pointers), so memory leaks are also not a concern if your tooling has no memory leaks.
However, I do agree that you should use everything stated in the video if you are writing super-highly optimized code and had to sacrifice some readability and abstraction for performance. In that case, you can't really avoid using pointers and there could be all sorts of hidden nasties that wouldn't be possible with proper abstraction.
Why are the testing frameworks whacky? They can deliver a tonne of value, in my experience
@@kippers12isOG I haven't used all of them, but from the ones I have tried, they usually involve heavy use of macros and transpiling schemes for dependency injection and just odd stuff like that. All you really need is to write a bunch of void functions that either throw something or don't, and a loop that calls them all and checks for what, if anything, each function threw.
> The Right Way to Write C++ Code
The right way is write C++ code in Rust 😀
Get out!
Saying this under a video in a C++ community... you have balls 😆
Another nothing but Rust propaganda (I see no discussion but just A > B). Thanks for example because it's the easiest way to show that isn't not worth it switching to Rust because of it's community
@@keshkek I've been giving Rust a try for the past couple of months. Read an entire book about it, got excited about it and decided to develop a Rust interface for my team's product, which currently is in C and C++... and then I faced its community. I have never gotten so many condescending comments to my beginners questions. Sometimes makes me feel like giving up on trying this language.
@@matthieud.1131 I've not even yet tried Rust (seriously considering it), but all these annoying comments in the internet make me wonder whether I want to interact with that community...
You should look into RapidCheck, it makes property based testing (a kind of fuzz testing) super easy.
"Always enable -Werror"
Vulkan and its 2000+ warnings for narrowing conversions.
Edit: grammar nazi.
You can always wrap it's headers with pragmas to disable them for place that you don't control.
Its*
Import the library as a system library and the compiler will ignore those warnings.
I prefer gtest, but there is cppunit.
I think gflags.exe deserves a mention alongside DrMemory and valgrind
I had never heard of it before! I've pulled up the docs and will take a look.
@@cppweekly The most helpful command in my experience is "gflags.exe /p /enable yourexecutable.exe /full" which will make Windows put an unreadable page after every allocation, and cause the debugger to break if the program tries to read or write there. I've found it's invaluable for tracking down certain kinds of memory errors. Make sure you remember to run "/disable" to disable it when you are finished