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