Why RAII rocks

by jjuhl • 11 years ago

40 62 11 years ago

kuon• 11 years ago

Isn't that similar to ARC in Objective-C?

mcphage• 11 years ago

ARC is (almost) purely automatic. You write your code however, and then a code analyzer goes through it to figure out where to put the memory management calls. (Also I'm pretty sure ARC still just does reference counting).

Joky• 11 years ago

ARC stands for Automatic Reference Counting: http://en.wikipedia.org/wiki/Automatic_Reference_Counting

pixelglow• 11 years ago

Essentially, yes.

In ARC, all strong pointers may have multiple owners. In C++11 RAII, the typical, defining use is for single owners (std::unique_ptr) but multiple owners are supported too (std::shared_ptr).

In ARC, local pointers may be reclaimed before their scope ends, if the compiler determines no further use of the pointer. In C++11 RAII, all such resources are reclaimed only at scope end.

ARC is not exception-safe by default, you have to compile with -fobjc-arc-exceptions to make it exception safe; however Apple standards have been moving away from using exceptions for recoverable conditions for some time now. C++11 RAII is of course exception-safe by default, it's one of the rationales behind the technique.

zwieback• 11 years ago

I was surprised how little I missed manual memory management when I switched from C++ to C# for everyday work.

RAII is something I do miss, though, even after years of C# I still feel lifetime management of objects is awkward.

tonyedgecombe• 11 years ago

For unmanaged resources using provides almost the same thing, the only downside I can see is it means yet more nesting.

cbsmith• 11 years ago

The other downside is you aren't as cleanly encapsulating the resource management logic.

MaulingMonkey3• 11 years ago

You can forget to write a using statement. In C++ you can omit your destructor entirely if all the members are already RAII classes, whereas in C# you still need to write a .Dispose() method.

Memory management is by and far the vast majority of resource management in C++ for me, which C# takes care of with garbage collection - so I don't miss RAII too much in C#. But if you tried to give me a C++ with using blocks but no RAII (read: you gave me C) I'd scream.

RAII is no panacea[1] - I'd say C#'s manual resource burden without RAII is still less than C++'s with RAII. Which is why I don't miss it too much. But it'd still be a nice addition. And I missed it dearly during my initial adoption of C#.

[1] e.g. in C++, you still have to worry about reference cycles, implementing the RAII constructs in the first place if existing ones aren't suitable, ensuring parents are kept in scope while referencing children, etc..

maxxxxx• 11 years ago

I think the omission of deterministic destructors is one of the biggest mistakes the C# designers made. The Dispose pattern feels like a band aid.

okasaki• 11 years ago

Why would you heap allocate something that you're deleting in the same function? Isn't there some equivalent length example that isn't so contrived?

EpicEng3• 11 years ago

There are numerous cases when one would do exactly that, which all boil down to "this thing is too big for stack allocation." Ever done any image processing?

mkale• 11 years ago

In addition, RAII is useful for more than just memory [de]allocation: database connections, resource handles, anything that you have to get/create and then cleanup/release.

bmm6o2• 11 years ago

Even in cases like that it's uncommon for the object to actually take up a lot of stack space. Since member variable's sizes have to be known at compile time it only applies to fixed-size (or parametrized) buffers.

TheCoelacanth• 11 years ago

There's also such a thing as move constructors, so that you can pass ownership to somewhere else and have it be deleted there.

For instance,

  std::unique_ptr<X> f () {
    return std::make_unique<X>();
  }

  void h (std::unique_ptr<X> x) {
    x->doSomething();
    // x is released after this function returns
  }

  void g () {
    auto x = f();
    h(std::move(x));
  }

santaclaus• 11 years ago

Love me some RAII. Also, why is C++ chock full of such opaque acronyms? RAII and SFINAE come to mind.

wololongong• 11 years ago

More: NRVO, Pimpl, SBRM, EBO, NVI, ODR, CRTP, STL, RTTI, TMP.

I've been using C++ for the past year at work. It's an absolute nightmare to learn.

stinos2• 11 years ago

SBRM, EBO, NVI, ODR, TMP -> care to explain those?

Anyway it does prove your point: have been using c++ way longer than you and these don't immediately ring a bell. Always more to learn! (or at least, always more super subtle details you'll only encounter once in a lifetime)

jjuhl2• 11 years ago

