RE: [Devel] C++ API for FreeType

[Graham Asher]

David,

to answer your questions,

<<<<<<
I'm actually extremely interested in knowing precisely which C++ facilities
you believe are important here.
>>>>>>

I shall answer that by looking at my code and listing the important features
I have used:

1. Classes - for objects like outlines
2. Private data members - for all data in class objects
3. Templates - for thin-template aggregate classes for dynamic arrays and
lists
4. Constructors and destructors.
5. Virtual functions - for use particularly in interface classes (like the
one used for decomposing outlines, which has four virtual functions: MoveTo,
LineTo, ConicTo and CubicTo)
6. Inline functions - to make it entirely unnecessary to use preprocessor
macros.

There is also an important design system that goes along with this, which is
that object ownership and lifetime is always clear and never constrained.
There is no object that owns all outlines, or all faces, etc; if I want a
new object of a certain type I just create it.

It goes without saying - but is often forgotten by API designers - that a
good API is one where it is possible to call all public functions of a
class, in any order, at any time; there is no state or context you have to
know about. If an object is accessible - that is, if you can get a pointer
to it by legal means (without casting) - then you can do anything you like
to it.

Another very important point: error handling is done without exception
handling, in the same way as FreeType, but I have adopted the EPOC-inspired
rules that (i) constructors can never fail; and thus (ii) objects requiring
memory allocation during construction do not have public constructors but
must be created using static factory functions:

        class MyClass
                {
                public:
                MyClass* New()
                        {
                        MyClass* c = new MyClass;
                        if (!c || c->Construct() != ENoError)
                                delete c;
                        return c;
                        }

                private:
                MyClass();
                int Construct();
                }

It would be even nicer to use the EPOC-like 'leave' system with a clean-up
stack, which I understand you also favour; and this idiom is perfectly
suited to it.

You make the point that there are two things to do:

<<<<<<
  - re-designing the API in OO fashion (be it in C++ or C),
    and knowing its benefits

  - C++ features that can only be implemented in C through
    painful tricks, and that add significant advantages
    to the project..
>>>>>>

I think the points I have made about object lifetime, ownership and the
freedom to call all accessible functions address the first item; and the C++
features that address the second one are mainly private data and
construction and destruction, but really include all the features I have
listed.

I've just thought of another thing. It's worth stressing to people who have
not worked with C++ that C++ adds *no* necessary speed overhead whatever
compared to C; and that questions of the efficiency of certain libraries
such as STL are not relevant to the project, which I am certain should not
use any libary facilities outside a few limited parts of stdlib, and
possibly not even those.

<<<<<<
Yes, your help would be greatly appreciated. Actually, I was wondering
wether you would be able to send us the header files that corresponding
to your C++ API, in order to have a better idea of what you're describing,
and be able to comment that.. ?

I would understand if you couldn't though..
>>>>>>

I shall ask the company I am working for whether I can send the header
files. I think there is a good chance - it may become part of a public
internal API to their system anyway.

Best regards,

Graham