Prev: Repeat a typedef or include a header with the typedef?
Next: needing std::iostream as an array of bytes
From: Juan Pedro Bolivar Puente on 25 Feb 2010 19:52
>
> But one of the new disadvantages: lambda pointers could only be used in
> templates and the type is 'unknown'. I have not found a reason for that
> behavior. Maybe this will be corrected in the next release :-) A generic
> functor could be used as workaround. But this not as cool as it could be .
>

I do not understand why requiring the usage of std::function to take
lambdas in non-generic functions makes lambdas "less cool"... The only
overhead that it has it that it might use the heap, but you would need
that too in any implementation of lambdas where there is a unified type
defined for them.

Note that every diferent lambda needs different amount of space to store
the closure. In C++ every type with value semantics should be able to be
stored on the stack, and for that you need to know the exact size that
you need to store values of that type. [1] That is why we allow the
compiler to define an unknown but determined (reminds me of quantum
physics :p) type, that you can still infer with auto for locally stored
lambdas, or pass as a template argument. If you want to treat them
generally in non-generic-code you have to use std::function, and the you
pay for the overhead of having the closure in the heap, as you would for
every other language supporting lambdas. Actually I personally find the
way lambdas are implemented in C++ very clever, because this still
allows the use of stack-based closures very efficiently thanks to
generic programming, while having all the power that it would have in
other more functional languages thanks to type erasure :D

JP

[1] To put this in a different way:

int v = 10;
auto l = [&v] (int a) { std::cout << v << a; }

Is the same as C++98:

struct my_lambda
{
int& v_;
my_lambda (int& v) : v_ (v) {}
void operator (int a) { std::cout << v_ << a; }
};
int v = 10;
my_lambda l (v);

As you can see, there is no way to define a general functor my_lambda
for all the different closures that you would have to store in different
contextes... unless you do at compiler level the kind of thing that
std::function correctly does at library level already :D


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Mathias Gaunard on 26 Feb 2010 05:30
On Feb 26, 9:35 am, Florian Weimer <f...(a)deneb.enyo.de> wrote:

> AFAIK, && only binds to rvalues, not lvalues anymore. Apparently,
> N2844 was adopted into the draft standard.

That seems fairly strange, since an lvalue is an rvalue.
Plus that means you can't do perfect forwarding of arguments without
using templates and their funny rules with regards to rvalue
references.

But heh, it seems rvalue references change every single month. Who
knows what we'll end up with.



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: SG on 27 Feb 2010 02:15
On 26 Feb., 23:30, Mathias Gaunard <loufo...(a)gmail.com> wrote:
> On Feb 26, 9:35 am, Florian Weimer <f...(a)deneb.enyo.de> wrote:
>
> > AFAIK, && only binds to rvalues, not lvalues anymore.
> > Apparently, N2844 was adopted into the draft standard.
>
> That seems fairly strange, since an lvalue is an rvalue.

By definition an expression is either an lvalue or an rvalue, not
both.

> Plus that means you can't do perfect forwarding of
> arguments without using templates and their funny rules
> with regards to rvalue references.
>
> But heh, it seems rvalue references change every single month.
> Who knows what we'll end up with.

Perfect forwarding is not affected by this change. If you use a
function parameter of type T&& where T will be deduced, lvalues will
still be bound to lvalue references (due to deduction rules and
reference collapsing) and rvalues will still be bound to rvalue
references.

The documents N2812 (pointing out a safety problem) and N2844
(proposing a fix for it) have been published about a year ago.

Since then I havn't seen any other proposals that intent to change the
rules regarding reference binding or the deduction rules. What I've
seen is one proposal to allow throwing move constructors (N2983) and
another one (N3044) that gives move constructors and move assignment
operators the "special" status so they can be implicitly generated,
defaulted and deleted. Although related to rvalue references, they're
pretty much orthogonal proposals.

Cheers,
SG

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Repeat a typedef or include a header with the typedef?
Next: needing std::iostream as an array of bytes