home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / cplus / 18976 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  3.4 KB

  1. Path: sparky!uunet!cs.utexas.edu!usc!news.cerf.net!nic.cerf.net!hlf
  2. From: hlf@nic.cerf.net (Howard Ferguson)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Preventing inheritance
  5. Date: 12 Jan 1993 02:07:54 GMT
  6. Organization: CERFnet Dial n' CERF Customer Group
  7. Lines: 65
  8. Message-ID: <1it95qINN55t@news.cerf.net>
  9. References: <1iqtnpINN283@news.cerf.net> <1993Jan11.195503.6255@athena.mit.edu>
  10. NNTP-Posting-Host: nic.cerf.net
  11.  
  12. In article <1993Jan11.195503.6255@athena.mit.edu> berczuk@space.mit.edu (Steve Berczuk) writes:
  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. I could overload new
  17. >|> and check the size of the object that is being allocated, but there
  18. >|> are two catchs. The first minor one is that this is a run-time check,
  19. >|> and it would be far preferable to catch this sort of thing at compile
  20. >|> time. More seriously, they could over-ride the new operator and by-pass
  21. >|> the check.
  22. >|>     yours totally paranoid,
  23. >|>             hlf
  24. >Umm, why would you want to do this?
  25. >
  26. >It seems like soing this sort of thing defeats the purpose fo using c++; I can
  27. >understand not wanting to "support" other users who inherit the class, but that
  28. >might be best approached by some sort of documentation (eg comments in the header
  29. >to the effect of "this class supports some wierd protocols that subclasses need to
  30. >enforce, subclass at your own risk"). 
  31. >
  32. >It is probably better to just ensure that instances of the class are  always in a
  33. >consistent state.
  34. >
  35. >Is there are really valid reason (aside from paranoia) that one would want to write
  36. >a class that could not be subclassed?
  37. >
  38. >
  39. >
  40.  
  41. A lot of people reacted in horror when I posted this question. Here is
  42. my reason. I am (hypothetically) writting a class library. I am 
  43. allowing my users pass me some data of set size but arbitrary type 
  44. (pointers would be a good example - you can usually depend on them
  45. to stay the same size). However I do not wish to ask my users to do
  46. nasty casts as they pass data  to me and get data from me.
  47.  
  48. So I give them a template, and get them to encapsulate the data in  the
  49. template. All of the templated classes inherit from a (effectively
  50. empty) parent class so the user is able to pass the objects
  51. created from the templates to the library. 
  52.  
  53. I could get the user to new the objects and pass them to me and I 
  54. would later delete them. Or he could delete them, or he might not 
  55. realise that I am going to delete them and delete them also (boom)
  56. or he could pass them to me twice  and I might then delete them
  57. twice (boom).
  58.  
  59. So instead I get the user to declare the objects locally and I do a 
  60. bitwise copy of it when I receive it. If I am going to do something
  61. as dangerous as a bitwise copy, I want to be very sure that the
  62. sucker has not changed size on me without my permisson.
  63.  
  64. You may argue that if he has inherited from my templated object and
  65. then passed it to me the bitwise copy will simply leave out the
  66. extra piece and everyone is happy. But what if he has multiply
  67. inherited and the organisation in memory has completely different
  68. organisation. The library might then copy the wrong parent. Also
  69. a wierd compiler might give things a strange arrangement in memory
  70.  
  71. I am sure there are plenty of other examples where a library 
  72. is supplying a class for a particular -- and possibly hacky --
  73. purpose and the coder does not want his hack broken by an
  74. over ambitious user.
  75.  
  76.     hlf
  77.