 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> So it's not really a closure, but a downward funarg. That's exactly the
> sort
> of thing I was talking about. You can't return a lambda, I take it?
>
> What's the type of
> [&](int x) { total += x; }
>
> What kind of variable can I assign that to?
"Lambda functions are function objects of a implementation-dependent type;
this type's name is only available to the compiler. If the user wishes to
take a lambda function as a parameter, the type must be a template type, or
it must create a std::function to capture the lambda value. The use of the
auto keyword can locally store the lambda function"
The 'auto' keyword is what Warp mentioned. I guess you can also use
std::function to safely return a lambda.
"However, if the lambda function captures all of its closure variables by
reference, or if it has no closure variables, then its type shall be
publicly derived from std::reference_closure<R(P)>, where R(P) is the
function signature with return type. This is expected to be a more
efficient representation for lambda functions than capturing them in a
std::function."
All this is from Wikipedia article "C++0x". Next time please do some minimal
research before claiming C++ sucks :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] san rrcom> wrote:
>> What's the type of
>> [&](int x) { total += x; }
>
>> What kind of variable can I assign that to?
>
> You don't have to know the type (and in fact, the type is unspecified).
> You create a variable like this:
>
> auto myLambdaFunc = [&](int x) { total += x; };
And when you return that from the function as the function's value, what
happens with the free variables? How do you declare the function that ends
execution with "return myLambdaFunc"? How do you make it a part of a structure?
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> All this is from Wikipedia article "C++0x". Next time please do some minimal
> research before claiming C++ sucks :)
Oh, I see the answer to my question.
"""
Closure variables for local variables can also be defined without the
reference symbol &, which indicates that the lambda function will copy the
value. This forces the user to declare their intent to reference local
variables or copy them. If a closure object containing references to local
variables is invoked after the innermost block scope of its creation, the
behaviour is undefined.
"""
So, basically, you don't really have lambda expressions. You have something
that looks like a lambda expression but is really a pointer to a chunk of
code. An actual lambda expression closes over variables, not over values.
And it's a value itself, not a chunk of code that isn't possible to evaluate
outside the context in which it was created.
You can't do something like
std::vector<std::function> xyz() {
struct { int a; } alpha;
std::vector<std::function> stuff;
for (int i = 0; i < 10; i++) {
stuff.pushback([](int x) { return alpha.a += x + i; };
}
return stuff;
}
void main() {
std::vector<std::function> thing1 = xyz();
std::vector<std::function> thing2 = xyz();
...
}
Basically, if you actually use a closure (rather than a downward funarg),
you wind up with undefined behavior. I'm sorry to say, that means C++'s
lambdas suck, and technically aren't even lambda expressions.
(Note this works fine in languages like C#, for example, because you
actually can have pointers that get cleaned up when you're done, so you can
generate code that allocates struct alpha on the stack and keeps it until
you throw away all the lambda expressions.)
> All this is from Wikipedia article "C++0x". Next time please do some minimal
> research before claiming C++ sucks :)
Oh, C++ sucks for a lot more reasons than just next decade's changes. ;-)
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> It's not like the new features would *replace* existing features. They
> are pure additions. So I really don't see your point.
> Lambdas will be at core language level in the exact same way as eg.
> generics in Java are at cure language level. I don't see your problem.
They interact poorly with the rest of the language, putting arbitrary
limitations on them, and thus not actually solving the problems lambdas are
usually used to solve. Thereby generally forcing yet another round of syntax
and kludge piled on top of the existing language, in the next release when
people try to fix *that*.
> And lambdas in the new C++ are syntactic sugar. The compiler will generate
> exactly the same machine code as if you had written a non-lambda function.
Yeah. Which means they aren't lambdas. They're just called lambdas.
>> Sure. And it has new syntax for new stuff, and it's cleanly integrated with
>> the rest of the language.
>
> You say it like the new C++ features aren't. Care to explain?
I thought the lambdas C++ was adding were actually lambdas. Since it's
impossible to actually implement lambda expressions in C++, I thought it
would be difficult to implement lambdas cleanly. I was right, but what C++
calls lambdas are actually implemented cleanly and integrated well. They
just aren't lambdas. They're anonymous functions.
>> I'm not. I'm criticizing the way C++ adds new features, not that it does.
>
> Right. When other languages add new features (let's say, for example,
> Java adding support for generics), that's ok. But when C++ adds new features,
> that's something to be critiqued.
Criticized, not critiqued.
The difference is that C++ seems to want to have both low-level stuff (like
manual memory management, say, and a lack of run-time type information) and
high-level stuff (like functional programming and sophisticated separate
compilation), and those sorts of things just don't go together well. You
can't have closures in a language without runtime type information.
>> Every new feature in C++ seems to be hurt by (1) not wanting to pay any
>> price if you don't use it,
>
> Care to explain how, for example, lambda functions would add some overhead
> to the C++ language even when you don't use them?
I would, *if* C++ actually was implementing lambda expressions. They're not.
They're implementing inline anonymous functions that don't close over the
free variables.
And yes, exactly, the *reason* that C++'s lambda expressions suck is
*because* the designers of C++ don't want to add any overhead to support it.
>> (2) not wanting to add any syntax for it,
>
> Have you even looked at how lambda functions will be written in the new
> C++ standard? How is it not adding new syntax for it?
A complete lack of any sort of keyword, like, oh, "lambda" maybe?
OK, so I thought they were standardizing the way Boost did it. They aren't.
It's better than that. But still wrong. :-)
>> and (3)
>> interacting poorly and confusingly with every other feature of the language.
>
> Care to elaborate?
A lambda that closes over local variables is undefined if you return it from
the function it was declared in? And (I'd guess) undefined if you use it
outside the block it was declared in if that block declares local variables
that are free inside the lambda expression?
A lambda that closes over a local variable "by value" closes over a
different local variable than another lambda that closes over the same local
variable?
>> If C++ added lambdas and they actually had things like pointers to stack
>> frames and so on, I'd probably not be bothered. But I strongly suspect the
>> lambdas they add are going to have so much brokenness to deal with the lack
>> of automatic memory management and such that it's going to be harder to use
>> lambdas than to just declare your own functions. And I'm betting the syntax
>> will be so baroque it's going to be almost impossible to read without doing
>> parsing in your head, too. Looking the little I did at the Boost lambda's,
>> they're utterly awful compared to any other language with real lambdas built in.
>
> Good thing you are not prejudiced nor biased in the least.
"Prejudiced" would imply that I'm not making judgements based on experience,
but rather based on lack of knowledge. Since I've been using languages that
support lambdas correctly for, oh, decades, as well as languages that can't
and don't try, I think I've called this one properly.
I'm biased against ugly languages that are a pile of hacks to fix flaws in
other hacks.
>>> I don't know if I'm just being paranoid, but I honestly think that you
>>> are doing this for the simple reason that you know that you are going to
>>> troll me.
>
>> No. I just don't like C++.
>
> And for that reason you have to constantly write prejudiced BS about it.
It's neither prejudiced nor BS. What makes you think it's prejudiced?
>> I think the way things get added to C++ is a bad
>> thing for a language.
>
> What way? Care to explain?
Sure. Adding a lambda expression whose evaluation is undefined depending on
where you invoke it and what variables it uses is "bad". The "way" in which
it gets added is "this works in a few limited cases to solve a handful of
specific problems, and if we can't support it well, we'll just do undefined
behavior instead of telling you it's broken."
> And which way would you think would be better?
Either accept that your language isn't suitable for that sort of
programming, or do it right.
>> Python added a lot of really ugly stuff under the covers, too. But it's
>> under the covers, and doesn't get in your way if you don't use it, and it's
>> usable for more than just the one idea the person thought of who suggested
>> it.
>
> First you critique C++ because the ideology is that new features don't
> have any effect if you don't use it.
No. I criticize C++ because the ideology is that new features aren't allowed
to add any overhead if you don't use them, and hence the new features are
broken by design to meet that other goal.
> Now you are praising Python for the exact same thing,
No. I'm simply saying that Python, while under the covers is ugly in some
ways, nevertheless is done *right* in the sense that instead of saying "this
is ugly, and hence broken," they say "this is ugly, but it works right."
> IMO you are just prejudiced and don't know what you are talking about.
When C++ stops adding features that have undefined behavior when you use
those same features the way the rest of the world does, I'll believe that
C++ is adding elegant features. As it is, I'll just have to laugh at people
who say that C++ is adding lambda expressions in the next release, just like
I laugh when people say things like "C++ has automatic memory management as
long as you write all the management code into your application and take
care not to hit the corner cases that blow up your memory model."
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> std::for_each(someList, [&total](int x) { total += x });
And, really, what's the advantage of this over a normal for loop?
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Programming languages should be designed not by piling feature on top of
feature, but by removing the weaknesses and restrictions that make additional
features appear necessary."
-- William D. Clinger in:
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-3.html#%_chap_Temp_3
http://lists.r6rs.org/pipermail/r6rs-discuss/2007-July/003080.html
C++ has always evolved by the exact opposite, by going from a simple C with
Objects preprocessor to a Java/C# wannabe now and everything in-between
(Haskell, Python etc).
There's only one other language that also evolves by continual absorption. That
being Perl, which still hasn't got anywhere near complete in the 6th revision,
started about 1 decade ago. It's hard to keep up with all that barroque
counterpoint.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> C++ has always evolved by the exact opposite, by going from a simple C with
> Objects preprocessor to a Java/C# wannabe now and everything in-between
> (Haskell, Python etc).
Which might not be so bad, except for the insistence that they add no actual
runtime support for any of it. So every feature is implemented half-assed,
with the other butt-cheek left to the programmer to fill in, lest you wind
up with a program that sits crooked. And heaven forbid any actual useful
application-level libraries be standardized. :-)
> There's only one other language that also evolves by continual absorption. That
> being Perl, which still hasn't got anywhere near complete in the 6th revision,
> started about 1 decade ago. It's hard to keep up with all that barroque
> counterpoint.
Yeah, I don't like Perl either. ;-)
On the other hand, I've decided that Python 3.x has finally surpassed Tcl in
terms of the capabilities that I use on a normal daily basis. It finally
supports unicode cleanly, multithreading, event programming, multiple
embedded interpreters, wrapped scripts, and so on. It actually does a lot
more than Tcl, and did, but it was missing some of my must-have features
which is now has in 3.x.
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> On the other hand, I've decided that Python 3.x has finally surpassed Tcl in
> terms of the capabilities that I use on a normal daily basis. It finally
> supports unicode cleanly, multithreading, event programming, multiple
> embedded interpreters, wrapped scripts, and so on. It actually does a lot
> more than Tcl, and did, but it was missing some of my must-have features
> which is now has in 3.x.
It also features much cleaner syntax and semantics. uplevel?! frankly... :P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Basically, if you actually use a closure (rather than a downward funarg),
> you wind up with undefined behavior. I'm sorry to say, that means C++'s
> lambdas suck, and technically aren't even lambda expressions.
You have embarked in a holy quest to prove that C++ will not have "true"
lambda functions, and for that reason it sucks. In fact, it seems that you
have started a holy war against C++ right now. Whatever it takes to prove
that it sucks.
Now that you have "proven" that C++ will not have "true" lambda functions,
you must be exhilarated.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > It's not like the new features would *replace* existing features. They
> > are pure additions. So I really don't see your point.
> > Lambdas will be at core language level in the exact same way as eg.
> > generics in Java are at cure language level. I don't see your problem.
> They interact poorly with the rest of the language, putting arbitrary
> limitations on them, and thus not actually solving the problems lambdas are
> usually used to solve. Thereby generally forcing yet another round of syntax
> and kludge piled on top of the existing language, in the next release when
> people try to fix *that*.
Says the person who didn't even know how lambda functions will be
implemented in the next C++.
Good thing you are not prejudiced in the least.
> > And lambdas in the new C++ are syntactic sugar. The compiler will generate
> > exactly the same machine code as if you had written a non-lambda function.
> Yeah. Which means they aren't lambdas. They're just called lambdas.
I like it how you succeed in making *everything* sound negative when
applied to C++, while at the same time the *exact same thing* is positive
in other languages.
For example, generics in Java being "just syntactic sugar" is a positive
thing, while lambdas in C++ being "just syntactic sugar" is a negative thing.
Good thing you are not biased in the least.
> You can't have closures in a language without runtime type information.
Oh, now C++ doesn't even have RTTI. Right.
Like "lambdas", what is called "RTTI" in C++ is not *really* RTTI, right?
I start seeing your general rule of thumb: Every programming language
feature, when implemented in C++, either isn't *really* that true feature,
or is magically converted into a negative aspect of the language (while
it's a positive feature in all other languages).
> >> (2) not wanting to add any syntax for it,
> >
> > Have you even looked at how lambda functions will be written in the new
> > C++ standard? How is it not adding new syntax for it?
> A complete lack of any sort of keyword, like, oh, "lambda" maybe?
Wow. The lack of a keyword is now a negative feature. Right.
I'm sure that if there was a keyword, that would also be a negative
feature. *Everything* is negative when implemented in C++.
> > Good thing you are not prejudiced nor biased in the least.
> "Prejudiced" would imply that I'm not making judgements based on experience,
> but rather based on lack of knowledge.
Are you seriously telling me that you did extensive research on the
new lambda function feature as specified by the current C++0x standard
draft before making your remarks? Because it certainly didn't sound like
that to me. It sounded more like you were making tons of assumptions and
bashing the feature based solely on that.
> I'm biased against ugly languages that are a pile of hacks to fix flaws in
> other hacks.
At least you dare to admit it.
> >> No. I just don't like C++.
> >
> > And for that reason you have to constantly write prejudiced BS about it.
> It's neither prejudiced nor BS. What makes you think it's prejudiced?
Because you write about a new language feature without even knowing how
it will be implemented.
> I'll just have to laugh at people
> who say that C++ is adding lambda expressions in the next release, just like
> I laugh when people say things like "C++ has automatic memory management as
> long as you write all the management code into your application and take
> care not to hit the corner cases that blow up your memory model."
I hope you have a good time laughing.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
