Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!rex!uflorida!gatech!purdue!haven!ncifcrf!lhc!lhc!warsaw From: warsaw@nlm.nih.gov (Barry A. Warsaw) Newsgroups: comp.lang.c++ Subject: General approaches to some common (for me) situations... Message-ID: Date: 19 Apr 91 16:57:36 GMT Sender: usenet@nlm.nih.gov (usenet news poster) Reply-To: warsaw@nlm.nih.gov Organization: Century Computing, Inc. Lines: 43 Here's a few "philosophical" questions for you. Say you've got a class wherein the constructor does some initializations of a particular system. These inits may possibly fail, preventing the user of the class from validly using any of the associated methods. How do you go about returning this information to the class user when the constructor does not return a value? Also assuming the object could be created from the heap or on the stack, setting "this" to null (legal for 2.0?), would not do the trick. So how do you handle this? I do this by having a private "init" flag which I set or reset depending upon the success of of the initializations, then IN EACH METHOD REQUIRING VALID INITIALIZATION, I check the value of this flag before doing anything. Usually I'll also need a method so that the class user can query for the init state. Second, many of my classes have a high degree of interconnectedness. In other words, the user instantiates class A and through interactions with A, A creates many instances of B. B's constructor is protected so the user cannot create B's (but A is a friend). A has a method which returns pointers to B's and A maintains a list of all B's it has created. Each B in turn maintains a pointer to its parent A object. This way, if A is destroyed, it can go through and destroy (or detach) each B it knows about. Also, if a particular B is destroyed (by the user), it can tell its A parent to stop keeping track of it. Even more tricky is that in addition to A's keeping track of B's, there may be a third class C which keeps track of the same set of B's. Lots of lists involved as you can see. Think of all these classes as instances of windows. Anybody have any thoughts on alternate (and perhaps more elegant or easier to manage) ways of handling these situations? Seems to crop up very often on my current project.... -Barry NAME: Barry A. Warsaw USMAIL: National Library of Medicine TELE: (301) 496-1936 Lister Hill National Center for INET: warsaw@nlm.nih.gov Biomedical Communications UUCP: uunet!nlm.nih.gov!warsaw Information Technology Branch 8600 Rockville Pike Bldg. 38A, Rm. 7s722 Bethesda, Md. 20894