Re: Uninitalized Face data

[Antoine Leca]

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