7 ms·

I'd definitely pick C++11 unless you need to use Rust. Rust is inherently memory safe - however in practical terms this isn't important for most applications.

I'd definitely pick C++11 unless you need to use Rust. Rust is inherently memory safe - however in practical terms this isn't important for most applications. If you are writing security critical applications Rust will provide you with some very important guarantees (ie. there are certain mistakes which are inherently not possible in the language). C++ doesn't really guarantee anything and if you're an idiot you can shoot yourself in the face. However in practical terms memory management in C++11 is very straightforwards and C++11 compliant code (ie. using the STL and not writing it like C) is very safe and clean. You're not mucking with raw pointers anymore The main issue I see is that Rust is still in early development. It may or may not get "big" in the coming years. And library support is ... lacking In contrast C++ has the STL and boost and every library under the sun. I haven't working with a lot of other languages extensively, but I've never seen anything as clean, robust and thorough as the STL and boost. C++ will remain relevant for a long long time. If Rust takes off in a big way, you'll be well positioned to jump ship.

hadoukenio 12y ago
Wow, that was a great comment and exactly the type of info I was after. I think (coming from a dynamic language world) the memory safeness is what pulls me towards Rust. But from what you say and what I've read elsewhere, that was old-style C++ and not C++1[17]. Thanks!
- Shamanmuni 12y ago
  Read what the other commenters are pointing out. Maybe the situation is better in C++ now than it was before, but it doesn't mean you can't shoot yourself in the foot, specially for a beginner. Rust was built with safety in mind from the start, there are errors you can make in C++ that the Rust compiler simply won't let. My advice is, if you're learning it for work, then go with C++. Even if it succeeds, it will take some years for Rust to be mainstream and as pointed out the library support is great. If you're learning it for fun or for the sake of learning something new. Then Rust is a very nice and promising language bringing things from functional languages that C++ lacks and offering very interesting tooling around it. Whatever you choose, after you feel confident with one go and learn the other as it will probably give a better perspective in the strengths and/or weaknesses of both.
- genericallyloud 12y ago
  I would just point out that the impetus for the Rust language was Mozilla looking for a better language to implement a browser in than C++. They obviously have a lot of experience writing C++ and how to do it as good as possible, but found it coming up short, especially as multi-core starts becoming the bottleneck.
jroesch 12y ago
I'm not sure in what world writing C++11 is "very straight forward ... safe and clean". You can easily write unsafe code without thinking about it. For example one can write a function that lends out a reference or pointer to memory that may or may not exist after the call exits, and this is impossible in Rust.
- bjz_ 12y ago
  To be precise, impossible outside defined `unsafe` blocks of code. It's still important to be able to drop down once and a while if you absolutely need to... you just don't want that ability all the time.
Jweb_Guru 12y ago
I definitely understand where you are coming from, and I agree that C++11's ecosystem maturity is a great reason to choose it at the moment. However, I cannot agree with you that Rust's safety guarantees are not useful for most C++ programs, or that you have to be an "idiot" to do memory-unsafe things in C++11. Someone at Yandex recently did a presentation about Rust [1] in which they pointed to a bit of (completely idiomatic!) C++11 code that caused undefined behavior. The audience, full of seasoned C++ and Java developers, was asked to identify the problem. Not one of them could point to what was causing it (the compiler certainly didn't). The next slide demonstrated how Rust's compiler statically prevented this issue. The issue could have taken weeks to surface and days to track down, and the C++ compiler simply didn't have enough information to determine that it was a problem. This is something that happens over and over to anyone using C++, in any application, not just security-critical ones. I'm not saying C++11 doesn't improve the situation, because it does--it would be disingenuous to say otherwise. But it's equally disingenuous to imply that C++11 makes memory management straightforward or safe. It does not. [1] http://habrahabr.ru/company/yandex/blog/235789/ http://habrahabr.ru/company/yandex/blog/235789/ (note: the presentation and site are in Russian).
- bjz_ 12y ago
  > Someone at Yandex recently did a presentation about Rust[1] in which they pointed to a bit of (completely idiomatic!) C++11 code that caused undefined behavior. It would be great to have at least that segment of the talk translated. Sounds like a good example.
  - pbsd 12y ago
    See slide 42 of STL's recent talk for what I guess will be a similar example: https://github.com/CppCon/CppCon2014/tree/master/Presentations/STL%20Features%20And%20Implementation%20Techniques%20-%20Stephan%20T.%20Lavavej%20-%20CppCon%202014 https://github.com/CppCon/CppCon2014/tree/master/Presentatio...
    - dbaupp 12y ago
      Reproduced here: const regex r(R"(meow(\d+)\.txt)"); smatch m; if (regex_match(dir_iter->path().filename().string(), m, r)) { DoSomethingWith(m[1]); } - What's wrong with this code? - Haqrsvarq orunivbe va P++11 - Pbzcvyre reebe va P++14 - .fgevat() ergheaf n grzcbenel fgq::fgevat - z[1] pbagnvaf vgrengbef gb n qrfgeblrq grzcbenel (http://rot13.com/ http://rot13.com/ 'd if you want to guess.)
