RE: [Devel] C++ API for FreeType

[Mark Storer]

I cheerfully agree with most of your points.

Save one: 

"they [constructors and destructors] are rather useless when you allocate
all your objects dynamically with explicit new/delete."

You reckon without things like smart pointers.  The std::auto_ptr<> template
in STL is an implementation of a smart pointer... it will automatically
delete one object when it is set to point at another, and will delete its
contents when it goes out of scope.  While templates may be out of the
question, it's not that difficult to build your own class to mimic that
behavior.

Glyph slots (for example) could be smart pointers.

There are other kinds of smart pointers as well (reference counting comes to
mind), but I don't know FT well enough to know where they'd be useful.

I STRONGLY recommned "Effective C++" by Scott Meyers.  It contains all sorts
of useful ideas, such as smart pointers.



--Mark Storer
  Software Engineer
  Cardiff Software

#include <disclaimer>
typedef std::disclaimer<Cardiff> Discard;


-----Original Message-----
From: Pavel Kankovsky [mailto:address@hidden
Sent: Sunday, January 13, 2002 9:45 AM
To: address@hidden
Subject: RE: [Devel] C++ API for FreeType


On Fri, 11 Jan 2002, Graham Asher wrote:

> 2. Private data members - for all data in class objects

They are almost useless in the context of a library like FT. The basic
private-public boundary is equivalent to the boundary of the library
itself. Types visible from the outside should include as few private stuff
as possible. In fact they should be either completely public or opaque
pointers (FT2 does not satify this condition but at least all "private"
fields of public structs are opaque). Types containing real private data
should be invisible to the code using the library.

> 4. Constructors and destructors.

They, esp. destructors, are extremely useful as long as you can exploit
their automatic invocation, ie. as long as the data you use are automatic
variables (or temporary values). OTOH, "they (as a mechanism rather
than a concept) are rather useless when you allocate all your objects
dynamically with explicit new/delete."

> 6. Inline functions - to make it entirely unnecessary to use preprocessor
> macros.

Well, there are some macros that cannot be replaced with inline functions.

The rest of things Graham proposed would certainly make code shorter,
clearer, and more readable--to a certain degree because they can be (and
sometimes they already are) emulated in C rather easily (I mean the amount
of work needed to do it would be insignificant compared to the amount of
work needed to, say, tune the autohinter or make workarounds for various
buggy but widely used fonts).

Unfortunately, advanced C++ features that would make real difference,
ie. exceptions and perhaps advanced templates, are off-limits because the
world is full of broken compilers.

> 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.

Speed overhead: no. Size overhead: yes, sometimes huge. C++ compiler has
to generate lots of data automatically (vtables, template instances, out
of line instances of inline code etc.). Because the compiles knows nothing
about other modules, a lot of data and code is generated multiple times,
and it is left to the linker to clean all this mess up. Unfortunately,
this approach leads to a disaster when the code is linked dynamically. One
of the reasons Qt & KDE are so bloated is that they mix C++ and dynamic
linking (moreover, this causes secondary performance penalty).

IMHO, this and the lack of C++ ABI that makes code generated by different
compilers (or even different versions of the same compiler) binary
incompatible, are the strongest arguments against C++. It may be still
worth trying to code FT in C++ but I do not think it would be a good idea
to do it before the next major redesign of the whole library.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."


_______________________________________________
Devel mailing list
address@hidden
http://www.freetype.org/mailman/listinfo/devel