defining function inside funtion.

[sandeeppoudel]

c++ gnu compiler doesn't allow defining functions inside functions. actually what is the process behind the compiling process due to which this type of defining function inside function inside function is restricted?
can you put the reasons in brief?
don't mention about lamdas ar any other tricks here. it will be your waste of time. i will read other articles relatin this. but i didn't found the actual reason of above so could you help me please?

[JLBorges]

A block scope may contain a class scope; a class scope may contain definitions of (member or friend) functions.
However, direct support for lexical closure is limited (to variables with static storage duration).

#include <iostream>

int f( int n )
{
    if( n < 2 ) return 0 ;

    else
    {
        static int sn ;
        sn = n ;

        struct s
        {
            static int g() { return sn*3 + 1 ; }
            static int h() { return sn/2 ; }
        };

        constexpr auto& g = s::g ;
        constexpr auto& h = s::h ;

        return 1 + f( n%2 ? g() : h() ) ;
    }
}

int main()
{
    std::cout << f(27) << '\n' ; // 111
}

http://coliru.stacked-crooked.com/a/dac2f4880f003a87

[Peter87]

I don't know the reason. It seems a bit inconsistent that nested local classes are allowed but nested functions are not.

GCC allows nested functions as an extension for C, but not for C++.
https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

There has been a proposal for nested functions but it was never accepted.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0295.pdf

Now that we have got lambdas I think the chances for having nested functions added to C++ are very slim.

[Duthomhas]

There is nothing inconsistent about it: nested functions creates headaches that are strictly unnecessary when implementing stack frames. I can only conclude that Ritchie didn't think that the compiler needed the extra complexity for a scoping trick of limited use.

Also, be careful not to confound nested functions and class methods — they are two different things.

[Cubbi]

C's grandfather, BCPL, had nested functions, but they didn't see local variables/parameters from the enclosing functions (so no stack frame headaches). They were dropped in B, and kept out of the language in C - I assume for simplicity, as dmr put it in https://www.bell-labs.com/usr/dmr/www/chist.html "B and C avoid this restriction by imposing a more severe one: no nested procedures at all"

and yes, in C++98 we had the workaround of local callable classes (manual like here http://www.gotw.ca/gotw/058.htm or as a macro here http://okmij.org/ftp/packages/vzeroin.cc ) , which evolved into C++11's lambdas.

PS: found a note in the lambda proposal pointing out a problem with nested functions: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1958.pdf
"Local functions which have access to the local variables are quite similar to the lambda functions and are supported by the GNU C compiler. It implements taking the address of a nested function using a technique called trampolines. The downside of this approach is that it requires executable stack. The upside is that there is implementation experience of a technique similar to what we are proposing."

PS/2: another evolution of the lambda proposal actually called a lambda that takes all its captures by reference "std::nested_function": http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2529.pdf

[jonnin]

Dare I say that macros could do this, though that is a horrid thing to do.

[Peter87]

Duthomhas wrote:

There is nothing inconsistent about it: nested functions creates headaches that are strictly unnecessary when implementing stack frames. I can only conclude that Ritchie didn't think that the compiler needed the extra complexity for a scoping trick of limited use.

Well, they could easily have allowed nested functions that were not allowed to access local variables in the surrounding function scope, which would be more consistent with how nested local classes work.

Edit: When I said nested classes what I really meant was local classes (i.e. classes that are defined inside functions).

[barnack]

To be honest i don't understand this limitation either. C implements nested functions without any problem, and sometimes they are indeed useful. If i need a subroutine which is useless for the entire program, even useless for the class using the function that requires that subroutine, then why should i make the subroutine exist in global or even class's scope? There's no reason if i can make that subroutine only exist inside the only scope where it's required.

[Repeater]

C implements nested functions without any problem

It's non-standard. Your compiler might allow it as a non-standard extension, but it's not C.

[JLBorges]

> they could easily have allowed nested functions that were not allowed to access
> local variables in the surrounding function scope

Yes.
The only real problem is the funarg problem; handling nested scoping and nested call stacks is otherwise trivial.

They could easily allow nested functions to access local variables with automatic storage duration in the surrounding function scope, as long as names/references/pointers to such nested functions would not be allowed to escape out of (be made available outside) the surrounding scope. cf. lambda capture by reference, where the responsibility to ensure non-leakage of the closure to other scopes is the responsibility of the programmer.

[Peter87]

I think I'm starting to understand why nested functions were never added to C++. Just making them regular functions without access to local variables of the surrounding scope would have been easy but not very useful. They probably wanted something that was more general and powerful, but still easy to use correctly, so they ended up with lambdas.

I said earlier that I thought it was inconsistent that we can have local classes but not nested functions (this doesn't necessarily mean I think it should be added) but these rules was inherited from C so it seems to be a question that is more appropriately aimed towards the C standards committee. If C didn't already have local structures the C++ committee might never have added local classes or they might have chosen to make them work differently.

Now that we've got lambdas there is probably not enough reason to motivate why nested functions should be added to the language. OK, making them regular functions without access to local variables in the surrounding scope would probably only require a minimal change to the standard and not too much work for the compiler implementers, but anything more advanced than that is not worth it. We don't need yet another complicated feature with a new set of rules for something that can easily be solved using existing features.