The C Object System ∗

Using C as a High-Level Object-Oriented Language

Laurent Deniau
CERN – European Organization for Nuclear Research
[email protected]

Abstract 1. Motivation
The C Object System (C OS) is a small C library which im- The C Object System (C OS) is a small framework which
plements high-level concepts available in C LOS, O BJECTIVE - adds an object-oriented layer to the C programming lan-
C and other object-oriented programming languages: uni- guage [1, 2, 3] using its programmable capabilities1 while
form object model (class, metaclass and property-metaclass), following the simplicity of O BJECTIVE -C [5, 6] and the
generic functions, multi-methods, delegation, properties, ex- extensibility of C LOS [8, 9, 10]. C OS aims to fulfill sev-
ceptions, contracts and closures. C OS relies on the program- eral general principles rarely met in a single programming
mable capabilities of the C programming language to extend language: simplicity, extensibility, reusability, efficiency and
its syntax and to implement the aforementioned concepts portability.
as first-class objects. C OS aims at satisfying several general
principles like simplicity, extensibility, reusability, efficiency 1.1 Context
and portability which are rarely met in a single program- C OS has been developed in the hope to solve fundamen-
ming language. Its design is tuned to provide efficient and tal programming problems encountered in scientific comput-
portable implementation of message multi-dispatch and mes- ing and more specifically in applied metrology [11, 12]. Al-
sage multi-forwarding which are the heart of code extensi- though this domain looks simple at first glance, it involves
bility and reusability. With COS features in hand, software nonetheless numerous fields of computer science; from low-
should become as flexible and extensible as with scripting level tasks like the development of drivers, protocols or state
languages and as efficient and portable as expected with C machines, the control of hardware, the acquisition of data,
programming. Likewise, C OS concepts should significantly the synchronization of concurrent processes, or the numer-
simplify adaptive and aspect-oriented programming as well ical analysis and modeling of huge data sets; to high-level
as distributed and service-oriented computing. tasks like the interaction with databases or web servers, the
Categories and Subject Descriptors D.3.3 [C Program- management of remote or distributed resources, the visual-
ming Language]: Language Constructs and Features; D.1.5 ization of complex data sets or the interpretation of scripts
[Programming Techniques]: Object-oriented Programming. to make the system configurable and controllable by non-
programmers [13, 14, 15]. Not to mention that scientific
General Terms Object-oriented programming. projects commonly have to rely on sparse human resources
Keywords Adaptive object model, Aspects, Class cluster, to develop and maintain for the long term such continually-
Closure, Contract, Delegation, Design pattern, Exception, evolving-systems (i.e. R&D). Therefore the challenge is am-
Generic function, Introspection, High-order message, Mes- bitious but I firmly believe that C OS provides the required
sage forwarding, Meta class, Meta-object protocol, Multi- features to simplify the development and the support of such
method, Open class model, Predicate dispatch, Program- systems as well as a wide variety of software projects.
ming language design, Properties, Uniform object model. 1.2 Principles
∗ COS project: http://sourceforge.net/projects/cos Given the context, it is essential to reduce the multiplicity of
the technologies involved, to simplify the development pro-
cess, to enhance the productivity, to guarantee the extensibil-
ity and the portability of the code and to adapt the required
skills to the available resources. Hence, the qualities of the
programming language are essential for the success of such
projects and should focus on the following principles:
[Copyright notice will appear here once ’preprint’ option is removed.] 1 In the sense of “Lisp is a programmable programming language”, [4].

Draft research paper for OOPSLA’09 1 2009/5/20

Simplicity The language should be easy to learn and use. “If a system is continually changing, or if you want users
The training curve for an average programmer should be as to be able to extend it, then the Dynamic Object Model ar-
short as possible what implies in particular a clear and con- chitecture is often useful. [...] Systems based on Dynamic
cise syntax. Simplicity should become an asset which guar- Object Models can be much smaller than alternatives. [...] I
antees the quality of the code and allows to write complex am working on replacing a system with several millions lines
constructions without being penalized by a complex formal- of code with a system based on a dynamic object model that
ism or by the multiplicity of the paradigms. C OS can be I predict will require about 20,000 lines of code. [...] This
learned within a few days by C programmers with some makes these systems easier to change by experts, and (in
knowledge of object-oriented concepts, although exploiting theory) should make them easier to understand and main-
the full power of C OS requires some experience. tain. But a Dynamic Object Model is hard to build. [...] A
system based on a Dynamic Object Model is an interpreter,
Extensibility The language should support the addition of
and can be slow.”.
new features or the improvement of existing features with-
This adaptive object model [21, 22] is actually what C OS
out changing significantly the code or the software archi-
provides, but at the level of the C programming languages
tecture. Concepts like polymorphism, message dispatch and
without significant efficiency loss. In particular, C OS has
open class model help to achieve good flexibility and exten-
been designed to support efficiently two key concepts —
sibility by reducing coupling. But they usually have a strong
multi-methods and fast generic delegation — and provides
impact on the efficiency. C OS dispatches messages with an
a uniform object model where classes, generics and meth-
efficiency in the range of the C ++ virtual member functions.
ods are first-class objects. Incidentally, C OS strengthens in-
Reusability The language should support code reusability, herently all the guidelines stated in [23] to build “flexible,
namely the ability to reuse or quickly adapt existing compo- usable and reusable object-oriented frameworks” as well
nents to unforeseen tasks. It is easier to achieve this goal if as architectural pattern proposed in [24] to design flexible
the language allows to write generic code, either by param- component-based frameworks.
eterization, either by abstraction, to ease the componentiza-
tion of design patterns [16, 17, 18]. To support the develop- 2. Overview
ment of generic components, C OS provides multi-methods
C OS is a small framework entirely written in portable2
to handle dynamic and polymorphic collaboration and dele-
C99 which provides programming paradigms like objects,
gation to handle dynamic and polymorphic composition.
classes, metaclasses, generic functions, multi-methods, del-
Efficiency A general purpose programming language must egation, properties, exceptions, contracts and closures. C OS
be efficient, that is it must be able to translate all kinds of al- syntax and features are directly available at the C source
gorithms into programs running with predictable resource code level through the use of the language keywords defined
usage (mainly C PU and memory) consistent with the pro- in the header file <cos/Object.h>.
cesses carried out. In this respect, programming languages
with an abstract machine close to the physical machine — 2.1 Concepts
a low-level language — offer generally better results. C is Polymorphism This concept available in object-oriented
admittedly known to achieve good efficiency. programming languages is the heart of software extensibil-
Portability A general purpose programming language must ity because it postpones to runtime the resolution of methods
be portable, that is it must be widely available on many ar- invocation and reduces coupling between callers and callees.
chitectures and it must be accessible from almost any other Besides, if the polymorphic types are dynamic, the coupling
languages (F FI). This point often neglected brings many ad- becomes almost inexistent and code size and complexity
vantages: it improves the software reliability, it reduces the are significantly reduced. On one hand, these simplifications
deployment cost, it enlarges the field of potential users and usually improve the programmer understanding who makes
it helps to find trained programmers. Regarding this point, less conceptual errors, draws simpler designs and increases
normalized programming languages (I SO) get the advantage. its productivity. On the other hand, dynamic typing post-
ISO C89 is normalized and well known for its availability pones the detection of unknown messages at runtime, with
and portability. the risk to see programs ending prematurely. But well tested
software reduce this risk to exceptional situations.
1.3 Proposition
Collaboration Software development is mainly about build-
C OS extends the C programming language with concepts ing collaborations between entities, namely objects. As soon
[19] mostly borrowed from O BJECTIVE -C and C LOS. The as polymorphic objects are involved everywhere to ensure
choice of designing the language as a C library instead of a good software extensibility and reusability, one needs poly-
compiler allowed to quickly explore various object models, morphic collaboration implemented by multi-methods. They
but R.E. Johnson’s paper on the dynamic object model [20]
definitely focused my research towards the final design: 2 Namely C89 and C99 variadic macros.

Draft research paper for OOPSLA’09 2 2009/5/20

