From: gb@cs.purdue.edu (Gerald Baumgartner) Newsgroups: comp.object,comp.lang.c++ Subject: signature implementation for G++ 2.5.2 and tech report available Date: 4 Nov 1993 12:03:00 -0500 Organization: Department of Computer Sciences, Purdue University
Announcing the paper
Signatures: A C++ Extension for Type Abstraction and Subtype Polymorphism
by Gerald Baumgartner and Vincent F. Russo. Tech report CSD-TR-93-059, Dept. of Computer Sciences, Purdue University, September 1993. Submitted to Software Practice & Experience.
and a beta release of our implementation of
signatures for GCC 2.5.2.
How to Get that Stuff? ----------------------
You can get both the paper and the implementation by ftp from
host: ftp.cs.purdue.edu (128.10.2.1)
login: anonymous
password: your e-mail address
directory: pub/gb
files: COPYING Copyright notice.
README This file.
Signatures.{dvi,ps}.gz DVI and Postscript versions
of the paper.
gcc-2.5.2.sig.diff.gz Patch to upgrade GCC 2.5.2.
test.tar.gz Test files and script to run the tests.
To make GCC 2.5.2 understand signatures, just copy the context diff file into the GCC source directory, type
gunzip gcc-2.5.2.sig.diff.gz patch < gcc-2.5.2.sig.diff
and rebuild and install `gcc,' `cc1plus,' the man pages, and the manual.
For compiling C++ code containing signatures, you need to use the command line option
-fhandle-signatures
We tested our extension on Sun 4 only, but since there are no changes to the compiler backend, it is expected work on other architectures as well. To test whether it works on your architecture, unpack the file `test.tar.gz' and run the shell script
Test
It compiles the test programs and runs them. If everything works correctly, all the test programs (all 40 of them) should print
Hello World.
What are Signatures anyway? ---------------------------
Roughly, signatures are type abstractions or interfaces of classes. They are related to ML's signatures, categories in Axiom, definition modules in Modula-2, interface modules in Modula-3, and types in POOL-I.
The main language constructs added are signatures and signature pointers. For example, the signature declaration
signature S
{
int foo (void);
int bar (int);
};
defines a new abstract type `S' with member functions `int foo (void)' and `int bar (int).' Signature types cannot be instantiated since they don't provide any implementation. Only signature pointers and signature references can be defined. For example,
C obj; S * p = &obj;
defines a signature pointer `p' and initializes it to point to an object of class type `C,' where `C' is required to contain the public member functions `int foo (void)' and `int bar (int).' The member function call
int i = p->foo ();
executes then `obj.foo ().'
Class `C' is called an implementation of the abstract type `S.' In this example, we could have made `S' an abstract virtual class and `C' a subclass of `S,' and we would have had the same effect. The advantages of signatures over abstract virtual classes are
- you can build a type hierarchy separate from the class inheritance (implementation) hierarchy, - subtyping becomes decoupled from inheritance, and - signatures can be used with compiled classes, while you cannot retrofit an abstract virtual class on top of compiled class hierarchies.
For more information, please, see the paper.
What's Implemented and what's not? ----------------------------------
Signature declarations and signature pointers are implemented and working. For examples of what's working and how to use them you can have a look at the test files.
The following bugs are known:
- The destructor of objects cannot be called though signature pointers.
- A signature pointer cannot point to an object of a class defined
by multiple inheritance.
- The signature conformance check does not work if the signature
contains other signature declarations or class declarations.
- Operator and conversion operator member functions of signatures
can only be called with function call syntax, such as
`p->operator+(17),' but not with operator or conversion syntax.
The following language constructs and features are not yet implemented:
- constants in signatures,
- signature references,
- signature inheritance,
- the `sigof' (signature of a class) construct,
- views (not even the parsing is done),
- signature templates, and
- exception specifications in signature member function declarations.
The following optimization is not implemented:
- Looking up a virtual class member function through a signature
pointer/reference requires double indirection. This can be optimized
by memoizing, so that only the first lookup of a member function
requires double indirection and further lookups require only single
indirection.
The items above are roughly in the order in which they will be implemented.
Besides bug fixes, the main features that have been implemented since the last release are default implementations of signature member functions and opaque types.
Feedback --------
Please, send your questions, comments, suggestions, and complaints to
gb@cs.purdue.edu
--
Gerald Baumgartner
Dept. of Computer Sciences, Purdue University, W. Lafayette, IN 47907
Internet: gb@cs.purdue.edu, UUCP: ...!{decwrl,gatech,ucbvax}!purdue!gb
This document was translated by ms2html v1.8 on 04.06.96.