Local Functions...

[deepakvsoni]

Why does C++ restrict definition of functions with in functions?
int f1() {
int f2() {
.....
}
} //This is not supported.

Thanks in advance to anybody who replies..

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-08-29 11:33, de*********@gmail.com wrote:

Why does C++ restrict definition of functions with in functions?
int f1() {
int f2() {
.....
}
} //This is not supported.

Thanks in advance to anybody who replies..

I have not studied the idea in detail but I can't come up with anything
that can be accomplished with nested functions that can't be done with
normal functions. In fact I find it a bit limiting since f2() can't be
called from a scope outside f1(), which means that you can't reuse f2()
in some other context.

--
Erik Wikström

[Matthias Pfeifer]

Erik Wikström wrote:

On 2007-08-29 11:33, de*********@gmail.com wrote:

>Why does C++ restrict definition of functions with in functions?
int f1() {
int f2() {
.....
}
} //This is not supported.

Thanks in advance to anybody who replies..

I have not studied the idea in detail but I can't come up with anything
that can be accomplished with nested functions that can't be done with
normal functions. In fact I find it a bit limiting since f2() can't be
called from a scope outside f1(), which means that you can't reuse f2()
in some other context.

you could feed f2 into some std::algorithm

int f1() {
void f2(double* ptr) {
.....
}
std::for_each(ptr, ptr+N, f2);
}

here the definition of f2 is local to the (probably) single place where
it is used.

matthias

[Abdo Haji-Ali]

<de*********@gmail.comwrote in message
news:11**********************@m37g2000prh.googlegr oups.com...

>
Why does C++ restrict definition of functions with in functions?

Because C++ has classes. Really, why would you need such function-level
encapsulation when you can do a more logical and defined class
encapsulation, I wonder?

--
Abdo Haji-Ali
Programmer
In|Framez

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-08-29 13:22, Matthias Pfeifer wrote:

Erik Wikström wrote:

>On 2007-08-29 11:33, de*********@gmail.com wrote:

>>Why does C++ restrict definition of functions with in functions?
int f1() {
int f2() {
.....
}
} //This is not supported.

Thanks in advance to anybody who replies..

I have not studied the idea in detail but I can't come up with anything
that can be accomplished with nested functions that can't be done with
normal functions. In fact I find it a bit limiting since f2() can't be
called from a scope outside f1(), which means that you can't reuse f2()
in some other context.

you could feed f2 into some std::algorithm

int f1() {
void f2(double* ptr) {
.....
}
std::for_each(ptr, ptr+N, f2);
}

here the definition of f2 is local to the (probably) single place where
it is used.

Yes, but applications change (so I might need f2() in some other place
later on) and I didn't really gain much by not having f2() in a wider
scope (such as a namespace or a class).

--
Erik Wikström

[Richard Herring]

In message <8N****************@newsb.telia.net>, Erik Wikström
<Er***********@telia.comwrites

>On 2007-08-29 11:33, de*********@gmail.com wrote:

>Why does C++ restrict definition of functions with in functions?
int f1() {
int f2() {
.....
}
} //This is not supported.
Thanks in advance to anybody who replies..

I have not studied the idea in detail but I can't come up with anything that
can be accomplished with nested functions that can't be done with
normal functions.

Nested functions would, in principle, have access to the local variables
of their containing function:

int f1() {
int i;
int f2() {
int j = i;
/* do stuff */
}
i = 1;
f2();
i = 2;
f2();
}
Making this work in practice, where the inner function might be invoked
recursively or indirectly, involves an extra level of indirection, which
means more work for the compiler and a potential performance hit at
runtime. Some languages (e.g. Pascal and some of the Algol family IIRC)
allow this; C and C++ follow their parent BCPL by simply banning such
things (actually BCPL allowed nested function definitions but outlawed
access to the parent function's local variables, so all the nested
declaration achieved was to reduce the scope of the inner function.)

>In fact I find it a bit limiting since f2() can't be called from a scope outside
f1(),

In the example above, what would f2() use for "i" ?

which means that you can't reuse f2() in some other context.

That's called "encapsulation" and is normally regarded as a Good Thing
;-)

--
Richard Herring

[Victor Bazarov]

Matthias Pfeifer wrote:

Erik Wikström wrote:

>On 2007-08-29 11:33, de*********@gmail.com wrote:

>>Why does C++ restrict definition of functions with in functions?
int f1() {
int f2() {
.....
}
} //This is not supported.

Thanks in advance to anybody who replies..

I have not studied the idea in detail but I can't come up with
anything that can be accomplished with nested functions that can't
be done with normal functions. In fact I find it a bit limiting
since f2() can't be called from a scope outside f1(), which means
that you can't reuse f2() in some other context.

