Re: [AD] END_OF_MAIN removal patch for msvc

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On November 17, 2008, Peter Wang wrote:
> On 2008-11-17, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> > On 17 Nov 2008, at 20:36, Peter Wang wrote:
> > > It might be best just to expose the boilerplate to the user.
> > > For any program which wants to be portable to Mac OS X, you'd write:
> > >
> > >     int real_main(int argc, const char *argv)
> > >     {
> > > 	al_init();
> > > 	...
> > >     }
> > >
> > >     int main(int argc, const char *argv)
> > >     {
> > > 	return al_run_in_main_thread(real_main, argc, argv);
> > >     }
> > >
> > > Nothing up the sleeves.
> > >
> > > We might need three different versions of al_run_in_main_thread,
> > > for zero arguments, two arguments, and three arguments.  Of course,
> > > we'd
> > > probably get sick of writing that and end up providing a macro:
> > >
> > >     ALLEGRO_MAIN_WRAPPER(real_main, argc, argv);
> > >
> > > which looks suspiciously like END_OF_MAIN().  *But* it doesn't require
> > > the symbol `_mangled_main_address' to exist, which causes problems
> > > when
> > > people try to load the Allegro shared object at run-time, and there is
> > > no name mangling.
> >
> > My main concern would be the number of people who forget to do that,
> > inadvertently creating platform-dependent code.
>
> I've done that with END_OF_MAIN(), too.  Granted, END_OF_MAIN() is
> shorter so easier to remember.
>
> > My secondary concern
> > would be how that would interact with other libraries (probably no
> > worse than END_OF_MAIN(), but the thought occured).
>
> No worse.
>
> > My third concern
> > would be that I actually think that looks uglier than END_OF_MAIN() ;)
>
> We can tweak it until you're happy ;-)
>
> Actually, the argc, argv arguments weren't needed.
>
>     int real_main(int argc, const char *argv)
>     {
> 	...
>     }
>     ALLEGRO_END_OF_MAIN(real_main);
>
> > I think it makes sense to split the problem in two: requiring a copy
> > of argv[] and having a non-standard main/main requirement.
> > The former can be solved by providing a function to pass it (we need
> > some sensible default if a user forgets to do this), assuming we
> > really want it still.
> > The latter was never needed on *nix and now isn't needed on Windows
> > anymore either. That leaves OS X.
> >
> > If OS X is the only platform that needs a magic main at the moment,
> > we should again look for a way to get rid of it there too. The
> > ucontext stuff Peter [Hull] mentioned would be what I'd look into,
> > assuming there's a way to make it work in Tiger (Leopard and up
> > shouldn't be a problem if I understand correctly). Maybe (optionally)
> > not in debug mode though, but then we'd still need END_OF_MAIN() just
> > for that. Some sort of progress...
>
> The ucontext idea is fun, but I have a feeling it's too clever.

Wait, didn't allegro specifically go to an event loop and whatnot to get 
around this little problem? al_init() initializes any internal lib state, and 
the event loop gives allegro time to "do its thing" when needed without having 
an explicit al_update_allegro(); api. 

> Peter

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx