freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] Searching for an FT2 tester program


From: David Turner
Subject: Re: [ft-devel] Searching for an FT2 tester program
Date: Wed, 25 Mar 2009 15:37:13 +0100

Thank you Oran, this looks better indeed. However, this is a patch against your previous patch and a patch against the current git sources would be better.

I also tried to apply your previous set of patches to the git repository, and it failed due to inconsistencies with the ChangeLog file. Can I ask you to provide a second set of patches from a more recent commit ?

I would also prefer if you do *not* modify public header files (e.g. ftimage.h), the corresponding declarations you want to add could instead be placed in internal/ftobjs.h

Apart from that, I'm still playing with the idea of using macros and other tricks to do the same thing, though this still requires a bit more work.
The main idea is to use a single declaration like the following:

#define  FT_FOO_CLASS_DEFS \
   _SIZE_FIELD( FT_UInt,      size ) \
   _FIELD( FT_Foo_InitFunc,   init ) \
   _FIELD( FT_Foo_DoneFunc,   done ) \
   _FIELD( FT_Foo_ActionFunc, action ) \

then use it repeatedly, e.g. to declare the corresponding FT_CMap_Class types:

/* declare FT_Foo_Class types */
#define  _CLASSNAME  FT_Foo_Class
#define  _CLASSDEFS  FT_FOO_CLASS_DEFS
#include FT_INTERNAL_CLASS_DECLARATION_H

which would generate the following code after pre-processing:

typedef const struct FT_Foo_ClassRec_*  FT_Foo_Class;

typedef struct FT_Foo_ClassRec_
{
  FT_UInt           size;
  FT_Foo_InitFunc   init;
  FT_Foo_DoneFunc   done;
  FT_Foo_ActionFunc action;
} FT_Foo_ClassRec;

then, to define a class in the code:

/* define 'foo_class' table */
#define    _CLASSVAR    foo_class

#define    _CLASSNAME   FT_Foo_Class
#define    _CLASSDEFS   FT_FOO_CLASS_DEFS
#define    _INITPREFIX  foo_
#define    foo_done     NULL
#include FT_INTERNAL_CLASS_DEFINITION_H

which in the non-PIC case would generate:

const FT_Foo_ClassRec   foo_class =
{
    sizeof(FT_Foo_ClassRec),
    foo_init,
    NULL,
    foo_action
};

(assuming foo_init and foo_action are already declared), but in the PIC case would do instead something like:

static void _init_foo_class( FT_Foo_ClassRec*  clazz )
{
  clazz->size   = sizeof(FT_Foo_ClassRec),
  clazz->init   = foo_init;
  clazz->done   = NULL;
  clazz->action = "">}

After that, there are other complicated details so that _init_foo_class is used appropriately,
i.e. it must be called at module initialization time in the PIC case only, with a heap-allocated
structure passed as a parameter. However, this can also be performed with macros.

I'm preparing a patch to show how this can work on the existing code base. However this is
going to take a long time, so I would prefer if we could first submit your changes, then slowly
migrate to this new scheme (we can do this piece by piece, fortunately).

There are also complications due to the fact that modules themselves are defined through a
constant table (but again, we can work with this with macros), and the challenge of "derived classes",
but I believe we should be able to support these as well with the minimal impact on duplication.

Regards


2009/3/22 Oran Agra <address@hidden>
Hi,
Here's a patch that changes what David requested, I hope I got it right.
Let me know if you have any other comments.
       Oran.


reply via email to

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