Object-Orientation FAQ

40 C++ Signatures (subtyping)

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 01.06.95.