Quote:
Originally Posted by
Elkvis
I think with optimizations enabled, the get(), operator* and operator-> are likely to be inlined, so they become as fast as raw pointers.
Yet somehow the same is not possible with the Rust smart pointers?
Quote:
This may be helpful, but it does introduce some overhead, no matter how efficient you try to make it.
How so? If it is handled at compile-time then it wouldn't need to be checked at runtime.
Quote:
This is a relatively small concern. Plenty of languages have a standard ABI. It doesn't make them great languages.
Having a standard ABI doesn't make a language great, not having a standard ABI certainly doesn't either. Which is prefferable?
Quote:
I fail to understand how this is a good thing. How do you modify a variable passed by reference?
Immutability is a cornerstone of the functional programming philosophy.
Immutable objects are simpler to reason about since you can make assumptions about variables and parameters that could not otherwise be made.
Immutable objects are inherently thread-safe.
They can result in a reduction of memory usage since identical values can reference the same piece of memory. Copying also becomes a simple matter of copying a reference/pointer.
If a variable needs to be changed it has to be declared mutable, in Rust passing it by reference implies transfering ownership of the variable from the caller to the callee. That's my impression of how it works, i'm no good at Rust yet (and i'm not going to be until the language is in a stable state) so i might be wrong.
Quote:
I'd consider that a bad thing. No automatic promotion of int to long? No conversion of any pointer to void*? This seems like a recipe for programmer headaches. [....] Never? I realize that using RTTI and dynamic_cast can be a sign of poorly-designed code, but sometimes it is actually necessary, and if there's no mechanism to achieve that, then this language is clearly deficient.
As you say, sometimes doing these unsafe things are necessary. In Rust you can wrap any piece of code in an 'unsafe' block, which pretty much turns the language into plain C in the sense that you can do whatever you like, but you'd better be sure you know what you're doing.
Quote:
No need to start hurling insults. C++ has gotten much better with the last update (C++11), and promises to improve even more with the next minor update. This is akin to saying "the first automobile was slow, noisy, and inefficient, so let's stop making cars, and make something else."
On the contrary? Let's keep making new cars that improve upon previous models! Elysia is the one making the argument that we already have something that works, so why bother improving upon it. No insult was offered, i think all developers -myself included- take a conservative stance on new approaches and technologies from time to time and often that is not a bad thing, but sometimes it can be.
Quote:
Every system that supports concurrency has the potential for race conditions. It is a rather immutable law of concurrent programming.
Thats fine, but then some systems are more prone to race conditions than others and i think C is one of the worst languages in this regard.
Quote:
C++ has made progress in this area. They added tons of thread support features in C++11. No language feature or library can completely prevent race conditions. The programmer is still responsible for writing code that behaves as expected.
Hey, i'm not the one that made the argument that this is a non-issue.