7 ms·

> Because C++ compatibility is impossible without being a derivative of C++, and C++ is hopeless in the safety department. I believe it is impossible to make C+

> Because C++ compatibility is impossible without being a derivative of C++, and C++ is hopeless in the safety department. I believe it is impossible to make C++ memory safe without making it not C++ anymore. Do you consider D to be a derivative of C++? I don't. They have a near perfect C++ interface. D can even catch C++ exceptions. It's pretty sweet. You can hear about the black magic Andrei used to get that to work here: http://cppcast.com/2015/10/andrei-alexandrescu/ http://cppcast.com/2015/10/andrei-alexandrescu/ Side note: I'm actually thinking the Rust and C++ comparison misses the mark. First of all, C++ cannot be obsoleted by rust, it's economically impossible. Secondly, I don't even think they compete in the same domain space. Rust is actually lower level than C++, in that it does lower level stuff in a more natural way. It's C, that Rust makes obsolete; which is something C++ totally failed to do (because of it's RTTI, exceptions, and other runtime features -- all things you and the rest of the Rust team intelligently scrapped). After trying embedded Rust, I'm completely done using C (and the C parts of C++). IMO the advantages C++ still has over Rust are: - libraries, libraries, libraries - C++ has so many great libraries - *writing* C++ libraries with SFINAE sugar is the bees knees. - much better support and tooling, but this is for sure a temporary advantage. - template meta-programming feels like a different language, it's dynamic, functional, and the difference is refreshing. I like the mental switch you have to do to go from writing a C++ template to writing a C++ model. - as much as header files suck, they let you skim an API much more easily than Rust or Swift. - performant, memory safe data structures: For example, it's trivial to write a low overhead pointer that can't dangle, throws an exception on nullptr deference, and that safely points to an object it doesn't own (even if that object is its owner). With this and a unique_ptr composed with similar safety mechanisms you now have the primitives needed to write any data structures or algorithm so that it is protected from undefined and unsafe behavior, yet remains performant. This solution has significantly less overhead than using reference counted pointers like shared_ptr derivatives or Rc. The performance tradeoff over using raw pointers is minuscule and totally dwarfed by the gain in safety guarantees. From what I've observed, you can't do this in Rust, if you try to write a doubly linked list you either have to use C-pointers that can dangle inside unsafe blocks, or eat the Rc overhead. EDIT: How could I forget to mention the glory that is constexpr? Advantages of Rust over C++ (again, IMO): - the correct defaults (aka opposite of C's insanity) - best C++11 features built in and defaulted (move semantics, unique_ptr is Box<T>, Rc is shared_ptr etc..) - Bad ass embedded capabilities. You don't nearly feel as crippled like you do in C++ without the STL. - the safety guarantees are real, and they're awesome - move semantics into closures looks so goddamn elegant. I love it - inline assembly doesn't feel like a hack - modules and cargo rock - secretly and surprisingly similar to ruby in a lot of places :) - it wants you to think functionally, and unlike Swift, it means it. This is a good thing.

dikaiosune 11y ago
> as much as header files suck, they let you skim an API much more easily than Rust or Swift Just to reply to this individual point, rustdoc is fantastic. Personally I much prefer having an HTML-rendered "header file" for a crate's API. Even if they aren't hosted, it's trivial to generate one yourself using `cargo doc`. To be maximally useful, the author needs to have made doc comments, but at least there's a standard format for that, and you might not have anything like that in a header file anyways.
- autoreleasepool 11y ago
  Super cool. I like everything they have going on with the triple slash comments too. Now all we need is an IDE that can get those docs up in a key stroke!
- heinrich5991 11y ago
  You can try crates.fyi for hosted docs, e.g. https://crates.fyi/crates/itertools/0.4.7/ https://crates.fyi/crates/itertools/0.4.7/
