RAII understanding - Accesing methods of a bounded pointer

Question

I was reading about the RAII concept and while attempting to understand it , I formulated the following example.

class foo_handler
{
private:
 foo* f;
public:
  foo_handler(foo* inc) : f(inc){}
  ~foo_handler(){delete f;}
};

My question is that suppose foo has a method called SomeMethod doesnt foo_handler need to have a method that has the following signature

foo* returnFoo();

so that we can access the exposed methods of foo ? I was a bit confused here since this link , the answer by the the_mandrill did not explain this scenario

so this could be used as

foo_handler d;
d.returnFoo()->SomeMethod();

This is not quite RAII: when the object gets destroyed f is no more available to anyone else — Marco A., Mar 05 '14 at 08:07
One way of handling access to f methods is to overload the operator ->, see http://stackoverflow.com/a/8782794/197657 — dutt, Mar 05 '14 at 08:10
@DavidKernin isnt that the point.The variable foo_handler is on the stack and when its scope ends it destroys `foo` — Rajeshwar, Mar 05 '14 at 08:21
yes, but you didn't acquire it yourself. Technically this is not RAII since there's no acquisition, somebody else acquired that pointer and might free it before your class finishes its job. Furthermore: using the acquired object inside the class is a suggested practice, but why do you need to create a returnFoo method? You can simply use the pointer where you need it inside the foo_handler class. — Marco A., Mar 05 '14 at 08:26
@DavidKernin are yu suggesting that the best approach is to add a method to foo_handler called "someMethod" which calls `f->someMethod()` ? — Rajeshwar, Mar 05 '14 at 08:32
If you use a foo_handler like this and multiple objects use a pointer to the same object, then you should consider using shared_ptr. Otherwise, a new in the constructor for every delete in the destructor. — tgmath, Mar 05 '14 at 08:38
This is just a rough sample class which merely tries to demonstrated RAII concept — Rajeshwar, Mar 05 '14 at 08:43

score 1 · Answer 1 · answered Mar 05 '14 at 08:56

First of all, there is a (widespread) confusion, so let me clear it.

RAII stands for Resources Acquisition Is Initialization. The concern here is one of class invariants, and tying the acquisition of the resource to the construction of the object means that: whenever you have an handle on such an object, it is backed by a resource.

Or put another way, if acquiring the resource fail, then the object is never born (its constructor aborts/throws/whatever).

However, because typically RAII containers will also take care of releasing the resource upon their destruction, RAII is often colloquially used to refer to proper resource management. This is beyond its scope though, and a container such as:

struct RaiiHandle {
    RaiiHandle(Handle& h): handle(h) {}

    Handle& handle;
};

which does nothing about resource management is still a RAII container as it guarantees the presence of the resource.

Other acronyms have been tried to express the proper management of resources, such as SBRM: Scope Bound Resource Management, however they did not take (in SBRM case, it fails to account for the fact that a resource is not necessarily tied to a lexical scope).

A word of caution on your interface.

In the days of C, there was a piece of wisdom that said that whoever allocated a resource (often memory) should also provide a method to deallocate it. This ensured that the resource was properly deallocated because only its creator knows how it was allocated. Even today, it still remains a good advice.

Your interface, however, suffers from asymmetry: you are passed a pointer and call delete on it. But what if it was a pointer to an array ? What if it was a stack object ? Calling delete is preposterous.

A word of caution on your implementation.

I hope for your sake this is a trimmed down example, however since they are missing I cannot help but remind you that you should follow the Rule of Three (make it Five in C++11).

A very simple way never to forget is to change your raw pointer for a unique_ptr (possibly with a custom deleter). It will have correct move members by default and will force you to write the copy members should you need them.

Back to your question: Yes in general you will need a way to access the underlying resource, otherwise it would be useless.

There are multiple ways though:

if your container is specialized, it may present a domain oriented interface, this is what fstream does for example: you do not access the FILE* or whatever is inside, but instead use << and >> and .eof(), etc..
you may return a handle (pointer or reference)
you may have a method that takes a functor and will call it with a reference to the object (more functional oriented, less seen in C++)

It is up to you to design the interface so that your clients may actually use the resource.

score 0 · Answer 2 · answered Mar 05 '14 at 08:34

C++ doesn't have a try-finally construct and RAII is basically a simulation of the finally block with the toolset of C++ (well, maybe a bit more than that but its quite easy to understand it this way if you know try-finally). You write a class with a destructor and you instantiate this class by value on your stack. When this instance runs out of the scope its destructor gets executed no matter how you leave the scope (with return, exception, break, continue, ...). This destructor execution can be treated as a "finally" block, so you can put the cleanup of your resources into the destructor to make sure that the resources don't leak at the end of the scope (In this case your foo*). In C++ there are also some special scopes (when you define an instance of your RAII-based class by value as part of another object - then the scope of your RAII object is the lifetime of its container object, this doesn't really fit with the try-finally example...)

This explanation is of course meaningful to you only if you understand the concept of the try-finally blocks from other languages... Visual C++ also had a nonstandard __finally handler (SEH based), I don't know whether it still has this.

Actually, this is the reverse, a `try`-`finally` (or a `defer`) is a poor man's resource handling for people stuck in languages that do not have a way to tie an action to the destruction of an object... or to tie the destruction of an object to a precise event (as happen with GC'ed language). — Matthieu M., Mar 05 '14 at 08:38
@Matthieu M. That's true, I used `try-finally` in my explanation because this construct is known basically by everyone. Even GC'ed languages have more sophisticated tools than this, for example the `with` statement of python, `using` of C# but getting automatically cleaned up at the right moment (as you said) is the best, RAII in C++ is really nice in this regard. — pasztorpisti, Mar 05 '14 at 08:42

RAII understanding - Accesing methods of a bounded pointer

2 Answers2