|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> 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.
That's also one of the great assets of the language. Consider this:
template<typename F>
void foo()
{
F(5);
}
Is that F(5) a function call or is it instantiating a variable of type F?
It's impossible to tell without knowing what F might be.
However, it doesn't matter! As long as F behaves like a function, that's
just fine. This is used quite a lot in template coding, eg. with functors
and comparators. This gives flexibility and versatility.
It's not like C++ was the only language which behaves like this.
> 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.
Most languages have special keywords to denote what you want to do.
For example, some languages might have a keyword like "function" to denote
that you are starting a function definition, as opposed to starting a
function call. I don't really see the big difference.
> You can't tell me a language with undecidable syntax isn't at least a little
> sucky, yes?
When that syntax brings flexibility, I don't consider is such a huge
problem.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> int& foo() {
> int myNumber = 42;
> return myNumber;
> }
> Undefined behavior when the caller tries to do something with the reference.
I think there's a reason why you can't have references to primitive
types in Java.
(Sometimes this can be a bit limiting, eg. because you can't pass
primitive types by reference to functions, for them to modify the
original values rather than copies.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|