Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Warp wrote:
> >>>     std::for_each(someList, [&total](int x) { total += x });
> > 
> >> And, really, what's the advantage of this over a normal for loop?
> > 
> >   Nothing. Since it's C++ code, it sucks.

> You know, if you're not mature enough to have a civil conversation, you 
> don't really need to participate.

  You really are a master of trolling, you know. I have to admire that.

  First you succeed in trolling me with your unusually heavy and biased
C++ bashing, and then you try to make it look like all you wanted to do
is have a simple civil conversation.

  You know perfectly that there's at least one person reading this
newsgroup who appreciates the C++ language and doesn't appreciate
excessive bashing, yet you deliberately write really inflammatory
comments and mocking about it. Every question you made about new C++
features were aimed solely at trying to find flaws in them. When your
questions were answered, you asked more questions, trying to find flaws.
You continued asking questions until you found some flaw you could point
out. (Eg. first you asked if lambda functions would use such a cumbersome
syntax as boost::lambda, and when you got shown that they won't, you asked
if you can assign lamdbda functions to variables, and when you got shown
that you can, you continued asking and asking until you found something
that you can consider a flaw so that you could mock the whole feature.
The whole purpose of this was clearly to find some flaw you could point
out.)

  You know perfectly that if you start such a heavy bashing, you are going
to piss off at least one C++ fan, yet you deliberately go on, perfectly
knowing what effect it will cause. I think that deep inside you enjoy
doing that.

  Then, when you succeed in your trolling, you act all innocent and civil
and complain that all you wanted to do is have a "civil conversation".
After making me all angry with your condescending attitude you can go
and safely call me "immature" and make yourself look so high and mighty.

  You really are good at trolling. Personally I could not get even near
that level of mastery.

> I asked an actual useful question, so I 
> could perhaps learn why people are working to put lambdas into the language 
> when they have restrictions that make them useless for what most other 
> people use lambdas for. If your only answer is "there's no advantage of 
> lambdas over coding a regular for loop", then yeah, C++ sucks.

  The std::for_each() function was only a simple example. There are many
other algorithms which cannot be implemented with a simple loop.

  Another example: You could give std::sort() a comparator as a lambda
function which has access to the variables in the local scope, something
which is very laborious to do currently.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   You are not discussing. You are bashing based on prejudice.

I think it's fair to say it isn't prejudice that the philosophy of C++ is 
that you don't pay for features where you don't use them. I'll admit the 
syntax seems much cleaner than I thought it would be, because I assumed 
they'd be doing something like Boost. However, C++ still doesn't have lambda 
expressions, and I'm rather at a loss why the people working on the 
standards called it that, since they aren't lambdas and they *didn't* 
include "lambda" as a keyword.

I gave examples of actual code that works in any language that has lambdas, 
and you tell me I'm not discussing C++ and that I'm prejudice. It sounds 
more like you're prejudice than me, really, defending C++ for some reason 
without actually offering any evidence I'm wrong. If I'm prejudiced and 
right, what does it matter that I'm prejudiced?

C++ sucks to the extent that you don't pay runtime overhead for features 
where you don't use them. This philosophy leads to a great number of warts 
on the language (such as delete vs delete[], & references vs && references, 
undefined behavior with non-virtual destructors in some cases, that static 
initializations aren't done in a reliable order, etc.). I can understand 
these warts, because they're focussed on performance and/or make the 
compiler writer's job easier (and hence make the language easier to 
implement and port).

The syntax also sucks, to a great extent due to the lame attempt to remain 
compatible with a different language they're already incompatible with. Had 
every C program actually been a valid C++ program with the same semantics, 
this might have made sense, but they failed to ensure this too.

I think the fact that I came to different conclusions than you do don't make 
it prejudice. I'm willing to learn, but if you can't tell me where I'm 
wrong, then telling me I'm bashing based on prejudice doesn't help.

-- 
   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:
> Darren New <dne### [at] sanrrcom> wrote:
>>>> 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.
> 
>> Sure. I've never hesitated to express my dislike of hacks, even when I 
>> recognise them as necessary hacks.
> 
>   I said that "at least you admit that you are biased". I didn't say that
> "at least you admit you dislike something". But of course you seem quite
> fluent at twisting things.

Sure. I'm biased against ugly half-ass hacks. I never disputed that. :-)

If the ugly half-ass hacks let you do something you couldn't otherwise do, 
that's a redeeming feature. That was why I brought up Python - their ugly 
half-ass hacks let you do things you can't easily do without them, hooking 
into the bowels of the scope/name resolution at runtime. It's hacky and I 
can't help but believe inefficient, but it lets you implement things you 
couldn't otherwise implement easily.

