4 ms·

One thing to consider about C++, though, is that it's powerful enough to already allow you to duplicate or very closely approximate the functionality you listed

One thing to consider about C++, though, is that it's powerful enough to already allow you to duplicate or very closely approximate the functionality you listed. This is the essence of what some people call "Modern C++". C++ functionality like references and smart pointers make pointer nullability and memory safety irrelevant, or at least much, much less of an issue than in C or older C++ code. RAII significantly helps with lifetime management of all sorts of resources, from memory to database connections to files. There are various collection libraries for C++ that make out-of-bounds accesses a non-issue, at a very minimal cost. Likewise, it's quite easy in almost all cases to avoid using unsafe casts and other behavior that may cause problems, when taking a more modern approach to C++. With a small amount of discipline, C++ of today can be much different than C++ of the 1980s or 1990s. Many of the pitfalls of that era can be avoided with remarkably little effort, especially when using C++11 and modern implementations. Yet it still easily gives you access to very powerful functionality for those rare cases when it is needed. This is much harder to do in many other, more modern languages.

steveklabnik 13y ago
There's no question that you _can_ write safe code in C++, but it's very, very hard. > With a small amount of discipline, I would just like to point out that when dynamic language advocates suggest that 'with a small amount of discipline, you can write reasonably safe dynamic code' and you laugh them off with comments about how static typing saves you from errors at compile time. The same is true with languages like Rust or Haskell; you don't need the discipline, the compiler catches such things for you.
- PommeDeTerre 13y ago
  The discipline involved with writing safe C++ code is somewhat different from the discipline involved with writing safe code in some dynamic language. In C++, it's mostly just a matter of understanding the language features you're using, and then avoiding ones that can be harmful in some cases, often in favor of much safer alternative approaches. The C++ compiler will still catch many other types of problems at compile time that wouldn't necessarily be noticed (assuming they even are noticed by the developer(s)) until runtime when using a dynamic language. The safety net offered by the C++ compiler may not be cast as wide as that of Rust or Haskell, but it's still there, and it does catch many common issues. And I think it's wrong to say that Rust and Haskell don't require discipline; they do. It's still easy to write inefficient or unmaintainable code in those languages, for example. You still need to know what you're doing, and how to use the functionality that they offer, in order to avoid problems like that. Now, the discipline needed when using a dynamic language not only includes the discipline needed when using C++ (that is, "don't do stupid stuff"), but it also includes not making trivial mistakes like typos, or missing some changes when refactoring, and so on. Much, much more discipline is needed when writing code in dynamic languages. That is the kind of discipline that can be automated away to a very large extent, however. Personally, I do think it's silly and wasteful to willingly take on responsibility for ensuring that sort of discipline for anything but the smallest scripts. So, yes, I will speak out against it and those who suggest it's acceptable, especially in larger systems.
  - pcwalton 13y ago
    > In C++, it's mostly just a matter of understanding the language features you're using, and then avoiding ones that can be harmful in some cases, often in favor of much safer alternative approaches. The number of security bugs that every large C++ codebase sees suggests otherwise. C++ is neither safe in practice nor in theory. (I can come up with many ways in which modern idiomatic C++ can be broken, often in an exploitable manner.)
  - masklinn 13y ago
    > And I think it's wrong to say that Rust and Haskell don't require discipline; they do. It's still easy to write inefficient or unmaintainable code in those languages, for example. Yes, but the subject was correctness and the discussion was about the fact that these languages makes it easier to write correct code than e.g. Go or C++.
pcwalton 13y ago
> C++ functionality like references and smart pointers make pointer nullability and memory safety irrelevant, or at least much, much less of an issue than in C or older C++ code. This is dangerously incorrect. Having spent much of my career finding new and exciting ways to break modern idiomatic C++'s memory safety, I can confidently say that no reasonable subset of C++ is memory safe. Try to solve iterator invalidation, for example.

steveklabnik 13y ago

There's no question that you _can_ write safe code in C++, but it's very, very hard. > With a small amount of discipline, I would just like to point out that when dynamic language advocates suggest that 'with a small amount of discipline, you can write reasonably safe dynamic code' and you laugh them off with comments about how static typing saves you from errors at compile time. The same is true with languages like Rust or Haskell; you don't need the discipline, the compiler catches such things for you.

PommeDeTerre 13y ago
The discipline involved with writing safe C++ code is somewhat different from the discipline involved with writing safe code in some dynamic language. In C++, it's mostly just a matter of understanding the language features you're using, and then avoiding ones that can be harmful in some cases, often in favor of much safer alternative approaches. The C++ compiler will still catch many other types of problems at compile time that wouldn't necessarily be noticed (assuming they even are noticed by the developer(s)) until runtime when using a dynamic language. The safety net offered by the C++ compiler may not be cast as wide as that of Rust or Haskell, but it's still there, and it does catch many common issues. And I think it's wrong to say that Rust and Haskell don't require discipline; they do. It's still easy to write inefficient or unmaintainable code in those languages, for example. You still need to know what you're doing, and how to use the functionality that they offer, in order to avoid problems like that. Now, the discipline needed when using a dynamic language not only includes the discipline needed when using C++ (that is, "don't do stupid stuff"), but it also includes not making trivial mistakes like typos, or missing some changes when refactoring, and so on. Much, much more discipline is needed when writing code in dynamic languages. That is the kind of discipline that can be automated away to a very large extent, however. Personally, I do think it's silly and wasteful to willingly take on responsibility for ensuring that sort of discipline for anything but the smallest scripts. So, yes, I will speak out against it and those who suggest it's acceptable, especially in larger systems.
- pcwalton 13y ago
  > In C++, it's mostly just a matter of understanding the language features you're using, and then avoiding ones that can be harmful in some cases, often in favor of much safer alternative approaches. The number of security bugs that every large C++ codebase sees suggests otherwise. C++ is neither safe in practice nor in theory. (I can come up with many ways in which modern idiomatic C++ can be broken, often in an exploitable manner.)
- masklinn 13y ago
  > And I think it's wrong to say that Rust and Haskell don't require discipline; they do. It's still easy to write inefficient or unmaintainable code in those languages, for example. Yes, but the subject was correctness and the discussion was about the fact that these languages makes it easier to write correct code than e.g. Go or C++.

pcwalton 13y ago

> C++ functionality like references and smart pointers make pointer nullability and memory safety irrelevant, or at least much, much less of an issue than in C or older C++ code. This is dangerously incorrect. Having spent much of my career finding new and exciting ways to break modern idiomatic C++'s memory safety, I can confidently say that no reasonable subset of C++ is memory safe. Try to solve iterator invalidation, for example.