dbaupp 12y ago
There's more to memory-unsafety than raw pointers; all of these are problems even in the most modern C++ versions: - iterator invalidation - dangling references - buffer overruns - use after move (and somewhat, use after free) - general undefined behaviour (e.g. overlong shifts, signed integer overflow) And there's more to memory safety than security critical applications. Rust means you spend a little more time fighting the compiler, but a lot less time fighting the debugger and a lot less time trying to reproduce heisenbugs caused by data races/undefined behaviour. Of course, the library/tool support is indisputably in C++'s favour. > if you're an idiot you can shoot yourself in the face If you're a human you will shoot yourself in the face. It just takes far too much brain power to write correct C++ always (a single mistake leads to brokenness), especially in a team where there can be implicit knowledge about how an API works/should work that may not be correctly transferred between people.
- pbsd 12y ago
  Iterator invalidation, dangling references, and use-after-move are all essentially the same thing---references outlasting their owner---no need to multiply the issues. Buffer overflows are an issue, yes, unavoidable due to the C legacy. On the other hand, it's somewhat ironic that you point to overlong shifts as a C++ problem when Rust has the exact same behavior. What does this function return? pub fn f(x: uint) -> uint { x >> 32 } Honestly, I loved the idea of Rust. I was sold a memory-safe C++, and that sounded awesome. But what I got instead was an ML with better low-level support; it felt like an enormous bait-and-switch, as nobody is interested in yet-another-functional-language.
  - dbaupp 12y ago
    Overlong shifts are currently not handled correctly, yes, but they will not be undefined behaviour; they will possibly be implementation-defined but will not lead to memory unsafety. > use-after-move [...] ---references outlasting their owner--- Not really, e.g. std::unique_ptr<int> x(1); foo(std::move(x)); std::cout << *x; // undefined behaviour Unless you mean something other than `&` references. > Honestly, I loved the idea of Rust. I was sold a memory-safe C++, and that sounded awesome. But what I got instead was an ML with some low-level extensions; it felt like an enormous bait-and-switch, as nobody is interested in yet-another-functional-language. Something in this sentence has to be wrong, since people are clearly interested in Rust: either people are interested in YAFL or Rust isn't what you seem to think it is. Anyway, that just sounds like a 'problem' with your background/expectations and/or whoever sold it to you. Rust is a C++ competitor (i.e. targets the similar low-level space) but it is not definitely trying to just be a C++ rewrite fixing the holes. I don't think there's any official marketing implying the latter.
pnathan 12y ago
I've had a vastly happier Rust experience than C++ experience (I've written in both, well beyond the "zomgz 50line starter program"). The Rust compiler is vastly smarter and gets you type checking you have to pay out the nose for in C & C++. I'm a fanboy of Rust, but I would suggest looking hard at Rust for any C or C++ production code going forward. (My default going forward for this space will be Rust unless overriding considerations say otherwise).
deleted 12y ago
[deleted]

hadoukenio 12y ago

Wow, that was a great comment and exactly the type of info I was after. I think (coming from a dynamic language world) the memory safeness is what pulls me towards Rust. But from what you say and what I've read elsewhere, that was old-style C++ and not C++1[17]. Thanks!

Shamanmuni 12y ago
Read what the other commenters are pointing out. Maybe the situation is better in C++ now than it was before, but it doesn't mean you can't shoot yourself in the foot, specially for a beginner. Rust was built with safety in mind from the start, there are errors you can make in C++ that the Rust compiler simply won't let. My advice is, if you're learning it for work, then go with C++. Even if it succeeds, it will take some years for Rust to be mainstream and as pointed out the library support is great. If you're learning it for fun or for the sake of learning something new. Then Rust is a very nice and promising language bringing things from functional languages that C++ lacks and offering very interesting tooling around it. Whatever you choose, after you feel confident with one go and learn the other as it will probably give a better perspective in the strengths and/or weaknesses of both.
genericallyloud 12y ago
I would just point out that the impetus for the Rust language was Mozilla looking for a better language to implement a browser in than C++. They obviously have a lot of experience writing C++ and how to do it as good as possible, but found it coming up short, especially as multi-core starts becoming the bottleneck.

jroesch 12y ago

I'm not sure in what world writing C++11 is "very straight forward ... safe and clean". You can easily write unsafe code without thinking about it. For example one can write a function that lends out a reference or pointer to memory that may or may not exist after the call exits, and this is impossible in Rust.

bjz_ 12y ago
To be precise, impossible outside defined `unsafe` blocks of code. It's still important to be able to drop down once and a while if you absolutely need to... you just don't want that ability all the time.

Jweb_Guru 12y ago