That's why I asked why a lambda in C++ is better than just coding the body 
in the for loop - I don't see that it gains you anything, and I was 
wondering what you'd code differently.

>   You are being an unusually bad jerk in this thread for some reason. Not
> your usual self. I'm curious what prompted your sudden holy war now.
> Bad day?

Heh. Sorry if I'm coming across strong. I'm having a good day actually. And 
I honestly appreciate you asking. And yea, ok, the "grow up already" 
statement was probably unnecessarily harsh. I was a little peeved that you'd 
take a perfectly reasonable question and attribute malice to it.

I think it might be that (1) this is the first time I've bashed C++ since I 
actually sat down and learned it in detail, so it has been a number of weeks 
or months, and (2) you're accusing me of being prejudiced without apparently 
accusing me of being wrong.  I don't have to know the details of how C++ 
implements lambdas to know they're not going to add GC to C++ in order to 
support them, yes?

I 100% honestly think you're taking things personally that aren't being 
personally directed at you. I haven't said you're foolish to use C++ or 
anything else directed at you.  I simply said C++ sucks in certain ways, and 
it seems counter-intuitive to me why people as smart as those standardizing 
C++ would add features like lambdas with no obvious benefit compared to the 
pitfalls you have to avoid when you use them.

-- 
   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:
> However, C++ still doesn't have lambda 
> expressions, and I'm rather at a loss why the people working on the 
> standards called it that, since they aren't lambdas and they *didn't* 
> include "lambda" as a keyword.

  This sounds like the same type of argument as "xyz is not an OS" vs.
"xyz is an OS", depending on your definition of "OS".

  One of the basic definition of "lambda function" in programming languages
is that they are "first-class objects". A first-class object is, usually,
defined as something you can express as a literal (or, in the case of
lambda functions, as a "nameless" function implementation), something
which you can create/instantiate "on the spot", and which you can store
in a variable.

  Some people might use the term "lambda function" as a synonym for
"nameless function".

  In the same way as something being or not being an operating system
depending on how pedantic you are about the definition, it can be fair
to say that something like the new C++ lambda functions can be said to
be or not be "true" lambda functions depending on how pedantic you want
to be about the definition.

  If you really want to be so pedantic about the definition, then by all
means. It's just rather irritating when you start mocking the language
because you don't agree with their terminology.

> It sounds 
> more like you're prejudice than me, really, defending C++ for some reason 
> without actually offering any evidence I'm wrong.

  It was not a question of being right or wrong. It was a question of your
glaringly condescending attitude, which was deliberately inflammatory.
You didn't show any respect whatsoever to people who might actually like
the language (nor to the people who are trying very hard to make it
better).

> If I'm prejudiced and 
> right, what does it matter that I'm prejudiced?

  You were not right. You started asking questions until you found
something which you could argue you are right about. You started with
prejudiced mocking without even knowing about how the feature will be
implemented. You had already decided that the feature sucks, without
even knowing anything about it.

> The syntax also sucks, to a great extent due to the lame attempt to remain 
> compatible with a different language they're already incompatible with. Had 
> every C program actually been a valid C++ program with the same semantics, 
> this might have made sense, but they failed to ensure this too.

  You could use the same argument to say that the syntax of Java and C# suck
as well.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> That's why I asked why a lambda in C++ is better than just coding the body 
> in the for loop - I don't see that it gains you anything, and I was 
> wondering what you'd code differently.

  As I already mentioned, the for_each() was just a simple example. There
are many other situations where a for-loop won't do. std::sort() is a good
example.

  You could, of course, create the same effect as with the lambda function
by other means, but it would be laborious and cumbersome (eg. creating a
struct of pointers to all the local variables you want visible
inside the comparator function, and implementing the comparator inside
that struct, and then instantiating the struct and giving it to std::sort),
and most probably the compiler wouldn't even be able to optimize it as well.

  The lambda functionality makes this a lot more convenient, and probably
also more efficient.

> I 100% honestly think you're taking things personally that aren't being 
> personally directed at you.

  You still know that I get trolled when someone writes such mocking words
about C++ as you have done.

> I haven't said you're foolish to use C++ or 
> anything else directed at you.  I simply said C++ sucks in certain ways, and 
> it seems counter-intuitive to me why people as smart as those standardizing 
> C++ would add features like lambdas with no obvious benefit compared to the 
> pitfalls you have to avoid when you use them.

  I really can't understand why you don't see the benefits.

  One could argue the same thing about almost any convenience feature.
