7 ms·

CppCon 2022 Best Practices Every C++ Programmer Needs to Follow – Oz Syed

41 points by mikece 3y ago

classified 3y ago
One developer's "best practice" is another developer's nightmare. Much of it depends on context.
- stackedinserter 3y ago
  Examples?
  - userbinator 3y ago
    goto.
not_your_vase 3y ago
Recommending counting new/delete operations in 2023? What about smart pointers? I would imagine that nowadays you should use new/delete only if you have to account for every CPU cycle to literally get every drop of performance...
- tcbawo 3y ago
  His larger point was having a focus on memory management. He mentioned new and delete in reference to ensuring they match up to avoid memory leaks. He also mentioned smart pointers. If you wanted every drop of CPU performance, you probably wouldn’t be doing lots of memory allocation. You would probably look at every operation in your critical path/loop and ask 1) do I have to do this at all? 2) do I have to do this right here/now? Cut out, defer, pre-allocate until you get as fast as you can.
- cdevries 3y ago
  I was surprised to see no talk of RAII when it came to memory management
- flohofwoe 3y ago
  He says "use smart pointers, if you have to" at around 1:33. But anyway, if performance matters at all you shouldn't heap-allocate in any hot code path in the first place. E.g. if memory management overhead is showing up in profiling, don't start looking for a faster general-purpose allocator, but instead rethink your memory management strategy ... and "I'll just put every C++ object behind a smart pointer" isn't really a memory management strategy ;)
  - mr_00ff00 3y ago
    Junior C++ dev here, but I feel like "use smart pointers, if you have to" is not the sentiment I usually hear. Isn’t it usually “use raw pointers, if you have to”?
    - okamiueru 3y ago
      Yes. The main problem with the talk is that it's just too general. It gives good advice, but it's only really good advice if you understand what it's trying to say, at which point you don't need the advice. Kinda impossible to cover "what every programmer needs to know" in 5 minutes. So, "use smart points, if you have to", should have been: "if you need to allocate memory dynamically, use smart pointers".
      - shrimp_emoji 3y ago
        > if you need to allocate memory dynamically, use smart pointers Oooh. Okay. :p I was like, "As opposed to what, raw pointers?!"
    - flohofwoe 3y ago
      As always the answer is "it depends". Smart pointers kind of 'encourage' that each C++ object lives in its own heap allocation, but this quickly becomes a problem if you deal with tens- or hundreds-of-thousands of small C++ objects that way, each in its own heap allocation, and on top a high number of those objects being frequently created and destroyed (for instance with std::make_unique or std::make_shared). I call this a "Java-style C++ code base". Technically this works and it's reasonably safe, because RAII takes care of memory management, just like GC takes care of memory management in Java. But the problem there is deeper: it's not smart pointers vs raw pointers, but that each small object lives in its own heap allocation. That's the typical scenario where you will see memory management becoming a performance problem (for at least two reasons: (1) heap allocation and especially deallocation isn't free, and (2) lots of cache misses when accessing objects that are spread more or less randomly over the address space). Ideally you'd group many similar objects into long-lived and compact arrays, process the data in those arrays in tight loops, minimize pointer indirections, and minimize allocations (ideally you'd only allocate those arrays once at program start, or when those arrays need to grow). Once you did all those things, memory managament suddenly becomes a non-problem (because you only have a handful of long-lived allocations to care about), and RAII becomes a lot less useful (because the 'objects' in those arrays will most likely just be C-style plain-old-data structs). This is basically the 'antithesis' to OOP. And before you know it you're back to writing C code, like it happened to me ;P TL;DR: there is no silver bullet for automatic memory management if performance matters.
jbotdev 3y ago
> In this session, learn some of the best practices that every C++ programmer needs to ensure successful completion of a project. I find it annoying when people say you “need” some best practice. The things you actually need are generally enforced by the tools (compiler errors in this case?). Everything else is subjective and/or depends on your use case.
- Yoric 3y ago
  I would disagree. In most programming languages, compiler errors and even linters lag by orders of magnitude behind the practices that will actually let you write code that stands a chance of being safe and secure. I haven't looked at this specific list yet, but I am yet to see a C++ project in which code works just by following what the tools tell you.
  - bluGill 3y ago
    I find tools are very helpful to reminding me of rules I forgot to apply, but they can only detect a limited subset of places where I forget to apply tools.
  - jbotdev 3y ago
    Maybe I’m arguing semantics, but my point is “need” seems a little subjective here. You can write insecure/unsafe/unreliable code and it’ll still run and compile just fine. You probably don’t want to, but you don’t “need” every program to be safe.