you could feed f2 into some std::algorithm

int f1() {
void f2(double* ptr) {
.....
}
std::for_each(ptr, ptr+N, f2);
}

here the definition of f2 is local to the (probably) single place
where it is used.

What problem does making it local solve that cannot be solved by
just having the function normal, outside of 'f1' body?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[werasm]

Matthias Pfeifer wrote:

you could feed f2 into some std::algorithm

This little piece of code compiles, and does something similar,
not that its of any use... It compiles under all of the
compilers I've checked, but I don't know whether its
compliant. I Nested classes can't be template parameters,
but <exec()is a static function - a true nested function,
it would seem.

#include <algorithm>
#include <vector>

int main()
{
struct local
{
static void exec( int ){}
};

std::vector<intv( 10, 10 );
std::for_each( v.begin(), v.end(), &local::exec );

return 0;
}

Regards,

Werner.

[werasm]

de*********@gmail.com wrote:

Why does C++ restrict definition of functions with in functions?
int f1() {
int f2() {
.....
}
} //This is not supported.

See my other reply. It does seem possible with that "hack", if
compliant.

Werner

[werasm]

werasm wrote:

#include <algorithm>
#include <vector>

int main()
{
struct local
{
static void exec( int ){}
};

std::vector<intv( 10, 10 );
std::for_each( v.begin(), v.end(), &local::exec );

return 0;
}

Regards,

Werner.

Could anybody please comment on whether this is standard compliant.
I've
found the following:

Par 9.8.4:
A Local class shall not have static data members.

I suppose a static member function does not fall into this category???

Regards,

Werner

[Victor Bazarov]

werasm wrote:

werasm wrote:

>#include <algorithm>
#include <vector>

int main()
{
struct local
{
static void exec( int ){}
};

std::vector<intv( 10, 10 );
std::for_each( v.begin(), v.end(), &local::exec );

return 0;
}

Regards,

Werner.

Could anybody please comment on whether this is standard compliant.

It's not.

I've
found the following:

Par 9.8.4:
A Local class shall not have static data members.

I suppose a static member function does not fall into this category???

What category?

Also, see [temp.arg.type]/2. A local class has no linkage.

You've apparently run into extensions in all compilers you've used.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Joe Greer]

werasm <we****@gmail.comwrote in news:11*********************@19g2000hsx.googlegrou ps.com:

>
Could anybody please comment on whether this is standard compliant.
I've
found the following:

Par 9.8.4:
A Local class shall not have static data members.

I suppose a static member function does not fall into this category???

Local classes aren't supposed to have external linkage. I would guess that static
data/functions would cause there to be external linkage and therefore not allowed.

joe

[osmium]

<de*********@gmail.comwrote:

Why does C++ restrict definition of functions with in functions?
int f1() {
int f2() {
.....
}
} //This is not supported.

Your best place to find an answer is in comp.std.c++. They should be
willing to discuss the evolution of the standard, it is a moderated group so
anticipate a lot of delay before you get an answer.

My guess is that it makes the writing of compilers simpler and more
manageable. Remember that the C++ evolved from simple roots. I much prefer
the alternative form you suggest.

[Victor Bazarov]

Alf P. Steinbach wrote:

* Victor Bazarov:

>werasm wrote:

>>werasm wrote:

#include <algorithm>
#include <vector>

int main()
{
struct local
{
static void exec( int ){}
};

std::vector<intv( 10, 10 );
std::for_each( v.begin(), v.end(), &local::exec );

return 0;
}

Regards,

Werner.
Could anybody please comment on whether this is standard compliant.

It's not.

Chapter & verse, please.

You made me think a bit (tsk-tsk).

[basic.link]/2, last bullet item.
[temp.arg.type]/2.

Since the name of a member of the local type cannot be referred to
from other modules (or from other scopes in the same module), it has
no linkage. As such it cannot appear as a type template argument.
However, in this particular situation, if the type of the second
argument of 'for_each' template is deduced to be "a function pointer"
and not "a member of 'local' class", then it's probably OK. I don't
know which what it would fall, though.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Bo Persson]

osmium wrote:
:: <de*********@gmail.comwrote:
::
::: Why does C++ restrict definition of functions with in functions?
::: int f1() {
::: int f2() {
::: .....
::: }
::: } //This is not supported.
::
:: Your best place to find an answer is in comp.std.c++. They should
:: be willing to discuss the evolution of the standard, it is a
:: moderated group so anticipate a lot of delay before you get an
:: answer.
::
:: My guess is that it makes the writing of compilers simpler and more
:: manageable. Remember that the C++ evolved from simple roots. I
:: much prefer the alternative form you suggest.

