Re: Removing the usage of X structures (or their names) in independent code

[Alex Gramiak <agrambot@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex Gramiak <agrambot@gmail.com>
>> Date: Wed, 08 May 2019 22:28:23 -0600
>> 
>> Numerous internal procedures in Emacs that aren't tied to X expect and
>> use structures with the same name as X structures: e.g., XColor,
>> XGCValues, GC, XRectangle, XChar2b, Display, Pixmap, Cursor.
>> 
>> This poses an issue when attempting to use a non-X backend to Emacs that
>> conditionally uses X itself: name clashes occur between the structures
>> intended for use in the independent Emacs code and the internal X
>> structures. Workarounds using the preprocessor exist but are ugly and
>> fragile.
>> 
>> What would be the preferred way to fix this situation? Two options are
>> to use typedefs for these structures like XImagePtr_or_DC, or to use
>> unions. Everything else being equal, I would prefer the union approach.
>
> 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.

>> Alternatively, for structures like XColor, there could be new generic
>> structures that all the backends share, but that would involve some
>> overhead on the X side for conversion.
>
> 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.

> 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.

In any case, would you prefer using names like EColor, EPixmap, EGC, or
Emacs_Color, Emacs_Pixmap, Emacs_GC?