Re: [AD] 2 errors encountered in current CVS |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 08 Sep 2001, Javier González <xaviergonz@xxxxxxxxxx> wrote:
> Geez, guess __forceinline was not available in MSVC 5 then
>
> Hey Peter, I am wondering, could I ask what's so wrong between clear with vs
> standard inlined one
> Ok, maybe standard inline doesn't get inlined in debug mode, but (if that's
> all) what's so
> wrong with it? After all debug mode isn't designed to be fast.
The whole point of changing `clear' to `clear_bitmap' was to remove
the conflict with the curses library (which also has a function
called `clear'). If our `clear' doesn't get inlined, then link
problems will occur if you try and use Allegro and curses together.
Some people must have thought we were renaming `clear' just for fun.
Hmm, maybe "static inline" would have been better. Let's see:
In one of our headers, we have:
#ifndef ALLEGRO_NO_CLEAR_BITMAP_ALIAS
static inline void clear(BITMAP *bmp)
{
clear_bitmap(bmp);
}
/* for compilers without inline ability: */
static void clear(BITMAP *bmp)
{
clear_bitmap(bmp);
}
/* for compilers without inline ability, and causes warnings for
* unused static functions: */
#define clear(bmp) ((clear_bitmap)(bmp))
#endif
To use with curses, you'd do:
#define ALLEGRO_NO_CLEAR_BITMAP_ALIAS
#include <allegro.h>
#include <ncurses.h>
- Use clear_bitmap() for allegro.
- Use clear() for curses.
- No problems.
Without curses, it's just the usual:
#include <allegro.h>
- Use either clear() or clear_bitmap() for Allegro.
- If optimised, clear() will be inlined to nothing.
- If not optimised, clear() will take one additional function call.
But the symbol `clear' will only be accessible from the current
module, thus not causing linker problems.
- No conflicts with clear() methods.
Anything I miss?
--
SPUBBLING (SPUB ling), v. The superhuman feat of trying to wash one's
hands and manipulate the "water saving" faucets at the same time.
-- Rich Hall, "Sniglets"