For example, one could argue that templates are useless because you can
do everything that can be done with templates by other means. Of course
you can. You can write asm and get the same functionality and be done
with it. However, your asm will certainly not be as clear and maintainable,
and certainly enormously longer than high-quality template code can be.

  Templates in C++ are very useful for many reasons. For instance, they
help avoiding code repetition when the same thing has to be done with
several types. They also help the compiler create more efficient code.
Templates also help abstracting your code so that it will become more
easy to maintain in the future. There are tons of reasons why templates
are a useful convenience feature, even if, technically speaking, you could
achieve the same end results without them (after all, C has been doing that
for quite a long time).

  Templates are in fact so powerful that entire books have been written
about them.

  Personally I see C++ lambda functions (in conjunction with things like
auto variables) having the same kind of potential.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> Darren New <dne### [at] sanrrcom> wrote:
>>>> Warp wrote:
>>>>>     std::for_each(someList, [&total](int x) { total += x });
>>>> And, really, what's the advantage of this over a normal for loop?
>>>   Nothing. Since it's C++ code, it sucks.
> 
>> You know, if you're not mature enough to have a civil conversation, you 
>> don't really need to participate.
> 
>   You really are a master of trolling, you know. I have to admire that.
> 
>   First you succeed in trolling me with your unusually heavy and biased
> C++ bashing, and then you try to make it look like all you wanted to do
> is have a simple civil conversation.

Seriously, in this post, the question was, *really*, what's the advantage?

Really. That's all I meant. That's why I said "really".  I'm not trolling. 
I'm trying to get someone who *does* understand the feature to tell me the 
advantage.

I understand the advantage of lambda expressions. I don't understand the 
advantage of what C++ calls lambda expressions over just using regular 
inline code, since the lambda expression isn't really a self-contained value 
you can return from its scope.

> Every question you made about new C++
> features were aimed solely at trying to find flaws in them. When your
> questions were answered, you asked more questions, trying to find flaws.

I'd say "limitations" rather than flaws. I tend to understand what a feature 
is intended for, and find that limitations on the feature are where I get 
tripped up.

> You continued asking questions until you found some flaw you could point
> out. (Eg. first you asked if lambda functions would use such a cumbersome
> syntax as boost::lambda, and when you got shown that they won't, you asked
> if you can assign lamdbda functions to variables, and when you got shown
> that you can, you continued asking and asking until you found something
> that you can consider a flaw so that you could mock the whole feature.

Nope. I knew C++ can't support lambdas in the usual sense of the word (as a 
mechanism for constructing closures). I was trying to figure out at what 
point it breaks down. The pointer to the part of the wikipedia page 
explaining it's undefined behavior to refer to a variable in a scope that 
has exited removed my confusion.

>   You really are good at trolling. Personally I could not get even near
> that level of mastery.

While I appreciate the complement, I really wasn't trying to piss you off. 
Maybe due to the social circles I've hung out in over the last few years, I 
tend to do such things more often than I should, unintentionally. I'm sorry 
if I've gotten your blood pressure up, and I hope I haven't disturbed your 
weekend.

I'll try to phrase things differently in the future, but even when I 
specifically disclaim I'm saying anything about you, you sometimes take 
things personally, so I'm not sure how much more I can make the questions 
sound as I mean them to be taken.

>   Another example: You could give std::sort() a comparator as a lambda
> function which has access to the variables in the local scope, something
> which is very laborious to do currently.

Hmmm. OK, thanks. I can see where something like that could be convenient. 
Most places I've seen that need that sort of thing pass in a "client data" 
sort of opaque pointer to allow it, so I guess this new stuff could obviate 
the need to design that in at the application layer.

-- 
   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:
>   This sounds like the same type of argument as "xyz is not an OS" vs.
> "xyz is an OS", depending on your definition of "OS".

Kind of, perhaps.

>   One of the basic definition of "lambda function" in programming languages
> is that they are "first-class objects".

Yes. But that's not the only part of the definition. You can store a C++ 
lambda in a variable, but that's not all that needs to be done to make it a 
lambda.

>   Some people might use the term "lambda function" as a synonym for
> "nameless function".

That only works if you actually close over the free variables. Unlike a lot 
of terms, lambda actually has a precise mathematical definition that was 
around before computers, and there are already terms for what C++ is calling 
lambda that are correct for what it does (e.g., "downward funarg"). They 
really are calling it the wrong thing if they call it "lambda".

>   If you really want to be so pedantic about the definition, then by all
> means. It's just rather irritating when you start mocking the language
> because you don't agree with their terminology.

