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:	(

	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


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


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

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 ` ().'

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

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

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.


Please, send your questions, comments, suggestions, and complaints to

Gerald Baumgartner
Dept. of Computer Sciences, Purdue University,  W. Lafayette, IN 47907
Internet:, UUCP: ...!{decwrl,gatech,ucbvax}!purdue!gb

>41 The Texas Persistent Store

  The Texas Persistent Store, version 0.1

Texas is a simple, portable, high-performance and (best of all) FREE
persistent store for C++ using "pointer swizzling at page fault time"
to translate persistent addresses to hardware-supported virtual addresses.

Texas is built on top of a normal virtual memory, and relies on the
underlying virtual memory system for caching.  It uses user-level virtual
memory protections to control the faulting of data from a persistent storage
file into virtual memory.

All addresses in a page are translated from a persistent format to
actual virtual addresses when the page is brought into virtual memory,
and subsequent memory references (including pointer traversals) are
just as fast as for non-persistent data.

Texas is easy to use, and is implemented as a UNIX library.  It is small
and can be linked into applications.  It requires no special operating 
system privileges, and persistence is orthogonal to type---objects may be 
allocated on either a conventional transient heap, or on the persistent
heap, as desired.

Texas supports simple checkpointing of heap data.  A log-structured storage
module is under development, and will provide fast checkpointing of small

Texas is beta software, and the current prerelease version supports only
simple single-machine operation.  Future releases will support client-server
operation, a flexible access control scheme, and transaction support.

Texas currently runs under SunOS and ULTRIX, using Sun CC or GNU C++.
Porting to other modern systems (e.g., OS/2, WNT, Mach) should be easy---it
requires only mprotect(), signal(), and sbrk() calls (or their equivalent)
to control virtual memory protection setting and trap handling.

Papers about the pointer swizzling scheme and Texas itself (referenced
below) are available via anonymous ftp from (IP address, as postscript files and in the
directory pub/garbage.

The source code for Texas is also available, in the directory


Paul R. Wilson and Sheetal V. Kakkad, "Pointer Swizzling at Page Fault
Time: Efficiently and Compatibly Supporting Huge Address Spaces on Standard
Hardware," Proc. Second Int'l. Workshop on Object Orientation in Operating
Systems, Sept. 1992, Dourdan, France, pp. 364--377.

Vivek Singhal, Sheetal V. Kakkad, and Paul R. Wilson, "Texas: an Efficient,
Portable Persistent Store", Proc. Fifth Int'l. Workshop on Persistent Object
Systems, Sept. 1992, San Miniato, Italy, pp. 11-33.

>42 OSE C++lib

From: (Graham Dumpleton)
Date: Tue, 16 Nov 1993 11:34:42 +1100 (EST)
Organisation: Telstra International
Phone: +61-2-287-3119


    OSE consists of three C++ class libraries, a build environment based on
    GNU make, programs for documentation extraction and other miscellaneous

    The C++ libraries include generic classes and some UNIX specific classes.
    Collection classes use templates compatable with AT&T C++ 3.0. If you
    have a C++ compiler which does not support templates, a template
    preprocessor supplied with OSE can be used.

    OSE uses a GNU style configure script, making it relatively easy to
    install, even on platforms for which it may not yet have been compiled.
    For DOS users, a script is provided to create a copy of the C++
    libraries suitable for compilation on that platform.


    OSE can be obtained via anonymous ftp from:

      Europe: []
	directory pub/programming/languages/C++/class-libraries/OSE

      United States []
	directory /pub/ose

      Australia: []
	directory pub/otc


    To get further information about OSE, without actually fetching the
    complete package, either fetch the file "ANNOUNCE" from one of the
    ftp sites, or send mail to:

>43 Traces,kiczales,MOP,DI
Go Back Up

Go To Previous

Go To Next