- rerx 3y ago
  That's not trivial, in particular with C++. However, the talk actually talks about setting up tooling as early as you can as a best practice, like multiple different compilers or regression test suits on all targeted platforms.
- tialaramex 3y ago
  > The things you actually need are generally enforced by the tools (compiler errors in this case?). No. This is specifically C++ which has IFNDR ("Ill-formed, No Diagnostic Required") which means the ISO document says there are things (a lot of things it turns out, WG21 appears to have given up even trying to enumerate them) which aren't valid C++ - and so you mustn't do them because the resulting program is meaningless - and yet the compiler isn't expected to detect them and reject your program. Henry Gordon Rice wrote an important PhD thesis about computation in like 1951. Rice's Theorem says that all non-trivial semantic properties are Undecidable. But we want semantic properties! So, if your programming language is going to have non-trivial semantic properties then you have two practical options: 1. Accept all programs which may have the desired semantic properties, since you can't always decide which those are, you give up and accept programs where you aren't sure, these programs are nonsense, but too bad. That's C++ with IFNDR 2. Reject all programs which may not have the desired semantic properties, since you can't always decide which those are either, you give up and spit out a compiler error when you aren't sure. If a program is rejected maybe the human programmer will rewrite it so that it's acceptable, which is a burden on them. That's what Rust does.