A year? That's nothing. Personally I'd consider anyone with less than 5 years of professional C++ experience a newbie. It's a complex language, it takes years to learn it well.

EliRivers2• 11 years ago

It's old, and it was created and sharpened by old people with Unix smudges on their fingers. This is not so much a good answer, as an excuse to indulge myself and listen to Stephenson for a moment.

The file systems of Unix machines all have the same general structure. On your flimsy operating systems, you can create directories (folders) and give them names like Frodo or My Stuff and put them pretty much anywhere you like. But under Unix the highest level--the root--of the filesystem is always designated with the single character "/" and it always contains the same set of top-level directories:

/usr /etc /var /bin /proc /boot /home /root /sbin /dev /lib /tmp

and each of these directories typically has its own distinct structure of subdirectories. Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river.

fla• 11 years ago

Long names get worn down to three-letter nubbins, like stones smoothed by a river.

Except when they don't ;)

alexnewman• 11 years ago

Rust is the answer. C++ is just soo legacy.

jjuhl2• 11 years ago

So what? Sure, rust is the new thing, node.js is the new thing, forget about SQL since NoSQL is the current thing. Etc etc, Bla bla bla. I hate this "let's chase every new thing and everything old is shit" attitude. C++ may be old but it does a great job at what it is targeted for (just like Fortran and many other "old" things). I'd really wish more people would stop chasing "new shiney" and just get work done. C++ may be complicated and old, but it gets work done.

Old, complicated and legacy does not equal bad.

nightski2• 11 years ago

It's also caused billions of dollars in damage. Hell, even just null pointers. Saying it does a great job is very generous. Even if it is the best language for low level work, it is still barely acceptable.

We should strive for advancement and progress in our field. There is a large difference between this and chasing the latest fad JS framework.

Unless you are saying that programming is a solved problem and C++ is about as advanced as we'll ever get.

EliRivers2• 11 years ago

Rust is the answer to a different question.

dicroce• 11 years ago

Does your language have mutexes and exceptions? You NEED RAII...

st3fan2• 11 years ago

Welcome to 2015.

KeytarHero5• 11 years ago

Yes, of course RAII is much shorter than a contrived example designed to be as long as possible. Here's a much shorter version:

    int unsafe2()
    {
        A* a = new A;
        int retval = 0;
    
        if (a->f())
        {
            B* b = new B;
    
            if (b->f())
                retval = b->g();
            else
                retval = a->g();
    
            delete b;
        }
    
        delete a;
        return retval;
    }

I agree that RAII is a good thing, but can we please avoid straw-man examples?

WizzleKake• 11 years ago

Why not just put a and b on the stack then? ;)

Bjarne says, "Code that creates an object using new and then deletes it at the end of the same scope is ugly, error-prone, and inefficient."

KeytarHero5• 11 years ago

Because it's an example of allocating things on the heap. You could also say the same about the "good" RAII version shown - but then there wouldn't be much point to the article, would there?

lumpypua• 11 years ago

How does this version handle exceptions?

KeytarHero5• 11 years ago

It doesn't. Just like the example it replaces.

I'm not saying this is the best way to write this code - there are several reasons RAII is better. But in this case, "look how messy non-RAII code is!" isn't the reason.

Devid20142• 11 years ago

This code work with assertion that constructors of A and B will never throw !

Devid20142• 11 years ago

Do you want to tell that this is correct and bug free code ? This is a example how to create lot of Memory Leaks.

KeytarHero5• 11 years ago

It's certainly not bug free. But that's not the point. All I did was rewrite that example with half as much code. The point of that example seems to be "look how much less code RAII takes!" and I'm just trying to show that, although you should use RAII, that's not the reason why.

fiveoak• 11 years ago

Won't this leak A if B's constructor throws an exception?

jasode• 11 years ago

I think 3 responses here have misinterpreted what you're illustrating. (e.g. "won't that leak?!?!")

KeytarHero could have wrote: "Here's a much shorter more realistic version of new/delete code that will have problems such as leakage after exceptions"

Since he didn't make that explicit, 3 replies seem to have misinterpreted the post as: "Here's a much shorter version that won't leak and doesn't need RAII"

Basically, his example is supposed to be "wrong" but it's a shorter version of "wrong".

KeytarHero5• 11 years ago

Exactly. Thanks.

Why RAII rocks

Related Stories