[AD] PALETTE and RGB* (part 2)

[Peter Wang <tjaden@xxxxxxxxxx>]

Sorry, I got confused in the other thread.  Let me try again:


If you put these prototypes in the same file, a C compiler will not
complain, so they are all equivalent:

    void foo(RGB *pal);
    void foo(RGB pal[PAL_SIZE]);
    void foo(PALETTE pal);

Ok, now, we're talking about 4.2 (possibly 4.0) so we don't want to
break anything.  The forms above are the only choices AFAIK (there is
already "void foo(RGB pal[])", but that's the same as the second).


void foo(RGB *pal);
-------------------

    IMHO, the _least_ readable.
  
    However, "RGB *":
    - works as a cast: (RGB *)
    - works as a return type: RGB *bar(void)


void foo(RGB pal[PAL_SIZE]);
----------------------------

    IMHO, the most readable.

    But it:
    - doesn't work as a cast: (RGB [])
    - doesn't work well as a return type: RGB bar(void)[]
	(well, gcc seems to not like it, maybe I got the syntax wrong)


void foo(PALETTE pal);
----------------------

    IMHO, also nicely readable.

    But:
    - it doesn't work as a cast: (PALETTE)
    - it doesn't work as a return type: PALETTE bar(void)
    - typedef arrays are generally confusing


So I'm tentatively changing my proposal to make all functions
consistently use "RGB *" syntax instead of "PALETTE".  How's that?


I say "tentatively" because I'm thinking of other languages.  Let's say
we're using Allegro from an a language with dynamically typed variables.
When a palette is created, it gets tagged as an "RGB *" value instead of
a "PALETTE" value.  You can then pass the value to any function needing
a palette without type errors.

However, if you create a single RGB struct¹ and it also gets tagged as a
"RGB *" value, and it gets passed (accidentally or otherwise) to a
function expecting a full palette, you will get a crash instead of a
run-time type error.

¹This needs to be possible to use get_color/set_color.

-- 
王浩禎