home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12278 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  4.7 KB
  1. Xref: sparky comp.lang.c++:12278 comp.std.c++:1077
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!ftpbox!motsrd!news
  4. From: shang@corp.mot.com (David (Lujun) Shang)
  5. Subject: Polymorphic Arguments -- An Informal Proposal
  6. Message-ID: <1992Aug12.201036.7384@cadsun.corp.mot.com>
  7. Sender: news@cadsun.corp.mot.com
  8. Reply-To: shang@corp.mot.com
  9. Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
  10. Date: Wed, 12 Aug 92 20:10:36 GMT
  11. Lines: 123
  12.  
  13.  
  14. The following proposal is informal and incomplete. It is proposed for 
  15. the purpose to give some hints to solve some major problems in the 
  16. current C++. I have not enough spare time to make a complete 
  17. investagation, if someone is interested or happened to have the 
  18. similiar thought, please let me know.
  19.  
  20. A constant, variable, parameter, reference, or pointer can be 
  21. polymorphic. We call them polymorphic arguments.
  22.  
  23. A polymorphic argument specified by class C can represent an 
  24. object of class C or one of its derived classes.
  25.  
  26. We call a non-polymorphic argument a type exact argument. A type 
  27. exact argument can accept an object of a derived class with a 
  28. conversion (slicing) to its exactly specified type.
  29.  
  30. In the present C++, a constant, a vriable, or a parameter is 
  31. a type exact argument. A class pointer or class reference is 
  32. a polymorphic argument.
  33.  
  34. In extended C++, we will have polymorphic constant, variable, 
  35. and parameter:
  36.  
  37.    poly Animal a;
  38.    const poly Animal a,  // usually as a function parameter
  39.  
  40. and we will have type exact pointer and reference:
  41.  
  42.    Animal sealed * ap;
  43.    Animal sealed * af;
  44.  
  45. Type exact pointer or reference cannot accept a value of pointer 
  46. or reference of derived classes. For example, "ap=aMammalPointer" 
  47. is invalid, and slicing will be made for "*ap =aMammal".
  48.  
  49. We should distinguish a polymorphic pointer from a pointer to a 
  50. polymorphic argument:
  51.  
  52.    poly Animal * ap;
  53.  
  54. is a pointer to a polymorphic argument, but pointer itself is not 
  55. polymorphic. However,
  56.  
  57.    Animal * ap; // it is "Animal poly * p" by default
  58.  
  59. is a polymorphic pointer but the argument pointed by the pointer 
  60. is not polymorphic.
  61.  
  62. Why should we distinguish a polymorphic argument from a exact 
  63. argument? Let us first consider the general implementation issues:
  64.  
  65. (1) For a polymorphic argument, we need combine a type reference 
  66. with the object code.
  67.  
  68. (2) For a type exact argument, only object code is presented. 
  69.  
  70. Therefore, we can 
  71.  
  72. (1) Integrate the convensional C types into class hierarchy 
  73. without sacrifying the space and the speed, since convensional 
  74. C arguments are not polymorphic, and we need not to combine a 
  75. type reference with them. For example, if we treat "int" as a 
  76. class,
  77.  
  78.    int i;
  79.  
  80. is still 4 byte (for 32bit machine) long.
  81.  
  82. (2) Implement a complete RTTI without the overhead on space if you 
  83. do not use them. The type code is included into the run time code 
  84. only when you use it with a polymorphic argument. For example, the 
  85. type code for "int" class is included into run time code (at link 
  86. time), only when you write the following code:
  87.  
  88.    poly number np;
  89.    ...
  90.    np = anInteger;
  91.  
  92. Therefore, each type or class has a type code but not necessarily 
  93. to be included into run time type code if you do not use it with 
  94. polymorphism.
  95.  
  96. (3) Implement sizeof(), typeof() of a polymorphic argument correctly. 
  97. Since each type will have a code, we can include two standard fields 
  98. in the type code, one is the unique (project-wide) type identifier 
  99. (can be an integer), the other is the real size of the object code. 
  100. (Here we can take the advantage of the fact that the type code is 
  101. linked into the run time code only for those types associated with  
  102. polymorphism.)
  103.  
  104. (4) Implement increment and decrement of pointers correctly (the 
  105. same reason as we can implement a correct sizeof()).
  106.  
  107. (5) Save the storage for homogeneous object container. For example,
  108.  
  109.     Animal * p;
  110.     Dog da[1000];
  111.     Cat ca[20000];
  112.  
  113. In current C++, if Animal has virtual functions, "da" will have 
  114. additional 4K bytes and "ca" will waste 80K bytes! It is really 
  115. not necessary to tag all objects in a homogeneous object container 
  116. since they are all in the same type. Now, since we only tag those 
  117. polymorphic arguments, we need only tag the polymorphic pointer p. 
  118. When
  119.  
  120.    p = da;
  121.  
  122. "p" get both the address of the "da" and the type of "Dog". 
  123. (When p++, p increases by the actual size of a dog.)
  124.  
  125. In case of one pointer vs. many heterogeneous objects, we 
  126. can use a polymorphic pointer to refer to many specific 
  127. non-polymorphic objects. Therefore, we can save much space.
  128.  
  129. In case of many pointers vs. one polymorphic object, we can 
  130. use non-polymorphic pointers to the polymorphic object. This 
  131. is the same struture in the current C++ implementation.
  132.  
  133. David Shang
  134.  
  135.  
  136.