Re: C Object System

jacob navia wrote:
Laurent Deniau wrote:
Ian Collins wrote:

Laurent Deniau wrote:

I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/cos-oopsla07-draft.pdf

I would be interested by any feedback from C programmers (with little OO
knowledge) to improve the paper quality, even if I don't know yet if the
paper will be accepted. It is not intended to be a manual nor an
introduction to OOP. Just to mention it (not in the paper), my
programming background is 10+ years of C/C++.

Given your background, I have to ask why? The features you describe in
the paper have already been added to C, in the form of C++.


<OT>
In fact, this is the usual answer I get when I am talking about OOP in C. But the object model of COS has nothing to do with the one of C++.

COS is very close to CLOS from the point of view of the object model with many similarities to ObjC due to the fact that it is built on top of C. But it is very far from C++. As an example, one can look at the GoF patterns and check for each one why it is needed. Most of them are there to solve either a problem related to static typing and/or coupling and/or dynamic behavior and/or missing meta-knowledge. As soon as you jump on the dark side (i.e. dynamic typing, dynamic dispatch, meta-classes), they become much less useful. Code and design become simpler but more permissive.

My point of view is that all the paradigms (SI, MI, template, overload, override, namespace) introduced by C++ provide (powerful) static glue (coupling) except dynamic_cast which is not the heart of C++ programming. C++ can be very flexible with meta-programming which is the modern approach of libraries design (i.e. STL, Boost). But this flexibility exists only statically at the code level and often makes unforeseen extension very difficult and/or complex to add. To achieve flexibility and extensibility in C++ at the level of frameworks, one need to think in term of roles and components (see ref 21 and 22 of the paper). Pushing this reasoning to the limits (i.e. one method per role) and the roles become generics. For a global approach to the problem but specific to C++, one can read the book of John Lakos "Large-Scale C++ Software Design".


The reasoning behind the C++ fixation with static construction of software is efficiency.

Objective C and all dynamic typed systems need a run time cost that
the designers of C++ thought it would not be worthwhile to implement.

This obsession with efficiency has some advantages (speed, for instance)
but imposes certain constraints to the language, constraints that
preclude introspection at run time, dynamic class definitions or similar
constructs.

They point are more related to static typing than to efficiency.

It would be interesting if you would explain your viewpoint about this
concerning your design. Is the cost of run time message lookup an
important part of the runtime in a typicall program?

For conclusion on real application, I am afraid that you will have to wait a bit. But since you have read the paper, you understand that I am also very concerned by this point. So I will do my best to make the answer being 'no'.

My experiences has shown that when polymorphism (flexibility, reuse) is a gain, then speed matters less (say within an average factor of 1.5 to 3, not 15 for Java or 100 for Python). When speed matters, polymorphism is often much less important. COS is an OO layer on top of C, so efficient algorithms can still be written in C and methods specialization call them when available. This is the typical approach of Cocoa (MacOS X) where half of the Objective-C API has an equivalent in bare C. The higher abstraction of OO also allows to make some better designs which often lead to better *average* efficiency.

The same apply to C++ except that with meta-programming (templates), it is possible to have the best of the two worlds as soon as everything is *statically known*. Unfortunately, in real application, a lot of information is loaded at runtime and translated into static information if it is possible. If it is not possible (often the case), you have to deal with various design patterns to write a framework equivalent to an interpreter and then complexity starts to grow exponentially. So the gain or the loss of efficiency with C++ is not that obvious. Not to say that C++ programs can be slowed down by many tricky pitfalls like badly written copy constructors or bad strategic choices of objects ownership.

As a conclusion, I believe that simplicity leads to better design which leads to good efficiency. Ultimate efficiency can still be achieved on the 5-20% part of your code which may need it. This is the target of COS. Here is a table summarizing my point of view (note are over 10):

C++ COS Java/C# Python/Ruby
flexibility 1-3-6 8-9-10 4-6-8 7-9-10
efficiency 6-8-10 5-8-10 3-5-7 1-2-4

in the form of worst/avrg/best cases from 1 (worst) to 10 (best). Obviously, commenting these values would take some time...

a+, ld.
.

Relevant Pages

  • Re: C Object System
    ... I would be interested by any feedback from C programmers (with little OO ... C++ can be very flexible with meta-programming which is the modern approach of libraries design ... To achieve flexibility and extensibility in C++ at the level of frameworks, one need to think in term of roles and components. ... but imposes certain constraints to the language, ...
    (comp.lang.c)
  • Software Development
    ... Programmers at very less investment. ... CAT Offers: ... Delphi Programmers: 18 Members ... Website architecture design ...
    (freebsd-questions)
  • Software Development
    ... Programmers at very less investment. ... CAT Offers: ... Delphi Programmers: 18 Members ... Website architecture design ...
    (freebsd-questions)
  • Software Development.
    ... Programmers at very less investment. ... Delphi Programmers: 18 Members ... Website architecture design ...
    (freebsd-questions)
  • Re: made it to page 4 of gforth tutorial
    ... Even the programmers on what I called the C team who had ... If you go to engineers who workfor a companies like Intel-- ... and design strategies-- don't be surprised when they ... it's been compilers from companies like ...
    (comp.lang.forth)