876978095789789 3y ago
How does modern C++ compare to Rust? As in, if someone is already familiar with C++, and is willing and able to use c++20, and maybe beyond, features, are there still some compelling reasons to switch to Rust?
- Yoric 3y ago
  Rust does have a few drawbacks (custom allocators, some people miss sfinae, I don't). However, the Rust standard library is, IMHO, vastly better designed that the C++ stdlib, in particular when it comes to concurrency. Also, the toolchain is quite good. And of course, linting is miles ahead of C++ and will presumably stay there forever, as Rust code is much easier to analyze than C++. So, I would say yes, it is worth. But truly, it probably depends on what you're coding.
  - pavlov 3y ago
    IMO a major exception is that if you’re interfacing with complex C++ libraries, it’s probably better to stay in C++ land rather than try to make it work from Rust. (Fixing bugs involving FFI is truly the worst, and C++ is particularly hairy to wrap from other languages.) One strategy is to put a minimal application-specific C layer around your C++ library, and call that from the Rust app. I’ve done that in the past and it kept the Rusties on the team happy enough. But you need to be fairly certain that the API can remain small enough and high-level enough even as needs grow, because nobody wants to be maintaining a C wrapper of hundreds of API calls a few years down the road.
- pjmlp 3y ago
  Assuming that you also make use of static analysis as part of the language, mostly developer culture. In C++ circles, safety conscious developers are always fighting against C like code, or disabling bounds checking. If you are in a team that values bounds checking enabled by default, and where C style coding is forbidden unless for FFI reasons, then it is another matter. See Jason Turner's starter packs. https://youtu.be/ucl0cw9X3e8 https://youtu.be/ucl0cw9X3e8
  - 3y ago
unglaublich 3y ago
I think it's better to just browse the 'CppCoreGuidelines' for the aspects that you are working on. C++ is multi paradigm and has an extremely broad user-base, no size fits all so select what you need. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...
- pjmlp 3y ago
  Not only browsing, enabling them of the static analysis tooling of your preference.
  - alchemist1e9 3y ago
    What C++ static analysis tools is considered the best currently? I need to work on a large C++ code base soon and haven’t in 2-3 years, and tbh have neglected leveraging such tool properly in the past, so hoping for some good pointers on a good setup on Linux.
    - pjmlp 3y ago
      Stuff like clang-tidy, Clion and Visual Studio builtin analysers (works better alongside SAL), or commercial tooling like these ones, https://www.incredibuild.com/blog/top-9-c-static-code-analysis-tools https://www.incredibuild.com/blog/top-9-c-static-code-analys...
fefe23 3y ago
This is a lightning talk of the category "someone on the internet has an opinion". The level is "count your new and delete and see that you have the same amount".
bfrog 3y ago
Every C++ dev has their own C++ that is idiomatic. Good luck matching that up with reality.
- classified 3y ago
  How do you define reality then?
  - mikece 3y ago
    How do we know that your reality, my reality, and his/her reality aren't three different things?
    - classified 3y ago
      Exactly. If "every C++ dev has their own C++ that is idiomatic", which is the reality you'd want to match it up with?
stackedinserter 3y ago
You can skip straight to the video: https://www.youtube.com/watch?v=xhTINjoihrk https://www.youtube.com/watch?v=xhTINjoihrk It's 5 minutes of very basic and generic statements, like "don't forget to free your memory", "follow rule of five" and "test your code".
AnimalMuppet 3y ago
C++ isn't a "needs to follow" kind of language. It's more "Here are some guidelines. If they don't fit what you need to do, feel free to not follow them, but you should probably know why."
hathym 3y ago
I would recommand this video from Hurb Sutter instead: https://www.youtube.com/watch?v=ELeZAKCN4tY&list=PLHTh1InhhwT6c2JNtUiJkaH8YRqzhU7Ags https://www.youtube.com/watch?v=ELeZAKCN4tY&list=PLHTh1Inhhw...
stephc_int13 3y ago
There are no "Best Practices", this is a toxic myth. Like engineering, methodology an design are always tradeoffs, highly dependent on context. Business constraints, company culture, legacy code, team strength and even individual preferences, all of that should be taken into account, there are different appropriate styles for different cases. The only "best practice" is a wide knowledge of what can be done, and the ability to pick and mix to optimize given the context.
- golergka 3y ago
  When I what circumstances would not using a version control system, for example, be the right choice?
  - stephc_int13 3y ago
    If you are a 8 years old kid learning to program, maybe.
- mr_00ff00 3y ago
  I don’t think having many options with trade-offs and “best practices” are mutually exclusive. Best practices at a minimum can be guidelines for how to build, and at there best they describe exactly what you should do based on the trade-offs and your current situation.
  - stephc_int13 3y ago
    There are best practices in a given context that can be worst practices in an other one. The coding style that is used in safety critical embedded software or high frequency trading would not be appropriate for gamedev or web, and vice versa.
- galoisscobi 3y ago
  This has been a revelation to me. I have always wanted to test in prod but best practices stopped me. Now is my time.
- 3y ago
okamiueru 3y ago
Posts like these are examples of what I find a bit disappointing on Hackernews. It looks interesting on the surface, but the ends up being generic and completely lacking of any substance. I wonder why these end up in the front-page.

41 points by mikece 3y ago

classified 3y ago

One developer's "best practice" is another developer's nightmare. Much of it depends on context.

stackedinserter 3y ago
Examples?
- userbinator 3y ago
  goto.

not_your_vase 3y ago

Recommending counting new/delete operations in 2023? What about smart pointers? I would imagine that nowadays you should use new/delete only if you have to account for every CPU cycle to literally get every drop of performance...

tcbawo 3y ago
His larger point was having a focus on memory management. He mentioned new and delete in reference to ensuring they match up to avoid memory leaks. He also mentioned smart pointers. If you wanted every drop of CPU performance, you probably wouldn’t be doing lots of memory allocation. You would probably look at every operation in your critical path/loop and ask 1) do I have to do this at all? 2) do I have to do this right here/now? Cut out, defer, pre-allocate until you get as fast as you can.
cdevries 3y ago
I was surprised to see no talk of RAII when it came to memory management
flohofwoe 3y ago
He says "use smart pointers, if you have to" at around 1:33. But anyway, if performance matters at all you shouldn't heap-allocate in any hot code path in the first place. E.g. if memory management overhead is showing up in profiling, don't start looking for a faster general-purpose allocator, but instead rethink your memory management strategy ... and "I'll just put every C++ object behind a smart pointer" isn't really a memory management strategy ;)
- mr_00ff00 3y ago
  Junior C++ dev here, but I feel like "use smart pointers, if you have to" is not the sentiment I usually hear. Isn’t it usually “use raw pointers, if you have to”?
  - okamiueru 3y ago
    Yes. The main problem with the talk is that it's just too general. It gives good advice, but it's only really good advice if you understand what it's trying to say, at which point you don't need the advice. Kinda impossible to cover "what every programmer needs to know" in 5 minutes. So, "use smart points, if you have to", should have been: "if you need to allocate memory dynamically, use smart pointers".
    - shrimp_emoji 3y ago
      > if you need to allocate memory dynamically, use smart pointers Oooh. Okay. :p I was like, "As opposed to what, raw pointers?!"
  - flohofwoe 3y ago
    As always the answer is "it depends". Smart pointers kind of 'encourage' that each C++ object lives in its own heap allocation, but this quickly becomes a problem if you deal with tens- or hundreds-of-thousands of small C++ objects that way, each in its own heap allocation, and on top a high number of those objects being frequently created and destroyed (for instance with std::make_unique or std::make_shared). I call this a "Java-style C++ code base". Technically this works and it's reasonably safe, because RAII takes care of memory management, just like GC takes care of memory management in Java. But the problem there is deeper: it's not smart pointers vs raw pointers, but that each small object lives in its own heap allocation. That's the typical scenario where you will see memory management becoming a performance problem (for at least two reasons: (1) heap allocation and especially deallocation isn't free, and (2) lots of cache misses when accessing objects that are spread more or less randomly over the address space). Ideally you'd group many similar objects into long-lived and compact arrays, process the data in those arrays in tight loops, minimize pointer indirections, and minimize allocations (ideally you'd only allocate those arrays once at program start, or when those arrays need to grow). Once you did all those things, memory managament suddenly becomes a non-problem (because you only have a handful of long-lived allocations to care about), and RAII becomes a lot less useful (because the 'objects' in those arrays will most likely just be C-style plain-old-data structs). This is basically the 'antithesis' to OOP. And before you know it you're back to writing C code, like it happened to me ;P TL;DR: there is no silver bullet for automatic memory management if performance matters.