reduce strong coupling that exist in the Visitor pattern (or
equivalent) as well as the amount of code needed to achieve Function/Behavior/Verb Type/State/Noun
the task. C OS provides message multi-dispatch with an effi- defgeneric defclass
function declaration structure definition
ciency in the range of the C ++ virtual member function. (interface) (definition)
1 1..5
Composition The composition of objects and behaviors is
a well known key-concept in software design. It enhances
software flexibility by introducing levels of indirection in
objects and behaviors. Most structural and behavioral design Specialization
patterns described in [28] introduce such indirections, but at defmethod
function definition
the price of an increased code complexity and coupling and (implementation)
hence a decreased reusability of the components built. The
delegation is an effective mechanism which allows to man- Figure 1. Roles of C OS components and their equivalent C-
age the composition of both, objects and behaviors, without forms. Multi-methods are classes specialization of generics.
introducing coupling. C OS provides delegation with the ef-
ficiency of message dispatch, seemingly a unique feature.
Classes Classes play the same role as structures in C and
Reflection Reflection is a powerful aspect of adaptive ob- define object attributes. They are bound to their superclass
ject models which, amongst others, allows to mimic the be- and metaclasses and define supertypes-subtypes hierarchies.
havior of interpreters. C OS provides full introspection and
limited intercession on polymorphic types and behaviors, Generics Generics play the same role as function declara-
that is classes, generics and methods, as well as object at- tions in C and define messages. They are essential actors of
tributes through the definition of properties. Since all C OS code extensibility and ensure correctness of formal parame-
components are first-class objects, it is trivial to replace cre- ters of messages between callers and callees.
ational patterns [28] by generic functions (section 8.1). Methods Methods play the same role as function defini-
tions in C and define specializations of generics. A method
Encapsulation Encapsulation is a major concern when de-
is invoked if the message belongs to its generic and the re-
veloping libraries and large-scale software. C OS enforces
ceivers match its classes (multi-methods).
encapsulation of class implementation because encapsula-
tion is not only a matter of managing coupling but also a
The similarities between C OS components and their equiv-
design issue. Besides, the object behaviors are represented
alent C-forms let C programmers with some notions of
by generics which favors the separation of concerns of inter-
object-oriented design be productive rapidly. The open ob-
faces and reduces cross-interfaces dependencies [23]. More-
ject model allows to define components in different places
over, the open class model of C OS allows to extend classes
and therefore requires an extra linking iteration to collect
on need without breaking the encapsulation (i.e. without “re-
their external symbols: link → collect3 → re-link. This fast
opening the box”) and reduces the risk of premature design.
iteration is automatically performed by the makefiles com-
Ownership The management of object life cycles requires ing with C OS before the final compilation stage that builds
a clear policy of ownership and scope rules. In languages like the executable or the dynamic library.
C and C ++ where semantic by value prevails, the burden is
put on the programmer’s shoulders. In languages like JAVA, 2.3 Syntax
C # and D where semantic by reference prevails, the burden C OS introduces new keywords to extend the C language with
is put on the garbage collector. In this domain, C OS lets the a user-friendly syntax half-way between O BJECTIVE -C and
developer choose between garbage collection (e.g. Boehm C LOS. C OS parses its syntax and generates code with the
GC [25]) and manual reference counting with rich semantic help of its functional C preprocessing library4 ; a module of
(section 3.5). a few hundred C macros which was developed for this pur-
pose. It offers limited parsing capabilities, token recognition,
Concurrency C OS has been designed from the beginning
token manipulation and algorithms like eval, map, filter, fold,
with concurrency in mind and shares only its dictionary of
scan, split borrowed from functional languages and working
static components. Per thread resources like message caches
on tuples of tokens. As a rule of thumb, all C OS symbols
and autorelease pools rely on either thread-local-storage or
and macros are mangled to avoid unexpected collisions with
thread-specific-key according to the availability.
other libraries, including keywords which can be disabled.
2.2 Components Despite of its dynamic nature, C OS tries hard to detect
all syntax errors, type errors and other mistakes at compile-
The object-oriented layer of C OS is based on three compo-
nents (figure 1) borrowed from C LOS which characterize the 3 C OS mangled symbols are collected with the nm command or equivalent.
open object model described in depth in [8] and [9]. 4 The description of this cpp library is beyond the scope of this paper.

Draft research paper for OOPSLA’09 3 2009/5/20

 time by using static asserts or similar tricks and to emit
meaningful diagnostics. The only point that C OS cannot class-declaration:
check at compile time is the understanding of a message by useclass( class-decl-list );
the receivers; an important “feature” to reduce coupling.
The syntax and grammar of C OS are summarized in the class-decl-list:
figures 2, 7, 8, 9, 10 and 11, following the notation of the class-decl
C99 standard [1]. class-decl-list , class-decl

3. Classes (nouns) class-decl:

class-name
C OS allows to define and use classes as easily as in other ( class-name ) local-name
object-oriented programming languages.

3.1 Using classes class-definition:

defclass( class-specifier )
The useclass() declaration allows to access to classes as ,→ struct-declaration-list (c99)
first-class objects. The following simple program highlights ,→ endclass
the similarities between C OS and O BJECTIVE -C:
1 #include <cos/Object.h> class-instantiation:
2 #include <cos/generics.h> makclass( class-specifier );
3

4 useclass(Counter, (Stdout)out); class-specifier:

5 class-name
6 int main(void) { class-name , (root class)
7 OBJ cnt = gnew(Counter); class-name , superclass-name
8 gput(out,cnt);
9 gdelete(cnt);
{class, superclass, local}-name:
10 }
identifier (c99)
which can be translated line-by-line into O BJECTIVE -C by:
Figure 2. Syntax summary of classes.
1 #include <objc/Object.h>
2 // Counter interface isn’t exposed intentionally
3 Lines 7 – 9 show the life cycle of objects, starting with
4 @class Counter, Stdout; gnew (resp. new) and ending with gdelete (resp. release).
5
They also show that generics are functions (e.g. one can
6 int main(void) { take their address). Finally, the line 8 shows an example of
7 id cnt = [Counter new];
multi-method where the message gput(_,_) will look for
8 [Stdout put: cnt];
9 [cnt release];
the specialization gput(mStdout,Counter) whose meaning
10 } is discussed in section 5. In order to achieve the same task,
O BJECTIVE -C code has to rely on the Visitor pattern, a bur-
Line 2 makes the standard generics like gnew, gput and den that requires more coding, creates static dependencies
gdelete5 visible in the current translation unit. O BJECTIVE - (strong coupling) and is difficult to extend.
C doesn’t need this information since methods are bound
to their class, but if the user wants to be warned for incor- 3.2 Defining classes
rect use of messages, the class definition must be visible. The definition of a class is very similar to a C structure:
This example shows that C OS requires less information than
O BJECTIVE -C to handle compile-time checks what leads to defclass(Counter)
int cnt;
better code insulation and reduces useless recompilations.
endclass
Moreover, it offers fine tuning of exposure of interfaces since
only the used generic functions have to be visible. which is translated in O BJECTIVE -C as:
Line 4 declares the class Counter6 and the alias out for
@interface Counter : Object {
local replacement of the class Stdout, both classes being int cnt;
supposedly defined elsewhere. In line 7, the generic type OBJ }
is equivalent to id in O BJECTIVE -C. // declaration of Counter methods not shown
5 By
@end
convention, the name of generics always starts by a ’g’.
6 By convention, the name of classes always starts by an uppercase letter. or equivalently in C LOS as:

Draft research paper for OOPSLA’09 4 2009/5/20

 }
NIL NIL // declaration of MilliCounter methods not shown
subclass of @end
Object Nil and in C LOS:
(defclass MilliCounter (Counter) ((mcnt)) )
Method Behavior Proxy Property Predicate In the three cases, the derived class inherits the attributes and
the methods of its superclass. Since C OS aims at insulating
Generic Class Tracer TrueFalse classes as much as possible, it discourages direct access to
superclass attributes by introducing a syntactic indirection
which forces the user to write obj->Super.attribute in-
MetaClass True False
stead of obj->attribute. The inheritance of multi-methods
has a different meaning and will be discussed in section 5.
PropMetaClass
Root class Defining a root class is an exceptional task but it
may be a necessity in some rare cases. C OS uses the terminal
Figure 3. Subset of C OS core classes hierarchy. symbol ⊥7 (represented by ’_’) to declare a class as a root
class. For example, Object is an important root class with
(defclass Counter (Object) ((cnt)) ) the following simple definition:

The Counter class derives from the root class Object — the defclass(Object,_)
U32 id; // object’s class identity
default behavior when the superclass isn’t specified — and
U32 rc; // reference counting
defines the attribute cnt. endclass
Class visibility What must be visible and when? In order But its methods must be defined with care since they provide
to manage coupling, C OS provides three levels of visibility: all the essential functionalities inherited by other classes.
none, declaration and definition. If you only use the generic
type OBJ, nothing is required (no coupling): Class rank C OS computes at compile-time the inheritance
depth of each class. The rank of a root class is zero (by
OBJ gnew(OBJ cls) {
definition) and each successive subclass increases the rank.
return ginit(galloc(cls));
} Dynamic inheritance C OS provides the message gchange-
Class(obj,cls) to change the class of obj to cls iff it is a
If you want to create instances of a class, only the declaration
superclass of obj’s class; and the message gunsafeChange-
is required (weak coupling):
Class(obj,cls,spr) to change the class of obj to cls iff both
OBJ gnewBook(void) { classes share a common superclass spr and the instance size
useclass(Book); // local declaration of cls is lesser or equal to the size of obj. These messages are
return gnew(Book); useful for implementing class clusters, state machines and
}
adaptive behaviors.
If you want to define subclasses, methods or instances with
automatic storage duration, the class definition must be visi- 3.4 Meta classes
ble (strong coupling). Like in O BJECTIVE -C, a C OS class definition creates a
parallel hierarchy of metaclass which facilitates the use of
3.3 Class inheritance classes as first-class objects. Figure 4 shows the complete
Class inheritance is as easy in C OS as in other object- hierarchy of the PropMetaClass class, including its meta-
oriented programming languages. Figure 3 shows the hi- classes.
erarchies of the core classes of C OS deriving from the root Class metaclass The metaclasses are classes of classes im-
classes Object and Nil. As an example, the MilliCounter plicitly defined in C OS to ensure the coherency of the type
class defined hereafter derives from the class Counter to system: to each class must correspond a metaclass [26]. Both
extend its resolution to thousandths of count: inheritance trees are built in parallel: if a class A derives from
defclass(MilliCounter, Counter) a class B, then its metaclass mA8 derives from the metaclass mB
int mcnt; — except the root classes which derive from NIL and have
endclass their metaclasses deriving from Class to close the inheri-
which gives in O BJECTIVE -C: tance path. Metaclasses are instances of the class MetaClass.
@interface MilliCounter : Counter { 7⊥ means “end of hierarchy” or NIL, but not the class Nil.
int mcnt; 8 The metaclass name is always the class name prefixed by a ’m’.

Draft research paper for OOPSLA’09 5 2009/5/20

