Understanding the meaning of the term and the concept - RAII (Resource Acquisition is Initialization)
Asked Answered
M

10

121

Could you C++ developers please give us a good description of what RAII is, why it is important, and whether or not it might have any relevance to other languages?

I do know a little bit. I believe it stands for "Resource Acquisition is Initialization". However, that name doesn't jive with my (possibly incorrect) understanding of what RAII is: I get the impression that RAII is a way of initializing objects on the stack such that, when those variables go out of scope, the destructors will automatically be called causing the resources to be cleaned up.

So why isn't that called "using the stack to trigger cleanup" (UTSTTC:)? How do you get from there to "RAII"?

And how can you make something on the stack that will cause the cleanup of something that lives on the heap? Also, are there cases where you can't use RAII? Do you ever find yourself wishing for garbage collection? At least a garbage collector you could use for some objects while letting others be managed?

Thanks.

Maratha answered 3/4, 2009 at 5:21 Comment(13)
UTSTTC? I like it! It's a lot more intuitive than RAII. RAII is badly named, I doubt any C++ programmer would dispute that. But it's not easy to change. ;)Oliveolivegreen
Just FYI, there are freely available GC libraries out there for C++.Winze
Here's Stroustrup's view on the matter: groups.google.com/group/comp.lang.c++.moderated/msg/…Leonoraleonore
@sbi, that's a great link, thanks. Make that an answer and I'll vote it up.Maratha
@Charlie: It's not worth an answer, I'll leave it where it is. Thanks anyway, it took me a while to dig this out...Leonoraleonore
@sbi: Anyway, +1 on your comment just for the historical research. I believe having the author's (B. Stroustrup) viewpoint on a concept's name (RAII) is interesting enough to have its own answer.Birdseed
@paercebal: Historical research? Now you have made me feel very old. :( I was reading the whole thread, back then, and didn't even consider myself a C++ newbie!Leonoraleonore
@sbi: All the contrary! Most experienced C++ coders know the exact words behind the RAII acronym, and most among them know the signification of RAII evolved so much the words "Resource Acquisition Is Initialization" can be considered quite limiting when compared to the concept it applies on. But I guess few among them can find a reference from B. Stroustrup describing exactly that. I tried once to find this exact quote, and failed to produce it for a colleague. The +1 was for finding the reference and sharing it, nothing more, nothing less. And certainly not suggesting you being a newbie. :-)Birdseed
possible duplicate of Does C++ support 'finally' blocks? (And what's this 'RAII' I keep hearing about?)Epictetus
I see a lot of helpful info here that is not on the other question. So many of these attempts to "organize" are subtracting value.Maratha
+1, I was about to ask the same question, glad I'm not the only one who understand the concept but make no sense of the name. Seems it should have been called RAOI - Resource Acquisition On Initialization.Phototransistor
"And how can you make something on the stack that will cause the cleanup of something that lives on the heap?" -- What a strange question. By storing a pointer to the heap thing in the stack thing, of course. This no different from void* p = malloc(5); ... free(p) except that the free is in the object's destructor, which is called implicitly upon leaving scope.Testosterone
I would have called it something like Resource Access Equals Object Lifetime.Testosterone
M
145

So why isn't that called "using the stack to trigger cleanup" (UTSTTC:)?

RAII is telling you what to do: Acquire your resource in a constructor! I would add: one resource, one constructor. UTSTTC is just one application of that, RAII is much more.

Resource Management sucks. Here, resource is anything that needs cleanup after use. Studies of projects across many platforms show the majority of bugs are related to resource management - and it's particularly bad on Windows (due to the many types of objects and allocators).

In C++, resource management is particularly complicated due to the combination of exceptions and (C++ style) templates. For a peek under the hood, see GOTW8).


C++ guarantees that the destructor is called if and only if the constructor succeeded. Relying on that, RAII can solve many nasty problems the average programmer might not even be aware of. Here are a few examples beyond the "my local variables will be destroyed whenever I return".

Let us start with an overly simplistic FileHandle class employing RAII:

class FileHandle
{
    FILE* file;

public:

    explicit FileHandle(const char* name)
    {
        file = fopen(name);
        if (!file)
        {
            throw "MAYDAY! MAYDAY";
        }
    }

