Why not the idea of ​​nested functions implemented in the old C ++ standard?

Question

There was an idea of ​​nested functions that were considered useless during the development of the older C ++ standard, because its use is mainly covered by another concept, such as object-oriented programming; or was it implemented not just as a simplification?

Answer 1

Nested functions — to be useful — you need a stack frame of the containing function as a 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(); // ... } } } 

What values ​​should Dip () access have?

Not? you simply duplicated the functionality of (anonymous) namespaces, more or less.
Only for i, because it's the only one defined before the function?
Just for me and x, because they are in scope like Dip() ? Should the compiler make sure that the constructor x already running, or is this your job?
What about z?

If Dip accesses both the local tripulate values ​​and the stack frame, so the internal prototype will be

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

You basically replicated the functionality of structures / classes and member functions, but on two incompatible and non-exchangeable paths. This is a big challenge for dubious gain.

I wanted local functions several times, simply because it would better indicate the area in which it is needed. But with all the questions ... There are more useful things to put more complexity into C ++.

Answer 2

The idea was raised (several times) during standardization. Steve Klamage wrote a post in comp.std.C ++ in 1996, answering the question of adding them to C ++. He summarized his points as:

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

The proposal to add nested functions in C ++ should show an important class of programming problems solved by nested functions that are inconvenient to solve otherwise. (Perhaps there are such problems, and I just did not see them.)

A later (1998) post by Andrew Koenig indirectly states that the committee did discuss this, but nothing came of 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 is also possible to support them through the "trampoline" code, but this method adds some compiler complexity (even if they are never used).

On the sidelines: all three are members of the C ++ standard committee (or, at least, were at that time). If memory serves, then Steve was either the organizer of the ISO committee or the chairman of the US committee.

Answer 3

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

Answer 4

You can use a nested class that has the method you need. In C ++, the idea is to group methods together with data to get classes and not have free functions around.