 NIL
Class
subclass of
NIL subclass of
instance of Nil
mObject

Object pmObject
mBehavior Property Predicate

Behavior pmBehavior
mClass name size TrueFalse Ordered

Class pmClass
mMetaClass True False Lesser Equal Greater

MetaClass pmMetaClass
mPropMetaClass Figure 5. Subset of C OS core class-predicates hierarchy.
PropMetaClass pmPropMetaClass
3.5 Class instances
Object life cycle The life cycle of objects in C OS is very
Figure 4. C OS core classes hierarchy with metaclasses. similar to other object-oriented programming languages,
namely it starts by creation (galloc) followed by initial-
ization (ginit and variants) and ends with deinitialization
Property metaclass In some design patterns like Singleton
(gdeinit) followed by destruction (gdealloc). In between,
or Class Cluster, or during class initialization (section 3.6),
the user manages the ownership of objects (i.e. dynamic
the automatic derivation of the class metaclass from its su-
scope) with gretain, grelease and gautoRelease like in
perclass metaclass can be problematic as detailed in [27].
O BJECTIVE -C. The copy initializer is the specialization of
To solve the problem C OS associates to each class a prop-
the generic ginitWith(_,_) for the same class twice. The
erty metaclass which cannot be derived; that is all methods
designated initializer is the initializer with the most cover-
specialized on the property metaclass can only be reached
age which invokes the designated initializer of the superclass
by the class itself. In order to preserve the consistency of
using next_method. Other initializers are secondary initial-
the hierarchy, a property metaclass must always derive from
izers which must invoke the designated initializer [7].
its class metaclass, namely pmA9 (resp. pmB) derives from mA
(resp. mB) as shown in the figure 4. Property metaclasses are Object type In C OS (resp. O BJECTIVE -C), objects are al-
instances of the class PropMetaClass. ways of dynamic type because the type of galloc (resp.
alloc) is OBJ (resp. id). Since it is the first step of the life cy-
Class objects With multi-methods and metaclasses in cle of objects in both languages, the type of objects can never
hands, it is possible to use classes as common objects. Fig- be known statically, except inside their own multi-methods.
ure 5 shows the hierarchy of the core class-objects used That is why C OS (resp. O BJECTIVE -C) provides the mes-
in C OS to specialized multi-methods with specific states. sage gisKindOf(obj,cls) (resp. [obj isKindOf: cls]) to in-
For instance messages like gand, gor and gnot are able to spect the type of objects. But even so, it would be danger-
respond to messages containing the class-predicates True, ous to use a static cast to convert an object into its expected
False and TrueFalse. The root class Nil is a special class- type because dynamic design patterns like Class Cluster and
object which means no-object but still safe for message dis- Proxy might override gisKindOf for their use. C OS also pro-
patch: sending a message to Nil is safe, but not to NIL. vides the message gclass(obj) which returns obj’s class.
Type system The C OS type system follows the rules of Object identity In C OS, an object is bounded to its class
O BJECTIVE -C, that is polymorphic objects have opaque through a unique 32-bit identifier produced by a linear con-
types (ADT) outside their methods and are statically and gruential generator which is also a generator of the cyclic
strongly typed inside; not to mention that multi-methods re- groups N/2k N for k = 2..32. This powerful algebraic prop-
duce significantly the need for runtime identification of poly- erty allows to retrieve efficiently the class of an object from
morphic parameters. Furthermore, the set of class – meta- the components table using its identifier as an index (Fig-
class – property-metaclass forms a coherent hierarchy of ure 6). Comparing to pointer-based implementations, the
classes and types which offers better consistency and more unique identifier has four advantages:
flexibility than in O BJECTIVE -C and S MALLTALK where
metaclasses are not explicit and derive directly from Object. It ensures better behavior of cache lookups under heavy
load (uniform hash), it makes the hash functions very fast
9 The property metaclass name is always the class name prefixed by a ’pm’. (sum of shifted ids), it is smaller than pointers on 64-bit

Draft research paper for OOPSLA’09 6 2009/5/20

 Class initialization For the purpose of pre-initialization,
Dictionary of behavioral components C OS ensures to invoke once by ascending class rank (super-
class first) all specializations of the message ginitialize
on property metaclass before the first message is sent. Like-
obj->id - - obj’s class wise, C OS ensures to invoke once by descending class
rank (subclasses first) all specializations of the message
gdeinitialize on property metaclass after exiting main.
table[obj->id & (table_size-1)]

Figure 6. Lookup to retrieve object’s class from object’s id. 4. Generics (verbs)
We have already seen in previous code samples that generics
machines and it can store extra information (high bits) like can be used as functions. But generics take in fact multiple
class ranks to speedup linear lookup in class hierarchies. forms and define each:
• a function declaration (defgeneric) which ensures the
Automatic objects Since C OS adds an object-oriented correctness of the signature of its methods (defmethod),
layer on top of the C programming language, it is possi- aliases (defalias) and next-methods (defnext).
ble to create objects with automatic storage duration (e.g.
on the stack) using compound literals (C99). In order to • a function definition used to dispatch the message and to
achieve this, the class definition must be visible and the find the most specialized method belonging to the generic
developer of the class must provide a special constructor. and matching the classes of the receivers.
For example the constructor aStr(’’a string’’)10 is equiv- • an object holding the generic’s metadata: the selector.
alent to the O BJECTIVE -C directive @’’a string’’. C OS al-
ready provides automatic constructors for many common A generic function has one definition of its semantics and is,
objects like Char, Short, Int, Long, Float, Complex, Range, in effect, a verb raised at the same level of abstraction as a
Functor and Array. Automatic constructors allow to create noun [4]. Figure 7 summarizes the syntax of generics, half
efficiently temporary objects with local scope and enhance way between the syntax of generic’s definition in C LOS and
the flexibility of multi-methods. For example, the initializer the syntax of method’s declaration in O BJECTIVE -C.
ginitWith(_,_) and its variants can be used in conjunc- Generic rank The rank of a generic is the number of re-
tion with almost all the automatic constructors aforemen- ceivers in its param-list. C OS supports generics from rank
tioned. Thanks to the rich semantic of C OS reference count- 1 to 5 what should be enough in practice since rank 1 to 4
ing, if an automatic object receives the message gretain or already cover all the multi-methods defined in the libraries
gautoDelete, it is automatically cloned using the message of C ECIL and DYLAN [29, 30, 36].
gclone and the new copy with dynamic scope is returned.
4.1 Message dispatch
Static objects Static objects can be built in the same way
as automatic objects except that they require some care in C OS dispatch uses global caches (one per generics rank)
multi-threaded environments. It is worth to note that all C OS implemented with hash tables to speedup method lookups.
components have static storage duration and consequently The caches solve slot collisions by growing until they reach
are insensitive to ownership and cannot be destroyed. a configurable upper bound of slots. After that, they use
packed linked list incrementally built to hold a maximum of
3.6 Implementing classes 3 cells. Above this length, the caches start to forget cached
Class instantiations create the class objects using the key- methods — a required behavior when dynamic class creation
word makclass and the same class-specifier as the corre- is supported. The lookup uses fast asymmetric hash func-
sponding defclass. C OS checks at compile-time if both tions (sum of shifted ids) to compute the cache slots and en-
definitions match. The counters implementation follows: sures uniform distribution even when all selectors have the
same type or specializations on permutations exist.
makclass(Counter);
makclass(MilliCounter,Counter); Fast messages C OS lookup is simple enough to allow
which is equivalent in O BJECTIVE -C to: some code inlining on the caller side to speedup message
dispatch. Fast lookup is enabled up to the generic rank spec-
@implementation Counter ified by COS_FAST_MESSAGE — from disabled (0) to all (5,
// definition of Counter methods not shown
default) — before the generic definitions (defgeneric).
@end
@implementation MilliCounter : Counter 4.2 Declaring generics
// definition of MilliCounter methods not shown
@end Generic declarations are less common than class declara-
tions but they can be useful when one wants to use gener-
10 By convention, automatic constructors always starts by an ’a’. ics as first-class objects. Since generic definitions are more

Draft research paper for OOPSLA’09 7 2009/5/20

