[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Devel] PureC
From: |
David Turner |
Subject: |
Re: [Devel] PureC |
Date: |
Sat, 16 Jun 2001 18:39:23 +0200 |
Hi Wolfgang,
>
> The first problem is to compile a construct like this one (example from
> ftimage.h):
>
> typedef enum FT_Glyph_Format_
> {
> ft_glyph_format_none = 0,
> ft_glyph_format_composite = FT_IMAGE_TAG( 'c', 'o', 'm', 'p' ),
> ft_glyph_format_bitmap = FT_IMAGE_TAG( 'b', 'i', 't', 's' ),
> ft_glyph_format_outline = FT_IMAGE_TAG( 'o', 'u', 't', 'l' ),
> ft_glyph_format_plotter = FT_IMAGE_TAG( 'p', 'l', 'o', 't' )
>
> } FT_Glyph_Format;
>
> PureC only allows INT as element of enumeration. So what can I do? One easy
> way would be:
>
> #ifdef __PUREC__
> typedef enum FT_Glyph_Format_
> {
> ft_glyph_format_none ,
> ft_glyph_format_composite ,
> ft_glyph_format_bitmap ,
> ft_glyph_format_outline ,
> ft_glyph_format_plotter
>
> } FT_Glyph_Format;
> #else........
>
> I guess, this works if and only if this enumeration is used inside
> FreeType without relation to imported type-data. But I do not know if
> this is so.
>
client applications should only use the enumeration identifiers,
so changing their values for _specific_ platforms should solve
the problem.
> Can I do so or do you have an other idea?
>
Just to clarify things, we're using an enumeration here is
to allow third-party extensions. For example, imagine that
we want to provide a "MetaFont" font driver for FT2.
We'll need:
- a "font driver" module to parse/load the font files
in memory, and generate metrics and glyph images
from them.
- a specific "renderer" module, since the glyph images
produced by MetaFont cannot easily be converted into
the bezier-based FT_Outline type.
If we use 32-bit integers for the glyph format type, we
can easily create a new one without risking conflicts
when two third-parties try to produce their own image
format. Of course, that's extremely unlikely but it's
relatively easy to be safe with enums..
I always thought that enum types were widened to "long"
in ANSI C if one of the constants listed couldn't fit
in an "int" type.
Could one of our ANSI-aware developers here give us
more details about this issue ? I didn't find anything
relevant in the books I own :-(
Now, using a special configuration macro to restrict the
use of simple integers for the glyph format type should
be enough.
Regards,
- David
- [Devel] PureC, Wolfgang Domröse, 2001/06/15
- Re: [Devel] PureC,
David Turner <=