    ~FileHandle()
    {
        // The only reason we are checking the file pointer for validity
        // is because it might have been moved (see below).
        // It is NOT needed to check against a failed constructor,
        // because the destructor is NEVER executed when the constructor fails!
        if (file)
        {
            fclose(file);
        }
    }

    // The following technicalities can be skipped on the first read.
    // They are not crucial to understanding the basic idea of RAII.
    // However, if you plan to implement your own RAII classes,
    // it is absolutely essential that you read on :)



    // It does not make sense to copy a file handle,
    // hence we disallow the otherwise implicitly generated copy operations.

    FileHandle(const FileHandle&) = delete;
    FileHandle& operator=(const FileHandle&) = delete;



    // The following operations enable transfer of ownership
    // and require compiler support for rvalue references, a C++0x feature.
    // Essentially, a resource is "moved" from one object to another.

    FileHandle(FileHandle&& that)
    {
        file = that.file;
        that.file = 0;
    }

    FileHandle& operator=(FileHandle&& that)
    {
        file = that.file;
        that.file = 0;
        return *this;
    }
}

If construction fails (with an exception), no other member function - not even the destructor - gets called.

RAII avoids using objects in an invalid state. it already makes life easier before we even use the object.

Now, let us have a look at temporary objects:

void CopyFileData(FileHandle source, FileHandle dest);

void Foo()
{
    CopyFileData(FileHandle("C:\\source"), FileHandle("C:\\dest"));
}

There are three error cases to handled: no file can be opened, only one file can be opened, both files can be opened but copying the files failed. In a non-RAII implementation, Foo would have to handle all three cases explicitly.

RAII releases resources that were acquired, even when multiple resources are acquired within one statement.

Now, let us aggregate some objects:

class Logger
{
    FileHandle original, duplex;   // this logger can write to two files at once!

public:

    Logger(const char* filename1, const char* filename2)
    : original(filename1), duplex(filename2)
    {
        if (!filewrite_duplex(original, duplex, "New Session"))
            throw "Ugh damn!";
    }
}

The constructor of Logger will fail if original's constructor fails (because filename1 could not be opened), duplex's constructor fails (because filename2 could not be opened), or writing to the files inside Logger's constructor body fails. In any of these cases, Logger's destructor will not be called - so we cannot rely on Logger's destructor to release the files. But if original was constructed, its destructor will be called during cleanup of the Logger constructor.

RAII simplifies cleanup after partial construction.


Negative points:

Negative points? All problems can be solved with RAII and smart pointers ;-)