 4.3 Defining generics
generic-declaration:
usegeneric( generic-decl-list ); Definitions of generics correspond to function declarations
in C and differ from O BJECTIVE -C method declarations by
generic-decl-list: the fact that they are neither bound to classes (prefix ’-’) nor
generic-decl to metaclasses (prefix ’+’). The following definitions:
generic-decl-list , generic-decl defgeneric(void, gincr, _1); // rank 1
defgeneric(void, gincrBy, _1, (int)by); // rank 1
generic-decl: defgeneric(OBJ , ginitWith, _1, _2); // rank 2
generic-name defgeneric(OBJ , ggetAt, _1, at); // rank 2
( generic-name ) local-name defgeneric(void, gputAt, _1, at, what); // rank 3

can be translated into C LOS as:

generic-definition:
defgeneric( generic-specifier ); (defgeneric incr (obj))
(defgeneric incr-by (obj by))
generic-variadic-definition: (defgeneric init-with (obj with))
defgenericv( generic-specifier , ...); (defgeneric get-at (obj at))
(defgeneric put-at (obj at what))
generic-specifier: Selector parameters like at are called open types (no paren-
return-type , generic-def , param-list thesis) since their type can vary for each specialization.
Other parameters like by are called closed types (with paren-
generic-def: thesis) and have fixed types and names: specializations must
generic-name use the same types and names as defined by the generic. This
( class-name ) generic-name enforces the semantic of monomorphic parameters which
could be ambiguous otherwise: int offset vs. int index.
param-list:
param-decl 5. Methods
param-list , param-decl
Methods are defined using a similar syntax as generics
param-decl: as summarized in figure 8. The following code defines a
param-nameopt (selector) method specialization of the generic gincr for the class
( param-type ) param-name Counter:
defmethod(void, gincr, Counter)
{return, param}-type: self->cnt++;
type-name (c99) endmethod
which in O BJECTIVE -C gives (within @implementation):
{generic, param}-name:
identifier (c99) - (id) incr {
self->cnt++;
Figure 7. Syntax summary of generics. }

often visible than class definitions, it is common to rename Methods specializers The receivers can be equivalently
them locally as in the following short example: accessed through selfn11 whose types correspond to their
void safe_print(OBJ obj) { class specialization (e.g. struct Counter*) and through un-
usegeneric( (gprint) prn ); named parameters _n whose types are OBJ for 1 ≤ n ≤ g,
if ( gunderstandMessage1(obj, prn) == True ) where g is the rank of the generic. It is important to un-
gprint(obj); derstand that selfn and _n are bound to the same object,
} but selfn provides a statically typed access which allows to
treat C OS objects like normal C structures.
which gives in O BJECTIVE -C:
void safe_print(id obj) { Multi-methods Multi-methods are methods with more
SEL prn = @selector(print); than one receiver and do not require special attention in
if ( [obj respondsToSelector: prn] == YES ) C OS. The following example defines the assign-sum opera-
[obj print]; tor (i.e. +=) specializations which adds 2 or 3 Counters:
}
11 self and self1 are equivalent.

Draft research paper for OOPSLA’09 8 2009/5/20

 defmethod(OBJ, gaddTo, Counter, Counter)
self->cnt += self2->cnt; method-definition:
retmethod(_1); // return self defmethod( method-specifier )
endmethod ,→ method-statement
,→ endmethod
defmethod(OBJ, gaddTo2, Counter,Counter,Counter)
self->cnt += self2->cnt + self3->cnt; method-specifier:
retmethod(_1); // return self return-type , method-def , param-list
endmethod
method-def:
About half of C OS generics have a rank > 1 (multi-methods) generic-name
and cover more than 80% of all the methods specializations. ( generic-name ) tag-nameopt (around method)

Class methods Class methods are methods specialized for method-statement:

classes deriving from Class what includes all metaclasses: compound-statement (c99)
defmethod(void, ginitialize, pmMyClass) compound-statement-with-contract (contract)
// do some initialization specific to MyClass.
endmethod method-return-statement:
retmethod( expressionopt );
defmethod(OBJ, gand, mTrue, mFalse)
retmethod(False); // return the class−object False method-alias-definition:
endmethod defalias( generic-specifier );
Method aliases C OS allows to specialize compatible gener-
ics with the same implementation. The following aliases de- alternate-next-method-definition:
fine specializations for gpush, gtop and gpop which share defnext( generic-specifier );
the specializations of gput, gget and gdrop respectively:
next-method-statement:
defalias(void, (gput )gpush, Stack, Object); next method( argument-expression-list );
defalias(OBJ , (gget )gtop , Stack, Object);
defalias(void, (gdrop)gpop , Stack, Object);
forward-message-statement:
Method types In order to support fast generic delegation forward message( argument-expression-list );
(section 5.2), C OS must use internally the same function
types (i.e. same C function signatures) for methods imple- Figure 8. Syntax summary of methods.
mentation belonging to generics of the same rank:
5.1 Next method
void (*IMP1)(SEL,OBJ,void*,void*);
void (*IMP2)(SEL,OBJ,OBJ,void*,void*); The next_method principle borrowed from C LOS12 is an
void (*IMP3)(SEL,OBJ,OBJ,OBJ,void*,void*); elegant answer to the problem of superclass(es) methods
... call (i.e. late binding) in the presence of multi-methods.
The first parameter _sel is the message selector (i.e. generic’s The following sample code defines a specialization of the
object) used by the dispatcher, the OBJs _n are the objects message gincrBy for the class MilliCounter which adds
used as selectors (i.e. receivers) by the dispatcher, the penul- thousandths of count to the class Counter:
timate parameter _arg is a pointer to the structure storing 1 defmethod(void, gincrBy, MilliCounter, (int)by)
the closed arguments of the generic (if any) and the last pa- 2 self->mcnt += by;
rameter _ret is a pointer to the placeholder of the returned 3 if (self->mcnt >= 1000) {
value (if any). The responsibilities are shared as follow: 4 defnext(void, gincr, MilliCounter);
• The generic functions are in charge to pack the closed
5 self->mcnt -= 1000;
6 next_method(self); // call gincr(Counter)
arguments (if any) into the structure pointed by _arg, to 7 }
create the placeholder pointed by _ret for the returned 8 endmethod
value (if any), to lookup for the method specialization and
to invoke its implementation (i.e.IMPn) with the prepared which is equivalent to the O BJECTIVE -C code:
arguments _sel, _n, _arg and _ret. - (void) incrBy: (int)by {
• The methods are in charge to unpack the closed argu- self->mcnt += by;
if (self->mcnt >= 1000) {
ments into local variables and to handle the returned
value appropriately. 12 Namely call-next-method.

Draft research paper for OOPSLA’09 9 2009/5/20

 self->mcnt -= 1000; 5.2 Delegation
[super incr];
Message forwarding is a major feature of C OS which was
}
}
developed from the beginning with fast generic delegation
in mind as already mentioned in the previous section.
Line 6 shows how C OS next_method replaces the message
sent to super in O BJECTIVE -C. By default, next_method Unrecognized message Message dispatch performs run-
calls the next method belonging to the same generic (e.g. time lookup to search for method specializations. If no spe-
gincrBy) where next means the method with the highest spe-
cialization is found, the message gunrecognizedMessagen is
SUBSTITUTED and sent with the same arguments as the orig-
cialization less than the current method. But in the example
above, the Counter class has no specialization for gincrBy. inal sending, including the selector. Hence these messages
That is why the line 4 specifies an alternate next method can be overridden to support the delegation or some adaptive
path, namely gincr, to redirect the next_method call to the behaviors. The default behavior of gunrecognizedMessagen
appropriate next method. In some cases, it might be safer to is to throw the exception ExBadMessage.
test for the existence of the next method before calling it: Forwarding message Message forwarding has been bor-
if (next_method_p) next_method(self); rowed from O BJECTIVE -C and extended to multi-methods.
The sample code below shows a common usage of message
It is worth to note that next_method transfers the returned forwarding to protect objects against invalid messages:
value (if any) directly from the called next method to the
1 defmethod(void, gunrecognizedMessage1, MyProxy)
method caller. Nevertheless, the returned value can still be
if(gundertstandMessage1(self->obj,_sel)==True)
accessed through the lvalue RETVAL.
2

3 forward_message(self->obj); // delegate
Methods specialization Assuming for instance the class 4 endmethod
inheritance A :> B :> C, the class precedence list for the which can be translated line-by-line into O BJECTIVE -C by:
set of all pairs of specialization of A, B and C by decreasing
order will be: 1 - (retval_t) forward:(SEL)sel :(arglist_t)args {
2 if ([self->obj respondsTo: sel] == YES)
(C,C)(C,B)(B,C)(C,A)(B,B)(A,C)(B,A)(A,B)(A,A) 3 return [self->obj performv:sel :args];
}
and the list of all next_method paths are: 4

(C,C)(C,B)(C,A)(B,A)(A,A) Here, forward_message propagates all the arguments, in-

(B,C)(B,B)(B,A)(A,A) cluding the hidden parameters _sel, _arg and _ret, to a
(A,C)(A,B)(A,A) different receiver. As for next_method, forward_message
transfers the returned value directly to the method caller and
The algorithm used by C OS to build the class precedence can be accessed through RETVAL in the same way.
list (i.e. compute methods rank) has some nice properties: it
provides natural asymmetric left-to-right precedence and it Fast delegation Since all methods belonging to generics
is non-ambiguous, monotonic and totally ordered [35]. with equal rank have the same C function signature and fall
into the same lookup cache, it is safe to cache the message
Around methods Around methods borrowed from C LOS gunrecognizedMessagen in place of the unrecognized mes-
provide an elegant mechanism to enclose the behavior of sage. Hence, the next sending of the latter will result in a
some primary method by an arbitrary number of around cache hit.
methods. Around methods are always more specialized than
their primary method but have an undefined precedence: This substitution allows the delegation to be as fast as
defmethod(void, gdoIt, A, A) message dispatch, seemingly a unique feature.
endmethod
Intercession of forwarded messages Since the closed ar-
defmethod(void, gdoIt, B, A) guments of the generic’s param-list are managed by a C
next_method(self1, self2); // call gdoIt(A,A) structure, it is possible to access each argument separately. In
endmethod order to do this, C OS provides introspective information on
generics (i.e. metadata on types and signatures) which allows
defmethod(void, (gdoIt), B, A) // around method to identify and retrieve the arguments and the returned value
next_method(self1, self2); // call gdoIt(B,A) efficiently. But this kind of needs should be exceptional and
endmethod
is beyond the scope of this paper.
defmethod(void, gdoIt, B, B) 5.3 Contracts
next_method(self1, self2); // call (gdoIt)(B,A)
endmethod To quote Bertrand Meyer [31], the key concept of Design
by Contract is “viewing the relationship between a class and

Draft research paper for OOPSLA’09 10 2009/5/20

