Implementing signatures for C++

Abstract

We outline the design and detail the implementation of a language extension for abstracting types and for decol1pling subLyping and inheritance in C++. This extension gives the user more of the flexibility of dynamic typing while retaining tltc efficiency and security of sLaiic typing. After a brief discussion of syntax and semantics of this language extension and examples of its usc, we present and analyze the cost of three different implementation techniques: a preprocessor to a C++ compiler, an implementation in the front end of a. C++ compiler, and a low-level implementation with back end support. Finally, we discuss the lessons we learned for fut.ure programming language design. 1. Using the same construct (class inheritance) for type abstraction and code sharing limits the power of both and unnecessarily couples implementation and interface specifications.2. In some cases, it is difficult (if not impossible) to retroactively introduce abstract base classes to a class hierarchy for the purpose of type abstraction.3. The hierarchy of abstract types and the class hierarchy of implementations may be difficult to reconcile with each other.We will show how signatures allow us to overcome these problems without a major overhaul of the C++ type system. Separation of Type and Class HierarchiesA problem with a single class hierarchy defining both abstract types and their implementations is that as the type hierarchy becomes more complex, it might become necessary to duplicate code. We use an example from computer algebra [3,2] to demonstrate this problem. Consider the abstract type GeneralHatrix with subtypes BegativeDefiniteHatrix and Orthogonal-Matrix. Both subtypes have functions that are not present in general matrices, e.g., the function inverse(). Assume we have several different implementations of these abstract types, namely DenseMatrix, which implements matrices as two-dimensional arrays, SparseMatrix, which uses lists of triples, and Permutation-Matrix, which is implemented as a special case of sparse matrices that takes advantage of permutation matrices only having one element in each row and column.If we try to model these types and implementations with a single class hierarchy, we end up either duplicating code or violating the type hierarchy. While DenseMatrix can be made a subclass of the abstract classes GeneralMatrix, HegativeDefiniteMa'trix, and OrthogonalHatrix by using multiple inheritance, we cannot do the same for SparseMatrix. Doing so would make PermutationHatrix, which is a subclass of SparseHatrix, an indirect subclass of NegativeDefiniteHatrix. Since permutation matrices are positive definite, this would violate the type hierarchy. The alternative of having a separate class SparseNegativeDefiniteHatrix is not satisfying either since it causes code replications.Similar arguments have been given in the literature to show that the collection class hierarchy of SMALLTALK~80 [13] is not appropriate as a basis for subtyping. While the problem does not arise with dynamic typing, it becomes an issu...

Type-based publish/subscribe

“…To achieve this, type definitions must be separated from type implementations. Several solutions have appeared to augment existing programming languages that lack this separation, e.g, by introducing signatures for C++ [BR97]. We continue this study with separation of these two aspects in mind.…”

Overview of the Mathemagix Type System

“…Several C++ extensions with "signatures" [2] or "concepts" [34] have been proposed in order to add such requirements. C++ also imposes a lot of restrictions on how templates can be used.…”

Extending Erlang by utilising RefactorErl

“…Baumgartner and Russo [4] implemented the concept of type signatures in C++ by translating new elements back to C++. Eden [27] extends Haskell with a small set of syntactic constructs for explicit process specification and creation, and translates back to plain Haskell by employing Template Haskell.…”