Re: RAII not always applicable?
restor wrote:
I actually didn't mean RAII, but a more general concept that could be
called "constructor establishes the class invariant". I wish it had a
name as popular as RAII.
Actually, a constructor that can not establish a class invariant must not
return, it must either throw (which is the default error signalling
mechanism) or it could in very rare cases invoke exit(). However,
establishing class invariants is the goal of the constructor, so it _must_
do that.
I guess you mean something else. Two examples are smart pointers or file
streams. Both can finish the constructor but be NULL or have their failbit
set. However, this is not a class invariant!
Now, as to the purpose of this post, I was trying to identify classes
of problems where the pattern "constructor establishes the class
invariant" cannot be applied.
Sorry, but this pattern by definition applies to all correct code. What you
have is a two-stage construction, where parts of an object are not usable
until a second initialisation took place. This however is not an invariant,
this is something that can and does change!
Uli
--
Sator Laser GmbH
Gesch?ftsf?hrer: Thorsten F?cking, Amtsgericht Hamburg HR B62 932
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]