3 ms·

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

by 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.

by roca 6y ago

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.