int main() or void main ()?

What is really correct way ?

int as return value is standard I think, I'll check it up

The standard is:

Code:

---

int main(int argc, char **argv)

---

(I can't remember whether envp is in the standard or not, but it's supported on quite a few compilers).

You don't have to use all the arguments, so int main() is still valid.

I always use int main, but my programming teacher insists on using void :rolleyes:

Silly fool :p

The ANSI standard suggests int, because void cannot return a value.

Both linux and windows want the app to return a value, so int main() is better, but not necessary, if you do void main() the return value wil usually be some random number if the CRT startup does not catch it.

Are we talking about what you can get away with on x86, or what the standard says? :p

On x86 the only difference return type makes is whether you get a real value or not, since it's returned by register. Some systems expect the value to be pushed onto the stack or something similar, and you can imagine the destruction caused if you didn't return a value ;)

Yeah, but I haven't seen anyone on this forum ever talking about any other CPUs than x86 compatible.

It applies to me at least (the reason why I'm a Nazi about it comes out now :p).

At work I use MIPS and SPARC. Since I don't know much about their internals I have to follow things like this "just in case".

Gee, what kind of weird job do you have?

Writing finite element analysis post-processing software that runs on Sun and SGI workstations :)

Admittedly PCs (especially those dual Athlon monsters) are overtaking them now, but that's what we've got and when you've got 8 CPUs you don't talk back ;)

Cool! What does that mean? "finite element analysis post-processing". Is it me or just my lack of English?

Do a search for finite element analysis and you'll see what I mean :)

Straut-soup said INT !

It's Stroustrup

Quote:

---

Originally posted by setnewfocus
Straut-soup

---

LOL :eek:

whats the point of returning a value in main()?

i use void 90% of the time, and if i wanna exit i just do exit(1)

Because it tells the OS how your program did. Returning a value other than 0 indicates that your program exited abnormally.

PS: I don't think exit is a good idea under C++, it might not call the destructors... *checks*

Look -

Every language has baggage. C grew up under UNIX. Standard ansi C allows void main() as well as int main().

Just like it allows goto.

Does this make goto a good choice?

NO!

Under unix you return 0 for success (ERROR_SUCCESS) and any other number (almost always one) as failure.
EXIT_FAILURE is a macro that is there for every version of c I've ever seen or heard of.

Code:

---

#define EXIT_FAILURE  1

---

C images can be chained, therefore the calling image wants to know the status of the called image. _exec() chains images as does about 20 other fuinctions under VC++.

Therefore, use int main() even tho I use void main() for C examples on this board a lot. This give you compatibility you may need later on.

I thought it was the other way round, i.e. UNIX grew up under C.

There seem to be certain situations where goto is ok:

Code:

---

void x()
{
  int* x = NULL;
  char* y = NULL;
  long* z = NULL;
  x = new int[120];
  y = new char[480];
  z = new long[120];
  ...
  if(failed)
  {
      delete [] x;
      delete [] y;
      delete [] z;
    }
    ...
    if(failed)
    {
      delete [] x;
      delete [] y;
      delete [] z;
    }
    ...
}

---

As opposed to:

Code:

---

void x()
{
  int* x = NULL;
  char* y = NULL;
  long* z = NULL;
  x = new int[120];
  y = new char[480];
  z = new long[120];
  ...
  if(failed)
      goto err;
  ...
  if(failed)
      goto err;
  ...
  return;
err:
  delete [] x;
  delete [] y;
  delete [] z;
}

---

This creates much cleaner code (no copy/pasting). Is this one of those few places where goto is ok?

Z.

thats where i use it, especially if theres a bunch of cleaning up to do

That's also where I thought goto had a rational use, but it's flawed, exceptions are much neater and prefered.

So, if failed, throw an exception?

Z.

[edit]
I really cant type.

Code:

---

void x() {
    int* x = new int[120];
    char* y = new char[480];
    long* z = new long[120];

    try {
        // something fails
    } catch(std::exception &ex) {
        cerr << ex.what() << endl;
        delete[] x;
        delete[] y;
        delete[] z;
    }
}

---

Although that won't protect you against new failing, which technically is supposed to throw an exception of type bad_alloc (derived from the standard exception class). So the better solution here is to have the pointers wrapped into a managed class that will delete the data if others failed.

but parksie, why is that a better solution? Why not catch the bad_alloc specifically?

Because you don't know which of the three new statements failed.

That was indeed annoying problem that I didn't take into account, will consider a change in the exception handling rules in BORK.