RE: [Devel] C++ API for FreeType - Portability

[Mark Storer]

It's fairly easy to solve the API-level arguments by using a C interface
atop your classes.

class foo 
{
public:
  int get_bar(void);
};

extern "C"
{
  int foo_get_bar(FOO_HANDLE foo);
}

That doesn't get you any closer to your embedded systems however.  I don't
know how important it is to bring your embedded systems along in the next
version.  Is FT2 'good enough' for them?


--Mark Storer
  Software Engineer
  Cardiff Software

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


-----Original Message-----
From: Manuel Bleichenbacher [mailto:address@hidden
Sent: Friday, January 11, 2002 3:40 PM
To: address@hidden
Subject: RE: [Devel] C++ API for FreeType - Portability


None of the major libraries in the open source world is written in C++.
That's for good reasons.

I don't dispute that rewriting freetype in C++ could improve its design and
interface, and make it easier to develop. However, C++ would make it much
harder to build applications composed of several libraries.

The portability discussion has circled around porting code from C++ compiler
A to C++ compiler B. That's not such a big issue with today's compilers. The
real problem is linking a library compiled with C++ compiler A and a library
compiled with C++ compiler B to the same application. It's impossible in
most cases.

Today's freetype library can be used in applications written in any
programming language and compiled with any compiler. That's because the C
struct layout and calling conventions are well defined and because their
run-time libraries are more or less standardized. If freetype is ported to
C++, it can no longer link to code compiled with a different C++ compilers,
and linking to other programming languages will be difficult because of the
hidden run-time libraries, template instantiations etc., which are required
by C++.

The situation arises for example on Solaris, where you find three different
popular compilers: Sun C++ 4.x, Sun C++ 5.x /6.x and gcc. They are
completely incompatible with regard to the produced code. They might compile
the same piece of C++ code but they generate code with incompatible object
layouts and their runtime libraries are in conflict. I know less about the
situation with Linux compilers but I could image that the situation is
similar with gcc 2.xx, gcc 3.xx and the Intel compilers.

And last but not least, a lot of embedded systems have no C++ compiler and
thus would have no new freetype versions.

So please, don't port freetype to C++ if you think it should stay one of the
major libraries used in diverse applications and any size of system. Port it
to C++ if you do it for educational purposes but do not otherwise care if
anybody else uses the library.

Wrappers for C++ (and Per, Python, Java, PHP etc.) are very much welcome, of
course.


-- Manuel


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