Re: [AD] END_OF_MAIN removal patch for msvc

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On November 18, 2008, Stefanos A. wrote:
> On Tue, 2008-11-18 at 18:25 -0500, Evert Glebbeek wrote:
> > On 18 Nov 2008, at 18:07, Thomas Fjellstrom wrote:
> > > Yeah, I'm not sure going whole hog on the event system is the right
> > > direction,
> > > but neither are hacks like END_OF_MAIN.
> >
> > END_OF_MAIN() actually works fairly well though, and it has the
> > distinct advantage of being very easy to change into a no-op on
> > platforms that dont (or no longer) need it. So unless there's a way
> > to truely make it a no-op on all platforms, maybe the best course of
> > action is the conservative course of action: not touch it.
> > As hacks go it also isn't horrible, I've seen far worse. The ucontext
> > stuff sounds like a bad hack, but if it's actually part of the OS...
> > I don't know.
>
> There are worse hacks that END_OF_MAIN, but not a whole lot :)
>
> The biggest problem is that it is very user-visible. The user
> (probably) doesn't understand why he has to type this. Even worse, the
> program may still work without the macro, but then fail on other
> platforms / configurations. This is the worst kind of bug, right in the
> hands of every single Allegro user: obscure, hard to reproduce and very
> easy to make.
>
> In that light, SDL is better: the implementation may be even more hacky,
> but at least it's not (much) visible to the user. GLFW is the best here:
> no magic sauce, the user simply has to poll for events (an easy concept
> to grasp).

This is what I want to do... Obviously. polling to keep allegro going really 
isn't a serious issue. And it gets rid of some nasty hacks.

> We are all long-time users of A4 and there are things we take for
> granted, but that shouldn't prevent positive changes from happening.
>
> > Anyway, while A5 is still in WIP stage at the moment, it should be
> > getting close to feature freeze or we're never going to make a spring
> > release date. Do we really want to discuss large changes to the
> > design (eg, changing the way Allegro works, mandating a message system)?
>
> Which is better: delaying a release for a month or a bad API that sticks
> for the next 5 years?

I don't think it'll require any real delays.

>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/