Nested functions in c++?

[block111]

Hello,
code like this:

int f1(int x){
int f2(int y){
return y*y;
}

if(x > 0)
return f2(x);
else
return -1;
}


is invalid. functions cannot have nested functions in c++. I read
comparison d vs other programming languages
http://www.digitalmars.com/d/comparison.html
it says that d has nested functions and other s don't. But I always
used a construct that gives effect of nested function, and I'd like to
ask if such code is valid according to the standard.

int f1(int x){
struct {
int operator()(int y){ return y*y; }
} f2;

if(x > 0)
return f2(x);
else
return -1;
}

Thanks

 

[Victor Bazarov]

code like this:

int f1(int x){
int f2(int y){
return y*y;
}

if(x > 0)
return f2(x);
else
return -1;
}


is invalid. functions cannot have nested functions in c++.
[...potential flame bait removed...] I always
used a construct that gives effect of nested function, and I'd like to
ask if such code is valid according to the standard.

int f1(int x){
struct {
int operator()(int y){ return y*y; }
} f2;

if(x > 0)
return f2(x);
else
return -1;
}

The code is valid.

Nested functions sometimes have other properties (qualities) that local
classes don't, like access to all automatic variables declared in the
scopes surrounding the one that contains the function. You cannot easily
achieve that with local classes. Of course, the usefulness of being able
to access "automatic" variables depends on whether you actually need it.
And apparently, all C++ programmers learned to live without it.

V

 

[Alf P. Steinbach]

* (e-mail address removed):

... I always
used a construct that gives effect of nested function, and I'd like to
ask if such code is valid according to the standard.

int f1(int x){
struct {
int operator()(int y){ return y*y; }
} f2;

if(x > 0)
return f2(x);
else
return -1;
}

Yes, although for efficiency I wouldn't code it like that.

It's not quite the same as a nested function in a language like e.g. Pascal.

Most important, the local class' members don't have access to the outer
function's arguments.

Second, the local class has internal linkage, and so cannot be used as a
template argument, and that also goes for the class members.

Third (although that has nothing to do with nested functions), AFAIK there's no
way to provide out-of-class definitions of members of a local class.

 

[Walter]

Hello,
code like this:

int f1(int x){
int f2(int y){
return y*y;
}

if(x > 0)
return f2(x);
else
return -1;
}


is invalid. functions cannot have nested functions in c++. I read
comparison d vs other programming languages
http://www.digitalmars.com/d/comparison.html
it says that d has nested functions and other s don't. But I always
used a construct that gives effect of nested function, and I'd like to
ask if such code is valid according to the standard.

int f1(int x){
struct {
int operator()(int y){ return y*y; }
} f2;

if(x > 0)
return f2(x);
else
return -1;
}

Yes, it is valid. But it lacks the point of a true nested function - being
able to access the local variables of the enclosing function:

int f1(int x){
int f2(int y){
return x*y; // note we're accessing parameter 'x' here
}

if(x > 0)
return f2(x);
else
return -1;
}

C++ programs often emulate this behavior using either macros or by passing
references to local variables as extra parameters to f2(). But having a true
nested function capability makes the code cleaner and more straightforward
to write.

 

[Yuriy Solodkyy]

They have some support for accessing local variables of outer functions
in Boost called Adaptive Closures. This of course is not the same as
with nested functions, but allows you to get access to some variables of
the outer stack frame (especially useful when you can't change the
signature).

Here is the link to read more:
http://www.boost.org/libs/spirit/phoenix/doc/adaptable_closures.html

Yuriy

 

[Walter]

They have some support for accessing local variables of outer functions
in Boost called Adaptive Closures. This of course is not the same as
with nested functions, but allows you to get access to some variables of
the outer stack frame (especially useful when you can't change the
signature).

Here is the link to read more:
http://www.boost.org/libs/spirit/phoenix/doc/adaptable_closures.html

Thanks for the link. What that does is move the declarations of locals into
a local class, and then presumably a pointer to that class is passed into
the 'nested' function. While I've used this technique, it's only a half
solution (doesn't do parameters) and is complex and obtuse to use.

 

[pavlov.pavel]

Thanks for answers, and links.
When I posted my message I didn't think about accessing local
variables, so this is't really nested function. I good article about
that I found: http://www.gotw.ca/gotw/058.htm

I only have a question to Alf:

Yes, although for efficiency I wouldn't code it like that.

How then would you code this place? with #define's? For such simple
case compiler optimization will result in the equivalent code like the
following:
int f1(int x){
if(x > 0)
return x*x;
else
return -1;
}

 

[Alf P. Steinbach]

* (e-mail address removed):

Thanks for answers, and links.
When I posted my message I didn't think about accessing local
variables, so this is't really nested function. I good article about
that I found: http://www.gotw.ca/gotw/058.htm

I only have a question to Alf:


How then would you code this place? with #define's? For such simple
case compiler optimization will result in the equivalent code like the
following:
int f1(int x){
if(x > 0)
return x*x;
else
return -1;
}

As a rule, don't rely on compiler optimizations when you can express what
you want in code. For example, use const& arguments for strings etc. instead
of relying on compiler optimization. In such cases, and in this case,
optimization considerations can indicate more _natural_ ways to write the
code, ways that more directly reflect the intended effect:

int f( int x )
{
struct local
{
static int square( int x ) { return x*x; }
};

return (x > 0? local::square( x ) : -1);
}

Here there is no unused implicit argument to function 'square'.

However, it's probably Bad Advice to tell people to think about optimization,
because in most cases those who think optimization end up with code that's not
just unnatural, extremely complicated and inefficient, but also plain wrong...