Re: [AD] No need for END_OF_MAIN (Windows)

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


On Friday 13 May 2005 22:54, you wrote:
> > Unfortunately, this will break code that has a struct member named 
main.
> > That may sound like an academic case, but it probably isn't.
> 
> I agree. Allegro 3.12 as well as Allegro 4.0 programs might use main as
> a struct memember, and then with the new version, suddenly would stop
> working (but I agree, it's an academic case).

Well, it seems that Julien at least uses it.
But I'd reject this fix anyway because it can break code without a really 
good reason for doing it.

> > It also suffers from the problem that int _mangled_main(); doesn't mean 
the
> > same thing in C++ as it does in C, although you can probably get around
> > that by replacing () with (int argc, char **argv).
> 
> Hm, wouldn't have though of that, but yes, the empty parenthesis are C
> only, in C++ they would declare a function with no parameters, even
> inside extern "C".

I think it's one of the reasons Allegro uses a void pointer to get the 
address of main(). Although I'm not sure why doing void 
*_mangled_main_addres = main; wouldn't generate a warning or error aswell 
in C++. It obviously doesn't.

> Both could be solved by simply providing main/WinMain inside Allegro,
> and have the user code use e.g. allegro_main as main function. Something
> like:
> 
> void allegro_main(void)
> {
>     /* program goes here */
> }

But then, we need to do the same on other platforms too, don't we?
I'm also not too much of a fan of having a custom `allegro_main' entry 
point and no `normal' main in user code. Probably for no good reason 
though.

> Another problem is when the ALLEGRO_NO_MAGIC_MAIN behavior is desired..

Yes, that is a problem. I'm curious if SDL has anything like that. As far 
as I know, you can't disable SDL's main mangling. At least, I looked for 
it and couldn't find it.

> but I'm not too sure how this currently works e.g. in OSX. I guess, just
> loading Allegro at runtime in OSX isn't as easy as in windows or linux,
> since some pre-allegro_init setup code seems to be in the
> allegro-provided main() function.

I have the sneaky suspicion that you actually can't pass 
ALLEGRO_NO_MAGIC_MAIN in MacOS X. Obviously I've never tried that though.

> [Oh, btw, speaking of OSX, Angelo told me in #allegro he sold his Mac,
> so he won't do any OSX work in the next time, so OSX all rests on Peter
> Hull and Thomas Harte and whoever does testing on it for now.]

Oi... too bad! Although Peter H. and Thomas H. have both been extremely 
helpful so far. As an aside, I'm considering getting a laptop for work, in 
which case I'll be sure to get a Mac (they're small, look cute, fairly 
powerful, work well when connected to beamers, everyone has one and I'm 
not paying for it anyway). That'll take at least a couple of weeks/months 
though.

> Exactly, that's the main reason why there's no point with a patch like
> this. As long as END_OF_MAIN is needed in OSX, all standard uses of
> Allegro on all platforms need it, else we lose source portability.

As it is right now, you get no warning in *nix or DOS about it not being 
present... is that something we should change? I don't think it matters in 
practice, as long as we don't document when it's not needed ;)

Evert




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