JC> exception handling was invented largely to deal with errors in ctors.
 That seems a tab broad.  Exceptions were designed to handle any sort of
 errors.  My understanding is that a primary design consideration was
 to relive the programmer from the tedium (and inevitable errors from such
 tedium) of continually checking function return values for error codes.
 JC> There's really no other clean method available.
 True enough.  But it also introduces some nasties as well.
 
 BL> Is it a good idea perhaps, to just allocate space for filename within 
 BL> the constructor and then handle everything else in a manifest::init() 
 BL> member?  That would seem redundant to me but perhaps overloading 
 BL> constructors is already redundant.
 JC> I would avoid this if at all possible.  It's nearly inevitable that if
 JC> you require a separate call to initialize the class that at least
 JC> occassionally somebody will forget to call it.  One of the major
 JC> strengths of C++ is its ability to ctors and ensure that as soon as an
 JC> object comes into existence, it WILL be initialized.  Separating the
 JC> two cripples this capability.
 That would depend upon how it's implemented.  As you know, MFC heavily
 relies upon the separate contruction/initialization paradigm and I don't
 see how this "cripples" it.
---
 þ Blue Wave/QWK v2.12 þ
---------------