The short answer is that it was not allowed in C, and nobody bothered
to add it to C++. In C++ you can put f1() and f2() in the same class,
possibly making f2 private, and they can then share the class' member
variables.

Bo Persson

[werasm]

Victor Bazarov wrote:

You made me think a bit (tsk-tsk).

[basic.link]/2, last bullet item.
[temp.arg.type]/2.

I've looked at these references, and I agree with the fact that the
static member function should have no linkage. I could not for
certain decide whether function pointers where treated differently (In
fact, I also think it should fail).

Pointers to local class members <int X::*fcertainly does not work
for
exactly the reason you've mentioned. Perhaps it works because the
argument is deduced by the function template (14.8.8), although,
attempting to do the same with pointers to member functions fails
with error:

"a template argument may not reference a local type"

I've performed compilations with later version of GCC, Comeau and
the compilers offered at www.dinkumware.com, all with the same
result. For comeau I've used --strict as option.

Thanks for response,

Regards,

Werner

[tragomaskhalos]

On 29 Aug, 10:33, "[e-mail]" <[e-mail]>
wrote:

Why does C++ restrict definition of functions with in functions?
int f1() {
int f2() {
.....
}

} //This is not supported.

Many of these "why doesn't C++ allow ...?" type questions
have been answered by Stroustrup in print, and this is no
exception. That said, I cannot track down the great man's
explanation for this case, but vaguely recall it has
something to do with accessibility of variables in the
enclosing scope (ie f1 here) requiring an extra context
pointer getting passed around, which would be an
unacceptable overhead; and this is precisely the reason
that others in this thread have already alluded to.

[Juha Nieminen]

Erik Wikström wrote:

I have not studied the idea in detail but I can't come up with anything
that can be accomplished with nested functions that can't be done with
normal functions. In fact I find it a bit limiting since f2() can't be
called from a scope outside f1(), which means that you can't reuse f2()
in some other context.

I can't come up with anything that can be accomplished with private
member functions and variables that can't be done with normal global
functions and variables. In fact I find it a bit limiting since such
a private member function or variable can't be called from a scope
outside the class, which means that you can't reuse the function or
variable in some other context.

(And for those who didn't get it: Yes, the above is sarcasm.)

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-08-31 11:14, Juha Nieminen wrote:

Erik Wikström wrote:

>I have not studied the idea in detail but I can't come up with anything
that can be accomplished with nested functions that can't be done with
normal functions. In fact I find it a bit limiting since f2() can't be
called from a scope outside f1(), which means that you can't reuse f2()
in some other context.

I can't come up with anything that can be accomplished with private
member functions and variables that can't be done with normal global
functions and variables. In fact I find it a bit limiting since such
a private member function or variable can't be called from a scope
outside the class, which means that you can't reuse the function or
variable in some other context.

Yes, I see your point. But data encapsulation is generally accepted as a
Good Thing (TM), and private member functions are a part of that. It is
my understanding that the C++ committee likes to add things that changes
the way people think, and I can't see nested functions doing that.

But who knows, in ten years someone will post some question to a usenet
group and someone will answer "... yes, but it is generally accepted
that nested functions are a Good Thing (TM)...".

--
Erik Wikström

[Jerry Coffin]

In article <FO****************@newsb.telia.net>, Er***********@telia.com
says...

[ ... ]

But who knows, in ten years someone will post some question to a usenet
group and someone will answer "... yes, but it is generally accepted
that nested functions are a Good Thing (TM)...".

I rather doubt it -- nested functions have been around a _long_ time
(e.g. in Pascal) but their lack in C and C++ doesn't seem to have caused
a major problem with usage or popularity. While they are a little bit of
a pain to implement, they're not really all that terrible -- especially
on some processors (such as the x86) that have instructions specifically
tailored to support them. OTOH, support for them is far from universal,
and generally carries some cost even where it's available.

In the end, like most things, it's a question of cost vs. benefit -- the
number of useful local functions is generally fairly small, so the
benefit is usually fairly minimal. The cost isn't terribly high, but
still probably greater than the benefit.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Juha Nieminen]

Jerry Coffin wrote:

I rather doubt it -- nested functions have been around a _long_ time
(e.g. in Pascal) but their lack in C and C++ doesn't seem to have caused
a major problem with usage or popularity. While they are a little bit of
a pain to implement, they're not really all that terrible -- especially
on some processors (such as the x86) that have instructions specifically
tailored to support them. OTOH, support for them is far from universal,
and generally carries some cost even where it's available.

