13 ms·

I spent the last 6 years writing C++. Would not recommend for a new project, unless some very specific conditions are met. The main reason being the memory (un-

I spent the last 6 years writing C++. Would not recommend for a new project, unless some very specific conditions are met. The main reason being the memory (un-)safety and the costs it generates.

einpoklum 7y ago
I wonder what kind of C++ you've been writing. Memory safety is much less of an issue than it used to be. When you use spans over raw arrays (or vectors etc.) - you can have bounds checking; if you use std::array - you won't make invalid accesses. As for memory management - that's essentially a solved problem, you just use smart pointers, and generally not allocate yourself. It's true that you _can_ shoot yourself in the foot with C++; but it's becoming increasingly more difficult to do so unintentionally.
- bb88 7y ago
  > I wonder what kind of C++ you've been writing. Last I checked there's still a lot of C++ code in legacy production systems -- and a lot that has never ever used a smart pointer.
  - einpoklum 7y ago
    That was exactly my point; GP says they've been writing C++ for the past 6 years, but seems to be talking about legacy code.
    - praptak 7y ago
      Nope, I meant modern C++. Granted, it has multiple mechanisms to prevent memory corruption but they are not watertight.
- praptak 7y ago
  vector::operator[] does not check bounds, neither do some libraries that I have to use, notably Google Protocol Buffers can turn a logic bug (bad index to repeated field) into an access to unallocated memory. Best practices do not fully eliminate segfaults. This is a practical observation.
  - AlexeyBrin 7y ago
    > vector::operator[] does not check bounds True, but modern C++ encourages the use of range based for loops and std::algorithm functions which are safer to use. Also, if you want to check for bounds use std::vector::at which checks for bounds at runtime.
  - cameldrv 7y ago
    It's truly insane that after all of the water under the bridge in the past twenty years with buffer overflows that the default way to access an array in C++ is not bounds-checked. If there is a performance critical loop and you need to avoid the check, there should be a way to do it but for gods sake don't make that the default.
    - deleted 7y ago
      [deleted]
    - praptak 7y ago
      Wouldn't that be against C++ philosophy? I mean fast by default, you need to explicitly enable anything that costs cycles.
  - jupp0r 7y ago
    > vector::operator[] does not check bounds vector::at does check bounds, is your argument that programmers shouldn't have a choice there or do you just not know the standard library that well?
    - praptak 7y ago
      My argument is that the price of the choice is memory corruption and the benefits seldom outweigh this cost.
      - jupp0r 7y ago
        Rust gives you that choice as well (unsafe).
- moosingin3space 7y ago
  > Memory safety is much less of an issue than it used to be. This is demonstrably false: https://twitter.com/LazyFishBarrel/status/1129000965741404160 https://twitter.com/LazyFishBarrel/status/112900096574140416... Additionally, new "safe" C++ APIs aren't: https://bugs.llvm.org/show_bug.cgi?id=34729 https://bugs.llvm.org/show_bug.cgi?id=34729 Apple's iOS 12.4 release fixes 37 CVEs, 28 of which are memory unsafety (75.7%). Microsoft's statistics corroborate this: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... Importantly, none of these sources show any improvements over time. If we saw meaningful improvements in "modern C++" codebases, I'd be much more willing to accept "modern C++". As it stands, there is no such evidence that "modern C++" provides any demonstrable benefits regarding memory safety.
  - kllrnohj 7y ago
    > Additionally, new "safe" C++ APIs aren't: https://bugs.llvm.org/show_bug.cgi?id=34729 https://bugs.llvm.org/show_bug.cgi?id=34729 std::string_view is a borrow interface, not a safe owner. It is a sharp knife, to be sure, but it's not billed as being safe, either, and it's not broken.
  - jupp0r 7y ago
    > Importantly, none of these sources show any improvements over time. If we saw meaningful improvements in "modern C++" codebases, I'd be much more willing to accept "modern C++". As it stands, there is no such evidence that "modern C++" provides any demonstrable benefits regarding memory safety. I don't know of any study comparing memory safety of "modern C++" vs "legacy C++" code. None of the references you provided contains any information about that, so I think it's unfair for you to pretend that it does. From my work over the last years I can tell you that the move from C++98 to C++11 and to a smaller extend the move from C++11 to C++14 has reduced memory corruption bugs by a significant amount. The way we teach C++ to junior engineers is very different to what it was before, a lot of practices that used to lead to unsafe conditions are frowned upon nowadays. It's by no means perfect compared to Rust, but it's definitely not the mess that it's often characterized at when people point to code that would never pass code review nowadays (ie the original article).

I spent the last 6 years writing C++. Would not recommend for a new project, unless some very specific conditions are met. The main reason being the memory (un-)safety and the costs it generates.

einpoklum 7y ago

I wonder what kind of C++ you've been writing. Memory safety is much less of an issue than it used to be. When you use spans over raw arrays (or vectors etc.) - you can have bounds checking; if you use std::array - you won't make invalid accesses. As for memory management - that's essentially a solved problem, you just use smart pointers, and generally not allocate yourself. It's true that you _can_ shoot yourself in the foot with C++; but it's becoming increasingly more difficult to do so unintentionally.

bb88 7y ago
> I wonder what kind of C++ you've been writing. Last I checked there's still a lot of C++ code in legacy production systems -- and a lot that has never ever used a smart pointer.
- einpoklum 7y ago
  That was exactly my point; GP says they've been writing C++ for the past 6 years, but seems to be talking about legacy code.
  - praptak 7y ago
    Nope, I meant modern C++. Granted, it has multiple mechanisms to prevent memory corruption but they are not watertight.
praptak 7y ago
vector::operator[] does not check bounds, neither do some libraries that I have to use, notably Google Protocol Buffers can turn a logic bug (bad index to repeated field) into an access to unallocated memory. Best practices do not fully eliminate segfaults. This is a practical observation.
- AlexeyBrin 7y ago
  > vector::operator[] does not check bounds True, but modern C++ encourages the use of range based for loops and std::algorithm functions which are safer to use. Also, if you want to check for bounds use std::vector::at which checks for bounds at runtime.
- cameldrv 7y ago
  It's truly insane that after all of the water under the bridge in the past twenty years with buffer overflows that the default way to access an array in C++ is not bounds-checked. If there is a performance critical loop and you need to avoid the check, there should be a way to do it but for gods sake don't make that the default.
  - deleted 7y ago
    [deleted]
  - praptak 7y ago
    Wouldn't that be against C++ philosophy? I mean fast by default, you need to explicitly enable anything that costs cycles.
- jupp0r 7y ago
  > vector::operator[] does not check bounds vector::at does check bounds, is your argument that programmers shouldn't have a choice there or do you just not know the standard library that well?
  - praptak 7y ago
    My argument is that the price of the choice is memory corruption and the benefits seldom outweigh this cost.
    - jupp0r 7y ago
      Rust gives you that choice as well (unsafe).
moosingin3space 7y ago
> Memory safety is much less of an issue than it used to be. This is demonstrably false: https://twitter.com/LazyFishBarrel/status/1129000965741404160 https://twitter.com/LazyFishBarrel/status/112900096574140416... Additionally, new "safe" C++ APIs aren't: https://bugs.llvm.org/show_bug.cgi?id=34729 https://bugs.llvm.org/show_bug.cgi?id=34729 Apple's iOS 12.4 release fixes 37 CVEs, 28 of which are memory unsafety (75.7%). Microsoft's statistics corroborate this: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... Importantly, none of these sources show any improvements over time. If we saw meaningful improvements in "modern C++" codebases, I'd be much more willing to accept "modern C++". As it stands, there is no such evidence that "modern C++" provides any demonstrable benefits regarding memory safety.
- kllrnohj 7y ago
  > Additionally, new "safe" C++ APIs aren't: https://bugs.llvm.org/show_bug.cgi?id=34729 https://bugs.llvm.org/show_bug.cgi?id=34729 std::string_view is a borrow interface, not a safe owner. It is a sharp knife, to be sure, but it's not billed as being safe, either, and it's not broken.
- jupp0r 7y ago
  > Importantly, none of these sources show any improvements over time. If we saw meaningful improvements in "modern C++" codebases, I'd be much more willing to accept "modern C++". As it stands, there is no such evidence that "modern C++" provides any demonstrable benefits regarding memory safety. I don't know of any study comparing memory safety of "modern C++" vs "legacy C++" code. None of the references you provided contains any information about that, so I think it's unfair for you to pretend that it does. From my work over the last years I can tell you that the move from C++98 to C++11 and to a smaller extend the move from C++11 to C++14 has reduced memory corruption bugs by a significant amount. The way we teach C++ to junior engineers is very different to what it was before, a lot of practices that used to lead to unsafe conditions are frowned upon nowadays. It's by no means perfect compared to Rust, but it's definitely not the mess that it's often characterized at when people point to code that would never pass code review nowadays (ie the original article).