[ Thread Index |
| More lists.liballeg.org/allegro-developers Archives
On 2006-09-07, Ron Novy <rsn1010011010@xxxxxxxxxx> wrote:
> >> Well, during development, you will always be in debug mode, and
> >> compile in release mode for the release, right?
> >> Few allegro programmers know that Allegro has a debugging mode (novices
> >> doesn't know it). Fewer knows how to use debugging mode, and even fewer
> >It's impossible to know this. If anyone doesn't know how to use debug
> >mode, or a debugger, they should learn.
> >I don't like Allegro's implementation of ASSERT. In DOS (and in
> >fullscreen modes generally) we needed to cleanly shut down the program
> >when an assertion was triggered, but an assert() from assert.h gives
> >more information than ASSERT() and is better with a debugger.
> Wouldn't it be fairly easy to add an #ifdef before the definition of
> allegros ASSERT so that we can take advantage of systems that provide
> a more advanced version of ASSERT ?
Yes, it's not hard to change. It's not dependent on platform but
whether the program has set a fullscreen video mode, i.e. possibly taken
over the screen.
> I use DJGPP and MINGW and I don't
> have MSVC so I'm not sure what the benefits would be. But then again I
> rarely use ASSERT in my own software (probably should) so I wouldn't
> have much use for it either way.
The benefits are at least:
(1) With plain assert() the expression which failed is printed out.
Allegro's ASSERT() only prints the filename and line number, which is
not as useful unless you have exactly the same copy of the Allegro
source code as used by the running program. In most cases the assertion
would be due to a NULL pointer, which is immediately obvious if the
expression is printed out.
(2) ASSERT tries to shut down Allegro and clean up. This can be quite
involved and changes Allegro's internal state from when the error
initially occurred. Also if there is a bug in the shut down routines
this can cause other errors (sometimes infinite loops).