Well, isn't the new C++ standard going to include lambda functions
which, afaik, are like nested function on steroids? So I don't think
it's a question of difficulty of implementation, but simply standardization.

[Jerry Coffin]

In article <46**********************@news.song.fi>,
no****@thanks.invalid says...

Jerry Coffin wrote:

I rather doubt it -- nested functions have been around a _long_ time
(e.g. in Pascal) but their lack in C and C++ doesn't seem to have caused
a major problem with usage or popularity. While they are a little bit of
a pain to implement, they're not really all that terrible -- especially
on some processors (such as the x86) that have instructions specifically
tailored to support them. OTOH, support for them is far from universal,
and generally carries some cost even where it's available.

Well, isn't the new C++ standard going to include lambda functions
which, afaik, are like nested function on steroids? So I don't think
it's a question of difficulty of implementation, but simply standardization.

I'm honestly not sure whether lambda's are included or not. I know
they've been proposed, but the papers I looked at (admittedly, not
within the last few months) didn't look entirely ready for acceptance
into a finished standard yet. Doing a quick search through N2315, the
only uses of "lambda" appear to be related to a random number generator
with an exponential distribution.

If memory serves, however, the proposals I've seen were for implementing
lambdas more or less like Boost does, creating temporary objects rather
than local functions, as such.

I don't have an exact list of the proposals that have been dropped, but
my understanding is that the last committee meeting was the deadline for
new features -- anything that wasn't sufficiently finished that it was
ready to be accepted has been dropped, at least for this round of
standardization. I don't know it for a fact, but my guess would be that
the lambda proposals probably fell into the group that have been dropped
(at least for now).

--
Later,
Jerry.

The universe is a figment of its own imagination.

[=?ISO-8859-15?Q?Erik_Wikstr=F6m?=]

On 2007-09-02 16:28, Jerry Coffin wrote:

In article <46**********************@news.song.fi>,
no****@thanks.invalid says...

>Jerry Coffin wrote:

I rather doubt it -- nested functions have been around a _long_ time
(e.g. in Pascal) but their lack in C and C++ doesn't seem to have caused
a major problem with usage or popularity. While they are a little bit of
a pain to implement, they're not really all that terrible -- especially
on some processors (such as the x86) that have instructions specifically
tailored to support them. OTOH, support for them is far from universal,
and generally carries some cost even where it's available.

Well, isn't the new C++ standard going to include lambda functions
which, afaik, are like nested function on steroids? So I don't think
it's a question of difficulty of implementation, but simply standardization.

I'm honestly not sure whether lambda's are included or not. I know
they've been proposed, but the papers I looked at (admittedly, not
within the last few months) didn't look entirely ready for acceptance
into a finished standard yet. Doing a quick search through N2315, the
only uses of "lambda" appear to be related to a random number generator
with an exponential distribution.

If memory serves, however, the proposals I've seen were for implementing
lambdas more or less like Boost does, creating temporary objects rather
than local functions, as such.

I don't have an exact list of the proposals that have been dropped, but
my understanding is that the last committee meeting was the deadline for
new features -- anything that wasn't sufficiently finished that it was
ready to be accepted has been dropped, at least for this round of
standardization. I don't know it for a fact, but my guess would be that
the lambda proposals probably fell into the group that have been dropped
(at least for now).

Looking at n2336 the Lambda expressions and closures proposal (n2329) is
listed under "Active topics in Evolution" which has the description
"These topics are in final review, with the intention to incorporate
each one in the next standard". The current proposal looks quite
complete to me, but I'm not on the committee, so I hope they will get it in.

I think it would be great to have lambda functions to use with the
standard algorithms such as for_each, find_if, etc.

--
Erik Wikström

[Jerry Coffin]

In article <p7****************@newsb.telia.net>, Er***********@telia.com
says...

[ ... ]

Looking at n2336 the Lambda expressions and closures proposal (n2329) is
listed under "Active topics in Evolution" which has the description
"These topics are in final review, with the intention to incorporate
each one in the next standard". The current proposal looks quite
complete to me, but I'm not on the committee, so I hope they will get it in.

We can hope -- and we should know quite soon. I'm pretty sure it's no
longer a question of whether it _will_ get in, but whether it _has
gotten_ in -- and I believe papers from the last meeting should be
available soon (if they aren't already -- I didn't look today).

I think it would be great to have lambda functions to use with the
standard algorithms such as for_each, find_if, etc.

I certainly like the idea as well, though I find their lack less
bothersome than many.

--
Later,
Jerry.

The universe is a figment of its own imagination.