151–160 of 231 posts
Earlier quoted context omitted.
There's no such thing as a "C/C++".
Alternatively, you could have C/C++ as a third, discrete category somewhere in the middle of the C C++ spectrum. For people who like namespaces, or overloading arithmetic operators for mathy vector/matrix/etc stuff in order to make the code more readable.
Earlier quoted context omitted.
Yep, on my domain it has been Java and .NET.
Java and .NET are Safe..... O.o Edit: For the uninitiated, I am baffled by the fact that people think Java and .NET are memory safe. Also if you meant that Java and .NET should be replaced by something memory safe.. I am absolutely for it. :)
Not only they have automatic memory management, they have an industry standard memory model for hardware access, adopted by C and C++ standards, used as inspiration for std:atomic on CUDA.
While you keep being baffled, where is Rust's memory model specification?
Earlier quoted context omitted.
At least in what concerns C++ there are several ways to try its safety instead of bearing the cost of a full rewrite. Using standard library types, actually integrating sanitizers into CI, enable bounds checking (even on release builds) and above all avoid C style coding. Naturally this doesn't work out for third party libraries that one doesn't have control over. So from a business point of view it boils down how mu…
You can write safe code in C++, but it requires you to go way out of your way and exercise constant vigilance, and it's not always obvious when you mess it up. This is the approach we've been trying for 20 years, and it generally hasn't worked well, because people are both flawed and lazy. This is the thing that's fundamentally different about Rust — it provides strong guarantees by default and requires you to specif…
Earlier quoted context omitted.
BTW there are garbage collectors for c++
Yep. C++/CLI, C++/CX, GC pluggable API introduced in C++11, C++ Builder VCL in ARC mode, Unreal C++ managed classes.
> at best, the temptation to RiiR is unproductive I think there are probably three cases here: (1) You have perfectly good software and your only motivation to rewrite is infatuation with how great Rust seems. In this case, yes, that's unproductive. (Infatuation-driven design is poor engineering and is a fairly widespread problem in the software industry.) (2) You already have other reasons to want to rewrite (design…
(4) You want to develop new components in rust, but it has to integrate with your existing components somehow.
Earlier quoted context omitted.
Yep, on my domain it has been Java and .NET.
Java and .NET are Safe..... O.o Edit: For the uninitiated, I am baffled by the fact that people think Java and .NET are memory safe. Also if you meant that Java and .NET should be replaced by something memory safe.. I am absolutely for it. :)
The author touched on the value of the original author, and this is something missing from the RiiR projects I've encountered. An open source project is more than just code. It's the community: the original authors and maintainers and their years of experience in that problem space. If you don't have a plan to move the community over to Rust (and the RiiR projects I've seen did not) you're (A) duplicating effort, (B)…
So maybe instead of "rewrite it in Rust", the answer is "build a new solution in Rust that meets the needs of a community of people who already use Rust".
This article is wonderful and I hope as a setup for second article, "How to Rewrite it in Rust"! > However at best, the temptation to RiiR is unproductive > A much better alternative is to reuse the original library and just publish a safe interface to it. Just as models are a lower dimensional representation of a more complex problem, [1] I have to re-iterate that there are no truth(ism)s in software and as in all e…
> But the biggest reason to rewrite it in Rust is safety. This is not a good reason if there are cheaper ways to get safety (at least for existing codebases). Indeed, there are sound static analysis tools (like TrustInSoft) that guarantee no undefined behaviour in C code. Using them is not completely free, and it may even require adding annotations to the code or even changing the code, but it does seem significantly…
Earlier quoted context omitted.
Java and .NET are Safe..... O.o Edit: For the uninitiated, I am baffled by the fact that people think Java and .NET are memory safe. Also if you meant that Java and .NET should be replaced by something memory safe.. I am absolutely for it. :)
More than Rust in multithreaded scenarios, actually. Not only they have automatic memory management, they have an industry standard memory model for hardware access, adopted by C and C++ standards, used as inspiration for std:atomic on CUDA. While you keep being baffled, where is Rust's memory model specification?
Just scroll up, I explicitly mentioned how it isn't. I just want to say, Java and C# isn't as safe as most people think.
Define industry standard, cause nothing points me towards industry standards actually being better than not industry standards.
Has everyone forgotten these http://cs.oswego.edu/pipermail/concurrency-interest/2017-Dec...
Nevertheless who knows I might not know anything, and I love being proved wrong when it makes most of the world a safer place (quite literally)... :P
Earlier quoted context omitted.
looks like you are arguing what "sparingly" means in that context because the rest of the sentence is totally valid. Stack and Heap allocation in C serve different purposes and there's really no rule of thumb to choose one and there's not even one case more frequent than the other. Allocate objects in the stack, it's faster. Unless you need a reference in a function in another context. Or it's too big. Or you're goin…
There's pretty easy rules: stack unless it needs to outlive the current scope, or is very large. That covers 99% of cases.