home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 17884 < prev    next >
Encoding:
Text File  |  1992-12-13  |  2.8 KB  |  58 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!spool.mu.edu!darwin.sura.net!max.fiu.edu!serss0!feathers
  3. From: feathers@serss0 (Michael Feathers)
  4. Subject: Re: Give me safe C++
  5. Organization: Florida International University, Miami
  6. Date: Sun, 13 Dec 1992 04:44:07 GMT
  7. Message-ID: <Bz6L5J.A9s@fiu.edu>
  8. References: <Bz2nDF.7B6@fiu.edu> <WARSAW.92Dec11124441@anthem.nlm.nih.gov> <1992Dec12.145403.26483@ucc.su.OZ.AU>
  9. Sender: news@fiu.edu (Usenet Administrator)
  10. Lines: 46
  11.  
  12. In article <1992Dec12.145403.26483@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  13. >In article <WARSAW.92Dec11124441@anthem.nlm.nih.gov> warsaw@nlm.nih.gov (Barry A. Warsaw) writes:
  14. >>
  15. >>Agreed. IMHO, the real power of C++ as a development language is the
  16. >>ability to easily climb up and down the abstraction ladder depending
  17. >>on the context of the problem.  Sometimes you need to mingle with the
  18. >>bits in the basement, sometimes you just need ADTs and sometimes you
  19. >>really want to do OOP.  The beauty of C++ is that it seamlessly
  20. >>supports many levels of abstraction.
  21. >
  22. >    While tending to support your liking of the C++ 'hybrid'
  23. >approach, I'm not so sure about 'seamlessly', are you?
  24. >
  25. >    And I think you tend to miss exactly where rigid restrictions
  26. >on functionality are the things which *yield* the very power you desire.
  27. >For example, virtual functions can be trivially implemented
  28. >using function pointers. Function pointers in fact are a vastly
  29. >more powerful technique than mere virtual functions. 
  30. >
  31. >    What makes virtual functions so useful is the fact that they
  32. >are so tightly restricted .. for example, unlike a genuine
  33. >function pointer they cannot be modified after object creation,
  34. >nor specialised on a per object basis.
  35. >
  36.  
  37. I think that it is useful here to take an overall view of a language.  The
  38. restrictions on virtual functions in C++ that you mention are definitional
  39. restrictions.  If we had specialization on a per object basis, the notion of 
  40. a class would not have the same meaning and the conceptual framework of the
  41. language would be altered.  In the overall view, one could say that C++ does
  42. not have a limitation on functionality by the definition of virtual functions
  43. because it does have function pointers and you can do exactly what you wish 
  44. (ignoring virtual functions).
  45.  
  46. In some other languages this is not the case.  Some functionality is restricted
  47. because it is deemed hazardous, and special rules are formulated so that it
  48. can not be attained with any language constructs.
  49.  
  50. Consider the static type checking of C++.  In the same way that you say that
  51. the definition of virtual functions restricts C++, I could say that type
  52. checking restricts C++.  However, in both cases, there is an "out" and no
  53. functionality is sacrificed.  You can use function pointers to specialize
  54. "objects" and you can uses casts to subvert type checking.
  55.  
  56.  
  57.  
  58.