pcwalton 11y ago
> Do you consider D to be a derivative of C++? I don't. They have a near perfect C++ interface. D can even catch C++ exceptions. It's not a near-perfect C++ interface, because D can't instantiate C++ templates on its own. > First of all, C++ cannot be obsoleted by rust, it's economically impossible. Rust can make C++ obsolete in a technical sense. But I agree of course that C++ is immortal. > For example, it's trivial to write a low overhead pointer that can't dangle, throws an exception on nullptr deference, and that safely points to an object it doesn't own (even if that object is its owner) Wrong. You can't write a pointer that can't dangle in C++. Think iterator invalidation, "this" invalidation, etc. I've given innumerable code samples to prove this in the past. It's hard to argue about this abstractly, so let's do this. If you give me the C++ code for a smart pointer that you claim is safe, I will construct you a code example showing use-after-free using that pointer. > From what I've observed, you can't do this in Rust, if you try to write a doubly linked list you either have to use C-pointers that can dangle inside unsafe blocks, or eat the Rc overhead. Yes, you can't do this in Rust. You also can't do it in C++. C++ is good at making you think that you're using pointers that can't dangle, as evidenced by posts like yours. It's not good at actually preventing things like use-after-free. > - template meta-programming feels like a different language, it's dynamic, functional, and the difference is refreshing. I like the mental switch you have to do to go from writing a C++ template to writing a C++ model. I much prefer the static approach of Rust's generics to the untyped templates of C++--the fact that templates feel like a different language is a disadvantage in my view--but this is a huge tradeoff and it largely comes down to taste. This is unlike the memory safety guarantees of Rust pointers, which are not a matter of taste; safety is a formal property that C++ references simply do not satisfy and cannot satisfy no matter what.

dikaiosune 11y ago

> as much as header files suck, they let you skim an API much more easily than Rust or Swift Just to reply to this individual point, rustdoc is fantastic. Personally I much prefer having an HTML-rendered "header file" for a crate's API. Even if they aren't hosted, it's trivial to generate one yourself using `cargo doc`. To be maximally useful, the author needs to have made doc comments, but at least there's a standard format for that, and you might not have anything like that in a header file anyways.

autoreleasepool 11y ago
Super cool. I like everything they have going on with the triple slash comments too. Now all we need is an IDE that can get those docs up in a key stroke!
heinrich5991 11y ago
You can try crates.fyi for hosted docs, e.g. https://crates.fyi/crates/itertools/0.4.7/ https://crates.fyi/crates/itertools/0.4.7/

pcwalton 11y ago

> Do you consider D to be a derivative of C++? I don't. They have a near perfect C++ interface. D can even catch C++ exceptions. It's not a near-perfect C++ interface, because D can't instantiate C++ templates on its own. > First of all, C++ cannot be obsoleted by rust, it's economically impossible. Rust can make C++ obsolete in a technical sense. But I agree of course that C++ is immortal. > For example, it's trivial to write a low overhead pointer that can't dangle, throws an exception on nullptr deference, and that safely points to an object it doesn't own (even if that object is its owner) Wrong. You can't write a pointer that can't dangle in C++. Think iterator invalidation, "this" invalidation, etc. I've given innumerable code samples to prove this in the past. It's hard to argue about this abstractly, so let's do this. If you give me the C++ code for a smart pointer that you claim is safe, I will construct you a code example showing use-after-free using that pointer. > From what I've observed, you can't do this in Rust, if you try to write a doubly linked list you either have to use C-pointers that can dangle inside unsafe blocks, or eat the Rc overhead. Yes, you can't do this in Rust. You also can't do it in C++. C++ is good at making you think that you're using pointers that can't dangle, as evidenced by posts like yours. It's not good at actually preventing things like use-after-free. > - template meta-programming feels like a different language, it's dynamic, functional, and the difference is refreshing. I like the mental switch you have to do to go from writing a C++ template to writing a C++ model. I much prefer the static approach of Rust's generics to the untyped templates of C++--the fact that templates feel like a different language is a disadvantage in my view--but this is a huge tradeoff and it largely comes down to taste. This is unlike the memory safety guarantees of Rust pointers, which are not a matter of taste; safety is a formal property that C++ references simply do not satisfy and cannot satisfy no matter what.