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