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