Doesn't using C++ RAII eliminate some of that? Or you use raw pointers often?
Re:Three months of Rust
by the_why_of_y on Saturday June 06, 2015 @06:59AM
(#9670382)
Anything in C++ generally comes with its very own footgun.
The one for RAII looks like this:
{
mutex_guard(some_mutex);
foo();
}
I don't understand the example. Why would it do that and not unlock after foo()?
Re:Three months of Rust
by the_why_of_y on Saturday June 06, 2015 @12:17PM
(#9671284)
The following code would do the right thing; see if you can spot the difference, and think about whether you would catch that in code review (g++/clang++/visualc++ won't warn about it).
{
mutex_guard guard(some_mutex);
foo();
}Ah, now I see it and it makes sense.
The answer to the code review question is obvious. I didn't see the error even though I was told what happens.
I guess you meant std::lock_guard.
Anyway, the first example creates a temporary object which doesn't lock anything since it will be destroyed right away because it's an rvalue (not sure why would anyone do that for locking, unless not knowingly). The second example creates a proper guard which lives until the end of the scope.
Re:Three months of Rust
by steveklabnik on Friday June 05, 2015 @02:44PM
(#9667231)
Rust uses RAII too. But borrowing makes it much more powerful.
"Despite the restrictions of the type system, I am more productive in Rust than I am in either Javascript or Haskell. It manages somehow to hit a sweet spot between safety and ease of use."
When I toyed with Rust last year (so, I'll admit my knowledge is outdated, I need to refresh it), I had a pleasant experience on the productivity side. The big reward for me, coming from C/C++, is that my programs simply worked as expected once I was past fixing all the errors the compiler reported. That usually doesn't happen this way in C/C++, where you spend additional time fixing whatever null deref and whatnot that break your program in subtle ways at runtime.