What does this mean?

[jrahhali]

Hi. I've got a question about a return statment and an exit() function. Here's the code:

NOTE: this is a member function of a fraction class that converts the fraction to lowest terms. as you might have guessed, *den is denominator and *num is numerator and gcd is greatest common divisor.

void fraction::lowterms()
{
	long tnum, tden, temp, gcd;

	tnum = labs(num);  
	tden = labs(den);
	if( tnum!=0 && tden==0 )
		{ cout << "Illegal fraction: devision by 0"; exit(1); } // <--PROBLEM HERE!!!!!
	else if( tnum==0 )
		{ num=0; den = 1; return; } // <--PROBLEM HERE!!!!!

	//...goes on to convert to lowest terms...
}

Now for the quetsions

1) I was taught that you use a return statment to return something to whatever is calling it. The return statement in the if statement just uses the keyword without anything following it. What does this mean?

2) I used exit() before to terminate a program, and was taught that 0 should be used to assure a successful termination. But the exit() function in the if statement uses a value of 1 for the argument. What does this mean?

I am using a Borland 5.5, so some of the functions may seem odd, but i'm not sure. the labs() function returns the absolute value of the supplied number.

[laserlight]

1) Let's take a look at the function:
void fraction::lowterms()
The return type is void.
So the function doesnt return anything.
We usually dont have to use return in this case.
However, to force the function to end and pass control back to the caller, we can then simply use:
return;

2) "and was taught that 0 should be used to assure a successful termination"
Then exit(1) means that "Houston, we have a problem"
Though frankly I'm not sure how standard using exit() is.
Probably would be better to return some error code, and handle the error more gracefully.
The function's return type, and possibly the way of use would have to be changed though.

[codec]

>> I was taught that you use a return statment to return something to whatever is calling
>> it. The return statement in the if statement just uses the keyword without anything
>> following it. What does this mean?

If you look at the definition of the function, it's return type is void.

 void fraction::lowterms()

This means the function cannot return a value. Therefore the return statement on it's own simply exits the procedure and returns execution to the calling procedure, immediately after when the procedure was called.

>> I used exit() before to terminate a program, and was taught that 0 should be used to
>> assure a successful termination. But the exit() function in the if statement uses a value
>> of 1 for the argument. What does this mean?

The exit(n) function just returns the specifed number to the operating system when the program terminates. These values are not often used. Normally they are only used in operating system batch command files.

Specifying 0 is just the accepted convention for success of the program. As 1 is for a failure.

Daniel

[jrahhali]

All right. That's pretty cool stuff. Thanks.

>>Specifying 0 is just the accepted convention for success of the program. As 1 is for a failure.

ahhh i see. so does this mean the number used in the exit() function doesn't matter at all to the OS, or the program, it's just used to tell the reader of success or error?

[codec]

That's true, yes (at least for Windows, not completely sure about *NIX). The number returned only matters to whatever interprets it.

So if you're not intending anything to interpret the value returned from your program, it's not really important, although for correctness, you should still return either success or failure as is required.

Take a look at these for more info on the exit() function

http://msdn.microsoft.com/library/de....2c_._exit.asp

http://msdn.microsoft.com/library/de...t_function.asp

MSDN Library is a great source for any Windows related programming.

-Dan

[codec]

This little snippet might also be useful to you

http://msdn.microsoft.com/library/de...asp?frame=true

[jrahhali]

Hey codec, this is really helpful. Thank's alot. I came across this in one of you links:

>>Issuing a return statement from the main function is equivalent to calling the exit() function with the return value as its argument.

does this mean finally i can use void main() - don't everyone freak out yet - and then put the statement exit(0); at the end?it sounds like it would be the same as if i used int main() and returned 0; Or is there still some reason why void main() is 'evil' and you should ALWAYS use int main()

[laserlight]

Or is there still some reason why void main() is 'evil' and you should ALWAYS use int main()

Using void main() doesnt adhere to the standards, so you *may* (or almost definitely would) have problems in some standard-compliant compilers and be unable to blame the compiler (aside from being unable to compile your code, of course).

[jrahhali]

>>Using void main() doesnt adhere to the standards, so you *may* (or almost definitely would) have problems in some standard-compliant compilers

so some (most) compilers have a problem with void main()? Which brings another question to mind. My compiler has no problem declaring main() void, so what exactly is the difference between how my comipler hadnles the end of a code and most standard compilers do? Does mine just..end? And others wait for a number to be returned to the OS to end?

[Prelude]

>Using void main() doesnt adhere to the standards
void main can conform to the standard, but chances are that our happy little forum-goers don't meet the strict criteria.

>so some (most) compilers have a problem with void main()?
Some compilers support void main, but others don't. The chances of getting burned are just too high for most people's tastes. If you use a compiler that allows void main, feel free to use it. Just don't expect us to take you seriously.

>so what exactly is the difference between how my comipler hadnles the end of a code and most standard compilers do?
If your compiler has the equivalent of

(void)main ( argc, argv );

then nothing will happen. On the other hand, if your compiler uses the equivalent of

action ( main ( argc, argv );

then Bad Things(TM) could happen because main's return value will be indeterminate. On the other other hand, if your compiler is super specially robust, accessing an indeterminate value assigned by the implementation may not cause a problem and nothing will happen. All of this relies on the quality of the implementation though. From what I've seen of some unnamed (for their own protection) compiler's source code, placing your trust in them for well defined undefined behavior would be foolish indeed.