Re: [AD] Proposal for new Allegro interface

[Laurence Withers <lwithers@xxxxxxxxxx>]

Thanks to Sven for these points -- they are all very good.

In reply to Sven Sandberg <svsa1977@xxxxxxxxxx>:
[snip]
>I agree that if something should be done, then what you suggest is very
>close to it. I even think that making palettes be 8 bit will work
>smoothly: As long as all old-style functions continue to assume 6-bit
>palettes, there's no harm done if the prefixed functions use 8-bit
>palettes.

Yes; the current set_palette et al. would use 6-bit palettes, and we
could provide al_set_palette8 for 8-bit palettes.

> There are four `extern PALETTE' variables, but those don't
>seem to be any problem either (black_palette isn't even different in 8
>bits, desktop_palette and default_palette are not read by the library
>anyway, and I don't think fli_palette is either).

Again, al_black_palette and al_black_palette8, etc.

> - What about variables? I think the only way to create aliases for
>these is with #defines. And this will be a problem for C++ programs
>which have member variables called e.g. `screen', `key' or `font', if
>one file that uses the class #includes <allegro.h> and another doesn't.
>This happens e.g. if the class is defined in some library. IMHO `key'
>and `font' are some of the worst namespace polluters so it would be a
>pity not to get rid of them.

Excellent point: something I totally missed. Under C++, this is a total
non-problem:

  extern FONT* al_font;
  namespace {
    FONT*& font = al_font;
  }

However, do we even need this? The following example compiles perfectly
under GCC's C++. Can somebody try it on MSVC, Borland, etc.? Thanks.

int other_clear = 0;

#define clear other_clear

#include <list>

void test(list<int>& l)
{
    l.clear();
}


> - Another problem is that some compilers (at least watcom) don't remove
>unused static functions, so that each object file will contain tons of
>such. Moreover, each such static function will contain a dependency to
>some part of Allegro (and conversely: each and every function in Allegro
>will be used in one of those functions), so that literally _all_ of
>Allegro will be linked in on those platforms.

OK, fair point. However, for a long while, most of Allegro was
statically linked under DJGPP even when you only used a few things due
to a bug (CONSTRUCTOR_FUNCTION wasn't defined under DJGPP), and Allegro
caused about a 200kb overhead once compressed with UPX. Obviously, you
get this overhead anyway if you use most of the stuff in Allegro.

And unless Watcom supports CONSTRUCTOR_FUNCTION (which I don't believe
it does), the whole lib is going to be linked in anyway. So although I
acknowledge that this is not ideal, I don't believe it is a show-
stopper.

Of course, I could extend the CONSTRUCTOR_FUNCTION system to cover
*everything*, thus solving the whole problem, but I don't like this
because it adds complexity where I don't think we need any.

> And it will require you to
>link with Allegro, which wasn't strictly needed before if you only used
>e.g. inline math functions.

As Peter said, I'm not really worried about this...

>But I would personally vote "no" unless someone comes up with good
>solutions to the problems I mentioned.

What do you think of the above?

Bye for now,
-- 
Laurence Withers, lwithers@xxxxxxxxxx
                http://www.lwithers.demon.co.uk/

Attachment: signature.asc
Description: PGP signature