home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 20075 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.0 KB
  1. Xref: sparky comp.lang.c++:20075 comp.object:5110
  2. Path: sparky!uunet!crdgw1!rpi!uwm.edu!spool.mu.edu!agate!doc.ic.ac.uk!pipex!demon!trmphrst.demon.co.uk!nikki
  3. From: nikki@trmphrst.demon.co.uk (Nikki Locke)
  4. Newsgroups: comp.lang.c++,comp.object
  5. Subject: Re: HELP : Array of objects of diff classes ??
  6. Message-ID: <728016608snx@trmphrst.demon.co.uk>
  7. Date: 25 Jan 93 19:50:08 GMT
  8. References: <mcampbel.727881449@eola.cs.ucf.edu> <1jdgecINNp06@aurora.engr.LaTech.edu>     <1993Jan19.112059.2882@ucc.su.OZ.AU>
  9. Sender: usenet@demon.co.uk
  10. Reply-To: nikki@trmphrst.demon.co.uk
  11. Followup-To: comp.lang.c++
  12. Organization: Trumphurst Ltd.
  13. Lines: 49
  14. X-Mailer: cppnews $Revision: 1.31 $
  15.  
  16. > >In article <1993Jan19.112059.2882@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  17. answers a question on how to create and use heterogeneous collections, 
  18. specifically a Holder which can contain PENCILs, PENs & ERASERs.
  19.  
  20. MAX>I assume that it reasonable to allow Holder to hold any one of these objects
  21. MAX>because there is some similarity between these objects.  e.g., they are all
  22. MAX>drawing tools or whatever.  This concept of similarity should be captured by
  23. MAX>classifiying each of these item classes as subclasses (or specializations) of
  24. MAX>the common class (e.g., drawing_object - which may be abstract).  Then, the
  25. MAX>Holder class simply has to be declared to be able to hold objects of type
  26. MAX>drawing_object.  Then, any instance of PENCIL, PEN, ERASER and any other class
  27. MAX>derived from drawing_object cam be held by a Holder instance.  Aggregates can
  28. MAX>hold heterogeneous collections etc.
  29.  
  30. In article <mcampbel.727881449@eola.cs.ucf.edu> mcampbel@cs.ucf.edu (Mike Campbell ) writes:
  31. > I've been following this thread with some interest, and I find your reply 
  32. > interesting.  
  33. > 
  34. > I agree with your analysis of the problem re: subclasses, however, what if
  35. > you buy/purchase/steal classes from multiple vendors/coworkers/victims ?
  36. > They necessarily will not have a common base class.  (Or is this correctly
  37. > deemed "superclass?")
  38.  
  39. So miltiply derive from the vendors class and from a common base class of 
  40. your own.
  41.  
  42. > Borland does this - they have a common base class, "Object", as I recall, and
  43. > all of the storage classes can hold 'objects'.  This allows the storage 
  44. > classes to hold just about anything in their provided class library, as every-
  45. > thing is derived from the 'object' class.
  46.  
  47. Which just goes to show how badly designed Borlands class library is !
  48. [ fx: Flameproof shields UP :-]
  49.  
  50. > Any ideas/thoughts from anyone on how to handle dissimilar base classes in a
  51. > 'holder' class?
  52.  
  53. Re-think your design - you almost certainly don't need heterogenous 
  54. collections.
  55.  
  56. If you really _do_ need them, then either ...
  57.  
  58. 1) Use a different language.
  59. 2) Wait for run-time type identification to arrive in C++
  60. 3) Write your own RTTI (like Borland did).
  61.  
  62. -- 
  63. Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
  64. trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
  65.