I want to know what is the difference between int main() and int main(void) in an allegro program.
If there are any other alternatives, please explain.

There is no difference. And that's basic c/c++, not allegro-specific.

You can also have int main(int argc, char* argv[]), which accepts command-line parameters. argc is the amount of arguments, argv is the array of arguments, with the first one being the program name.

In C++, the standards state the void should be omitted. The C++ standards also makes the names argc and argv mandatory, but in C, you can call them whatever you want. Most C++ compilers probably do allow this anyway, even though it's not following the standard.

There is a difference in Allegro terms . Always use int main(int argc, char **argv). On Mac and maybe iOS it's required in C++ programs. You can't compile with int main(void).

For the most part, how you define your main is up to if you need command line arguments, or just how lazy you are feeling at the time.

Allegro has requirements for main to work on OS X, (and perhaps other platforms). The required form is int main(int argc, char **argv).

I have no idea where the docs tell the user, but I remember it from discussions in past threads.

Edit:
Slow Hippo is Slow

Ok, thanks for replies!

Really? That's pretty surprising, considering you don't have to use the same argument names in .h declaration and the .cpp definition.

Yup.

http://www-d0.fnal.gov/~dladams/cxx_standard.pdf

Section 3.6.1 paragraph 2

Hmm...

Well, that doesn't explicitly say that those particular names are required; but I can see why people might think that the strict technical meaning may allow particular implementations to disallow different argument names..

But I still doubt that was the intended meaning of the document; and I'm not completely convinced that it is even the strict technical meaning! (I'm actually reading this version now, because I figure it's more up-to-date; and I'm scanning through other sections to see whether it says that the particular variable names are unimportant in function definitions.

I notice that in 8.3.5 (of the document I linked to) it says

So to me that implies int main(void) is ok.

And ...

... could imply int main(int argc, char** argv) is allowed...

In any case, despite the possible technicalities, I'd still be pretty comfortable renaming argc and argv if I wanted to – but I don't think I'd ever have a good reason to do so anyway.

My interpretation of it is that those two forms are the only two forms that MUST be accepted, and that other forms are optional.

Ditto. GCC and MSVC++ both allow things that aren't in the standards, and they're the two most widely used compilers.

Its bad style to do int main(void). My Comp Sci I professor would kill me if he saw me still using int main (void) or even worse, void main(void).

I am sure someone will correct me if I any of these points are wrong...

int main() and int main(void) are actually different. The 1st says the number of arguments is unspecified (implicit), where the 2nd one says that there is none (explicit).

If a type is not specified in C it assumes that its an int. So main() assumes that the return value is an int. Where void main() says that main does not return a value, operating systems get quite upset when main doesn't return anything.

That's only true in C. In C++, f() is equivalent to f(void).

Void functions always "return" something, but it's probably random garbage.

I'm not so sure about that. The return value is passed on the stack normally (afaik). The compiler should be free to omit the stack push/pop for a return value if the function is declared as "returning" void.

I thought they were normally stored in the EAX register if they fitted.
But I'm not sure.

Well then all my assembly code is wrong. OTOH, it works fine.

It has always been a mystery to me what main should return.
So I finally googled.

http://stackoverflow.com/questions/204476/what-should-main-return-in-c-c
"I believe that main() should return either EXIT_SUCCESS or EXIT_FAILURE. They are defined in stdlib.h"

Only useful if your program is used by another program. As far as I know, the OS doesn't care what programs return.

If there's more than 1 potential error state, it should return a different non-zero value for each. For something that either works or doesn't, then sure, EXIT_SUCCESS and EXIT_FAILURE are good.

EDIT: Though the actual range of values that can be returned differs between operating systems. I think some only go from 0 to 255.

The value returned by main is used as an exit code for the process. But exit codes are only 8-bits on all OSes where I've seen them firsthand (DOS/Windows and several Unixes) so only the low 8 bits are preserved.
The most important convention is return 0 on success and non-zero on failure, but it only actually matters if whatever runs your program cares about it :
For example if you set up your program to run using Windows's scheduler, after execution the log will mark it "failed" if the return code wasn't zero.

Nonsense.

void main(void) isn't proper C and he'd be right to kill you (or at least look at you very sternly) for using it. int main(void) is perfectly fine.

Depends, I think.

I'm sure this used to be true back when I was looking at 16 bit DOS assembly. I'm also fairly sure you're supposed to use rax (eax, ax, al, whatever) in 64 bit assembly. I'm far less sure about 32 bit, but I think it's supposed to be eax there as well.

From an Agner Fog pdf.

{"name":"606545","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/b\/9bf3d5b0ae0cd879ea7c9b6a7a924015.png","w":873,"h":571,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/b\/9bf3d5b0ae0cd879ea7c9b6a7a924015"}

Ah, so register first, then stack if needed. I thought using a register was just an optimization C compilers liked to do, and the stack was the proper place for it. At least on x86 where there is no dedicated return register.

There's no stack in the usual sense mentioned there. ST(0) etc. are the "stack" on the floating point coprocessor, the XMMx stuff are the SSE registers.

Oh, really? Huh.

Are return registers demanded by C, or is it implementation defined?

I like to explicitly declare void arguments. Just as I like to fully qualify instance members with this and class namespaces. There's nothing wrong with it. In fact, I'd argue that it's better. You're being more explicit about what you want. There's less chance of you making a mistake that way.

Append:

char * [] is the most correct type for argv AFAIK. I'm not sure if people were saying that doesn't work on OS X (for whatever stupid reason) or if those people are just used to char ** (there's little practical difference).

Implementation defined, that's why he made that chart.

[EDIT]

Or maybe I should have said OS defined.

In C you WANT to declare void arguments. In C++ it doesn't matter, but maybe makes it a bit clearer.

I see, good to know. So I assume most/all implementations for x86 do it that way? I would assume yes, just so they are somewhat compatible.

Yes, although there are tons of other gotchas, such as Windows requiring prepended underscores on globals in the assembly code but not the C code, Linux has the "red zone" (although you can ignore that if you want) etc.

Windows also has a different calling convention for some things. But I don't know if that affects the return. The underscore thing just just part of the object/binary spec. COFF demands an leading underscore. Even C compilers add the underscore in the compiled code.

{"name":"606547","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/d\/9d61580b64b73c2a6f341b02584456f0.png","w":1236,"h":1316,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/d\/9d61580b64b73c2a6f341b02584456f0"}