1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
|
/* Minimal object-oriented facilities for C.
Copyright (C) 2006, 2015 Free Software Foundation, Inc.
Written by Bruno Haible <bruno@clisp.org>, 2006.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation; either version 2.1 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
/* This file defines minimal facilities for object-oriented programming
style in ANSI C.
The facilities allow to define classes with single inheritance and
"virtual" methods.
Strict type checking is provided in combination with a C++ compiler:
The code compiles in ANSI C with less strict type checking; when
compiled with a C++ compiler, strict type checking is done.
In contrast to [OOC] and [OOPC], this implementation concentrates on the
bare essentials of an object-oriented programming style. It does not
provide features that are "sometimes useful", but not essential.
Features:
- Combination of fields and methods into a single object. YES
- Description of objects of same shape and same behaviour
by a class. YES
- Single inheritance. YES
- Multiple inheritance. NO
- Operator overloading (compile-time polymorphism). NO
- Virtual methods (run-time polymorphism). YES
- Information hiding: private/protected/public. private fields
- Static fields and methods. NO
- Constructors, destructors. NO
- 'new', 'delete'. NO
- Exception handling. NO
- Garbage collection. NO
- Templates / Generic classes with parameters. NO
- Namespaces. NO
- Hidden 'this' pointer in methods. NO
- Declaring or implementing several classes in the same file. NO
Rationale for NO:
- Multiple inheritance is not supported because programming languages
like Java and C# prove that they are not necessary. Modern design
patterns use delegation more often than composition; this reduces
the pressure to use multiple inheritance.
Multiple inheritance of "interfaces" (classes without fields) might
be considered, though.
- Operator overloading is not essential: The programmer can rename
methods so that they carry unambiguous method names. This also makes
the code more readable.
- Virtual methods are supported. Non-virtual methods are not: they
constitute an assumption about the possible subclasses which is more
often wrong than right. In other words, non-virtual methods are a
premature optimization - "the root of all evil", according to
Donald E. Knuth.
- Information hiding: 'protected' is not supported because it is always
inappropriate: it prohibits the use of the delegation design pattern.
'private' is implemented on fields. There are no 'public' fields,
since the use of getters/setters allows for overriding in subclasses
and is more maintainable (ability to set breakpoints). On the other
hand, all methods are 'public'. 'private` methods are not supported
because methods with static linkage can be used instead.
- Static fields and methods are not supported because normal variables
and functions with static or extern linkage can be used instead.
- Constructors and destructors are not supported. The programmer can
define 'init' and 'do_free' methods himself.
- 'new', 'delete' are not supported because they only provide the
grouping of two lines of code into a single line of code.
- Exception handling is not supported because conventions with a return
code can be used instead.
- Garbage collection is not supported. Without it the programmer's life
is harder, but not impossible. The programmer has to think about
ownership of objects.
- Templates / Generic classes with parameters are not supported because
they are mostly used for container classes, and container classes can
be implemented in a simpler object-oriented way that requires only a
very limited form of class inheritance.
- Namespaces are not implemented, because they can be simulated by a
consistent naming convention.
- A hidden 'this' pointer in methods is not implemented. It reduces the
transparency of the code (because what looks like a variable access can
be an access through 'this') and is simply not needed.
- Declaring or implementing several classes in the same file is not
supported, because it is anyway good practice to define each class in
its own .oo.h / .oo.c file.
Syntax:
The syntax resembles C++, but deviates from C++ where the C++ syntax is
just too braindead.
A root class is declared in a .oo.h file:
struct rootfoo
{
methods:
int method1 (rootfoo_t x, ...); ...
};
and in the corresponding .oo.c file:
struct rootfoo
{
fields:
int field1; ...
};
A subclass is declared in a .oo.h file as well:
struct subclass : struct rootfoo
{
methods:
int method2 (subclass_t x, ...); ...
};
and in the corresponding .oo.c file:
struct subclass : struct rootfoo
{
fields:
int field2; ...
};
This defines:
- An incomplete type 'struct any_rootfoo_representation' or
'struct subclass_representation', respectively. It denotes the memory
occupied by an object of the respective class. The prefix 'any_' is
present only for a root class.
- A type 'rootfoo_t' or 'subclass_t' that is equivalent to a pointer
'struct any_rootfoo_representation *' or
'struct subclass_representation *', respectively.
- A type 'struct rootfoo_implementation' or
'struct subclass_implementation', respectively. It contains a virtual
function table for the corresponding type.
- A type 'struct rootfoo_representation_header' or
'struct subclass_representation_header', respectively, that defines
the part of the memory representation containing the virtual function
table pointer.
- Functions 'rootfoo_method1 (rootfoo_t x, ...);' ...
'subclass_method1 (subclass_t x, ...);' ...
'subclass_method2 (subclass_t x, ...);' ...
that invoke the corresponding methods. They are realized as inline
functions if possible.
- A declaration of 'rootfoo_typeinfo' or 'subclass_typeinfo', respectively,
each being a typeinfo_t instance.
- A declaration of 'ROOTFOO_SUPERCLASSES' or 'SUBCLASS_SUPERCLASSES',
respectively, each being an initializer for an array of typeinfo_t.
- A declaration of 'ROOTFOO_SUPERCLASSES_LENGTH' or
'SUBCLASS_SUPERCLASSES_LENGTH', respectively, each denoting the length
of that initializer.
- A declaration of 'rootfoo_vtable' or 'subclass_vtable', respectively,
being an instance of 'struct rootfoo_implementation' or
'struct subclass_implementation', respectively.
- A header file "rootfoo.priv.h" or "subclass.priv.h" that defines the
private fields of 'struct rootfoo_representation' or
'struct subclass_representation', respectively.
A class implementation looks like this, in a .oo.c file:
struct subclass : struct rootfoo
{
fields:
int field2; ...
};
int subclass::method1 (subclass_t x, ...) { ... } [optional]
int subclass::method2 (subclass_t x, ...) { ... }
...
At the place of the second "struct subclass" definition, the type
'struct subclass_representation' is expanded, and the macro 'super' is
defined, referring to the vtable of the superclass. For root classes,
'super' is not defined. Also, 'subclass_typeinfo' is defined.
Each method subclass::method_i defines the implementation of a method
for the particular class. Its C name is subclass__method_i (not to be
confused with subclass_method_i, which is the externally visible function
that invokes this method).
Methods that are not defined implicitly inherited from the superclass.
At the end of the file, 'subclass_vtable' is defined, as well as
'subclass_method1 (subclass_t x, ...);' ...
'subclass_method2 (subclass_t x, ...);' ...
if they were not already defined as inline functions in the header file.
Object representation in memory:
- Objects have as their first field, called 'vtable', a pointer to a table
to data and function pointers that depend only on the class, not on the
object instance.
- One of the first fields of the vtable is a pointer to the
'superclasses'; this is a NULL-terminated array of pointers to
typeinfo_t objects, starting with the class itself, then its
superclass etc.
[OOC] Axel-Tobias Schreiner: Object-oriented programming with ANSI-C. 1993.
[OOPC] Laurent Deniau: Object Oriented Programming in C. 2001.
*/
#ifndef _MOO_H
#define _MOO_H
/* Get size_t, abort(). */
#include <stdlib.h>
/* An object of this type is defined for each class. */
typedef struct
{
const char *classname;
} typeinfo_t;
/* IS_INSTANCE (OBJ, ROOTCLASSNAME, CLASSNAME)
tests whether an object is instance of a given class, given as lower case
class name. */
#define IS_INSTANCE(obj,rootclassname,classname) \
(((const struct rootclassname##_representation_header *)(const struct any_##rootclassname##_representation *)(obj))->vtable->superclasses_length \
>= classname##_SUPERCLASSES_LENGTH \
&& ((const struct rootclassname##_representation_header *)(const struct any_##rootclassname##_representation *)(obj))->vtable->superclasses \
[((const struct rootclassname##_representation_header *)(const struct any_##rootclassname##_representation *)(obj))->vtable->superclasses_length \
- classname##_SUPERCLASSES_LENGTH] \
== & classname##_typeinfo)
/* This instance test consists of two comparisons. One could even optimize
this to a single comparison, by limiting the inheritance depth to a fixed
limit, for example, say, depth <= 10. The superclasses list would then
need to be stored in reverse order, from the root down to the class itself,
and be filled up with NULLs so that the array has length 10. The instance
test would look like this:
#define IS_INSTANCE(obj,rootclassname,classname) \
(((const struct rootclassname##_representation_header *)(const struct any_##rootclassname##_representation *)(obj))->vtable->superclasses \
[classname##_SUPERCLASSES_LENGTH - 1] \
== & classname##_typeinfo)
but the classname##_superclasses_length would no longer be available as a
simple sizeof expression. */
#endif /* _MOO_H */
|