 defmethod(void, gincrBy, MilliCounter, (int)by)
compound-statement-with-contract: PRE test_assert(by >= 0 && by < 1000,
declaration-without-initializer (c99) ’’millicount out or range’’);
,→ pre-statementopt post-statementopt body-statement BODY // same code as before
endmethod
pre-statement: The PRE statement ensures that the incoming by is within
PRE statement the expected range and the next_method call in the BODY
statement ensures that the contract of gincr is also fulfilled.
post-statement:
POST statement Assertions and tests In order to ease the writing of con-
tracts and unit tests, C OS provides two standard tests:
body-statement: • test_assert(expr[,str][,func,file,line]) is a replace-
BODY statement ment for the standard assert and raises an ExBadAssert
exception on failure. The (optional) parameters str, func,
test-assert-statement: file and line are transfered to THROW for debugging.
test assert( bool-expr ) • test_invariant(obj[,func,file,line]) checks for the
test assert( bool-expr , cstr )
class invariants of objects. It can only be used inside
test assert( bool-expr , func , file , line )
methods and is automatically invoked on each receiver if
test assert( bool-expr , cstr , func , file , line )
the invariant contract level is active. The (optional) pa-
rameters func, file and line are transfered to ginvariant.
test-invariant-statement:
test invariant( object-expr ) Class invariants The test_invariant assertion relies on
test invariant( object-expr , func , file , line ) the message ginvariant which must be specialized for
MilliCounter to be effective in the previous example:
Figure 9. Syntax summary of contracts. defmethod(OBJ, ginvariant, MilliCounter,
(STR)func, (STR)file, (int)line)
next_method(self); // check Counter invariant
its clients as a formal agreement, expressing each party’s int mcnt = self->mcnt;
rights and obligations”. Most languages that support Design test_assert(mcnt >= 0 && mcnt < 1000,
by Contract provide two types of statements to express the ’’millicount out of range’’, func, file, line);
obligations of the caller and the callee: preconditions and endmethod
postconditions. The caller must meet all preconditions of
the message sent, and the callee (the method) must meet its Here, test_assert propagates the location of the calling
own postconditions — the failure of either party leads to a test_invariant to improve bug tracking.
bug in the software. In that way, Design by Contract (i.e. Contracts and inheritance In the design of E IFFEL, Ber-
developer point of view) is the complementary tool of Unit trand Meyer recommends to evaluate inherited contracts as
Testing [42] (i.e. user point of view) and they both enhance a disjunction of the preconditions and as a conjunction of
the mutual confidence between developers and users, help to the postconditions. But [32] demonstrates that E IFFEL-style
better identify the responsibilities and improve the design of contracts may introduce behavioral inconsistencies with in-
interfaces. heritance, thus C OS prefers to treat both pre and post con-
To illustrate how contracts work in C OS with the syntax ditions as conjunctions. This is also the only known solu-
summarized in figure 9, we can rewrite the method gincr: tion compatible with multi-methods where subtyping is su-
perseded by the class precedence list.
defmethod(void, gincr, Counter)
int old_cnt; // no initializer! Contracts levels The level of contracts can be set by defin-
PRE old_cnt = self->cnt; ing the macro COS_CONTRACT to one of the levels:
POST test_assert(self->cnt < old_cnt);
• NO disable contracts (not recommended).
BODY self->cnt++;
endmethod • COS_CONTRACT_PRE enables PRE sections. This is the rec-
ommended level for production phases (default level).
The POST statement test_assert checks for counter over-
flow after the execution of the BODY statement and throws • COS_CONTRACT_POST enables PRE and POST sections. This
an ExBadAssert exception on failure, breaking the contract. is the usual level during the development phases.
The variable old_val initialized in the PRE statement before • COS_CONTRACT_ALL enables PRE and POST sections as well
the execution of the BODY statement, plays the same role as as test_invariant statements. This is the highest level
the old feature in E IFFEL. As well gincrBy can be improved: usually set during debugging phases.

Draft research paper for OOPSLA’09 11 2009/5/20

