Differences between C and C++: Can Anyone Explain?

[blazero]

I spent a small amount of time learning C before going into C++, and would like to know why main() has to be int now when it was void before. It seems pointless, as no OS can use the return value for anything good.

I know this question may sound stupid, but it's purely human to wonder.

 

[Salem]

> as no OS can use the return value for anything good.
Actually, most non MS-windows OS can easily get the status result.
For example, in a console, it is in the ERRORLEVEL shell variable.
If your programs ever become useful enough to others in a scripting environment, returning useful status values will get you many blessings from the users of your programs.

Long ago, I once tried to use a program written by a void main programmer, and it was pure hell trying to figure out whether it succeeded or failed. This is because the OS got some random garbage for the exit status since the programmer could not be bothered with a few extra keystrokes.

> and would like to know why main() has to be int
main has always returned an int, in both C and C++.

Sloppy compilers accept void main for some odd reason. Like saving a few keystrokes in many thousands of lines of source code actually saves anything. The problem with learning dialect-C (or what your compiler will let you get away with) is that moving to another compiler breaks all your assumptions about what is ANSI-C vs. some compiler vendors extensions.

Read the C FAQ
This isn't some esoteric argument, there is at least one real system where this really matters - example

--

 

[chipperMDW]

> no OS can use the return value for anything good.

That's wrong.

As Salem already said, it does get used for something good in scripting, at least in Unix-like systems.

Consider the following script (no need to undestand what it's doing):

tar xzf stuff.tar.gz && cp stuff/README ~/docs && rm -r stuff ||
echo "Something bad happened..." >&2 && exit 1;

If programs didn't use return values, you'd have to write:

tar xzf stuff.tar.gz;
if [ ! -e stuff ]
then
    echo "Something bad happened..." >&2;
    exit; # no return value, of course
fi

cp stuff/README ~/docs;
if [ ! -e stuff ]
then
    echo "Something bad happened..." >&2;
    exit; # no return value, of course
fi

rm -r stuff;
if [ -e stuff ]
then
    echo "Something bad happened..." >&2;
    exit; # no return value, of course
fi

That's not as correct. You don't know if the files exist or don't exist because of the commands failing or some other reason.

Of course, that wouldn't even work, since the [tt][[/tt] program wouldn't return anything to [tt]if[/tt].


> when it was void before.

When was that? Again, main has always returned int. It is invalid C and C++ for main to return void. Just because some misguided compilers accept it doesn't make it valid.

 

[chipperMDW]

Ok, the indentation in that first script is horrible... but it's still the better one.

 

[lionelhill]

I've always felt it's a bit arbitary what gets returned. I mean, an integer is useful, but surely there are better and more flexible ways for a program to communicate with its operating system than a single integer, take-it-or-leave-it? But these questions are theoretical. An integer is what we've got, and that's that. And it Is useful.

 

[PerFnurt]

>surely there are better and more flexible ways for a program to communicate with its operating system

Probably. But consider it should work for _ALL_ operating systems.

/Per
[sub]
"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."[/sub]

 

[Salem]

Well anything more complicated than a small positive integer can be stored in a file.

For example, a program can print a verbose description of why it failed to stderr, and also return an exit status indicating that there was a problem.

If you couple this with the shell's ability to redirect output (using [tt]>, >>, ``, |[/tt]), its a pretty powerful system.

Oh, and back on topic C and C++ differences


--

 

[lionelhill]

oh, yes, I'm not saying there aren't a lot of other ways to do it. For that matter most operating systems provide environment variables that can be set and changed from within a program. But all in all it seems a bit arbitary to provide this extra integer. You could make a file stating the output of your program every time if you like making files, or always set environment variables (quite tidy that one: you set it at the start to "something went wrong", and last thing you do before you stop is set it to "it all went right"; then no matter how your program ends/collapses-in- anarchy, the result is correctly defined).

Let's face it, the "just an integer" is not a carefully thought out piece of logic, it's just something historical. Of course it might be unwise to change it now in a new version of some operating system, since backward compatibility is a good thing.

But it's all a bit theoretical. It's not going to change, is it?

 

[PerFnurt]

>most operating systems provide

most != all

/Per
[sub]
"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."[/sub]

 

[blazero]

The way I learned C, it allowed the use of a void type for main(). Only in C++ have I got warning errors for non-int main() functions. main() being of the int type has its uses, but most of the time it simply returns 0, so again I wonder why so many compilers force main() as int.

 

[Salem]

When you get past student exercise programs, and start working on real programs that can have real failures, then you will understand.

> so again I wonder why so many compilers force main() as int.
Because the compiler writers have read the standards, and those standards say main returns an int.

I assume you wouldn't dream of providing code like this to a colleague if they asked for this,

int add( int a, int b);

and you provided them with this.

void add ( int a, int b ) {
   int c = a + b;
   // something will be returned, I just dont care....
}

So why treat main() with such a careless attitude?

--

 

[chipperMDW]

> The way I learned C, it allowed the use of a void type for main(). Only in C++ have I got warning errors for non-int main() functions.

*Ahem*:

> Just because some misguided compilers accept it doesn't make it valid.

The same goes for teachers, books, online tutorials, or whatever you learned from.


> main() being of the int type has its uses, but most of the time it simply returns 0...

So? Most of the time, fclose simply returns 0.


> ...so again I wonder why so many compilers force main() as int.

*Ahem*:

> It is invalid C and C++ for main to return void.

Most compilers do try to flag invalid code. That's part of their function.

If you still can't or won't believe it's invalid, as we've said, look at what the creator of C++ has to say about it. If you don't believe us, perhaps you'll believe him:

http://www.research.att.com/~bs/bs_faq2.html#void-main

 

[chipperMDW]

lionelhill:

We need an OS where we can declare OS-level types and have programs return those.


So, when you install, say, a web browser, you'd declare a "BrowserReturnStatus" OS-level class.

You'd have declare the browser program (function) like:

BrowserReturnStatus mozilla( string URL );

And, of course, overload it for alternate command line options.


Then you'd be able to pass OS-level pointers to programs around, and have program templates, and program objects...

And you'd have those OS-level types that could have member programs, or inherit from other types, or you could have virtual member programs, pure virtual member programs...

It'd be great.


[tt]$ Program* p = new browser<Mozilla,BrowserTraits<Mozilla> >
$ p->run( new URL<HTTP>( "

http://www.google.com"

) )[/tt]