 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Maciej Sobczak
Guest
|
|
| Back to top |
|
 |
tmk@netvision.net.il
Guest
|
 Posted: Sun Jan 09, 2005 6:59 am Post subject: Re: Lambda - let's write it down |
 |
|
Well, lambda expressions exist in many languages, like Python, but I
don't think that we should add them to C++.
First of all, we'd like to design a program first, and then write it
down. The method of introducing new functions/classes on the fly
presents a different paradigm - first write, and later do post-mortem
design. I agree that this is an acceptable pattern, and I see it in
many places, but I don't think that we should encourage this behaviour.
One of the problems with lambda expressions in C++ is that C++ is a
relatively strongly typed language. Expressions used in C++ have to
belong to/inherit from/have transformation to some type. If you invent
a new type, you would have nothing to do with it outside of its
environment. If you use inheritance, it's standard C++, and you can
define a class as an independent entity.
An additional difficulty is that a natural implementation will be
self-modifying code which doesn't give you good security (viruses,
testability problems).
| Quote: | From the other hand, you can easily do what you want if you define a
functor object with all needed additional parameters as its attributes. |
Instead of writing
....some type... a={lambda x,y: return (x*y-1)*c;};
you can define a class C that inherits from std::binary_function with
types of x, y and needed result and keeps c as its attribute. Then you
can write
C a = C(c);
Michael
Maciej Sobczak wrote:
| Quote: | Hi,
This post is meant to be a continuation of the old subthread that
currently is named "C++0x lambda expressions".
I have gathered together my own thoughts - what was previously flying
in
the air and sometimes lacked consistency.
It helped me to review my own points.
It is available here:
http://www.msobczak.com/prog/articles/lambdacpp.html
Any comments are welcome.
|
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Terje Slettebø
Guest
|
| Posted: Sun Jan 09, 2005 7:08 am Post subject: Re: Lambda - let's write it down |
|
|
"Maciej Sobczak" <no.spam (AT) no (DOT) spam.com> wrote
| Quote: |
This post is meant to be a continuation of the old subthread that
currently is named "C++0x lambda expressions".
I have gathered together my own thoughts - what was previously flying in
the air and sometimes lacked consistency.
It helped me to review my own points.
It is available here:
http://www.msobczak.com/prog/articles/lambdacpp.html
|
I've read the article, and have been following the thread this came from,
and I, too, tend to prefer a syntax like (from the above article):
std::sort(b, e, bool (int a, int b) { return a < b; });
or, if types are unknown:
std::sort(b, e, template
b; })
(However, as Maciej have pointed out, you might quite often have enough
context to not need type deduction here.)
rather than something like:
std::sort(b, e, _1 < _2); // Boost.Lambda version
std::sort(b, e, {a, b: a < b }) // Syntax deduced from one of Dave A's
postings
I'll later in this posting come to how the first versions may be transformed
by the compiler, but sufficient to say now is that they will both enable
inline calls to the lambda function.
My reasons for preferring the former forms are as follows (some of these
arguments are also used in the article):
- They are in a way a "natural" extension to current syntax. A lambda
function is essentially an unnamed function, and how better to represent
this in C++ than... a function (template) without a name? Even people not
knowing about the feature might be able to guess what it does, if they are
familiar with C++.
- It is explicit about the type of the parameters and the return value (if
any). Some might prefer it not to be so, preferring type inference, instead.
I also find type inference, such as how it's done in Haskell, to be rather
elegant, but C++ isn't Haskell, and I don't know if we should make it so.
The type inference in itself may be handy, but perhaps not the syntax
(however, I understand that's not a big issue).
Making type inference work for C++, in general (all functions, not just
unnamed ones), may be rather difficult, due to the separate compilation
model. What will the function signature be? And if we allow type inference
for lambda functions, only, we're making a special case, with lambda
functions having "powers" not available to ordinary functions.
Function templates is one way C++ supports type inference, and it's
perfectly applicable here. This also enables full control over parameter
types, as pointed out in the article.
- It supports meaningful names for the parameters (also like the last
example, but unlike the BLL one).
- The point in the article about the ease one may move between lamdba
version and normal function, for example if one find the lambda version
become too complex, or perhaps useful in other contexts.
- As it doesn't require additional type inference, it's essentially just a
text transformation, so it should be relatively easy to implement.
However, one of my main reasons for posting, is to point out that, when it
comes to the implementation of this, I think it would be better to perform a
transformation/rewrite like Dave A. has suggested, rather than a "naïve"
rewrite from the syntax, as used in the article. That is, one may rewrite:
std::sort(b, e, bool (int a, int b) { return a < b; });
as:
struct __compiler_generated
{
bool operator(int a, int b) const // Possibly static
{ return a < b; }
};
std::sort(b, e, __compiler_generated());
rather than:
bool __compiler_generated(int a, int b)
{ return a < b; }
std::sort(b, e, __compiler_generated);
The first version enables the call to the lambda function to be inlined,
while the second one, given that a pointer to function is passed to
std::sort, makes it much less likely that the call will be inlined. I
suggest you (Maciej) update the paper with the first rewrite rule, if you
agree.
Another thing, I feel that using "lambda" for everything unnamed (as is done
in the article) may be confusing. "lambda" comes from functional programming
(well, from lambda calculus, originally), where it's used to mean unnamed
_functions_. Thus, I think we should restrict the use of "lambda" to that,
and instead use unnamed classes and objects, when we talk about that, rather
than "lambda classes" or "lambda objects", or some such.
Regards,
Terje
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Dave Harris
Guest
|
| Posted: Sun Jan 09, 2005 11:19 pm Post subject: Re: Lambda - let's write it down |
|
|
[email]no.spam (AT) no (DOT) spam.com[/email] (Maciej Sobczak) wrote (abridged):
| Quote: | This post is meant to be a continuation of the old subthread that
currently is named "C++0x lambda expressions".
I have gathered together my own thoughts - what was previously flying
in the air and sometimes lacked consistency.
It helped me to review my own points.
It is available here:
http://www.msobczak.com/prog/articles/lambdacpp.html
Any comments are welcome.
|
So far I don't find it exciting because the lambdas are not closures. They
don't have access to variables from their enclosing scope. That to me is
more important than being able to define them at their point of use.
-- Dave Harris, Nottingham, UK
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Maciej Sobczak
Guest
|
| Posted: Sun Jan 09, 2005 11:22 pm Post subject: Re: Lambda - let's write it down |
|
|
Hi,
Terje Slettebø wrote:
| Quote: | http://www.msobczak.com/prog/articles/lambdacpp.html
However, one of my main reasons for posting, is to point out that, when it
comes to the implementation of this, I think it would be better to perform a
transformation/rewrite like Dave A. has suggested, rather than a "naïve"
rewrite from the syntax, as used in the article. That is, one may rewrite:
std::sort(b, e, bool (int a, int b) { return a < b; });
as:
struct __compiler_generated
{
bool operator(int a, int b) const // Possibly static
{ return a < b; }
};
std::sort(b, e, __compiler_generated());
rather than:
bool __compiler_generated(int a, int b)
{ return a < b; }
std::sort(b, e, __compiler_generated);
The first version enables the call to the lambda function to be inlined,
while the second one, given that a pointer to function is passed to
std::sort, makes it much less likely that the call will be inlined. I
suggest you (Maciej) update the paper with the first rewrite rule, if you
agree.
|
I acknowledge your point, but there are resons to keep it unchanged.
Not the whole world is functor-oriented and I would find it extremely
frustrating if the lambda could be used with std::sort, but not with
std::qsort. Or with std::find but not with std::bsearch. And so on.
The point is that there are tons of C libraries (or C++ libraries that
use pointer to functions instead of functors), just waiting to benefit
from lambda. Ruling them out would be a disaster.
On the other hand, some variants are of course possible, like:
std::sort(b, e, inline bool (int a, int b) { return a < b; });
^^^^^^
Smart enough compiler would discover that std::sort can accept functors
and rewrite the whole thing in this direction, potentially benefiting
from inlining. On the other hand, the following is still possible,
because the result of "function lambda" is normally a pointer to
function, not a function object:
atexit(void () { puts("Good bye!"); });
And of course, the "class lambda" always allows you to write true
functor explicitly if you are really sure you need it - the distinction
between "function lambda" and "class lambda" was made exactly to give
you this control.
So:
// 1.
std::sort(b, e, bool (int a, int b) { return a < b; });
// 2.
std::sort(b, e,
struct { bool operator()(int a, int b) const { return a < b; } }()
);
// 3.
std::sort(b, e, inline bool (int a, int b) { return a < b; });
In 1. you ask for pointer to function (not likely inlined, but
appropriate for C libraries), in 2. you ask for function object
(appropriate for inlining) and in 3. you ask for the "smart mode"
(rewrite to functor and if its ill-formed, silently fall back to pointer
to function).
I will update the article with this.
| Quote: | Another thing, I feel that using "lambda" for everything unnamed (as is done
in the article) may be confusing.
|
Yes, I realize it. The word "anonymous" would be much more appropriate
in the broader context.
Regards,
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
jakacki
Guest
|
| Posted: Mon Jan 10, 2005 10:10 am Post subject: Re: Lambda - let's write it down |
|
|
Michael wrote:
[...]
| Quote: | One of the problems with lambda expressions in C++ is
that C++ is a relatively strongly
typed language. Expressions used in C++ have to belong
to/inherit from/have transformation to some type. If you
invent a new type, you would have nothing to do with it
outside of its environment. If you use inheritance, it's
standard C++, and you can define a class as an independent
entity. An additional difficulty is that a natural
implementation will be self-modifying code which doesn't
give you good security (viruses, testability problems).
|
It seems that you mistook lambda expressions for on-the-fly
compilation.
| Quote: | From the other hand, you can easily do what you want
if you define a
functor object with all needed additional parameters as
its attributes.
Instead of writing
....some type... a={lambda x,y: return (x*y-1)*c;};
you can define a class C that inherits from
std::binary_function with
types of x, y and needed result and keeps c as its
attribute. Then you can write
C a = C(c);
|
Well, so why not let a compiler do it for us? OP's paper shows this kind
of transformations. Have you read it?
BR
Grzegorz
--
Free C++ frontend library: http://opencxx.sourceforge.net
China from the inside: http://www.staryhutong.com
Myself: http://www.dziupla.net/gj/cv
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Maciej Sobczak
Guest
|
| Posted: Mon Jan 10, 2005 8:27 pm Post subject: Re: Lambda - let's write it down |
|
|
Hi,
Dave Harris wrote:
| Quote: | So far I don't find it exciting because the lambdas are not closures. They
don't have access to variables from their enclosing scope. That to me is
more important than being able to define them at their point of use.
|
The opportunities that come with such access are great, but at the same
time it may be a place where Bad Things will achieve their peak density.
That's why I'm sceptical about this concept.
I think it may be instructive to ask for comments where there is an
already existing experience with it. What is the opinion of those who
actually used it in other languages?
Does it help, in total?
Is it easy to write/read/modify/maintain?
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
David J. Littleboy
Guest
|
| Posted: Tue Jan 11, 2005 10:42 am Post subject: Re: Lambda - let's write it down |
|
|
"Maciej Sobczak" <no.spam (AT) no (DOT) spam.com> wrote:
| Quote: | Dave Harris wrote:
So far I don't find it exciting because the lambdas are not closures.
They
don't have access to variables from their enclosing scope. That to me is
more important than being able to define them at their point of use.
|
Agreed.
| Quote: | The opportunities that come with such access are great, but at the same
time it may be a place where Bad Things will achieve their peak density.
That's why I'm sceptical about this concept.
I think it may be instructive to ask for comments where there is an
already existing experience with it. What is the opinion of those who
actually used it in other languages?
|
You should read Guy L. Steele's two papers on function closers in a
lexically scoped lisp from the 70s.
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-353.pdf
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-379.pdf
http://library.readscheme.org/page1.html
Closures are incredibly useful and powerful. Furthermore, they work
amazingly naturally in a lexically scoped language like C++.
| Quote: | Does it help, in total?
|
I'd think that in the context of the STL containers, lambda closures would
be seriouosly useful, since they allow you to write functions that refer to
the current state (in the closed free variables) while iterating over one or
more containers.
| Quote: | Is it easy to write/read/modify/maintain?
|
I'd prefer that lambda expressions be flagged by a keyword, e.g.
int lambda (int a, int b) { <statements> }
but with some creative indenting it works fine. (The lambda could help
creative text editors format nicely as you type.)
David J. Littleboy
Tokyo, Japan
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Thorsten Ottosen
Guest
|
| Posted: Tue Jan 11, 2005 10:45 am Post subject: Re: Lambda - let's write it down |
|
|
| Quote: | Hi,
Dave Harris wrote:
So far I don't find it exciting because the lambdas are not closures. They
don't have access to variables from their enclosing scope. That to me is
more important than being able to define them at their point of use.
The opportunities that come with such access are great, but at the same
time it may be a place where Bad Things will achieve their peak density.
That's why I'm sceptical about this concept.
|
The idea that stuff should be in the language if it could be misused hasn't
really
been one of C++'s major design goals, has it? :-)
| Quote: | I think it may be instructive to ask for comments where there is an
already existing experience with it. What is the opinion of those who
actually used it in other languages?
Does it help, in total?
Is it easy to write/read/modify/maintain?
|
It's really powerful; with it we have (anonymous) local function support.
br
-Thorsten
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Hyman Rosen
Guest
|
| Posted: Tue Jan 11, 2005 10:46 am Post subject: Re: Lambda - let's write it down |
|
|
Maciej Sobczak wrote:
| Quote: | I think it may be instructive to ask for comments where there is an
already existing experience with it. What is the opinion of those who
actually used it in other languages? Does it help, in total?
Is it easy to write/read/modify/maintain?
|
In Ada, it is common to use (named) local procedures and functions
as parameters of generic instantiations, as opposed to the function
object approach used by C++. The local routine just keeps its state
in the local variables of its containing scope. Everyone there likes
doing it that way.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Terje Slettebø
Guest
|
| Posted: Tue Jan 11, 2005 10:47 am Post subject: Re: Lambda - let's write it down |
|
|
"Maciej Sobczak" <no.spam (AT) no (DOT) spam.com> wrote
| Quote: | Hi,
Terje Slettebø wrote:
The first version enables the call to the lambda function to be inlined,
while the second one, given that a pointer to function is passed to
std::sort, makes it much less likely that the call will be inlined. I
suggest you (Maciej) update the paper with the first rewrite rule, if
you
agree.
I acknowledge your point, but there are resons to keep it unchanged.
Not the whole world is functor-oriented and I would find it extremely
frustrating if the lambda could be used with std::sort, but not with
std::qsort. Or with std::find but not with std::bsearch. And so on.
The point is that there are tons of C libraries (or C++ libraries that
use pointer to functions instead of functors), just waiting to benefit
from lambda.
|
Yes. After I had posted this, I also read your posting about possible code
bloat from multiple instantiations, so there are arguments either way.
However, a sort with an indirect call per comparison (rather than a simple
comparison) would hardly be very efficient (compared to what it could be).
OTOH, if most work is done by other things than the comparision/indirect
call, then it may be different..
| Quote: | And of course, the "class lambda" always allows you to write true
functor explicitly if you are really sure you need it - the distinction
between "function lambda" and "class lambda" was made exactly to give
you this control.
So:
// 1.
std::sort(b, e, bool (int a, int b) { return a < b; });
// 2.
std::sort(b, e,
struct { bool operator()(int a, int b) const { return a < b; } }()
);
// 3.
std::sort(b, e, inline bool (int a, int b) { return a < b; });
In 1. you ask for pointer to function (not likely inlined, but
appropriate for C libraries), in 2. you ask for function object
(appropriate for inlining) and in 3. you ask for the "smart mode"
(rewrite to functor and if its ill-formed, silently fall back to pointer
to function).
|
2 tends to be a little too wordy, even for my taste (i.e. I tend to find 1
(or 3) acceptable as it looks like C++), and I think it shouldn't be
necessary to use "inline" to enable "smart mode".
However, depending on how you specify the grammar, you may need something
like "inline" to disambiguate, anyway, or the compiler may need to do some
lookahead, to understand the meaning of the code. To illustrate:
f( int() { ... });
"int()" is a valid expression, today, so is this a function, f, being called
with a lambda function, or is it being called with int(), followed by some
(surprising?) braces?
Regarding the use of functions or objects, again. If you were to allow bound
variables from the surrounding context in your lambda function, then
function objects provide handy closures for them. And, no, I don't think you
should have to write this code, yourself (as 2 hints to).  Contrived
example:
void f(int n1, int n2)
{
std::sort(b, e, bool (int a, int b) { return a*n1 < b*n2; } )
}
Possible translation:
struct __compiler_generated
{
__compiler_generated(int n1, int n2) : n1(n1), n2(n2) {}
bool operator()(int a, int b) { return a*n1 < b*n2; }
int n1;
int n2;
};
void f(int n1, int n2)
{
std::sort(b, e, __compiler_generated(n1, n2));
}
Some another arguments for function objects, compared to functions:
- Function objects is the way things are typically done today, with things
like std::plus, bind1st, etc. Lambda would automate the creation of such
function objects.
- They are first-class citizens in C++, being values (something functions
are not, but function pointers are). You can't pass or return functions from
other functions, but you can do so with function objects. The same goes for
partial application (supplying some parameters, to yield a new function),
and functional composition.
Regards,
Terje
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Terje Slettebø
Guest
|
| Posted: Tue Jan 11, 2005 1:02 pm Post subject: Re: Lambda - let's write it down |
|
|
<tmk (AT) netvision (DOT) net.il> wrote
| Quote: | Well, lambda expressions exist in many languages, like Python, but I
don't think that we should add them to C++.
First of all, we'd like to design a program first, and then write it
down. The method of introducing new functions/classes on the fly
presents a different paradigm - first write, and later do post-mortem
design.
|
I think you're wrong about this. If I want to e.g. sort "person" classes on
the lastname, then with lambda I may do (using the syntax in the article):
std::sort(b, e, bool(const person &a, const person &b) { return a.lastname <
b.lastname; } )
How can you argue that just because the function is written inline, the
design is done after the code is written?
In any case, evolutionary design (before, during, or after the code is
written) is gaining momentum as a successful development technique (agile
development), rather than the "traditional" way of trying to predict the
whole design from the start, and often getting it wrong, making it either
too complex, or not flexible enough in the right places.
Anyway, that's really a different discussion, and unless you can present a
convincing argument for exactly how lambda functions would prevent up-front
design, I think we should drop it.
| Quote: | One of the problems with lambda expressions in C++ is that C++ is a
relatively strongly typed language. Expressions used in C++ have to
belong to/inherit from/have transformation to some type. If you invent
a new type, you would have nothing to do with it outside of its
environment.
|
I don't understand what you mean, here. Even with type inference, the type
will still be a normal type in the C++ type system; you just don't have to
specify it (just like function templates).
| Quote: | An additional difficulty is that a natural implementation will be
self-modifying code which doesn't give you good security (viruses,
testability problems).
|
I think you've misunderstood the kind of lambda being discussed here. They
are simply unnamed functions, meaning that you can have the point of
definition and the point of use close to each other, which tends to improve
cohesion and readability, IOW good software design. The code won't be
"self-modifying" at runtime, nor at compile-time.
| Quote: | From the other hand, you can easily do what you want if you define a
functor object with all needed additional parameters as its attributes.
Instead of writing
...some type... a={lambda x,y: return (x*y-1)*c;};
you can define a class C that inherits from std::binary_function with
types of x, y and needed result and keeps c as its attribute. Then you
can write
C a = C(c);
|
Sure, but that means you have to write a class for every operation you want
to do, and you have to put it in the global namespace, possibly far from its
use. Apart from the above mentioned advantages of lambda, it also helps to
reduce the "syntactic noise" of defining such functions.
Regards,
Terje
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Dave Harris
Guest
|
| Posted: Tue Jan 11, 2005 11:44 pm Post subject: Re: Lambda - let's write it down |
|
|
[email]no.spam (AT) no (DOT) spam.com[/email] (Maciej Sobczak) wrote (abridged):
| Quote: | // 1.
std::sort(b, e, bool (int a, int b) { return a < b; });
// 2.
std::sort(b, e,
struct { bool operator()(int a, int b) const { return a < b; } }()
);
// 3.
std::sort(b, e, inline bool (int a, int b) { return a < b; });
In 1. you ask for pointer to function (not likely inlined, but
appropriate for C libraries), in 2. you ask for function object
(appropriate for inlining) and in 3. you ask for the "smart mode"
(rewrite to functor and if its ill-formed, silently fall back to
pointer to function).
|
I agree it's good to be able to specify a function rather than a struct.
However, although the syntax for function falls naturally out of the
existing grammar, it still seems a bit unobvious to me. Also the use of
"inline" in (3) is not obvious either, and it's making the compiler be too
clever (so clever I'm not sure humans will always be able to follow it),
and perhaps the backtracking will lead to implementation problems.
I'd go back to the suggestion from the thread of using "inline" as the
function name. And use "struct" if you want a functor instead.
// (1) Function pointer.
std::sort(b, e, bool inline(int a, int b) { return a < b; });
// (2) Struct.
std::sort(b, e, struct { bool operator()(int a, int b) const {
return a < b; } }() );
// (3) Abbreviated struct.
std::sort(b, e, bool struct(int a, int b) { return a < b; });
Here (3) has the same effect as (2) but with fewer tokens. Although my (1)
is a token longer than yours, I think the extra clarity is worth it.
Incidently, I wasn't entirely happy with the trailing () in (2), but if
they can be omitted from (3) that would be fine. Then we would allow:
return new struct { bool operator()(int a, int b) const {
return a < b; } };
but not:
return new bool struct(int a, int b) const { return a < b; };
because the first has a type where the second has an object. This seems
natural to me, and it might satisfy some of James Kanze's concerns.
-- Dave Harris, Nottingham, UK
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Allan W
Guest
|
| Posted: Wed Jan 12, 2005 8:57 pm Post subject: Re: Lambda - let's write it down |
|
|
Maciej Sobczak wrote:
| Quote: | I think it may be instructive to ask for comments where there is an
already existing experience with it. What is the opinion of those who
actually used it in other languages?
Does it help, in total?
Is it easy to write/read/modify/maintain?
|
I have a little experience with nested functions in Pascal.
Not quite the same thing, but similar intent.
The equivalent in C++ would be:
.. void foo(iter b, iter e) {
.. bool lessint(int a, int b) { return a < b; }
.. std::sort(b, e, lessint);
.. }
To be honest, I don't have a lot of experience with nested functions.
I do know that overuse of this feature can be just as bad as overuse
of any other feature, i.e. in C++, overuse of overloaded operators
or macros. However, for simple cases I found nested functions allowed
me to express myself elegantly.
I know that nested functions aren't quite the same thing as lambdas,
but I think that some of the problems solved with lambdas are also
solved with nested functions. I'd like to see this concept explored
by someone that has more experience with it than I do.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Dave Harris
Guest
|
| Posted: Wed Jan 12, 2005 8:58 pm Post subject: Re: Lambda - let's write it down |
|
|
[email]no.spam (AT) no (DOT) spam.com[/email] (Maciej Sobczak) wrote (abridged):
| Quote: | I think it may be instructive to ask for comments where there is an
already existing experience with it. What is the opinion of those who
actually used it in other languages?
Does it help, in total?
Is it easy to write/read/modify/maintain?
|
Yes. Very much so. At least in latently typed languages, whether
dynamically type-checked like Smalltalk and Lisp, or statically
type-checked like Haskell.
In languages with mandatory manifest type declarations, eg Java, less so,
because the verbosity of the type declarations get in the way. However,
that's an issue with anonymous functions generally, not with closures. Of
course they can be abused, as can any feature.
I don't know of any language that has closures which doesn't also have
garbage collection, but I think that's because languages without GC are
rare. I suspect that practical experience of this combination will have to
be gained in C++ itself.
It might be useful, or at least interesting, to know the relative
importance of the 3 kinds of anonymous function:
(a) No access to enclosing scope.
(b) Read-only access to enclosing scope.
(c) Write access to enclosing scope.
Java actually forbids (c), which is occasionally annoying.
Do you have any reason to think closures will be harder to maintain than
equivalent code? At the moment, if you use an anonymous function you may
find a small change to the spec forces you to rewrite your routine to not
use one, precisely because they cannot access anything from the enclosing
scope.
For example:
void print_to_cout( iterator first, iterator last ) {
for_each( first, last, void struct( int x ) {
cout << x << "n";
} );
}
if we want the output stream to be an argument, this seems natural:
void print_to( iterator first, iterator last, ostream &os ) {
for_each( first, last, void struct( int x ) {
os << x << "n"; // Not allowed?
) };
}
and if it is not supported, then we have to either use binders, or
hand-craft a struct with an ostream reference and a constructor to
initialise it. Frankly I'd just as soon use a for-loop. But the above, I
think, is quite readable.
-- Dave Harris, Nottingham, UK
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
