Re: What value and type should my functions return?
* Victor Bazarov:
Jeff Schwab wrote:
dwightarmyofchampions@hotmail.com wrote:
Hello. I am currently learning the C++ language, and I'm having
trouble with functions. Generally speaking, should my functions be
returning bool, void, or int?
There's no "generally speaking" here. The appropriate return type
varies wildly from one function to the next.
And how is my main function supposed to
handle errors in my function definitions?
By catching exceptions.
#include <cstdlib>
#include <iostream>
#include <stdexcept>
double divide(double dividend, double divisor) {
if (divisor == 0.0) {
throw std::range_error( "attempted division by zero" );
}
return dividend / divisor;
}
int main() try {
std::cout << "3.0 / 5.0 == " << divide(3.0, 5.0) << '\n';
std::cout << "3.0 / 0.0 == " << divide(3.0, 0.0) << '\n';
return EXIT_SUCCESS;
} catch (std::exception const& x) {
std::cerr << "error: " << x.what() << '\n';
return EXIT_FAILURE;
}
As an example, suppose I have a function foo() return true if the
function had no errors and false if an error was encountered
That's common in C, but it's usually the wrong thing to do in C++.
OOH you say "no generally speaking", OTOH you say "usually"...
Jeff's "no generelly speaking" was about routine result types. The "usually was
about error reporting. I agree with both those.
In
fact there is no single correct recommendation, like "by catching
exceptions". Depends on the QoI of the compiler. C++ exception
handling *can* be expensive. It *can* be much cheaper (quicker)
to return 'false' in case of an incomplete operation while
returning the result in a variable passed by reference, instead of
setting up the 'try-catch' mechanism in the caller. If your
function is called many millions of times, consider the performance.
Of course, there is no "generally" correct course of action. It
has to be measured.
For professional development in a more or less rational work environment,
correctness and clarity is far more important than micro-efficiency.
For a novice learning C++, which the OP describes him/her self as, it is the
only practical criterion.
Focusing on micro-efficiency here yields complexity (which lowers programmer
efficiency and learner's efficiency, wasting time on non-essentials) and
probably, ironically, also increases higher level more serious inefficiency
(e.g. algorithmic inefficiency) due to lack of focus on higher level issues and
the greatly increased cost of addressing such issues, but that is darn difficult
to measure since it's in the hypothetical realm of what if this program was
implemented very differently. It's understandable to focus only on things that
are easy to measure. But it's not good software engineering practice; software
engineering is about all those other things, which is why the main advice about
micro-optimization (known as the laws of optimization) is (1) don't do it, (2)
don't do it yet, and (3) measure, measure, measure, and hey, don't do it yet.
Cheers,
- Alf
--
Due to hosting requirements I need visits to [http://alfps.izfree.com/].
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!