home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11402 < prev    next >
Encoding:
Text File  |  1992-07-22  |  4.7 KB  |  121 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!netmbx!jrobie
  3. From: jrobie@netmbx.netmbx.de (Jonathan Robie)
  4. Subject: Re: Covariant Types in Derived Classes
  5. Organization: netmbx, Berlin, Germany
  6. Date: Thu, 23 Jul 1992 07:36:29 GMT
  7. Message-ID: <P6C5COF@netmbx.netmbx.de>
  8. References: <5W0422J@netmbx.netmbx.de> <1992Jul20.154835.9269@ucc.su.OZ.AU> <92A5AID@netmbx.netmbx.de> <1992Jul21.183932.1541@ucc.su.OZ.AU>
  9. Lines: 110
  10.  
  11. maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  12.  
  13. >In article <92A5AID@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
  14. >>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  15.  
  16. >>Then you
  17. >>need to find out how many members you have in each class and how to
  18. >>access them.....
  19.  
  20. >    I dont understand.
  21.  
  22. If I want a generic print function that can handle all types as though they
  23. were basic types, then this print function must know the location and type
  24. of each member, and also the name if the function is to be particularly
  25. useful.
  26.  
  27. >but NOT to streams. I use Windows, there are NO streams
  28. >(well, there are: disk files I personally open).
  29. >    So you see immediately there is a problem here.
  30.  
  31. But if Windows provides you with general tools like the ones
  32. I am describing then there is no such problem.  To do so they
  33. need the run time type information.
  34.  
  35. >For the types of application you have mentioned,
  36. >where full knowledge of the structure of a class is required
  37. >(in effect, the source), C++ is clearly inadequate.
  38. >To REALLY do what you want, you need a proper, fullscale,
  39. >reflexive system.
  40.  
  41. Yes and no.  All of the applications I have mentioned can get by
  42. with run time type identification.  A full scale reflective system
  43. certainly has its advantages, but 
  44.  
  45. >What concerns me is that, for example, if you can say
  46. >get a description of the details of a class,
  47. >then you can 'cheat' the system, and fiddle with details
  48. >that were supposed to be hidden.
  49.  
  50. You can do this with pointers also.  What concerns me is that
  51. people are already writing precompilers for C++ simply because
  52. they need this run time identification for such bread and butter
  53. applications as object oriented databases.  That is OK if only
  54. one of the tools you use needs a precompiler, but when you need
  55. two tools which each need a precompiler this can lead to problems.
  56.  
  57. Similarly, if every tool you use defines an Object type from which
  58. all of your classes must be derived then you start having problems
  59. when you want to use several tools simultaneously.
  60.  
  61. >Of course, in an OO database you might want to do exactly that:
  62. >how else can the user define a new object?
  63.  
  64. >But then you are writting in C++ a new system, and an interpreter
  65. >aided by the C++ run-time system: I don't know what you
  66. >call this class of programs, but for this class of programs
  67. >you need run-time support---LOTS of it. No argument.
  68.  
  69. No, I am not aware of any OO database which uses an interpreter
  70. to build class methods.  Typically, a standard C++ constructor
  71. is used to create a new object.  But the database maintains a
  72. class dictionary to keep track of data members.
  73.  
  74. >It is just not the sort of program I think of as a typical
  75. >use for C++, principally because it is a static system
  76. >designed for writting type-safe programs,
  77. >and NOT a system designed for implementing systems
  78. >compatible with itself.
  79.  
  80. Object oriented databases are a very typical tool for use with
  81. C++, as are user interface tools, CASE tools, communications
  82. packages, etc.   The C++ community is better off if these tools
  83. are easily available.  You do not need a fully reflective system
  84. to provide these tools, and you would not need precompilers if
  85. the run time identification were available.
  86.  
  87. >Why not use Smalltalk or Lisp: they already have the 
  88. >properties you need. C++ with only run-time support
  89. >added will STILL be almost unworkable for a system
  90. >like an OO database that really requires reflexivity.
  91.  
  92. Type safe systems are essential.  Neither Smalltalk nor Lisp are
  93. type safe.  At ECOOP this year I was struck by the extent to which
  94. all sides agreed that both type safety and dynamic binding are
  95. important.  Maybe there will be a language in the future which
  96. is fully reflective and is as good as C++ for large scale systems
  97. development.  For now we are focussing on providing tools for
  98. existing languages.  C++ is wildly popular, and is the best market
  99. for our tools.  It is also a good language, with a few minor wrinkles
  100. here and there...
  101.  
  102.  
  103.  
  104. Jonathan
  105.  
  106. ===========================================================================
  107.  
  108. Jonathan Robie        jrobie@netmbx.UUCP
  109. Arnold-Zweig-Str. 44    jrobie@netmbx.in-berlin.de
  110. O-1100 Berlin        
  111. Deutschland        Phone:  +37 (2) 472 04 19  (Home, East Berlin)
  112.                 +49 (30) 342 30 66 (Work, West Berlin)
  113.  
  114.  
  115.  
  116. -- 
  117. Jonathan
  118.  
  119. ===========================================================================
  120.  
  121.