why wasn't the idea of nested functions, implemented in older c++ standard?

Question

was the idea of nested functions considered to be useless during the time of developing older c++ standard, because its usage is basically covered by another concept like object-oriented programming; or it wasn't implemented just as a matter of simplification?

Answer 1

You don't really need them - you can simply use static functions to accomplish the same thing. Even when programming in languages that do support nested functions, like Pascal, I avoid them because (to me at least) they make the code more complex and less readable.

Answer 2

You can either use a nested class having the method you need. In C++ the idea is to group methods together with data to get classes and not having loose functions around.

Answer 3

Nested functions - to be useful - need the stack frame of the containing function as context. Look at this:

class Foo()
{
   void Tripulate()
   {
       int i=0; 

       void Dip()
       {
           // ...
       }

       int x = 12;
       for(i=1; i<=3; ++i)
       {
          int z= 33;
          Dip();
          // ...
       }
   }
}

Which values should Dip() get access to?

None? you have just duplicated the functionality of (anonymous) namespaces, more or less.
Only to i, because it's the only one defined before the function?
Only to i and x, because they are in the sam scope as Dip()? Does the compiler have to make sure the constructor of x did already run, or is that your job?
What about z?

If Dip gets any access to both the local values of tripulate and the stack frame, so the internal prototype would be

   void Dip(Foo * this, __auto_struct_Dip * stackContext)
   {
       // ...
   }

You have basically replicated the functionality of structs / classes and member functions, but on two incompatible and non-exchangable paths. That's a lot of complexity for a questionable gain.

I've wished for local functions a few times, simply because this would better indicate the scope where this is needed. But with all the questions... there are more useful things to throw more complexity onto C++.

Answer 4

The idea was raised (a number of times) during standardization. Steve Clamage wrote a post in comp.std.c++ in 1996 responding to a question about adding them to C++. He summarized his points as:

In the end, it seems to me that nested functions do not solve any programming problem for which C++ does not already have a solution at least as good.

A proposal to add nested functions to C++ should show an important class of programming problems solved by nested functions which are inconvenient to solve otherwise. (Perhaps there are such problems, and I simply haven't seen them.)

A later (1998) post by Andrew Koenig indirectly states that the committee did discuss it, but nothing seems to have materialized from it.

The obvious way to support nested functions requires hardware support, and still adds a bit of overhead. As pointed out in a post by Fergus Henderson, it's also possible to support them via "trampoline" code, but this method adds some compiler complexity (even if they're never used).

As an aside: all three are members of the C++ standard committee (or at least were at the time). If memory serves, at that time Steve was either convener of the ISO committee or chairperson of the US committee.