[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Removing the usage of X structures (or their names) in independent c
From: |
Eli Zaretskii |
Subject: |
Re: Removing the usage of X structures (or their names) in independent code |
Date: |
Thu, 09 May 2019 20:12:03 +0300 |
> From: Alex Gramiak <address@hidden>
> Cc: address@hidden
> Date: Thu, 09 May 2019 10:26:44 -0600
>
> > Why do you prefer a union? It uglifies the code and makes it harder
> > to read and understand. OTOH, having a backend-independent type (what
> > you call "typedef") is much cleaner.
>
> The union approach would be more future-proof (if the goal of multiple
> backends at once is realized), and I find it neater than having
> different types per backend. I would consider the union approach as
> having a "backend-independent type"; in the union approach, all backends
> of Emacs would have that union as the type, whereas in the typedef
> approach each backend pastes its own type into the generic parts of the
> code.
>
> The above goal is still far away, so it wouldn't be terrible to use
> typedefs in the interim.
Yes, I'd prefer not to make changes that are needed by future far-away
goals, especially when those changes makes the code less readable.
> > If that new structure is defined as (for example)
> >
> > typedef XColor EColor;
> >
> > then there's no overhead at all: you could simply assign an EColor to
> > XColor or even use the former directly in APIs that want the latter.
>
> Right, I meant overhead in the case of defining a new structure rather
> than defining a new name for the structure. For example:
>
> struct EColor
> {
> uint16_t red;
> uint16_t blue;
> uint16_t green;
> uint16_t alpha; /* Who knows, maybe? */
> unsigned long long pixel;
> };
>
> Which would need to be converted to XColor on the X backend.
But that's not needed if you use typedef as above for X. And for
non-X platforms we already have a definition of XColor, which just
needs to be renamed to EColor.
> > For more complex situations, see what we do with 'struct font' and
> > 'struct FOOfont' for font backend FOO.
>
> Could you point me to somewhere specific for this? I'm unsure to what
> you're referring.
For example, in ftfont.h:
struct font_info
{
struct font font;
#ifdef HAVE_LIBOTF
bool maybe_otf; /* Flag to tell if this may be OTF or not. */
OTF *otf;
#endif /* HAVE_LIBOTF */
FT_Size ft_size;
int index;
[...]
}
And an example how this is used in xftfont.c:
static int
xftfont_draw (struct glyph_string *s, int from, int to, int x, int y,
bool with_background)
{
block_input ();
struct frame *f = s->f;
struct face *face = s->face;
struct font_info *xftfont_info = (struct font_info *) s->font;
This is for when you need to extend a platform-independent struct (in
this case 'struct font') with platform-dependent additions.
> In any case, would you prefer using names like EColor, EPixmap, EGC, or
> Emacs_Color, Emacs_Pixmap, Emacs_GC?
The Emacs_ prefix is short enough, so I guess it's better.