Re: Why is RAII called RAII?
"Goran Pusic" <goranp@cse-semaphore.com>
In fact, in many cases, the resources at not acquired at
initialization time but later on during object lifetime.
(Warning: I am off-exact-topic).
These cases are wrong most of the time.
Are they now?
You are talking about two-phase initialization.
2-phase init is definitely a 'school' that lingers on, especially because
many homegrown coding standards prohibit exceptions.
But it is not everything -- many clases can pick up stuff en-route, or use
alternative resources, or a different set at different states.
Each two-phase initialization brings in one more
state into the program (object available, but unusable), which is
incidental complexity.
Even the traditional 2-phase init has its good use cases, especially if you
can chose it. See MFC's CFile. You have both ctor that opens file
immediately from passed info and throws on error. And another that just
creates the object and you can Open() later. And can reuse it too, after
close.
You can have CFile members in an object that will open the file eventually,
that is not part of 'init' but its natural life cycle.
In my experience, when one thinks this is
needed, there is usually a different design where it's not, and impact
on code size and performance is negligible and can go either way.
I have a library of many RAII handler objects. And my experience is that
the simplest case -- just having ctor and dtor -- are the least used.
If I write a new one, I generally make it use the auto_ptr interface:
- ctor with optional taking ownership
- reset()
- release()
- dtor
And it serves best. Clients can still use it for pure RAII. Can use just the
RRID (resource release is destruction (C) Matthew Wilson ;). Can reuse via
reset. Or even transfer stuff or handle spacial cases via release().
At my new place i did not (yet) import my suite, deciding we use boost
anyway, that has smart poitners, including scoped_ptr. I thought it will
be the same as my auto_prtNC (NC for no-copy) -- but no, it has the reducer
interface, and it turned out a general PITA.
The important feature of 'RAII' is not construction (not even the
interface), but the strict unique ownership imposed by design and coding
policy -- so you can always tell who is responsible for what, and with the
RRID behavior, most of problems go away automagically.
As for the original question: term RAII got stuck, despite using it we quite
rarely mean RAII in the original sense, but more the mentioned RRID or SBRM
or something alike.