Re: Why is RAII called RAII?
"Goran Pusic" <email@example.com>
Even the traditional 2-phase init has its good use cases, especially if
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
Yes. My contention is: this is incidental complexity that serves not
C++ is traditionally multi-paradigm, so you are allowed to follow your
attitude, but leave others to have their ways too.
E.g. why would you want to "reuse" CFile object?
For example to close the log file every 24 (or 1 or whatever) hours and open
another. Or when it gets idle.
infinitely more expensive to actually open a file on the file system
than to construct a C++ object. There has to be a rather particular
use-case (IMHO) to warrant two-phase construction.
This is not multiphace contruction, but a separate use case. Or better put,
mutable state of your object during its lifetime.
Your logic could go out to the mutable/immutable class concepts. Both are
valuable, and have their good use. Trying to talk down one because the
other is useful hardly helps.
And indeed, there are stream class hierarchies in other frameworks
(VCL of Borland, Java, .NET), containing file-backed streams, that
have no separate "open", and I don't remember people complaining about
People are not complaining because whenever that interface is bad for their
use approach they pick some other tool and move on.
In a deal of cases in my program I chose not to implement 'clear()' like
facility in a class, rather have it as smart_ptr<T>, and reset( new
T(...) ). Especially if that member is tied to some specific states, and is
reset(0) on transition to others.
Using indirection and smart pointers can cover up for some narrowed
interfaces, like missing copy or missing ability to a delayed init.
It's a up to judgement which variant have more complexity -- I'd rather just
skip it ;-)