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