From 643d18393008f7de83897ca1d85db86fdf352b14 Mon Sep 17 00:00:00 2001 From: Michael Roitzsch Date: Sat, 8 May 2004 15:05:02 +0000 Subject: document some more about object oriented C, C vs. C++ and _x_assert/_x_abort CVS patchset: 6499 CVS date: 2004/05/08 15:05:02 --- doc/hackersguide/overview.sgml | 66 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 64 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/hackersguide/overview.sgml b/doc/hackersguide/overview.sgml index eef0f2732..7a4db78c0 100644 --- a/doc/hackersguide/overview.sgml +++ b/doc/hackersguide/overview.sgml @@ -521,7 +521,7 @@ Object oriented programming in C xine uses a lot of design principles normally found in - object oriented designs. As xine is written in c, a few + object oriented designs. As xine is written in C, a few basic principles shall be explained here on how xine is object oriented anyway. @@ -567,6 +567,31 @@     this->values[MAX_STACK_SIZE - ++this->stack_size] = i;    } + + The part added to the derived class is private, because when + defining the new structure directly in the .c file, where it will + be used, outside modules have no way of seeing the definition + of the derived class. A public derivation is possible by defining + the above structure in a .h file for others to include. + + + Something similar to a protected, package or friend visibility is also + possible: + +   struct my_stack_s { +    void (*push)(my_stack_t *this, int i); +    void (*add)(my_stack_t *this); +    int (*pop)(my_stack_t *this); +    +   #ifdef STACK_INTERNAL +    void (*flush)(my_stack_t *this); +   #endif +   }; + All modules, who need to access the internal part have to add +    #define STACK_INTERNAL + before including the header with the definition. It is clear that only + those friend modules can derive from this class. + Finally the contructor malloc()s the data struct (private variant) and fills in function pointers and default values. Usually the @@ -589,7 +614,28 @@     /* return public part */     return &this->stack;    } - + + + Why not using C++? + + After all these considerations about object oriented C, you might + ask, why we do not use C++ after all? The easy answer would be: xine wants + to be as fast as possible and C++ is simply too slow. But this is only the + easy answer and it is not entirely true any more. Thoughtfully applied, you + can write very fast C++ code with today's compilers, but these compilers might + not be available on all platforms in the necessary quality. Even with + a sophisticated compiler, C++ is much harder to optimize than plain C and thus + C compiles much faster. Another big problem is that the C++ ABI is not as + well-defined as the C ABI. With C, you can easily mix libraries and + applications built by different compilers. With C++, this is unlikely to work. + But the final argument is that xine does not really need C++. xine's + inheritance hierarchy is very flat, mostly one level only and does not need + things like multiple or virtual inheritance. Most of the external projects + that are used by xine are plain C as well and using more than one language + complicates the build system. As we saw above, we can emulate + object orientation reduced to our real needs in plain C. + + @@ -720,6 +766,22 @@ Then the output will be: "modulename: (function_name:42) message". + + _x_assert/_x_abort + + These are not purely logging functions, but despite their original C library versions, + they always output debugging text, which is why usage of these functions is preferred. + + + _x_assert() checks a condition and prints a note, + when the condition is false. In addition, a debug build and only a debug build will + terminate the application, when the condition is false. Release versions will only + print the note, but try to continue. + + + _x_abort() always terminates the application after printing a note. + + -- cgit v1.2.3