I definitely understand where you are coming from, and I agree that C++11's ecosystem maturity is a great reason to choose it at the moment. However, I cannot agree with you that Rust's safety guarantees are not useful for most C++ programs, or that you have to be an "idiot" to do memory-unsafe things in C++11. Someone at Yandex recently did a presentation about Rust [1] in which they pointed to a bit of (completely idiomatic!) C++11 code that caused undefined behavior. The audience, full of seasoned C++ and Java developers, was asked to identify the problem. Not one of them could point to what was causing it (the compiler certainly didn't). The next slide demonstrated how Rust's compiler statically prevented this issue. The issue could have taken weeks to surface and days to track down, and the C++ compiler simply didn't have enough information to determine that it was a problem. This is something that happens over and over to anyone using C++, in any application, not just security-critical ones. I'm not saying C++11 doesn't improve the situation, because it does--it would be disingenuous to say otherwise. But it's equally disingenuous to imply that C++11 makes memory management straightforward or safe. It does not. [1] http://habrahabr.ru/company/yandex/blog/235789/ http://habrahabr.ru/company/yandex/blog/235789/ (note: the presentation and site are in Russian).

bjz_ 12y ago
> Someone at Yandex recently did a presentation about Rust[1] in which they pointed to a bit of (completely idiomatic!) C++11 code that caused undefined behavior. It would be great to have at least that segment of the talk translated. Sounds like a good example.
- pbsd 12y ago
  See slide 42 of STL's recent talk for what I guess will be a similar example: https://github.com/CppCon/CppCon2014/tree/master/Presentations/STL%20Features%20And%20Implementation%20Techniques%20-%20Stephan%20T.%20Lavavej%20-%20CppCon%202014 https://github.com/CppCon/CppCon2014/tree/master/Presentatio...
  - dbaupp 12y ago
    Reproduced here: const regex r(R"(meow(\d+)\.txt)"); smatch m; if (regex_match(dir_iter->path().filename().string(), m, r)) { DoSomethingWith(m[1]); } - What's wrong with this code? - Haqrsvarq orunivbe va P++11 - Pbzcvyre reebe va P++14 - .fgevat() ergheaf n grzcbenel fgq::fgevat - z[1] pbagnvaf vgrengbef gb n qrfgeblrq grzcbenel (http://rot13.com/ http://rot13.com/ 'd if you want to guess.)

dbaupp 12y ago

There's more to memory-unsafety than raw pointers; all of these are problems even in the most modern C++ versions: - iterator invalidation - dangling references - buffer overruns - use after move (and somewhat, use after free) - general undefined behaviour (e.g. overlong shifts, signed integer overflow) And there's more to memory safety than security critical applications. Rust means you spend a little more time fighting the compiler, but a lot less time fighting the debugger and a lot less time trying to reproduce heisenbugs caused by data races/undefined behaviour. Of course, the library/tool support is indisputably in C++'s favour. > if you're an idiot you can shoot yourself in the face If you're a human you will shoot yourself in the face. It just takes far too much brain power to write correct C++ always (a single mistake leads to brokenness), especially in a team where there can be implicit knowledge about how an API works/should work that may not be correctly transferred between people.

pbsd 12y ago
Iterator invalidation, dangling references, and use-after-move are all essentially the same thing---references outlasting their owner---no need to multiply the issues. Buffer overflows are an issue, yes, unavoidable due to the C legacy. On the other hand, it's somewhat ironic that you point to overlong shifts as a C++ problem when Rust has the exact same behavior. What does this function return? pub fn f(x: uint) -> uint { x >> 32 } Honestly, I loved the idea of Rust. I was sold a memory-safe C++, and that sounded awesome. But what I got instead was an ML with better low-level support; it felt like an enormous bait-and-switch, as nobody is interested in yet-another-functional-language.
- dbaupp 12y ago
  Overlong shifts are currently not handled correctly, yes, but they will not be undefined behaviour; they will possibly be implementation-defined but will not lead to memory unsafety. > use-after-move [...] ---references outlasting their owner--- Not really, e.g. std::unique_ptr<int> x(1); foo(std::move(x)); std::cout << *x; // undefined behaviour Unless you mean something other than `&` references. > Honestly, I loved the idea of Rust. I was sold a memory-safe C++, and that sounded awesome. But what I got instead was an ML with some low-level extensions; it felt like an enormous bait-and-switch, as nobody is interested in yet-another-functional-language. Something in this sentence has to be wrong, since people are clearly interested in Rust: either people are interested in YAFL or Rust isn't what you seem to think it is. Anyway, that just sounds like a 'problem' with your background/expectations and/or whoever sold it to you. Rust is a C++ competitor (i.e. targets the similar low-level space) but it is not definitely trying to just be a C++ rewrite fixing the holes. I don't think there's any official marketing implying the latter.

pnathan 12y ago

I've had a vastly happier Rust experience than C++ experience (I've written in both, well beyond the "zomgz 50line starter program"). The Rust compiler is vastly smarter and gets you type checking you have to pay out the nose for in C & C++. I'm a fanboy of Rust, but I would suggest looking hard at Rust for any C or C++ production code going forward. (My default going forward for this space will be Rust unless overriding considerations say otherwise).

deleted 12y ago

[deleted]