jbotdev 3y ago

> In this session, learn some of the best practices that every C++ programmer needs to ensure successful completion of a project. I find it annoying when people say you “need” some best practice. The things you actually need are generally enforced by the tools (compiler errors in this case?). Everything else is subjective and/or depends on your use case.

Yoric 3y ago
I would disagree. In most programming languages, compiler errors and even linters lag by orders of magnitude behind the practices that will actually let you write code that stands a chance of being safe and secure. I haven't looked at this specific list yet, but I am yet to see a C++ project in which code works just by following what the tools tell you.
- bluGill 3y ago
  I find tools are very helpful to reminding me of rules I forgot to apply, but they can only detect a limited subset of places where I forget to apply tools.
- jbotdev 3y ago
  Maybe I’m arguing semantics, but my point is “need” seems a little subjective here. You can write insecure/unsafe/unreliable code and it’ll still run and compile just fine. You probably don’t want to, but you don’t “need” every program to be safe.
rerx 3y ago
That's not trivial, in particular with C++. However, the talk actually talks about setting up tooling as early as you can as a best practice, like multiple different compilers or regression test suits on all targeted platforms.
tialaramex 3y ago
> The things you actually need are generally enforced by the tools (compiler errors in this case?). No. This is specifically C++ which has IFNDR ("Ill-formed, No Diagnostic Required") which means the ISO document says there are things (a lot of things it turns out, WG21 appears to have given up even trying to enumerate them) which aren't valid C++ - and so you mustn't do them because the resulting program is meaningless - and yet the compiler isn't expected to detect them and reject your program. Henry Gordon Rice wrote an important PhD thesis about computation in like 1951. Rice's Theorem says that all non-trivial semantic properties are Undecidable. But we want semantic properties! So, if your programming language is going to have non-trivial semantic properties then you have two practical options: 1. Accept all programs which may have the desired semantic properties, since you can't always decide which those are, you give up and accept programs where you aren't sure, these programs are nonsense, but too bad. That's C++ with IFNDR 2. Reject all programs which may not have the desired semantic properties, since you can't always decide which those are either, you give up and spit out a compiler error when you aren't sure. If a program is rejected maybe the human programmer will rewrite it so that it's acceptable, which is a burden on them. That's what Rust does.

876978095789789 3y ago

How does modern C++ compare to Rust? As in, if someone is already familiar with C++, and is willing and able to use c++20, and maybe beyond, features, are there still some compelling reasons to switch to Rust?