 Most notably, properties are class-objects deriving from the
property-declaration: class Property (fig. 3) with lowercase names prefixed by P_.
useproperty( property-decl-list );
Class properties Once properties have been defined, it is
property-decl-list: possible to define some class-properties:
property-decl defproperty(Counter, (cnt)value, int2OBJ, gint);
property-decl-list , property-decl defproperty(Counter, ()class, gclass);
with:
property-decl: OBJ int2OBJ(int val) { // cannot be a method
property-name return gautoDelete(aInt(val));
( property-name ) local-name }

property-definition: The value property is associated with the cnt attribute with
defproperty( property-def ); read-write semantic and uses user-defined boxing (int2OBJ)
and unboxing (gint). The class property is associated with
property-def: the entire object (omitted attribute) with read-only semantic
property-name and uses the inherited message gclass to retrieve it.
( super-property-name ) property-name Sometimes the abstraction or the complexity of the prop-
erties require handwritten methods. For instance:
class-property-definition: defmethod(OBJ, ggetAt, Person, mP_name)
defproperty( class-property-def ); retmethod(gcat(self->fstname, self->lstname));
endmethod
class-property-def:
is equivalent to, assuming gname(Person) is doing the gcat:
class-name , property-attr
class-name , property-attr , get-funcopt defproperty(Person, ()name, gname);
class-name , property-attr , get-funcopt , put-funcopt
Using properties The example below displays the name
property-attr: property of an object (or raise the exception ExBadMessage):
property-name void print_name(OBJ obj) {
( object-attributeopt ) property-name useproperty(name);
gprint(ggetAt(obj, name));
{property, super-property}-name, object-attribute: }
identifier (c99)
6. Exceptions
Figure 10. Syntax summary of properties.
Exceptions are non-local errors which ease the writing of
interfaces since they allow to solve the problems where the
5.4 Properties
solutions exist. To state it differently, if an exceptional con-
Property declaration is a useful programming concept which dition is detected, the callee needs to return an error and let
allows, amongst others, to manage the access of object at- the caller take over. Applying recursively this behavior re-
tributes, to use objects as associative arrays or to make ob- quires a lot of boilerplate code on the callers side to check
jects persistent. Figure 10 summarizes the syntax of proper- returned status. Exceptions let the callers choose to either
ties in C OS which are just syntactic sugar on top of the defi- ignore thrown errors or to catch them and take over.
nition of class-objects and the specialization of the accessors Implementing an exception mechanism in C on top of the
ggetAt and gputAt already mentioned in section 4.3. standard setjmp and longjmp is not new. But it is uncom-
Property definition Properties in C OS are defined conven- mon to see a framework written in C which provides the
tionally with lowercase names: full try-catch-finally statements (figure 11) with the same se-
mantic as in other object-oriented programming languages
defproperty( name ); (e.g. JAVA, C #). The CATCH declaration relies on the mes-
defproperty( size ); sage gisKindOf to identify the thrown exception, what im-
defproperty( class );
plies that the order of CATCH definitions matters, as usual.
defproperty( value );
The sample program hereafter gives an overview of ex-
For example, the last property definition is equivalent to: ceptions in C OS:
defclass(P_value, Property) 1 int main(void) {
endclass 2 useclass(String, ExBadAssert, mExBadAlloc);

Draft research paper for OOPSLA’09 12 2009/5/20

 • Line 15 catches the class ExBadAlloc which is thrown
try-statement: when a memory allocation failure occurs. Throwing an
TRY instance of the class in a such context would not be safe.
,→ statement
• Line 23 destroys the two strings whatever happened.
,→ catch-statement-listopt
Their initial states have been set to be neutral for these
,→ finally-statementopt
operations in case of failure.
,→ ENTRY
C OS allows to throw any kind of object but it provides also
catch-statement-list: a hierarchy of exceptions deriving from Exception: ExBad-
catch-statement Alloc, ExBadArity, ExBadAssert, ExBadCast, ExBadDomain,
catch-statement-list catch-statement ExBadFormat, ExBadMessage, ExBadProperty, ExBadRange,
ExBadSize, ExBadType, ExBadValue, ExNotFound, ExNot-
catch-statement: Implemented, ExNotSupported, ExErrno, and ExSignal.
CATCH( class-name , exception-nameopt ) statement Among these exceptions, ExErrno and ExSignal are spe-
CATCH ANY( exception-nameopt ) statement cial cases used respectively to convert standard errors (i.e.
test_errno()) and registered signals into exceptions.
finally-statement:
FINALLY statement 7. Performance
In order to evaluate the efficiency of C OS, small test suites13
throw-statement: have been written to stress the message dispatcher in various
THROW( object-expr ); conditions. The test results summarized in table 1 and fig-
THROW( object-expr , func , file , line ); ure 12 have been performed on an Intel DualCore2TM T9300
RETHROW(); C PU 2.5 Ghz with Linux Ubuntu 64-bit and the compiler
G CC 4.3 to compile the tests written in the three languages.
exception-name: The timings have been measured with clock() and aver-
identifier (c99) aged over 10 loops of 2 · 108 iterations each. The Param.
column indicates the number of parameters of the message
Figure 11. Syntax summary of exceptions. split by selectors (open types) and arguments (closed types).
The other columns represent the performances in million of
invocations sustained per second for respectively C ++ vir-
3 STR s1 = 0; tual member functions, O BJECTIVE -C messages and C OS
4 OBJ s2 = Nil; messages. The tests stress the dispatcher with messages al-
5
ready described in this paper: incr increments a counter,
6 TRY
incrBy{2..5}opt accept from 1 to 5 extra closed parameters
7 s1 = strdup(’’str1’’);
8 s2 = gnewWithStr(String, ’’str2’’); (to stress the construction of _arg) and addTo{2..4}opt add
9 test_assert(0, ’’throw ExBadAssert’’); from 2 to 5 Counters together (to stress multiple dispatch).
10 Multiple dispatch has been implemented with the Visitor de-
11 CATCH(ExBadAssert, ex) sign pattern in C ++ and O BJECTIVE -C.
12 printf(’’assertion %s failed (%s,%d)\n’’, Concerning the performance of single dispatch, C OS
13 gstr(ex), ex_file, ex_line); shows a good efficiency since it runs in average at about the
14 gdelete(ex); same speed as C ++ and about ×1.6 faster than O BJECTIVE -
15 CATCH(mExBadAlloc, ex) // catch class ExBadAlloc C. On one hand, C OS efficiency decreases faster than C ++
16 printf(’’out of memory (%s,%d)\n’’, effciency because it passes more hidden arguments (i.e. _sel
ex_file, ex_line);
17
and _arg) and uses more registers to compute the dispatch.
18 gdelete(ex);
On the other hand, C ++ shows some difficulties to manage
19 CATCH_ANY(ex)
20 printf(’’unexpected exception %s (%s,%d)\n’’, efficiently multiple inheritance of abstract classes. Concern-
21 gstr(ex), ex_file, ex_line); ing the performance of multiple dispatch, C OS outperforms
22 gdelete(ex); C ++ and O BJECTIVE -C by factors ×1.9 and ×5.3. Concern-
23 FINALLY // always executed ing the performance of message forwarding, we have seen
24 free(s1); that by design, it runs at the full speed of message dispatch
25 gdelete(s2); in C OS. Rough measurements of O BJECTIVE -C message
26 ENDTRY forwarding (linear lookup) shows that C OS performs from
27 } ×50 to ×100 faster, depending on the tested classes.

The code above shows some typical usages: 13 These testsuites can be browsed on sf.net in the module CosBase/tests.

Draft research paper for OOPSLA’09 13 2009/5/20

 Tests Param. C++ O BJ C C OS 250
single dispatch
counter incr 1+0 176 122 218 200
counter incrBy 1+1 176 117 211
counter incrBy2 1+2 176 115 185 150
counter incrBy3 1+3 176 112 171
counter incrBy4 1+4 167 111 154 100
counter incrBy5 1+5 167 107 133
multiple dispatch incr 50
incrBy
counter addTo 2+0 90 40 150 incrBy2
incrBy3
counter addTo2 3+0 66 23 121 incrBy4 0
ObjC incrBy5
counter addTo3 4+0 45 16 90 C++
addTo
addTo2
counter addTo4 5+0 40 12 77 COS addTo3
addTo4

Table 1. Performances summary in 106 calls/second. Figure 12. Performances summary in 106 calls/second.

Multi-threading The same performance tests have been encapsulation, polymorphism, low coupling (messages)
run with P OSIX multi-threads enabled. When the Thread- and contracts are also assets for this principle.
Local-Storage mechanism is available (Linux), no signif- • The reusability comes from the key concepts of C OS
icant impact on performance has been observed (<1%). which enhance generic design: polymorphism, collabo-
When the architecture supports only P OSIX Thread-Specific- ration (multi-methods) and composition (delegation).
Key (Mac OS X), the performance is lowered by a factor • The efficiency measurement shows that key concepts per-
×1.6 and becomes clearly the bottleneck of the dispatcher.
form well compared to other mainstream languages.
Object creation Like other languages with semantic by • The portability comes from its nature: a C89 library.
reference, C OS loads heavily the C memory allocator (e.g.
malloc) which is not very fast. If the allocator is identified It is widely acknowledged that dynamic programming
as the bottleneck, it can be replaced with optimized pools languages simplify significantly the implementation of clas-
by overriding galloc or by faster external allocators (e.g. sical design patterns [28] when they don’t supersede them
Google tcmalloc). C OS also takes care of automatic objects by more powerful dynamic patterns [7, 33, 34]. This section
which can be used to speed up the creation of local objects. focuses on how to use C OS features to simplify design pat-
terns or to turn them into reusable components, where the
Other aspects Other features of C OS do not involve such definition of componentization is borrowed from [16, 17]:
heavy machinery as in message dispatch or object creation.
Thereby, they all run at full speed of C. Contracts run at the Component Orientation = Encapsulation + Polymorphism
speed of the user tests since the execution path is known at + Late Binding + Multi-Dispatch + Delegation.
compile time and flattened by the compiler optimizer. Empty
try-blocks run at the speed of setjmp which is a well known
bottleneck. Finally next_method runs at 70% of the speed 8.1 Simple Patterns
of an indirect function call (i.e. late binding) because it also Creational Patterns It is a well known fact that these pat-
has to pack the closed arguments into the generic’s _arg terns vanish in languages supporting generic types and intro-
structure. spection. We have already seen gnew (p. 5), here is more:
OBJ gnewWithStr(OBJ cls, STR str) {
8. Component-Oriented Design Patterns return ginitWithStr(galloc(cls), str);
This overview of C OS shows that the principles stated in the }
introduction are already well fulfilled. So far:
OBJ gclone(OBJ obj) {
• The simplicity can be assumed from the fact that the en- return ginitWith(galloc(gclass(obj)), obj);
}
tire language can be described within few pages, includ-
ing the grammar, some implementation details and few The Builder pattern is a nice application of property meta-
examples and comparisons with other languages. classes to turn it into the so called Class Cluster pattern:
• The extensibility comes from the nature of the object defmethod(OBJ, galloc, pmString)
model which allows to extend (methods bound to gener- retmethod(_1); // lazy, delegate the task to initializers
ics), wrap (around methods) or rename (method aliases) endmethod
behaviors with a simple user-friendly syntax. Besides,

Draft research paper for OOPSLA’09 14 2009/5/20

 defmethod(OBJ, ginitWithStr, pmString, (STR)str) Key-Value-Coding We have already seen that properties
OBJ lit_str = galloc(StringLiteral); allow to access to object attributes, but to implement KVC,
retmethod( ginitWithStr(lit_str, str) ); we need to translate strings (key) into properties (noun):
endmethod
defmethod(OBJ, ggetAt, Object, String)
This example shows how to delegate the object build to the OBJ prp = cos_property_getWithStr(self2->str);
initializer which in turn allocates the appropriate object ac- if (!prp) THROW(gnewWith(ExBadProperty,_2));
cording to its arguments, an impossible task for the allocator. retmethod( ggetAt(_1, prp) );
The allocation of the StringLiteral uses the standard allo- endmethod
cator inherited from Object, even if it derives from the class
String (thanks to property metaclass). Now, the code: defmethod(void, gputAt, Object, String, Object)
OBJ prp = cos_property_getWithStr(self2->str);
OBJ str = gnewWithStr(String,’’literal string’’); if (!prp) THROW(gnewWith(ExBadProperty,_2));
will silently return an instance of StringLiteral. This is gputAt(_1, prp, _3);
the cornerstone of Class Clusters where the front class (e.g. endmethod
String) delegates to private subclasses (e.g. StringLiteral) where cos_property_getWithStr is an optimized version of
the responsibility to build the object. It is worth to note that cos_class_getWithStr for properties from the API of C OS,
each pmString specialization needed to handle new subclass which also provides cos_class_{read,write}Properties
is provided by the subclass itself (thanks to the open class to retrieve all the properties of a class (and its superclasses).
model), which makes the Builder pattern truly extensible.
Key-Value-Observing Adding access notifications of prop-
Most complex or multi-purpose classes of C OS are designed
erties is the next step after KVC, using around methods:
as class clusters (e.g. Array, String, Functor, Stream).
defmethod(OBJ, ggetAt, (Person), mP_name)
Garbage Collector This exercise will show how to sim- useclass(After, Before);
plify memory management in C OS with only few lines of OBJ context = aMthCall(_mth,_1,_2,_arg,_ret);
code. We start by wrapping the default object allocator such gnotify(center, context, Before);
that it always auto-releases the allocated objects: next_method(self1, self2); // get property
defmethod(OBJ, (galloc), mObject) // around method gnotify(center, context, After);
next_method(self); // allocate endmethod
gautoRelease(RETVAL); // auto−release where _mth is the object representing the method itself.
endmethod This example assumes that observers and objects observed
Then we neutralize (auto-)delete and reinforce retain: have already been registered to some notification center as
defmethod(void, (gdelete), Object) commonly done in the Key-Value-Observing pattern.
endmethod 8.2 Proxies and Decorators
defmethod(OBJ, (gautoDelete), Object) Proxy Almost all proxies in C OS derive from the class
BOOL is_auto = self->rc == COS_RC_AUTO; Proxy which handles some aspects of this kind of class:
retmethod( is_auto ? gclone(_1) : _1 ); defclass(Proxy);
endmethod OBJ obj; // delegate
endclass
defmethod(void, (gretain), Object)
next_method(self); #define gum1 gunrecognizedMessage1 // shortcut
if (self->rc == COS_RC_AUTO) #define gum2 gunrecognizedMessage2 // shortcut
RETVAL = gretain(RETVAL); // once more for auto
endmethod defmethod(void, gum2, Proxy, Object)
Now, the following code: forward_message(self1->obj, _2);
check_ret(_sel, _ret, self1);
OBJ pool = gnew(AutoRelease); endmethod
for(int i = 0; i < 1000; i++)
OBJ obj = gnewWithStr(String, ’’string’’); defmethod(void, gum2, Object, Proxy)
gdelete(pool); // pool specialization, collect the strings forward_message(_1, self2->obj);
does not create any memory leak, there is no longer the need check_ret(_sel, _ret, self2);
to delete or auto-delete your objects. For the first runs, you endmethod
can rely on the default auto-release pool managed by C OS.
// ... other rank specializations
Then a profiler of used memory will show the appropriate
locations where intermediate auto-release pools should be where the small function check_ret takes care to return the
added to trigger the collects and limit the memory usage. proxy when the forwarded message returns the delegate obj.

Draft research paper for OOPSLA’09 15 2009/5/20

Tracer For the purpose of debugging, C OS provides the Now, messages of rank one not understood by the IOStreams
simple proxy Tracer to trace the life of an object: (e.g. gget, gread) will be forwarded to their InStream.
defclass(Tracer,Proxy) // usage: gnewWith(Tracer, obj); Distributed Objects Without going into the details, we can
endclass mention that C OS already implements all the key concepts
required to develop a distributed object system on the model
defmethod(void, gum2, Tracer, Object) of O BJECTIVE -C and C OCOA. A challenge for the future.
trace_msg2(_sel, self1->Proxy.obj, _2);
next_method(self1, self2); // forward message 8.3 Closures and Expressions
endmethod
C OS provides the family of gevaln messages (equivalent
defmethod(void, gum2, Object, Tracer) to C OMMON L ISP funcall) and the class cluster Functor
trace_msg2(_sel, _1, self2->Proxy.obj); to support the mechanism of closures and more generally
next_method(self1, self2); // forward message lazy expressions and high order messages. The objects rep-
endmethod resenting the context of the closure (i.e. the free variables)
are passed to the Functor constructor which handles partial
// ... other rank specializations evaluation and build expressions. The next example shows
where trace_msg2 prints useful information on the console. another way to create a counter in P ERL using a closure:

Locker The locker is a proxy which avoids synchroniza- 1 sub counter {

tion deadlock on shared objects that can be encountered in 2 my($val) = shift; # seed
3 $cnt = sub { # incr
programming languages supporting only single-dispatch [8]:
4 return $val++;
defclass(Locker,Proxy) // usage: gnewWith(Locker, obj); 5 };
pthread_mutex_t mutex; 6 return $cnt; # return the closure
endclass 7 }
8

defmethod(void, gum1, Locker) // like smart pointers 9 $cnt = counter(0);

lock(self); // lock the mutex 10 for($i=0; $i<25000000; $i++)
next_method(self); // forward the message 11 &$cnt();
unlock(self); // unlock the mutex
endmethod which can be translated into C OS as:
1 OBJ counter(int seed) {
defmethod(void, gum2, Locker, Locker) 2 OBJ fun = aFunctor(gincr, aCounter(seed));
sorted_lock2(self1, self2); // lock in order 3 return gautoDelete(fun);
next_method(self1, self2); // forward the message 4 }
sorted_unlock2(self1, self2); // unlock in order 5
endmethod 6 int main(void) {
7 OBJ cnt = counter(0);
// ... other rank specializations (total of 63−6 combinations) 8 for(int i=0; i<25000000; i++)
9 geval(cnt);
For the sake of efficiency, higher ranks use sorting networks.
10 }
Multiple Inheritance The first version of C OS was na-
The line 2 creates the closure using the automatic construc-
tively implementing multiple inheritance using the C3 algo-
tor aFunctor which takes the generic function gincr and
rithm [35] to compute the class precedence list on the way
deduces its arity (here 1) from the remaining parameters,
of DYLAN, P YTHON and P ERL 6. But it was quickly consid-
namely the seed boxed in the counter. Line 3, the message
ered as too complex for the end-user and incidental as far as
gautoDelete extends the lifespan of both the functor and the
fast generic delegation could be achieved. Indeed, multiple
counter to the dynamic scope. As one can see, C OS achieves
inheritance can be simulated by composition and delegation
the same task as P ERL with about the same amount of code
with an efficiency close to native support14 :
but runs more than ×15 faster. The example below:
defclass(IOStream, OutStream)
fun = gaddTo(Var,y) // works only with messages
OBJ in_stream;
fun = aFunctor(gaddTo,Var,y) // works with functions
endclass
create a closure with arity 2 where Var specifies an argu-
defmethod(void, gum1, IOStream) ment placeholder and y an argument object. The message
forward_message(self->in_stream); geval1(fun,x) is then equivalent to gaddTo(x,y).
endmethod
The following example shows a more advanced example
14 O BJECTIVE -C delegation is too slow to simulate multiple inheritance. involving lazy expressions and indexed placeholders:

Draft research paper for OOPSLA’09 16 2009/5/20

 // return f 0 = (f (x + dx) − f (x))/dx 9.1 Related work
OBJ ggradient(OBJ f) {
Ooc This old framework uses the ooc preprocessor written
OBJ x = aVar(0); // placeholder #1
OBJ dx = aVar(1); // placeholder #2
in AWK [40] to provide a basic object-oriented layer. It relies
OBJ f_x = geval1(f, x); // lazy expression on void pointers and requires much defensive programming
OBJ f_xpdx = geval1(f, gadd(x, dx)); // idem to ensure correct use of objects. Besides, it gives full control
return gdiv(gsub(f_xpdx, f_x), dx); // idem over inheritance like in prototype-based languages.
} Dynace This framework includes the dpp preprocessor and
0
// return f (x)|dx a large library of classes [41]. Dynace features are equivalent
OBJ gderivative(OBJ f, OBJ dx) { to those of O BJECTIVE -C except that it supports multiple
return geval2(ggradient(f), Var, dx); inheritance. However, Dynace message dispatch is about ×3
} slower than C OS even with jumpTo assembly code enabled
and accessing object attributes is a bit awkward and relies on
Now we can map this function to a bag of values (strict
fancy macros (e.g. accessIVs, GetIVs, ivPtr, ivType).
evaluation) or expressions (lazy evaluation) indifferently:
OBJ fun = gderivative(f, dx); Gnome Objects The Gnome/Gtk+ Object System provides
OBJ new_bag = gmap(fun, bag); basic object-oriented programming and requires to write un-
safe and unchecked code. Despite that this system cumulates
High Order Messages The principle behind H OMs is to all the problems of Ooc and Dynace, it is nonetheless simple,
construct on-the-fly an expression from their arguments portable and implements a prototype-based object model.
composition [37] — a technique known for more than a 9.2 Summary
decade in C ++ meta-programming. Once the expression is
completed, the last built object evaluates the expression and C OS seems to be unique by the set of features it provides to
returns the result. While C ++ meta-expressions rely strongly the C programming language without requiring a third party
on static types (i.e. traits) and templates to build and simplify preprocessor or compiler nor any platform or compiler spe-
the expressions, H OMs rely on the delegation mechanism: cific feature. The library approach allowed to explore rapidly
some object models and to select the most appropriate one
• With fast generic delegation, no need to cache the mes-
fulfilling the best the aimed principles: simplicity, extensi-
sage in the H OM objects as in the aforementioned paper. bility, reusability, efficiency and portability. Moreover, the
• With multi-methods, no need to provide multiple H OMs list of features is complete and consistent: augmented syn-
for similar tasks (i.e. gfilter, gselect and gcollect). tax to support object-oriented programming, uniform object
• With lazy expression, no need to construct complex meta- model with extended metaclass hierarchy, multi-methods,
expressions or to reorder compositions. fast generic delegation, design by contract, properties and
key-value coding, exceptions, ownership and closures. C OS
H OMs are an important tool for modern framework design features have been optimized from the design point of view,
since they play the role of weavers of cross-cutting concerns but for the sake of simplicity and portability, code tuning
otherwise solved by foreign technologies based on subject- has never been performed and lets some room for future im-
oriented [38] and aspect-oriented programming [39]. Like- provement. The 8000 lines of source code of C OS can be
wise, the availability of H OMs simplify drastically the im- downloaded from sourceforge.net under the LGPL license.
plementation of interpreters reflecting the classes and meth-
ods of the underlying language like in F-S CRIPT [43]. References
[1] International Standard. Programming Languages – C.
9. Conclusion ISO/IEC 9899:1999.
Some frameworks, with the help of external preprocessors [2] S.P. Harbison, and G.L. Steele. C: A Reference Manual.
or compilers, propose extensions to the C programming lan- Prentice Hall, 5th Ed., 2002.
guage, but none of them provide a set of features as consis-
[3] D.R. Hanson. C Interfaces and Implementations: Techniques
tent, complete and efficient as C OS. Besides, even if the fea- for Creating Reusable Software. Addison-Wesley, 1997.
tures of C OS are not new, I am not aware of a single program-
[4] J.K. Foderaro. Lisp is a Chameleon. Communication of the
ming language which provides the same set of features with
ACM, Vol. 34 No. 9, 1991.
the same simplicity, portability and efficiency. Finally, very
few programming languages target all the principles stated [5] B.J. Cox, and A.J. Novobilski. Object-Oriented Program-
in the introduction. In particular, modern type systems which ming: An Evolutionary Approach. Addison-Wesley, 1991.
try to improve code flexibility and reusability to ease the de- [6] Developer Guide. The Objective-C 2.0 Programming
sign of generic components, tend to be lazy (static duck typ- Language. Apple Computer Inc., 2008.
ing), overcomplicated (C++ ADL) and counter productive for [7] Developer Guide. Cocoa Fundamentals Guide. Apple
average or occasional developers. Computer Inc., 2007.

Draft research paper for OOPSLA’09 17 2009/5/20

 [8] S.E. Keene. Object Oriented Programming in Common Lisp: Garbage Collectors. 30th ACM Sigplan Symposium
A Programmers Guide to the Common Lisp Object System. on Principles of Programming Languages (PoPL’2002).
Addison-Wesley, 1989. http://www.hpl.hp.com/personal/Hans_Boehm/gc.
[9] G. Kiczales, J. des Rivières, and D.G. Bobrow. The Art of the [26] R. Razavi, N. Bouraqadi, J. Yoder, J.F. Perrot, and R. John-
Metaobject Protocol. MIT Press, 1991. son. Language support for Adaptive Object-Models using
[10] R.P. Gabriel, J.L. White, and D.G. Bobrow. C LOS: Integrat- Metaclasses. ESUG Conference 2004 Research Track, 2004.
ing Object-Oriented and Functional Programming. Commu- [27] N.M. Bouraqadi-Saâdani, T. Ledoux, and F. Rivard. Safe
nication of the ACM, Vol. 34 No. 9, 1991. Metaclass Programming. OOPSLA’98, 1998.
[11] J. Bosch. Design of an Object-Oriented Framework [28] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design
for Measurement Systems. Systems Domain-Specific Patterns: Elements of Reusable Object-Oriented Software.
Application Frameworks, Ch. 11, John Wiley & Sons, 2000. Addison-Wesley, 1995.
[12] J. Bosch, P. Molin, M. Mattsson, and P.O. Bengtsson. [29] E. Dujardin, E. Amiel and E. Simon. Fast Algorithm for
Object-Oriented Framework-based Software Development: Compressed Multimethod Dispatch Table Generation. ACM
Problems and Experiences. ACM, 2000. Transactions on Programming Languages and Systems, Vol.
[13] J.M. Nogiec, J. DiMarco, H. Glass, J. Sim, K. Trombly- 20, January 1998.
Freytag, G. Velev and D. Walbridge. A Flexible and [30] Y. Zibin and Y. Gil. Fast Algorithm for Creating Space
Configurable System to Test Accelarator Magnets. Particle Efficient Dispatching Table with Application to Multi-
Accelerator Conference (PAC’01), 2001. Dispatching. OOPSLA’02, 2002.
[14] M. Nogiec, J. Di Marco, S. Kotelnikov, K. Trombly-Freytag, [31] B. Meyer. Object-Oriented Software Construction. Prentice
D. Walbridge, M. Tartaglia. A Configurable component-based Hall, 2nd Ed., 1997.
software system for magnetic field measurements. IEEE [32] R.B. Findler, M. Latendresse, and M. Felleisen. Behavioral
Trans. On Applied Superconductivity, Vol. 16 No. 2, 2006. Contracts and Behavioral Subtyping. 9th ACM Sigsoft
[15] P. Arpaia, L. Bottura, M. Buzio, D. Della Ratta, L. Deniau, International Symposium on Foundations of Software
V. Inglese, G. Spiezia, S. Tiso, L. Walckiers. A software Engineering, 2001.
framework for flexible magnetic measurements at CERN. [33] P. Norvig. Design Patterns in Dynamic Programming.
Instrumentation and Measurement Technology Conference http://www.norvig.com/design-patterns, 1996.
(IMTC’07), 2007.
[34] G.T. Sullivan Advanced Programming Language Features
[16] K. Rege. Design Patterns for Component-Oriented Software for Executable Design Pattern. Technical Report AIM-2002-
Development. Euromicro’99 Conference, vol. 2, no. 2, 1999. 005, MIT Artificial Intelligence Laboratory, 2002.
[17] B. Meyer, K. Arnout. Pattern Componentization: The Visitor [35] K. Barrett, B. Cassels, P. Haahr, D.A. Moon, K. Playford, and
Example. Computer, vol. 39, no. 7, July 2006. P. Tucker Withington. A monotonic superclass linearization
[18] B. Meyer, K. Arnout. Pattern Componentization: The Factory for Dylan. OOPSLA’96, 1996.
Example. Innovations in Systems and Software Engineering, [36] The Cecil Group. Cecil Standard Library Manual. Depart-
vol. 2, no. 2, July 2006. ment of Computer Science and Engineering, University of
[19] J.C. Mitchell. Concepts in Programming Languages. Washington, 2004.
Cambridge University Press, 2001. [37] M. Weiher and S. Ducasse. High Order Message. OOP-
[20] R.E. Johnson. Dynamic Object Model. http://st-www. SLA’05, 2005.
cs.uiuc.edu/users/johnson/papers/dom, 1998 [38] W. Harrison, H. Ossher. Subject-Oriented Programming (A
[21] D. Riehle, M. Tilman and R.E. Johnson. Dynamic Object Critique of Pure Objects). OOPSLA’93, 1993.
Model. 7th Conference on Pattern Languages of Programs [39] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes,
(PLoP’2000), 2000. J.M. Loingtier, and J. Irwin. Aspect-Oriented Programming.
[22] J.W. Yoder and R.E. Johnson. The Adaptive Object-Model European Conference on Object-Oriented Programming
Architectural Style. 3rd Working IEEE Conference on (ECOOP’97), 1997.
Software Architecture (WICSA’2002), 2002. [40] A.T. Schreiner. Object-Oriented Programming with ANSI C.
[23] J. van Gurp, and J. Bosch. Design, Implementation and http://www.cs.rit.edu/~ats/books/ooc.pdf, 1994
Evolution of Object-Oriented Frameworks: Concepts & [41] B. McBride. Dynace: Dynamic C language extension.
Guidelines. Software Practice & Experience, John Wiley http://algorithms.us/, 2006.
& Sons, March 2001.
[42] K. Beck. Test-Driven Development: By Example. Addison-
[24] D. Parsons, A. Rashid, A. Telea, and A. Speck. An archi- Wesley, 2002.
tectural pattern for designing component-based application
frameworks. Software Practice & Experience, John Wiley & [43] P. Mougin. The F-Script Language, 1998–2006.
Sons, November 2005. http://www.fscript.org/.

[25] H. Boehm. Bounding Space Usage of Conservative

Draft research paper for OOPSLA’09 18 2009/5/20