freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Devel] FT_Outline_Copy


From: Graham Asher
Subject: RE: [Devel] FT_Outline_Copy
Date: Tue, 24 Sep 2002 17:43:13 +0100

Scott,

thanks for your reply.

<<<<<<
Constructors and destructors are the simplest solution,
because they already know how an object needs to get cleaned up.
>>>>>>

Yes - and private members, virtual functions, and notational aspects like
being able to declare variables at their point of first use. I advocate
nothing more than a subset of C++ - but not a very restrictive one. I tend
to find it convenient to use everything except RTTI, virtual inheritance,
exceptions, and a few other finicky things. I agree with you completely on
the idea of adhering to a basic coding standard. My background is in working
on multi-platform C++ code for Symbian, Slangsoft and RIM, among others, and
it's really not too hard to establish some simple ground rules.

<<<<<<
But is there any reason
why we can't have a maintained C++ API to wrap it?
>>>>>>

No, there isn't. But I would go further than that and suggest making all the
FreeType objects - faces, glyphs, outlines, and so on - into classes and
using these internally as well as externally.

<<<<<<
I guess another option would be to introduce constructors and
destructors to FreeType, with extremely well-defined semantics about
when they are supposed to be invoked. That could help at least make it
easier to manage the problems of object ownership, etc. If the user
constructs an object, he is responsible for destructing it. If the
library constructs an object, *it* is responsible for destructing it.
>>>>>>

This is exactly what I am in favour of. It's also useful to establish the
rule that public constructors can't fail. If I need to create an object that
allocates memory or does something else that can fail, I use an idiom
borrowed from Symbian: make the constructor private and write a public
factory function called New that returns NULL if it fails:

class CMyClass
        {
        public:
        static CMyClass* New();
        ~CMyClass();

        private:
        CMyClass();

        // etc.
        };

That way, if you can get hold of a pointer to CMyClass, you know it points
to a valid object.

My general rule when designing APIs is that all public functions should be
callable in any order. That is, there must be no states that control what is
or is not legal.

Best regards,

Graham





reply via email to

[Prev in Thread] Current Thread [Next in Thread]