BLM> class manifest { 
 BLM> public: 
 BLM> manifest(); 
 BLM> manifest(const char *filename); 
 BLM> ~manifest(); 
 BLM> 
 BLM> void report_name(); 
 BLM> 
 BLM> private: 
 BLM> char* select(char *filename, int len); 
 BLM> char      *filename; 
 BLM> ifstream  *mstreamp; 
 BLM> }; 
 BLM> 
 BLM> 
 BLM> ...manifest is initialized by one of the following constructors... 
 BLM> 
 BLM> 
 BLM> manifest::manifest(){ 
 BLM> filename = new char[FILENAME_MAX]; 
 BLM> while (!select(filename, FILENAME_MAX - 1)); 
 BLM> mstreamp = new ifstream(filename); 
 BLM> } 
 
 BLM> How do I handle errors in opening the ifstream? 
 The ! operator is overloaded to indicate failure.  So you could add at 
 the end of the above constructor something like...
 if (!*mstreamp) {
  delete[] filename;
  delete mstreamp;
  NotifySystemOfFailure();
 }
 You could do a variety of actions in NotifySysytem...().  For example,
 you could throw an exception.  You could also set the value of 
 mstreamp to zero and require that it be queried before continuing
 (yuck).  One good feature to add to NotifySystem..() is the reason
 why the file stream creation/open deal failed.
  
 BLM> Is it a good idea perhaps, to just allocate space for filename within 
 BLM> the constructor and then handle everything else in a manifest::init() 
 BLM> member?  That would seem redundant to me but perhaps overloading 
 BLM> constructors is already redundant. 
 A separate construction step and then a create or init step is a
 common C++ technique.  MFC (for one example) does this quite a bit.
 It does prevent the classic problem of "partly created members".
---
 þ Blue Wave/QWK v2.12 þ
---------------