[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Uninitalized Face data
From: |
Antoine Leca |
Subject: |
Re: Uninitalized Face data |
Date: |
Thu, 24 Feb 2000 10:10:50 +0100 |
Arnar Mar Hrafnkelsson wrote:
>
> If I have an array of instance handles say:
>
> int i;
> TT_instance instance[10];
>
> for(i=0;i<10;i++) {
> instance[i]=NULL; /* this is the part that
> it doesn't like */
> }
Neither do I ;-)
You are suposed to create the instances with something like:
for(i=0;i<10;i++) {
TT_New_Instance(some_face, instance[i]);
}
> The reason is that freetype arranges TT_instance like:
>
> struct TT_Instance_ { void* z; };
> typedef struct TT_Instance_ TT_Instance;
Well, you did cheat by looking at the sources without:
- reading the doc (and in particular docs/apiref.txt)
- reading the comments that are just above the part you copied.
Here is a more larger extract:
] /* Here are the definitions of the handle types used for FreeType's */
] /* most common objects accessed by the client application. We use */
] /* a simple trick: */
] /* */
] /* Each handle type is a structure that only contains one */
] /* pointer. The advantage of structures is that they are */
] /* mutually exclusive types. We could have defined the */
] /* following types: */
] /* */
] /* typedef void* TT_Stream; */
] /* typedef void* TT_Face; */
] /* typedef void* TT_Instance; */
] /* typedef void* TT_Glyph; */
] /* typedef void* TT_CharMap; */
] /* */
] /* but these would have allowed lines like: */
] /* */
] /* stream = instance; */
] /* */
] /* in the client code this would be a severe bug, unnoticed */
] /* by the compiler! */
] /* */
] /* Thus, we enforce type checking with a simple language */
] /* trick... */
] /* */
] /* NOTE: Some macros are defined in tttypes.h to perform */
] /* automatic type conversions for library hackers... */
> It seems that I have two choices -
>
> 1) Check the internal z pointer
> - which would seem like doing something I shouldn't be doing.
If you do that, you qualify yourself as:
- a library hacker, since you access datas that are supposed to
be hidden, as explained above
- ... which does reinvent the wheel, because the usage of the z
pointer is exactly what the macros (cited above) do.
> 2) Create an array of pointers to TT_instance and dereference all the
> time.
I see another solution: instead of using an array of TT_instance,
you create an array of structures, which structures contains:
- a TT_Instance object (which is a handle);
- everything your application might also need (in your case,
I believe a flag to signal if the instance is initialised or
not is what you are presently asking for).
> - This is a tad annoying since this seems to be a pointer anyway.
>
> It would be nice to have some macros like: Not_Null( instance );
> but from what I gathered in the documentation they were mostly for
> internals programming.
To know if a handle to an instance still is valid is not a straight-
forward task, indeed (need to check on deallocation of the instance
via TT_Done_Instance, as well as `indirect' ways like de-allocating
the face). This is even worse for TT_Glyph I believe.
David, is it an idea for new API?
Antoine
- Uninitalized Face data, Arnar Mar Hrafnkelsson, 2000/02/23
- Re: Uninitalized Face data,
Antoine Leca <=
- Re: Uninitalized Face data, Arnar Mar Hrafnkelsson, 2000/02/24
- Re: Uninitalized Face data, Bertrand Petit, 2000/02/24
- Re: Uninitalized Face data, Just van Rossum, 2000/02/24
- Re: Uninitalized Face data, Antoine Leca, 2000/02/24
- Re: Uninitalized Face data, Werner LEMBERG, 2000/02/24
- Re: Uninitalized Face data, Just van Rossum, 2000/02/24
- Re: Uninitalized Face data, Stefan Seefeld, 2000/02/24
- Re: Uninitalized Face data, Antoine Leca, 2000/02/25
- Re: Uninitalized Face data, David Turner, 2000/02/25
Re: Uninitalized Face data, Pavel Kankovsky, 2000/02/24