Hi,
I realised that this is possibly the single most pointless question ever asked, but can’t I just ask it anyway?
Why do you use “return” at the end of a function that’s declared as void?
Surely declaring a function as void will would force the compiler to create a return call for you?
Am I missing something?
Barry
“return” is simply optional in a void function. Many use it as, IMHO, it is old programming habit that every function must return something. In prior programming days, there used to be functions and subroutines.
Functions were really subroutines that returned some sort of value, subroutines simply did some processing that was going to be repeated at other times in the main line of execution. Subroutines never returned anything, but modified something (internal variables or screen, etc.).
In C (and thus C++), gone were the concept of subroutines - everything became a function. Functions always return something. C allowed for subroutines by specifying the return type of “void.” It has been a while since I’ve done C, so I can’t recall directly if return was required, but I do believe it was - every function had to “return” back to the main execution.
Now, however, “return” is optional for a function that returns “void.”
Hopefully I have the history correct - has been a while.
return in a void function (or any other function) would stop the execution and return. If it is at the very end of a void function it would have no effect.
In any function (including void functions) you can use the return statement to avoid nested ifs or for loops etc, depending on the function login.
Suppose you have this function that works with pointers so you have to check them against null before using them, e.g.
void myFunction(MyClassA *a) {
if (a) {
MyClassB *b = a->getB();
if (b) {
b->usefulFunction();
}
}
}
These nested ifs can be rewritten with return statements like so:
void myFunction(MyClassA *a) {
if (!a) return;
MyClassB *b = a->getB();
if (!b) return;
b->usefulFunction();
}NOTE: having ‘return’ anywhere but at the end is generally bad form. Best to test for cases that continue, leaving ‘return’ only at the end of the code block.
That is a text-book note. The practice as always may differ. There are API that require having multiples of nested IFs to be used correctly, e.g. Microsoft COM. And they specifically have best practices that recommend using return statements instead of having e.g. five ifs nested. It is contributing to readability and maintainability of the code at the end.
Hence why I said “generally” - sometimes it can’t be avoided, though care should be taken to attempt to avoid if at all possible - one entry, one exit is best practice.
“one entry, one exit” is an old assembly language (and maybe fortran too) best-practice when you could enter a subroutine form more than one instructions, or leave it likewise. 
Just wanted to check that it’s not some new explicit requirement of c++11! I haven’t come across a compiler [even on Sun] that doesn’t automatically create a return at the end of a function, but I believe in the Kernighan and Ritchie days it was actually a requirement [first c compilers didn’t save the IP on a stack when generating assembler] ️
Not a massive fan of using return as a control mechanism! It reminds me way to much of got to to let me do it without wincing 
I’ve never come across an API that actually requires the use of return at multiple points in a function. Setting a flag and using return in a single place is a lot safer ️ the only legitimate use of return as a control mechanism I can think of off the top of my head is using it for recursion.