3 ms·

> all of the programs studied were written in C or C++, and that this study predates C++11. Moving to C++11 and using atomics and scoped locks would probably ch

> all of the programs studied were written in C or C++, and that this study predates C++11. Moving to C++11 and using atomics and scoped locks would probably change the numbers substantially I keep seeing this claim, "C++ is better now!" Does anyone have any experience that really defends this claim? One of the reasons that I've become so enthralled with Rust is that it's adopted a memory access system which aligns with everything that I've learned over my career in distributed systems: -all data const/final by default -No nulls, fully initialized structs -semantics that require the developer to adopt good practices in accessing memory across threads I can go on, but it's already obvious to me that Rust is a huge leap forward in terms of threading and the guarantees it makes. I left C++ a long time ago, and it happened to coincide with a atomic increment bug/memory leak that took me 2 weeks to track down in the STL String library. This was back in 2000, early days of multiprocessor x86. This exact thing is solvable with the new C++ atomic support, but does it guarantee that you'll use it across threads like Rust?

nickpsecurity 10y ago
I only know one form of safe C++ outside MISRA rules: Ironclad C++. https://www.cis.upenn.edu/~stevez/papers/DENO+13.pdf https://www.cis.upenn.edu/~stevez/papers/DENO+13.pdf Its only drawback is it can't catch all use-after-free. So, they add a heap-precise, conservative GC for that. There's quite a few techniques in the literature for detecting use-after-free. Add one of those to eliminate the GC and... what's left at that point?
helmut_hed 10y ago
It is probably easier to write correct concurrent code now, thanks to the new features he mentions. However, as always plenty of rope is provided, and the old programs are still valid (and have the same semantics). I couldn't say how it compares to Rust, but "better now" seems pretty accurate.
MaulingMonkey 10y ago
> This exact thing is solvable with the new C++ atomic support, but does it guarantee that you'll use it across threads like Rust? No. That said, stuff like Clang's thread safety annotations can help: http://clang.llvm.org/docs/ThreadSafetyAnalysis.html http://clang.llvm.org/docs/ThreadSafetyAnalysis.html > I left C++ a long time ago Lucky ;). C++, and all the supporting tooling around it, is better than it used to be, make no mistake. But C++ is still no Rust - make no mistake on that either.

nickpsecurity 10y ago

I only know one form of safe C++ outside MISRA rules: Ironclad C++. https://www.cis.upenn.edu/~stevez/papers/DENO+13.pdf https://www.cis.upenn.edu/~stevez/papers/DENO+13.pdf Its only drawback is it can't catch all use-after-free. So, they add a heap-precise, conservative GC for that. There's quite a few techniques in the literature for detecting use-after-free. Add one of those to eliminate the GC and... what's left at that point?

helmut_hed 10y ago

It is probably easier to write correct concurrent code now, thanks to the new features he mentions. However, as always plenty of rope is provided, and the old programs are still valid (and have the same semantics). I couldn't say how it compares to Rust, but "better now" seems pretty accurate.

MaulingMonkey 10y ago

> This exact thing is solvable with the new C++ atomic support, but does it guarantee that you'll use it across threads like Rust? No. That said, stuff like Clang's thread safety annotations can help: http://clang.llvm.org/docs/ThreadSafetyAnalysis.html http://clang.llvm.org/docs/ThreadSafetyAnalysis.html > I left C++ a long time ago Lucky ;). C++, and all the supporting tooling around it, is better than it used to be, make no mistake. But C++ is still no Rust - make no mistake on that either.