warsaw@nlm.nih.gov (Barry A. Warsaw) (04/19/91)
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
mittle@blinn.watson.ibm.com (Josh Mittleman) (04/22/91)
The first problem you describe is one of the reasons that exception handling is being introduced into the language. See ARM, 353ff for a thorough discussion. Without exception handling there are lots of kluges to deal with the situtation you describe: error code members, static error code variables, etc. In the second part of your post, it sounds like you really need a class SetOfB which manages all of the allocation and deallocation of B's. Class A contains a SetOfB and can add B's to it. In A's destructor, you destroy the SetOfB, which in turn destroys all the B's currently in the set. If some other class C needs to reference the same SetOfB, then you have to decide whether the A or the C owns the SetOfB. Assuming that the A owns it, the C should have a pointer to the SetOfB, or perhaps just to the A. =========================================================================== Josh Mittleman (mittle@watson.ibm.com or joshua@paul.rutgers.edu) J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY 10598