Re: [AD] Proposal for new Allegro interface

[Sven Sandberg <svsa1977@xxxxxxxxxx>]

Laurence Withers wrote:
> Under C++, this is a total non-problem:
> 
>   extern FONT* al_font;
>   namespace {
>     FONT*& font = al_font;
>   }

Nice! Is `namespace' a standard feature and supported by all compilers?
I didn't know about it, but if it works, then it seems to solve a lot of
problems. But at least one problem remains: In C, if someone does:

   #include "myfile.h"
   #include <allegro.h>
   void foo(void)
   {
      KEY_STRUCT k;
      k.key = 1;
   }

where myfile.h declares

   typedef struct
   {
      int key;
   } KEY_STRUCT;

then `key' will be renamed after but not before allegro.h was included
so it gives a compiler error on the line `k.key = 1'. It is easily
solved by the programmer (just move #include <allegro.h> to the top of
each file), but not everyone who compiles a program is the person who
wrote it and not even everyone is a programmer. I don't know how common
this problem is though.

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

I think the reason why this can work is that:
 (1) `list' is a template, not a class, so it will be instantiated in
the object file that belongs to your source file and not in the C++
library, and
 (2) The #define occurs before the definition of the class, so both the
identifiers of the source file and the header file will be renamed.

If (1) or (2) is violated, I don't think the program will compile (or
link) correctly. The following certainly does not link under djgpp:

[keyclass.h]
   class KeyClass
   {
      void key(void);
   };

[keyclass.cc]
   #include "keyclass.h"
   void KeyClass::key(void) {}

[main.cc]
   extern int al_key[];
   #define key al_key
   #include "keyclass.h"

   int main(void)
   {
      KeyClass kc;
      kc.key();
      return 0;
   }

But anyway, if the `namespace' trick works, then we don't need the above
discussion :-).

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

There's also another problem with the unused static functions that I
forgot to mention: msvc 5 with warning level 4, and watcom, and possibly
other non-gcc-compilers, will generate tons of warnings for all programs
that use old names because most of the static inline functions will be
unused. I don't think this can be fixed without either converting the
file to use the prefixed API and #define NO_ALIAS, or remove the
warning. Maybe I'm overworried, but I just want to shed some light on
the problems before they arise.

Sven