Re: [AD] Magic main in Windows

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


On Monday 02 August 2004 11:58, Chris wrote:
> Unfortunately, because main can have varying arguments (main(), 
> main(void), main(int argc), main(int argc, char *argv[]), main(int argc, 
> char *argv[], <something> argz)), you can't know what the programer has 
> made and thus what to pass. The only way you could handle that would be 
> to create a macro that handles variable arguments, but those are only in 
> C99 (I'm not even sure C++ can do them).

I think the standard says main(void) and main(int, char**) are valid, but 
someone may want to check that.
Allegro currently works around this nicely by using a function pointer and 
a cast, as in Sam's example. We have basically

/* in user code, after Allegro's name mangling */
int _mangled_main(...)
{
}

/* in Allegro code */
int main(int argc, char *argv[]) 
{ 
   int (*real_main) (int, char*[]) = (int (*) (int, char*[]))_mangled_main;
   /* stuff */
   return (*real_main)(argc, argv); 
}

This is why I think that renaming the user's main and define our own (as 
SDL does), combined with a function pointer to work around the possible 
different definitions of main (what Allegro already does now) can be a way 
to work around the need for END_OF_MAIN() on Windows. Don't know how to 
work around the OS X problem though... :(

The problem with doing something more fancy than renaming main() to 
something else, like including code with it, is that it will do what we 
want for the actual main function. It will blow up in our faces in the 
case of the element of a struct being named main though (which is not an 
issue right now).

It'd suck if we can figure out a way to eliminate END_OF_MAIN() on all 
platforms except MacOS X.

Evert





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