Yoric 3y ago
Rust does have a few drawbacks (custom allocators, some people miss sfinae, I don't). However, the Rust standard library is, IMHO, vastly better designed that the C++ stdlib, in particular when it comes to concurrency. Also, the toolchain is quite good. And of course, linting is miles ahead of C++ and will presumably stay there forever, as Rust code is much easier to analyze than C++. So, I would say yes, it is worth. But truly, it probably depends on what you're coding.
- pavlov 3y ago
  IMO a major exception is that if you’re interfacing with complex C++ libraries, it’s probably better to stay in C++ land rather than try to make it work from Rust. (Fixing bugs involving FFI is truly the worst, and C++ is particularly hairy to wrap from other languages.) One strategy is to put a minimal application-specific C layer around your C++ library, and call that from the Rust app. I’ve done that in the past and it kept the Rusties on the team happy enough. But you need to be fairly certain that the API can remain small enough and high-level enough even as needs grow, because nobody wants to be maintaining a C wrapper of hundreds of API calls a few years down the road.
pjmlp 3y ago
Assuming that you also make use of static analysis as part of the language, mostly developer culture. In C++ circles, safety conscious developers are always fighting against C like code, or disabling bounds checking. If you are in a team that values bounds checking enabled by default, and where C style coding is forbidden unless for FFI reasons, then it is another matter. See Jason Turner's starter packs. https://youtu.be/ucl0cw9X3e8 https://youtu.be/ucl0cw9X3e8
- 3y ago

unglaublich 3y ago

I think it's better to just browse the 'CppCoreGuidelines' for the aspects that you are working on. C++ is multi paradigm and has an extremely broad user-base, no size fits all so select what you need. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

pjmlp 3y ago
Not only browsing, enabling them of the static analysis tooling of your preference.
- alchemist1e9 3y ago
  What C++ static analysis tools is considered the best currently? I need to work on a large C++ code base soon and haven’t in 2-3 years, and tbh have neglected leveraging such tool properly in the past, so hoping for some good pointers on a good setup on Linux.
  - pjmlp 3y ago
    Stuff like clang-tidy, Clion and Visual Studio builtin analysers (works better alongside SAL), or commercial tooling like these ones, https://www.incredibuild.com/blog/top-9-c-static-code-analysis-tools https://www.incredibuild.com/blog/top-9-c-static-code-analys...

fefe23 3y ago

This is a lightning talk of the category "someone on the internet has an opinion". The level is "count your new and delete and see that you have the same amount".

bfrog 3y ago

Every C++ dev has their own C++ that is idiomatic. Good luck matching that up with reality.

classified 3y ago
How do you define reality then?
- mikece 3y ago
  How do we know that your reality, my reality, and his/her reality aren't three different things?
  - classified 3y ago
    Exactly. If "every C++ dev has their own C++ that is idiomatic", which is the reality you'd want to match it up with?

stackedinserter 3y ago

You can skip straight to the video: https://www.youtube.com/watch?v=xhTINjoihrk https://www.youtube.com/watch?v=xhTINjoihrk It's 5 minutes of very basic and generic statements, like "don't forget to free your memory", "follow rule of five" and "test your code".

AnimalMuppet 3y ago

C++ isn't a "needs to follow" kind of language. It's more "Here are some guidelines. If they don't fit what you need to do, feel free to not follow them, but you should probably know why."

hathym 3y ago

I would recommand this video from Hurb Sutter instead: https://www.youtube.com/watch?v=ELeZAKCN4tY&list=PLHTh1InhhwT6c2JNtUiJkaH8YRqzhU7Ags https://www.youtube.com/watch?v=ELeZAKCN4tY&list=PLHTh1Inhhw...

stephc_int13 3y ago

There are no "Best Practices", this is a toxic myth. Like engineering, methodology an design are always tradeoffs, highly dependent on context. Business constraints, company culture, legacy code, team strength and even individual preferences, all of that should be taken into account, there are different appropriate styles for different cases. The only "best practice" is a wide knowledge of what can be done, and the ability to pick and mix to optimize given the context.

golergka 3y ago
When I what circumstances would not using a version control system, for example, be the right choice?
- stephc_int13 3y ago
  If you are a 8 years old kid learning to program, maybe.
mr_00ff00 3y ago
I don’t think having many options with trade-offs and “best practices” are mutually exclusive. Best practices at a minimum can be guidelines for how to build, and at there best they describe exactly what you should do based on the trade-offs and your current situation.
- stephc_int13 3y ago
  There are best practices in a given context that can be worst practices in an other one. The coding style that is used in safety critical embedded software or high frequency trading would not be appropriate for gamedev or web, and vice versa.
galoisscobi 3y ago
This has been a revelation to me. I have always wanted to test in prod but best practices stopped me. Now is my time.
3y ago

okamiueru 3y ago

Posts like these are examples of what I find a bit disappointing on Hackernews. It looks interesting on the surface, but the ends up being generic and completely lacking of any substance. I wonder why these end up in the front-page.