home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18330 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  7.4 KB
  1. Xref: sparky comp.lang.c++:18330 comp.object:4641
  2. Path: sparky!uunet!think.com!ames!purdue!not-for-mail
  3. From: gb@cs.purdue.edu (Gerald Baumgartner)
  4. Newsgroups: comp.lang.c++,comp.object
  5. Subject: GCC 2.3.2 implementation of signatures for C++
  6. Date: 22 Dec 1992 19:39:34 -0500
  7. Organization: Department of Computer Sciences, Purdue University
  8. Lines: 194
  9. Message-ID: <1h8cg6INNccc@ector.cs.purdue.edu>
  10. NNTP-Posting-Host: ector.cs.purdue.edu
  11.  
  12. Just ready for Christmas, a beta test version of our implementation of
  13. signatures for C++ has been released and is available by anonymous FTP
  14. from:
  15.  
  16.     host:        ftp.cs.purdue.edu    (128.10.2.1)
  17.  
  18.     login:        anonymous
  19.  
  20.     password:    your e-mail address
  21.  
  22.     directory:    pub/gb
  23.  
  24.     files:        COPYING            Copyright notice.
  25.  
  26.             README            This file.
  27.  
  28.             gcc-2.3.2.sig.diff.Z    Context diffs for GCC 2.3.2.
  29.  
  30.             pldi.dvi.Z        Paper submitted to PLDI '93
  31.                         (compressed DVI file).
  32.  
  33.             pldi.ps.Z        Paper submitted to PLDI '93
  34.                         (compressed Postscript file).
  35.  
  36.             test.tar.Z        Test files and script to run
  37.                         the tests.
  38.  
  39. To make GCC 2.3.2 understand signatures, just copy the context diff
  40. file into the GCC source directory, type
  41.  
  42.     zcat gcc-2.3.2.sig.diff.Z | patch
  43.  
  44. and recompile `gcc' and `cc1plus.'
  45.  
  46. For compiling C++ code containing signatures, you need to use the
  47. command line option
  48.  
  49.     -fhandle-signatures
  50.  
  51. We tested our extension on Sun 4 only, but since there are no changes
  52. to the compiler backend, it should work on other architectures as
  53. well.  To test whether it works on your architecture, unpack the file
  54. `test.tar.Z' and run the shell script
  55.  
  56.     Test
  57.  
  58. It compiles the test programs and runs them.  If everything works
  59. correctly, all the test programs (all 37 of them) should print
  60.  
  61.     Hello World.
  62.  
  63.  
  64. What are Signatures anyway?
  65. ---------------------------
  66.  
  67. Roughly, signatures are type abstractions or interfaces of classes.
  68. They are related to ML's signatures, categories in Scratchpad II,
  69. definition modules in Modula-2, interface modules in Modula-3, and
  70. types in POOL-I.
  71.  
  72. The main language constructs added are signatures and signature pointers.
  73. For example, the signature declaration
  74.  
  75.     signature S
  76.     {
  77.       int foo (void);
  78.       int bar (int);
  79.     };
  80.  
  81. defines a new abstract type `S' with member functions `int foo (void)'
  82. and `int bar (int).'  Signature types cannot be instantiated since they
  83. don't provide any implementation.  Only signature pointers and signature
  84. references can be defined.  For example,
  85.  
  86.     C obj;
  87.     S * p = &obj;
  88.  
  89. defines a signature pointer `p' and initializes it to point to an object
  90. of type `C,' where class `C' is required to contain the public member
  91. functions `int foo (void)' and `int bar (int).'  The member function call
  92.  
  93.     int i = p->foo ();
  94.  
  95. executes then `obj.foo ().'
  96.  
  97. Class `C' is called an implementation of the abstract type `S.'  In
  98. this example, we could have made `S' an abstract class and `C' a
  99. subclass of `S,' and we would have had the same effect.  The advantages
  100. of signatures over abstract classes are
  101.  
  102.     - we can build a type hierarchy separate from the class inheritance
  103.       (implementation) hierarchy,
  104.     - subtyping becomes decoupled from inheritance, and
  105.     - signatures can be used with compiled classes, while we cannot
  106.       retrofit an abstract class on top of compiled class hierarchies.
  107.  
  108.  
  109. Differences between Paper and Implementation
  110. --------------------------------------------
  111.  
  112. The paper does not reflect accurately what has been implemented.  The
  113. paper is in the form as we submitted it to the PLDI '93 Conference on
  114. Programming Languages, Design, and Implementation (modulo some corrections
  115. of typos).
  116.  
  117. There are three main differences between the paper and the implementation:
  118.  
  119.      1. For a class to conform to a signature, there must be class member
  120.     functions with EXACTLY the same return type, number of arguments,
  121.     and argument types as specified in the signature.
  122.  
  123.     It is not possible for the argument types of the class member
  124.     function to be supertypes of the argument types as specified in
  125.     the signature.  To implement this, signature table entries would
  126.     need to point to little pieces of code which perform the necessary
  127.     conversions and then call the class member function.
  128.  
  129.      2. Signature pointers and signature references take up three words
  130.     of memory as opposed to two words as mentioned in the paper.  We
  131.     needed to add a virtual function table pointer `vptr' in addition
  132.     to the fields `optr' and `sptr' to be able to call virtual class
  133.     member functions correctly.
  134.  
  135.     The need for a `vptr' field in a signature pointer arises because
  136.     `vptr' fields in objects are not at a well-known location.  If
  137.     every object of a virtual class would have its `vptr' at offset 0,
  138.     say, we would not need a `vptr' field in the signature pointer.
  139.  
  140.      3. Signature table entries take up two words of memory instead of one
  141.     word as described in the paper.  Since signature tables are allocated
  142.     in static storage, the additional memory requirement shouldn't hurt,
  143.     but it makes signature member function calls faster because no bit
  144.     operations are needed to extract the flag that distinguishes between
  145.     virtual and non-virtual class member functions.
  146.  
  147.     Also, to allow a signature pointer to point to an object of a class
  148.     that is defined using multiple inheritance, we need to store more
  149.     information in a signature table entry.  The additional field needed
  150.     is the offset by which `this' is changed when calling the class
  151.     member function.
  152.  
  153.  
  154. Not yet Implemented Language Constructs
  155. ---------------------------------------
  156.  
  157. The following language constructs and features are not yet implemented.
  158. This list is roughly in the order in which we intend to implement them.
  159.  
  160.       - No debug information is output for signature pointers and
  161.     signature tables.
  162.       - The destructor of objects cannot be called though signature pointers.
  163.       - A signature pointer cannot point to an object of a class defined
  164.     by multiple inheritance.
  165.       - Signature default implementations are not implemented.
  166.       - The signature conformance check does not work if the signature
  167.     contains other signature declarations, class declarations, or
  168.     opaque type declarations.  A `typedef' referring to a built-in
  169.     type or a type defined outside the signature causes no problems.
  170.       - Operator and conversion operator member functions of signatures
  171.     cannot be called with operator call or conversion syntax.  They
  172.     can be called with function call syntax, though, such as
  173.     `p->operator+(17).'
  174.       - Signature references are not implemented.
  175.       - Signature inheritance is not implemented.
  176.       - The construct `sigof' for extracting the signature information
  177.     of a class is not implemented.
  178.       - Exceptions cannot be specified with signature member functions.
  179.       - Signature templates are not implemented.
  180.       - Looking up a virtual class member function through a signature
  181.     pointer/reference requires double indirection.  This can be optimized
  182.     by memoizing, so that only the first lookup of a member function
  183.     requires double indirection and further lookups require only one
  184.     indirection.
  185.  
  186. Q: With so many features not yet implemented, is there anything implemented
  187.    at all?
  188.  
  189. A: Yes, all the syntax analysis and error reporting is in place and the
  190.    main language constructs `signature' and signature pointers are nearly
  191.    fully implemented.  The parts that are implemented should cover most
  192.    uses of signatures, and in most cases where something is not implemented
  193.    the compiler reports that.
  194.  
  195.  
  196. Feedback
  197. --------
  198.  
  199. Please, send your questions, comments, suggestions, and complaints to
  200.  
  201.     gb@cs.purdue.edu
  202.  
  203. Cheers,
  204.  
  205. Gerald
  206.