RAII is sometimes unwieldy when you need delayed acquisition, pushing aggregated objects onto the heap.
Imagine the Logger needs a SetTargetFile(const char* target). In that case, the handle, that still needs to be a member of Logger, needs to reside on the heap (e.g. in a smart pointer, to trigger the handle's destruction appropriately.)

I have never wished for garbage collection really. When I do C# I sometimes feel a moment of bliss that I just do not need to care, but much more I miss all the cool toys that can be created through deterministic destruction. (using IDisposable just does not cut it.)

I have had one particularly complex structure that might have benefited from GC, where "simple" smart pointers would cause circular references over multiple classes. We muddled through by carefully balancing strong and weak pointers, but anytime we want to change something, we have to study a big relationship chart. GC might have been better, but some of the components held resources that should be release ASAP.


A note on the FileHandle sample: It was not intended to be complete, just a sample - but turned out incorrect. Thanks Johannes Schaub for pointing out and FredOverflow for turning it into a correct C++0x solution. Over time, I've settled with the approach documented here.

Mcclenon answered 3/4, 2009 at 12:51 Comment(7)
+1 For pointing that GC and ASAP don't mesh. Doesn't hurt often but when it does it's not easy to diagnose :/Stoke
One sentence in particular that I overlooked on earlier reads. You said that "RAII" is telling you, "Acquire your resources inside constructors." That makes sense and is almost a word-for-word paraphrase of "RAII". Now I get it even better (I'd vote you up again if I could :)Maratha
One major advantage of GC is that a memory allocation framework can prevent the creation of dangling references in the absence of "unsafe" code (if "unsafe" code is allowed, of course, the framework can't prevent anything). GC is also often superior to RAII when dealing with shared immutable objects like strings which often have no clear owner and require no cleanup. It's unfortunate that more frameworks don't seek to combine GC and RAII, since most applications will have a mix of immutable objects (where GC would be best) and objects that need cleanup (where RAII is best).Philoprogenitive
@supercat: I generally like GC - but it works only for ressources the GC "understands". E.g. the .NET GC does not know the cost of COM objects. When simply creating and destroying them in a loop, it will happily let the application run into the ground regarding address space or virtual memory - whatever comes first - without even thinking of maybe doing a GC. --- furthermore, even in a perfectly GC'd environment, I still miss the power of deterministic destruction: you can apply the same pattern to other artificats, e.g. showing UI elements under certian conditions.Mcclenon
@peterchen: One thing I think is absent in a lot of OOP-related thinking is the concept of object ownership. Keeping track of ownership is often clearly necessary for objects with resources, but is also often necessary for mutable objects without resources. In general, objects should encapsulate their mutable state either in references to possibly-shared immutable objects, or in mutable objects of which they are the exclusive owner. Such exclusive ownership does not necessarily imply exclusive write access, but if Foo owns Bar, and Boz mutates it, ...Philoprogenitive
...it should be clear that Boz is mutating Bar as a means of updating the state of Foo, and not as a means of updating its own state. One of the nice things about C++ is that it has a much better concept of object ownership than Java and derivatives. It goes perhaps a little too far, precluding the possibility of creating full-fledged generic types at run-time, but having a clear distinction between a Thing, a *Thing, and a &Thing (or, for C++/CLI, a ^Thing), is better than having a loosy-goosy Thing reference type.Philoprogenitive
@Mcclenon that's not so much a problem with GC in the abstract as it is a problem with short-sighted GC implementations: it is not conceptually hard for a language to make GC pluggable much the way that a constructor and destructor in C++ make automatic stack frame management pluggable. Memory is just one kind of possible garbage. The key things are - what's the operation that needs to be hooked to count acquisitions of this resource? what's the cleanup logic for this resource? and what's the limit or logic for determining "pressure" to detect when collection can't be delayed any more?Berrie
B
45

There are excellent answers out there, so I just add some things forgotten.

0. RAII is about scopes

RAII is about both:

  1. acquiring a resource (no matter what resource) in the constructor, and un-acquiring it in the destructor.
  2. having the constructor executed when the variable is declared, and the destructor automatically executed when the variable goes out of scope.

Others already answered about that, so I won't elaborate.

1. When coding in Java or C#, you already use RAII...

MONSIEUR JOURDAIN: What! When I say, "Nicole, bring me my slippers, and give me my nightcap," that's prose?

PHILOSOPHY MASTER: Yes, Sir.

MONSIEUR JOURDAIN: For more than forty years I have been speaking prose without knowing anything about it, and I am much obliged to you for having taught me that.

— Molière: The Middle Class Gentleman, Act 2, Scene 4

As Monsieur Jourdain did with prose, C# and even Java people already use RAII, but in hidden ways. For example, the following Java code (which is written the same way in C# by replacing synchronized with lock):

void foo()
{
   // etc.

   synchronized(someObject)
   {
      // if something throws here, the lock on someObject will
      // be unlocked
   }
 
   // etc.
}

... is already using RAII: The mutex acquisition is done in the keyword (synchronized or lock), and the un-acquisition will be done when exiting the scope.

It's so natural in its notation it requires almost no explanation even for people who never heard about RAII.

The advantage C++ has over Java and C# here is that anything can be made using RAII. For example, there are no direct build-in equivalent of synchronized nor lock in C++, but we can still have them.

In C++, it would be written:

void foo()
{
   // etc.

   {
      Lock lock(someObject) ; // lock is an object of type Lock whose
                              // constructor acquires a mutex on
                              // someObject and whose destructor will
                              // un-acquire it 
   
      // if something throws here, the lock on someObject will
      // be unlocked
   }
 
   // etc.
}

which can be easily written as it would be in Java/C# (using C++ macros):

#define LOCK(mm_mutex) \
if(Lock lock{mm_mutex}) {} \
else

void foo()
{
   // etc.

   LOCK(someObject)
   {
      // if something throws here, the lock on someObject will
      // be unlocked
   }
 
   // etc.
}

2. RAII have alternate uses

WHITE RABBIT: [singing] I'm late / I'm late / For a very important date. / No time to say "Hello." / Goodbye. / I'm late, I'm late, I'm late.

— Alice in Wonderland (Disney version, 1951)

You know when the constructor will be called (at the object declaration), and you know when its corresponding destructor will be called (at the exit of the scope), so you can write almost magical code with but a line. Welcome to the C++ wonderland (at least, from a C++ developer's viewpoint).

For example, you can write a counter object (I let that as an exercise) and use it just by declaring its variable, like the lock object above was used:

void foo()
{
   double timeElapsed = 0 ;
   
   {
      Counter counter(timeElapsed) ;
      // do something lengthy
   }
   // now, the timeElapsed variable contain the time elapsed
   // from the Counter's declaration till the scope exit
}

which of course, can be written, again, the Java/C# way using a macro:

void foo()
{
   double timeElapsed = 0 ;

   COUNTER(timeElapsed)
   {
      // do something lengthy
   }
   // now, the timeElapsed variable contain the time elapsed
   // from the Counter's declaration till the scope exit
}

3. Why does C++ lack finally?

[SHOUTING] It's the final countdown!

— Europe: The Final Countdown (sorry, I was out of quotes, here... :-)

The finally clause is used in C#/Java to handle resource disposal in case of scope exit (either through a return or a thrown exception).

Astute specification readers will have noticed C++ has no finally clause. And this is not an error, because C++ does not need it, as RAII already handle resource disposal. (And believe me, writing a C++ destructor is magnitudes easier than writing the right Java finally clause, or even a C#'s correct Dispose method).

Still, sometimes, a finally clause would be cool. Can we do it in C++? Yes, we can! And again with an alternate use of RAII.

Conclusion: RAII is a more than philosophy in C++: It's C++

RAII? THIS IS C++!!!

— C++ developer's outraged comment, shamelessly copied by an obscure Sparta king and his 300 friends

When you reach some level of experience in C++, you start thinking in terms of RAII, in terms of construtors and destructors automated execution.

You start thinking in terms of scopes, and the { and } characters become ones of the most important in your code.

And almost everything fits right in terms of RAII: exception safety, mutexes, database connections, database requests, server connection, clocks, OS handles, etc., and last, but not least, memory.

The database part is not negligible, as, if you accept to pay the price, you can even write in a "transactional programming" style, executing lines and lines of code until deciding, in the end, if you want to commit all the changes, or, if not possible, having all the changes reverted back (as long as each line satisfy at least the Strong Exception Guarantee). (see the second part of this Herb's Sutter article for the transactional programming).

And like a puzzle, everything fits.

RAII is so much part of C++, C++ could not be C++ without it.

This explains why experienced C++ developers are so enamored with RAII, and why RAII is the first thing they search when trying another language.

And it explains why the Garbage Collector, while a magnificient piece of technology in itself, is not so impressive from a C++ developer's viewpoint:

  • RAII already handles most of the cases handled by a GC
  • A GC deals better than RAII with circular references on pure managed objects (mitigated by smart uses of weak pointers)
  • Still A GC is limited to memory, while RAII can handle any kind of resource.
  • As described above, RAII can do much, much more...
Birdseed answered 19/1, 2011 at 21:24 Comment(5)
A Java fan: I'd say that GC is way more useful than RAII as it handles all memory and frees you from many potential bugs. With GC, you can create circular references, return and store references and its hard to get it wrong (storing a reference to a supposedly short-lived object lengthens its live time, which is a sort of memory leak, but that's the only problem). Handling resources with GC doesn't work, but most resources in an application have a trivial live cycle, and the few remaining ones are no big deal. I wish we could have both GC and RAII, but that seems to be impossible.Terrorize
I don't think you can actually implement a preprocessor macro LOCK as you described here. The LOCK(...) in LOCK(...) { ... } can't reach out and swallow that {. You could do { LOCK(...) ... } or LOCK(..., ...) or LOCK(...) ... UNLOCK or with some cleverness even LOCK(...)(...), but not LOCK(...){...}.Berrie
Yes, we can... ;-) This is called variable injection, and is based on the fact in C++, variables can be declared in, for example, a if statement, and that this variable is then available both in the true-branch scope, and in the false-branch scope. You can see an example on Godbolt: godbolt.org/z/oMPe6Thev . I've added the code of the macro in the answer to clarify it.Birdseed
C# now has a form of RAII, it's just that you have to write using before the variable declaration, e.g. using var x = new MyResource(); and it will be cleaned up at the end of the scope.Exordium
@Neme: Indeed, you're right, both C# and Java come with a "form of RAII", but that's a very limited form that barely captures the surface of RAII, as shown by the following examples: --- You have no way to declare that a class member variable should be Disposable but to write all the code. --- If your class is Disposable, if you forget to use the using keyword (or write all the boiiler plate for a member variable), then it won't be disposed.Birdseed
H
11

RAII is using C++ destructors semantics to manage resources. For example, consider a smart pointer. You have a parameterized constructor of the pointer that initializes this pointer with the adress of object. You allocate a pointer on stack:

SmartPointer pointer( new ObjectClass() );

When the smart pointer goes out of scope the destructor of the pointer class deletes the connected object. The pointer is stack-allocated and the object - heap-allocated.

There are certain cases when RAII doesn't help. For example, if you use reference-counting smart pointers (like boost::shared_ptr) and create a graph-like structure with a cycle you risk facing a memory leak because the objects in a cycle will prevent each other from being released. Garbage collection would help against this.

Hoebart answered 3/4, 2009 at 5:28 Comment(2)
So it should be called UCDSTMR :)Congratulatory
On a second thought, I think UDSTMR is more appropriate. The language (C++) is given, so the letter "C" is not needed in the acronym. UDSTMR stands for Using Destructor Semantics To Manage Resources.Congratulatory
H
10

I'd like to put it a bit more strongly then previous responses.

RAII, Resource Acquisition Is Initialization means that all acquired resources should be acquired in the context of the initialization of an object. This forbids "naked" resource acquisition. The rationale is that cleanup in C++ works on object basis, not function-call basis. Hence, all cleanup should be done by objects, not function calls. In this sense C++ is more-object oriented then e.g. Java. Java cleanup is based on function calls in finally clauses.

Hangover answered 3/4, 2009 at 8:50 Comment(2)
Great answer. And "initialization of an object" means "constrctors", yes?Maratha
@Charlie: yes, especially in this case.Hangover
A
8

I concur with cpitis. But would like to add that the resources can be anything not just memory. The resource could be a file, a critical section, a thread or a database connection.

It is called Resource Acquisition Is Initialization because the resource is acquired when the object controlling the resource is constructed, If the constructor failed (ie due to an exception) the resource is not acquired. Then once the object goes out of scope the resource is released. c++ guarantees that all objects on the stack that have been successfully constructed will be destructed (this includes constructors of base classes and members even if the super class constructor fails).

The rational behind RAII is to make resource acquisition exception safe. That all resources acquired are properly released no matter where an exception occurs. However this does rely on the quality of the class that acquires the resource (this must be exception safe and this is hard).

Audre answered 3/4, 2009 at 7:45 Comment(3)
Excellent, thank you for explaining the rationale behind the name. As I understand it, you might paraphrase RAII as, "Don't ever acquire any resource through any other mechanism than (constructor-based) initialization". Yes?Maratha
Yes this is my policy, however I am very wary of writing my own RAII classes as they must be exception safe. When I do write them I try to ensure exception safety by reusing other RAII classes written by experts.Audre
I've not found them hard to write. If your classes are properly small enough, they're not hard at all.Untread
S
7

The problem with garbage collection is that you lose the deterministic destruction that's crucial to RAII. Once a variable goes out of scope, it's up to the garbage collector when the object will be reclaimed. The resource that's held by the object will continue to be held until the destructor gets called.

Stead answered 3/4, 2009 at 5:34 Comment(2)
The problem is not only determinism. The real problem is that finalizers (java naming) get in the way of GC. GC is efficient because it does not recall the dead objects, but rather ignores them into oblivion. GCs must track objects with finalizers in a different way to guarantee that they are calledHayseed
except in java/c# you would probably clean up in a finally block rather than in a finalizer.Tanhya
G
4

RAII comes from Resource Allocation Is Initialization. Basically, it means that when a constructor finishes the execution, the constructed object is fully initialized and ready to use. It also implies that the destructor will release any resources (e.g. memory, OS resources) owned by the object.

Compared with garbage collected languages/technologies (e.g. Java, .NET), C++ allows full control of the life of an object. For a stack allocated object, you'll know when the destructor of the object will be called (when the execution goes out of the scope), thing that is not really controlled in case of garbage collection. Even using smart pointers in C++ (e.g. boost::shared_ptr), you'll know that when there is no reference to the pointed object, the destructor of that object will be called.

Goldfish answered 3/4, 2009 at 6:8 Comment(0)
U
4

And how can you make something on the stack that will cause the cleanup of something that lives on the heap?

class int_buffer
{
   size_t m_size;
   int *  m_buf;

   public:
   int_buffer( size_t size )
     : m_size( size ), m_buf( 0 )
   {
       if( m_size > 0 )
           m_buf = new int[m_size]; // will throw on failure by default
   }
   ~int_buffer()
   {
       delete[] m_buf;
   }
   /* ...rest of class implementation...*/

};


void foo() 
{
    int_buffer ib(20); // creates a buffer of 20 bytes
    std::cout << ib.size() << std::endl;
} // here the destructor is called automatically even if an exception is thrown and the memory ib held is freed.

When an instance of int_buffer comes into existence it must have a size, and it will allocate the necessary memory. When it goes out of scope, it's destructor is called. This is very useful for things like synchronization objects. Consider

class mutex
{
   // ...
   take();
   release();

   class mutex::sentry
   {
      mutex & mm;
      public:
      sentry( mutex & m ) : mm(m) 
      {
          mm.take();
      }
      ~sentry()
      {
          mm.release();
      }
   }; // mutex::sentry;
};
mutex m;

int getSomeValue()
{
    mutex::sentry ms( m ); // blocks here until the mutex is taken
    return 0;  
} // the mutex is released in the destructor call here.

Also, are there cases where you can't use RAII?

No, not really.

Do you ever find yourself wishing for garbage collection? At least a garbage collector you could use for some objects while letting others be managed?

Never. Garbage collection only solves a very small subset of dynamic resource management.

Untread answered 3/4, 2009 at 15:21 Comment(2)
I've used Java and C# very little, so I've never had it to miss, but GC certainly cramped my style when it came to resource management when I had to use them, because I couldn't use RAII.Untread
I've used C# a lot and agree with you 100%. In fact, I consider a non-deterministic GC to be a liability in a language.Deleterious
W
2

There are already a lot of good answers here, but I'd just like to add:
A simple explanation of RAII is that, in C++, an object allocated on the stack is destroyed whenever it goes out of scope. That means, an objects destructor will be called and can do all necessary cleanup.
That means, if an object is created without "new", no "delete" is required. And this is also the idea behind "smart pointers" - they reside on the stack, and essentially wraps a heap based object.

Windhover answered 3/4, 2009 at 11:4 Comment(2)
No, they don't. But do you have a good reason to ever create a smart pointer on the heap? By the way, the smart pointer was just an example of where RAII can be useful.Windhover
Maybe my use of "stack" v.s. "heap" is a little sloppy - by an object on "the stack" I meant any local object. It can naturally be a part of an object e.g. on the heap. By "create a smart pointer on the heap", I meant to use new/delete on the smart pointer itself.Windhover
F
1

RAII is an acronym for Resource Acquisition Is Initialization.

This technique is very much unique to C++ because of their support for both Constructors & Destructors & almost automatically the constructors that are matching that arguments being passed in or the worst case the default constructor is called & destructors if explicity provided is called otherwise the default one that is added by the C++ compiler is called if you didn't write an destructor explicitly for a C++ class. This happens only for C++ objects that are auto-managed - meaning that are not using the free store (memory allocated/deallocated using new,new[]/delete,delete[] C++ operators).

RAII technique makes use of this auto-managed object feature to handle the objects that are created on the heap/free-store by explcitly asking for more memory using new/new[], which should be explicitly destroyed by calling delete/delete[]. The auto-managed object's class will wrap this another object that is created on the heap/free-store memory. Hence when auto-managed object's constructor is run, the wrapped object is created on the heap/free-store memory & when the auto-managed object's handle goes out of scope, destructor of that auto-managed object is called automatically in which the wrapped object is destroyed using delete. With OOP concepts, if you wrap such objects inside another class in private scope, you wouldn't have access to the wrapped classes members & methods & this is the reason why smart pointers (aka handle classes) are designed for. These smart pointers expose the wrapped object as typed object to external world & there by allowing to invoke any members/methods that the exposed memory object is made up of. Note that smart pointers have various flavors based on different needs. You should refer to Modern C++ programming by Andrei Alexandrescu or boost library's (www.boostorg) shared_ptr.hpp implementation/documentation to learn more about it. Hope this helps you to understand RAII.

Fenestella answered 3/4, 2009 at 10:3 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.