4 ms·

> C++ hasn't seemed to have changed that, either. C++ is not like C. Putting some C++ objects in a C codebase would, indeed, not change it much, but if you wri

> C++ hasn't seemed to have changed that, either. C++ is not like C. Putting some C++ objects in a C codebase would, indeed, not change it much, but if you write in modern C++, some memory errors will literally disappear, and some become less likely. Caveat: This is based on language mechanics, standard library facilities and recommended idioms; of course people can write unsafe C++ if they want to.

bsder 6y ago
> of course people can write unsafe C++ if they want to. The problem is knowing the safe subset of the language requires continuous study and deep understanding. It also has changed with time. I used to have a bookshelf in order to understand C++. I suspect that has not changed. I do not need a bookshelf to understand the "safe" subset of Rust.
- einpoklum 6y ago
  You are partially correct but mostly incorrect, I would say. It's true that writing safe code requires some study and some understanding. But you don't need to "know what's safe". That _is_ complicated - there are a lot of complex depths to the language. The thing is, the non-expert user can avoid them. For example, a green developer can start with "Avoid using new and delete directly; use vectors, other containers, or unique_ptr's instead. Maybe shared_ptr's in some cases." If at some point they really need to write their own allocating class, they'll be told to be very careful with the allocation, and take into account the possibility of exceptions, concurrent execution by other threads etc. Also, when you're not sure of yourself, there's a good enough reference in the form of the C++ Core Guidelines [1]. (That's a long document, but you don't need to read through it.) Finally, a whole lot of memory error hazards / unsafe code can be statically identified and discouraged. Gradually, IDEs and other tools have started doing so. [1] - isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
roca 6y ago
And modern C++ features makes some memory errors more likely, e.g. dangling references from lambda captures and string_view/span. I'm not optimistic about the safety of modern C++. Most people who really care about safety long ago left the C++ building.
- pjmlp 6y ago
  Some of us are in the managed language world now, the problem is that C++ still has the best integration story with Java and .NET codebases, which Rust still needs to catch up to. So modern C++ will have to do for the few cases that require going out of them, e.g. runtime plugins for native agents, COM/UWP with access to OS APIs, IDE mixed language debugging, GUI components. Also there is the whole issue that GPGPU shaders and Apple/Google/MS driver stacks are mostly about C++. So one either does managed language + C++, or managed language + C++ + additional glue effort + Rust, not much to win currently.
  - roca 6y ago
    You seem to be assuming that everyone uses Java or .NET and C++. That seems wrong to me.
    - pjmlp 6y ago
      No, that is where I am coming from. I can give examples with other managed languages that are more at home with C++ infrastructure for the time being, like JavaScript, Swift, Julia.
- einpoklum 6y ago
  No, they do not: * Dangling references from lambda captures are no different than dangling references or pointers passed without lambdas, and not more likely to be used. * spans are no worse, and usually better, than using a raw pointer and a size; they don't make memory errors more likely. * string_view - indeed, it potentially introduces a dangling pointer. But - that only happens if you store it. Which is why I qualified my claim to "using recommended idioms". If you replace your `const char*` or `const std::string&` with `std::string_view` you have not introduced a potential memory error. More generally - new language/library construct which do not manage their own memory can introduce memory errors. But, luckily, C++ now has a better "harness" of protecting you from many of these without costing you and performance nor introducing now memory issues. So I stand by my claim. Having said that - C++ is not a safety-guaranteed language, and if that's what you need then it is indeed not the language to use.

bsder 6y ago

> of course people can write unsafe C++ if they want to. The problem is knowing the safe subset of the language requires continuous study and deep understanding. It also has changed with time. I used to have a bookshelf in order to understand C++. I suspect that has not changed. I do not need a bookshelf to understand the "safe" subset of Rust.

einpoklum 6y ago
You are partially correct but mostly incorrect, I would say. It's true that writing safe code requires some study and some understanding. But you don't need to "know what's safe". That _is_ complicated - there are a lot of complex depths to the language. The thing is, the non-expert user can avoid them. For example, a green developer can start with "Avoid using new and delete directly; use vectors, other containers, or unique_ptr's instead. Maybe shared_ptr's in some cases." If at some point they really need to write their own allocating class, they'll be told to be very careful with the allocation, and take into account the possibility of exceptions, concurrent execution by other threads etc. Also, when you're not sure of yourself, there's a good enough reference in the form of the C++ Core Guidelines [1]. (That's a long document, but you don't need to read through it.) Finally, a whole lot of memory error hazards / unsafe code can be statically identified and discouraged. Gradually, IDEs and other tools have started doing so. [1] - isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

roca 6y ago

And modern C++ features makes some memory errors more likely, e.g. dangling references from lambda captures and string_view/span. I'm not optimistic about the safety of modern C++. Most people who really care about safety long ago left the C++ building.

pjmlp 6y ago
Some of us are in the managed language world now, the problem is that C++ still has the best integration story with Java and .NET codebases, which Rust still needs to catch up to. So modern C++ will have to do for the few cases that require going out of them, e.g. runtime plugins for native agents, COM/UWP with access to OS APIs, IDE mixed language debugging, GUI components. Also there is the whole issue that GPGPU shaders and Apple/Google/MS driver stacks are mostly about C++. So one either does managed language + C++, or managed language + C++ + additional glue effort + Rust, not much to win currently.
- roca 6y ago
  You seem to be assuming that everyone uses Java or .NET and C++. That seems wrong to me.
  - pjmlp 6y ago
    No, that is where I am coming from. I can give examples with other managed languages that are more at home with C++ infrastructure for the time being, like JavaScript, Swift, Julia.
einpoklum 6y ago
No, they do not: * Dangling references from lambda captures are no different than dangling references or pointers passed without lambdas, and not more likely to be used. * spans are no worse, and usually better, than using a raw pointer and a size; they don't make memory errors more likely. * string_view - indeed, it potentially introduces a dangling pointer. But - that only happens if you store it. Which is why I qualified my claim to "using recommended idioms". If you replace your `const char*` or `const std::string&` with `std::string_view` you have not introduced a potential memory error. More generally - new language/library construct which do not manage their own memory can introduce memory errors. But, luckily, C++ now has a better "harness" of protecting you from many of these without costing you and performance nor introducing now memory issues. So I stand by my claim. Having said that - C++ is not a safety-guaranteed language, and if that's what you need then it is indeed not the language to use.