9 ms·
I find that most of the arguments given against C++ (such as memory leaks or dangling pointers) can be avoided by using Modern C++ features, like never allocati
by ericpts 10y ago
I find that most of the arguments given against C++ (such as memory leaks or dangling pointers) can be avoided by using Modern C++ features, like never allocating memory with new but using std::make_unique or avoiding null pointers with not_null from GSL or std::optional.
- burntsushi 10y agoThis seems to be about inline with some criticism this guide got on /r/rust: https://www.reddit.com/r/rust/comments/5qq7ty/a_guide_to_porting_c_c_to_rust/dd1wrh1/ https://www.reddit.com/r/rust/comments/5qq7ty/a_guide_to_por... Specifically, I think this work should be regarded as a "work in progress." :-)
- Tesl 10y agoDon't think there is a std::optional yet, have to go with boost::optional. I think you're point is completely correct though. You can write very safe code today using modern C++ features.
- vvanders 10y agoThose things help but it's still possible to return a pointer to an inner part of an allocation(say an element in a vector) and then have the vector go out of scope. Rust is much more robust about catching those cases and verifying that you don't have objects outliving their references.
- geezerjay 10y ago> Those things help but it's still possible to return a pointer to an inner part of an allocation(say an element in a vector) and then have the vector go out of scope. That's something that the programmer needs to specifically ask for, and I'm not aware of any C++ compiler which doesn't throw a bunch of warnings regarding an object's scope and lifetime. That means your point boils down to arguing that if a programmer really wants to, he can still shoot himself in the proverbial foot by writing C++ code, but in order for that to happen he needs to have a death wish and intentionally avoid all warnings and safe practices to begin with.
- catnaroek 10y agoI don't see any C++ compilers raising warnings because you use shared mutable objects without grabbing the right lock first.
- MaulingMonkey 10y agoCheck out https://clang.llvm.org/docs/ThreadSafetyAnalysis.html https://clang.llvm.org/docs/ThreadSafetyAnalysis.html Requires manual annotation and isn't nearly as systematic and comprehensive as the Rust compiler, but I've found threading bugs with this in existing code that I was about to modify.
- catnaroek 10y agoAh, this is very nice.
- vvanders 10y agoI've seen variations of the below in just about every codebase I've worked in. Just ran it through GCC, Clang and MSCV(W4) with no warnings ;). #include <vector> int main() { struct Foo { int bar; }; Foo* bar; { std::vector<Foo> foos; foos.emplace_back(Foo{1}); foos.emplace_back(Foo{2}); bar = &foos[1]; } bar->bar = 2; }
- Const-me 10y agoTrue, found similar bugs in my own C++ code, and I read and fix all warnings. However, I never spent more than 10 minutes fixing that. Debug version of MS C runtime fills freed heap memory with a magic number 0xFEEEFEEE. You’ll get exception in runtime, and you’ll immediately have the idea what’s wrong with the code.
- vvanders 10y agoYeah, this is a trivial example. It becomes trickier when you start dealing with things across library boundaries where you might not have source code. I've seen 5 minute fixes and things that took weeks to track down(yay for non deterministic repros).
- adrianN 10y agoI think the difference is that in C++ the programmer has to be careful, whereas in Rust the compiler makes sure that only safe stuff happens (outside of unsafe blocks, that is).
- bluejekyll 10y agoIs there a compiler option in C++ to only allow this safe variant of the language to be used? I find this argument to be a false comparison to the features of Rust, especially on dataraces, etc. I've never seen a 100% clean, modern C++ codebase. If you know of one, could you point us to it? Also, this is just me, given experience writing code in C++ and Rust, I find Rust to be a more ergonomic language (YMMV).
- deleted 10y ago[deleted]
- ericpts 10y agoYou can try to use some extra tools that clang provides, such as the static analyzer ( https://clang-analyzer.llvm.org/ https://clang-analyzer.llvm.org/ ) or tidy ( http://clang.llvm.org/extra/clang-tidy/ http://clang.llvm.org/extra/clang-tidy/ ) with checks like the cppcoreguidelines.
- pjmlp 10y agoAnd what do you do when clang isn't an option, due to customer, target hardware, OS or even language extensions? This is what I mean in another thread about outsourcing safety.
- otabdeveloper 10y ago> And what do you do when clang isn't an option, due to customer, target hardware, OS or even language extensions? Then you cannot use Rust and must settle for lack of safety. (A profoundly silly question -- if modern C++ is not an option for whatever reason, then Rust is doubly so.)
- pjmlp 10y agoOnly when people mix languages with implementations. Just because the only existing Rust compiler uses LLVM, it doesn't mean another implementations will not surface. So hypothetical the OS not targeted by clang, can still have a Rust compiler on the OS SDK, offering all safety guarantees from Rust. For example, there are OSes and hardware architectures not supported by clang that have Ada and even Java AOT compilers.
- sidlls 10y agoA good bit of "legacy" C++ features are used in a number of applications that articles lists as "mission critical" perfectly well, too. Some of the arguments along memory safety, to my eyes, appear to be bordering on the hysterical. There are many legitimate criticisms of C++ ("legacy" or "modern"), including some related to memory management and safety. That hasn't impeded its use (its safe use) in a number of applications. As a long-time user of C++, I find Rust to be more appealing in many ways. I don't think "C++ is dangerous" is a good approach to advertising Rust to the C++ community.
- pjmlp 10y agoI agree, those of us that care about safety have moved to other languages and only come back to C++ when we need the features C++ excels at. A good way to see what C++ community cares about, in order to make Rust appealing to them, is to see the work from SG14 (games and HPC) on ANSI C++. That is the type of crowd that Rust should target, and they care about performance without belts above all.
- sidlls 10y agoI care about safety and recognize that I can achieve it in C++. These claims that it's not possible, prohibitively difficult and so on are basically unsupported assertions. They're exactly the kind of argument that people who would like to see Rust gain traction shouldn't be making, because they impugn the credibility of the person making them.
- pjmlp 10y agoI can also achieve it in C++, and do it on my personal projects. Working with teams on typical enterprise environments is another total different story. Just last week I had to do an acceptance review of a C# application for a customer, I surely wouldn't want those devs touching C++ as well.
- quicknir 10y agoThe over emphasis on memory safety makes for a very weak pitch. I only spend a tiny fraction of my time on memory related issues. Most bugs are simply not memory related. If you're writing Firefox or SSL, a memory mistake may be a vulnerability and a serious issue. In games, hpc, hft, etc, a memory mistake is almost always just another bug. Would be great instead to see more examples of how e.g. destructive move in That allows generating better assembly.
- w8rbt 10y agoAgreed. C++ is far safer than C and just as safe as rust. If the rust crowd was really serious about convincing C and C++ devs to move to rust, then they ought to have made the syntax identical (or at least much closer) to C than it currently is. That's the primary reason Java took off. If you know C, you can write working C++ and Java programs straight away. For rust, we have to stop and relearn how to apply the logic (thus slow/no adoption). And, I'm really sick of the constant HN sales pitches for rust. Make the transition easy and rust will stand on its own/sell itself (or not).
- catnaroek 10y agoWhen did C++ add a language-enforced mechanism for ruling out dangling references, data races, uses after `std::move()`, etc.?
- pjmlp 10y agoThey didn't, but had Java and .NET been AOT compiled to native code since the beginning and you would see less C and C++ code around. So now that even them have got the AOT memo, and Go and Swift also exist, I think the 2017's focus on productivity is very important. The work done in the borrow check is incredibly and has already influenced decisions on the D, Swift and C++ communities. Yet they all agree that they don't want to make it as hard as Rust. Chris Lattner mentioned the feature in Swift should be exposed to expert programmers doing kernel and driver related programming. I imagine Rust's image should be better than a language from experts for experts.
- catnaroek 10y ago> I think the 2017's focus on productivity is very important. If the yardstick of “productivity” is how fast you can write incorrect programs, I'm not terribly interested in “productivity”. I'm sick of being a defensive user, having to refrain from probing how systems work in undocumented and likely unforeseen scenarios, lest I completely break them in unrecoverable ways. I'd rather see an axiomatic semantics for unsafe Rust, so that I can formally prove that my unsafe Rust code doesn't break safe Rust's integrity guarantees. > So now that even them have got the AOT memo, and Go and Swift also exist Support for running in an unmanaged environment is a red herring. If you want to manage resources correctly, you have to care about ownership and lifetimes, regardless of whether you are doing systems programming (user programs manage resources too), need AOT compilation (JIT-compiled programs manage resources too) or need a GC-less environment (GC doesn't work for resources that need to be reclaimed eager and deterministically). > I imagine Rust's image should be better than a language from experts for experts. I have no idea. I'm not a member of any community (not a “Rustacean”, not a “Haskeller”, not anything), and I have no personal interest (financial or emotional) in any specific technology becoming popular. I only care about technical facts. Are facts for experts only?
- catnaroek 10y agoHow do you prevent an object from being used after you `std::move()` it? --- Reply to moomin: The type system's intrinsic expressiveness limits the kinds of verification tricks you can “teach” it.
- moomin 10y agoYou teach the compiler to treat it as an error. The point being that this isn't practically available in C++ and is mandatory in Rust.
- pjmlp 10y agoIt only works if the whole company buys into it, including only linking against libraries whose authors also adopt those practices. What I have learned since learning it in 1993, using it including teaching the language to first year students, is that any safety feature that isn't imposed by the language instead outsourced to best practices or external tools tends to be ignored by the majority.
- maxxxxx 10y agoWhat you are saying is probably true but it's also sad. That's why we end up with languages without preprocessor or multiple inheritance because some people misuse these extremely useful features.
- iopq 10y agoYou don't need a preprocessor. Lisp-style macros are much easier to use due to hygiene and in general not being text-based.
- jeffdavis 10y agoAlso, if you need to change all of your APIs to work with unique pointers, then it's effectively a rewrite anyway.
- eximius 10y agoAbsolutely. But you still CAN make these mistakes, so people will. No one claims that it is literally impossible to write safe C++, just really damn hard and that you'll probably fail given a sufficiently large codebase. Rust makes it impossible for some set of errors.