There are currently no frequently asked questions associated with this exercise – that’s where you come in! You can contribute to this section by offering your own questions, answers, or clarifications on this exercise. Ask or answer a question by clicking reply () below.
If you’ve had an “aha” moment about the concepts, formatting, syntax, or anything else with this exercise, consider sharing those insights! Teaching others and answering their questions is one of the best ways to learn and stay sharp.
Join the Discussion. Help a fellow learner on their journey.
Ask or answer a question about this exercise by clicking reply () below!
You can also find further discussion and get answers to your questions over in Language Help.
Agree with a comment or answer? Like () to up-vote the contribution!
I have changed all the names and run the program. It gives the results but then the running does not end. Under the run button a line keeps on circling and I can not go to the next chapter. Help?
@blog2221734404@web0701642805 Actually, the exercise doesn’t require the return type to be an int for the fancy_double function (the function with double parameters). You can try it for yourself. The name of the function of course must be changed to fancy_number but the return type is your choice. If you leave the return type as int OR if you decide to change the return type to double, both will be graded correct and the exercise will turn green.
As for which return type to choose, it depends on the the purpose of the function. If we want the result to always be an integer (regardless of whether the inputs are int or double), then we should leave the return type as int. If there is no such restriction, then we can change the return type to double. Both will be valid overloads.
the way i understood “function overloading” is to define a function making it do things it wasn’t designed for. similar to CPU overclocking.
but no the article still defined the sample functions three times because it does three different things! only the name of the function was changed (to be all the same). what’s the point?
Suppose you want a function for printing information in a nicely formatted manner to the terminal. We want to be able to print different types of data and the formatting will also vary depending on the data type. We may want a string to be printed in a specific manner. We may want a number to be printed with a certain precision. We may want to be able to handle collections of elements such as arrays.
One way to tackle this would be to give different names to each of the functions. We could define a function called printStr. Another one called printNum. Another one called printArr and so on. That would work, but we would have to either remember all the function names down to the capitalization/abbreviations or go hunting in the documentation trying to find the correct function name for our task.
We could instead use function overloading to define all these different versions but give them a single name: print. What happens in the different versions may be significantly different depending on the data type. But we will have only have to remember one function name. We could make the calls print("abc"), print(339.245), print({3, 55, 31}) etc. If we need to look up what is going on inside any specific overload, we will be able to browse the documentation more easily as well, because the overloads will be grouped together.
sticking to a naming convention is one of the most advised to any programmer. that shouldn’t be an issue.
naming a function should be based on what it does. that’s also most advised so that just looking at the name will tell you what the function is supposed to do. no need to look it up.
the confusion will start when a function is named “sort”, for example, and you really have to look up what it is sorting on. wouldn’t “sortFirstName” be a better function name?
how C++ uses and defines function overloading is, to me, irresponsible here.