Well, it's well-established terminology that means something different. It's 
like if they added "unlimited precision integers" as long as they fit in a 
machine register, because, you know, you've got unlimited precision *after* 
the decimal point.

>   It was not a question of being right or wrong. It was a question of your
> glaringly condescending attitude, which was deliberately inflammatory.

Well, only a little. :-) Point taken. I'll try to tone it down in the 
future. My apologies.

>   You were not right. You started asking questions until you found
> something which you could argue you are right about. You started with
> prejudiced mocking without even knowing about how the feature will be
> implemented. You had already decided that the feature sucks, without
> even knowing anything about it.

As I said, I knew it wasn't going to start copying stack frames to the heap 
and then GCing it later.

>   You could use the same argument to say that the syntax of Java and C# suck
> as well.

The syntax of a lot of stuff in Java *does* suck. The syntax of C# gets 
increasingly baroque as they add more features. But C++ syntax is so bad you 
can't even tell whether a line of code is a type declaration or a variable 
declaration or a function invocation without reading all the include files. 
To the point where you start getting things like the "typename" keyword 
(iirc) just to tell the compiler whether you meant to give a type or a 
variable name at that point.

You can't tell me a language with undecidable syntax isn't at least a little 
sucky, yes?

-- 
   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:
>   You could, of course, create the same effect as with the lambda function
> by other means, but it would be laborious and cumbersome (eg. creating a
> struct of pointers to all the local variables you want visible
> inside the comparator function, and implementing the comparator inside
> that struct, and then instantiating the struct and giving it to std::sort),
> and most probably the compiler wouldn't even be able to optimize it as well.

That's actually how C# implements lambdas. Except that with GC available, 
you can then return the lambda and the local variables (in all the stack 
frames above that you've closed over) still exist until you GC the lambda 
expression.  Just so's ya know.

>   The lambda functionality makes this a lot more convenient, and probably
> also more efficient.

Certainly more convenient, yes.

>> I 100% honestly think you're taking things personally that aren't being 
>> personally directed at you.
> 
>   You still know that I get trolled when someone writes such mocking words
> about C++ as you have done.

I'll sincerely try to sound less mocking in the future.

>   I really can't understand why you don't see the benefits.

Now that you've given me some examples to think about, I do. I was thinking 
about the convenience of actual lambda functions that I've taken advantage 
of, none of which are supported by what C++ calls lambda functions. Now that 
you describe some examples where C++ lambdas are convenient, I can visualize 
places where I've worked around the lack of that sort of feature.

For example, in Tcl, when you initialize a DLL written in C, you get to 
return a void* from the initialization feature, and that void* gets carried 
around by the interpreter and passed back into whatever functions that DLL 
declared as Tcl-accessible. So that's the same sort of situation in which 
using a downward funargs in C++ would be helpful. And it's not a lambda 
either. :-)

I probably write different kinds of code than you do, but it doesn't really 
come up that often in stuff I write in an OO language. Maybe because the 
stuff that I'd normally be closing over I'm instead holding in member 
variables, so the "this" gets passed around anyway for context.

>   Personally I see C++ lambda functions (in conjunction with things like
> auto variables) having the same kind of potential.

I think C++ templates are far more powerful than C++ lambdas. Altho lambdas 
that actually do the closure stuff are pretty powerful too. (For example, 
you can define the integers using nothing but them. :-)

-- 
   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 wrote:
> I can pass you a void* and

That's a C feature. Real C++ programmers don't use void*. So no, of course
you have no RTTI on a void*.

> The traceback in your exceptions
> can tell you what the values passed as arguments to the function on each
> frame...

Yes they can.

> Hell, you can't even tell me how big an array is

No, but you'll see me using std::vector, not arrays, in C++.

> I know how it *won't* be implemented. It won't be implemented such that
> references to local variables survive the end of the stack frame those
> local variables are allocated in. That's enough.

They never do, and programmers better know that... They are "local
variables" for a reason. And in my mind it wouldn't be a stack if it kept
alive after 'popped' :D

int& foo() {
   int myNumber = 42;
   return myNumber;
}

Undefined behavior when the caller tries to do something with the reference.

Post a reply to this message

Darren New wrote:
> Warp wrote:
>>     std::for_each(someList, [&total](int x) { total += x });
> 
> And, really, what's the advantage of this over a normal for loop?

You tell me.

int total = 0;
std::vector<int> someList;

std::for_each(someList, [&total](int x) {
   total += x;
});

vs

int total = 0;
std::vector<int> someList;

for (std::vector<int>::const_iterator i = someList.begin(); i !=
someList.end(); ++i) {
    total += *i;
}

Post a reply to this message