C++: what's the usage of declaring a function inside another function? - c++

Question

Stanley Lippman's "C++ primer" mentioned, in page 234 that
Ordinarily, it is a bad idea to declare a function locally. However,
to explain how scope interacts with overloading, we will violate this
practice and use local function declarations.
...
void print(const string &);
void print(double); // overloads the print function
void fooBar(int ival)
{ ...
// bad practice: usually it's a bad idea to declare functions at local scope
void print(int); // new scope: hides previous instances of print
print(ival); // ok: print(int) is visible
print(3.14); // ok: calls print(int); print(double) is hidden
}
Nevertheless, which situation it might make sense to do so, declaring a function inside the body of a function?
I recall similar code in Scheme:
(define (PowerSet set)
(if (null? set) '(())
(let ((PowerSetAfterHead (PowerSet (cdr set) ) ))
(append PowerSetAfterHead
(PowerSet (cdr set) )
(map
(lambda (subset)
(cons (car set) subset
)
)
(PowerSet (cdr set) )
)
)
)
)
)
Is it normally used to hide from misuse of a "local function" that intends for the outer function's usage only? something like internal class? Or is it useful in some design patterns?

Answer 1

The problem arises when there is an ambiguity in calling a function. Thus to avoid the ambiguity in some scope you can redeclare the required function that hides all other functions with the same name of the outer scope.
Consider the following simple example. If you run the following program
#include <iostream>
void f( int ) { std::cout << "f( int )" << std::endl; }
void f( double ) { std::cout << "f( double )" << std::endl; }
int main()
{
f( 10l );
return 0;
}
you will get an error like
prog.cpp:10:9: error: call of overloaded 'f(long int)' is ambiguous f( 10l );
But if you will add a declaration of function f within main like this
#include <iostream>
void f( int ) { std::cout << "f( int )" << std::endl; }
void f( double ) { std::cout << "f( double )" << std::endl; }
int main()
{
void f( double );
f( 10l );
return 0;
}
the code will be compiled and the output will look like
f( double )

Answer 2

Your scheme example both declares and defines a local function.
The C++ example just declares a function locally.
These are different things.
You can create the rough equivalent of scheme local functions with lambdas in C++11.
The declaring of a function locally just says "there exist a function of this name and signature". What more, it does so in a narrower scope than the one outside the function, and as there are functions in said narrower scope only they are considered for overloading (not the ones in the wider scope).
No new function is created -- it must be defined elsewhere. (You cannot define a local function in C++, barring things like local class methods and lambdas)
You could use this to change how overload resolution works, but this is rarely a good idea. In the case that you have an overload ambiguity, you are better off manually converting the types and then calling the overload set, and have it resolve normally.
An alternative is to declare only the overload you want to invoke, then invoke it. This can result in surprising behavior, so do so only in a very narrow scope if you can, and document why you are doing it and what possible problems could occur (as few programmers will have the scope-hiding overload rules at the front of their brain when reading your code without at least a bit of prompting).
I do not think I have ever ran into a situation where I had to declare a function locally.
The handful of times I did it it was because I was hacking into some serious ball of mud code, and wanted to make an extremely local change for prototype/debugging purposes. I simply declared a function signature and called it somewhere. The function was a static local in another .cpp file in the same library elsewhere, I removed the static there and tested the result of calling it.
This saved creating a header file (or modifying one), exposing it formally, including said header where we where using it. Prior to committing to production I would go through steps like that (and probably clean up the interface of that static local function while I was at it).
So, I used it for a quick and dirty prototype hack. The last time I did this I ended up reverting it after I did the prototype hack, which was easier because I had only touched 2 files each at 1 spot.