home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / cplus / 19002 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  2.3 KB
  1. Path: sparky!uunet!mcsun!sunic!hagbard!loglule!jbn
  2. From: jbn@lulea.trab.se (Johan Bengtsson)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Preventing inheritance
  5. Message-ID: <5517@miramon.lulea.trab.se>
  6. Date: 12 Jan 93 12:13:55 GMT
  7. References: <1993Jan11.195503.6255@athena.mit.edu>
  8. Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
  9. Lines: 42
  10. X-Newsreader: TIN [version 1.1 + PL8]
  11.  
  12. Steve Berczuk (berczuk@space.mit.edu) wrote:
  13. : In article <1iqtnpINN283@news.cerf.net>, hlf@nic.cerf.net (Howard Ferguson) writes:
  14. : |> 
  15. : |> If I create a class which I am supplying to other users, how do I
  16. : |> make sure that they do not inherit from it ever.
  17. [...]
  18. : |>     yours totally paranoid,
  19. : Umm, why would you want to do this?
  20.  
  21. You may wish to create a class completely without virtual functions
  22. (size or C compatibility considerations).  If someone unwittingly
  23. inherits from such a class, the non-virtual destructor will not
  24. properly destroy data members added in the subclass.  This may be
  25. harmless, lose a small amount of dynamic memory, or completely
  26. stop an application due to lack of resources such as file handles
  27. (if the subclass adds a data member that represents an open file).
  28.  
  29. : [...]I can understand not wanting to "support" other users who inherit
  30. : the class, but that might be best approached by some sort of
  31. : documentation
  32.  
  33. Not all users will notice this (they should, but they won't).
  34. As the supplier of the base class you may be indirectly affected
  35. when those users send in bug reports, or claim that your code
  36. is "unreliable".  It is better to make sure that the compiler
  37. catches those errors early.  Instead of subclassing the users
  38. will have to use the class as a data member.
  39.  
  40. : (eg comments in the header to the effect of "this class
  41. : supports some wierd protocols that subclasses need to
  42. : enforce, subclass at your own risk"). 
  43.  
  44. The protocol need not be "weird" in order to have the constraint.
  45. The size of small classes can double in size if you support
  46. subclassing (you should have at least a virtual destructor).  You
  47. may not always want to pay that price.
  48.  
  49. -- 
  50. --------------------------------------------------------------------------
  51. | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
  52. | Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
  53. --------------------------------------------------------------------------
  54.