News for hackers. Stuff that matters.

A comment on Under the hood of C++ lambdas and std::function.

Re:Under the hood of C++ lambdas and std::function by doomrobo on Sunday March 27, 2016 @08:27PM (#11372093)
If anyone is curious, as of C++14 you can `move` variables into a lambda scope (like Rust's move ||) as follows

    Foo foo; // Foo implements a move constructor
    auto l = [cap = std::move(foo)](){ do_stuff(cap);} // Make the lambda
    do_stuff(foo); // ILLEGAL. Cannot use moved value
    l(); // Run the lambda
[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by svalorzen on Monday March 28, 2016 @06:41AM (#11373529)
Note that `do_stuff` may not necessarily be illegal, since a moved value is required to be valid but in an unknown state. So maybe the result of `do_stuff` will be unspecified and unknowable (unless it requires some specific assumptions about the data), but any operations on `foo` should not give rise to obvious errors.
[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by Kristine1975 on Monday March 28, 2016 @06:43AM (#11373535)
>// ILLEGAL. Cannot use moved value

Actually that depends on the implementation of "Foo". After all "foo" has not been destroyed yet.

Edit: An instance of std::unique_ptr for example points to nullptr after having been moved to another instance (C++14 Standard ยง20.8.1p4.2).

[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by rjeli on Monday March 28, 2016 @01:08AM (#11372834)
At this time, what can Rust accomplish with the borrow checker that C++ can't accomplish with move semantics?
[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by Too on Monday March 28, 2016 @03:53AM (#11373182)
In c++ if you pass something as reference there is nothing preventing the receiving function from keeping a pointer to that reference even after returning.

Right now the only way to enforce this is by convention: 1. move/unique/shared_ptr=receiver allowed to keep pointer, 2. raw ptr=totally banned, 3. reference=caller must outlive callee and called function is not allowed to keep pointer after returning. The last scenario here is not enforcable by the compiler.

[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by bjz_ on Monday March 28, 2016 @01:17AM (#11372852)
Rust's moves are implicit, making it easier to write code that doesn't copy heap allocated memory, and you can't get 'use after moves' like in C++ - the type system will pick that up.
[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by rjeli on Monday March 28, 2016 @01:42AM (#11372903)
Oh, having only read about and not used recent C++ practices, I assumed use-after-move would be caught at compile time. Looking around a bit, it seems there's not even a warning for this; is there a reason? It seems like it would be very useful.
[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by catnaroek on Monday March 28, 2016 @04:03AM (#11373205)
In C++, "moving" and "copying" are a matter of class design. While you are expected to use move (resp. copy) constructors and assignments to, well, move (resp. copy); the language doesn't rule out using them for other purposes.

In Rust, assignment and argument passing always move, "moving" always does the right thing (make a shallow copy and invalidate the original object), and you can't override this behavior. Furthermore, Rust splits what C++ calls "copying" into two concepts: shallow copying (which is the same as moving, except the original object isn't invalidated, and the type checker guarantees you can only do it when it makes sense) and deep cloning (which may be expensive and needs to be explicitly requested by the programmer).

This is why Rust can track which objects are no longer usable.

[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by Animats on Monday March 28, 2016 @02:54AM (#11373071)
Move is a template level concept, not a language concept. The compiler has no idea that something was moved, rather than assigned. Some implementations null out the "moved from" reference, so that a use after move will dereference null and crash the program.

I've referred to the attempts to fix C++ ownership semantics with templates as "wallpapering over the mold".

[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by girvo on Monday March 28, 2016 @02:54AM (#11373072)
> is there a reason

Yeah, basically that it's quite difficult to implement especially with C++'s baggage and undefined behaviour, from what I remember

[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by loqi on Wednesday March 30, 2016 @05:51AM (#11388132)
Rust disallows mutation of multiply-referenced data, which prevents things like iterator invalidation and data races.
[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by sebastic on Monday March 28, 2016 @06:13AM (#11373468)
Compiler will not warn this:

    MovableObject a, b, c;
    b = std::move(a);
    c = std::move(a);
`c` may contain garbage.

BTW the "move trait" (as its called in rust) is a related but orthogonal concept to its borrow checker.

[ Parent | on HN ]
Re:Under the hood of C++ lambdas and std::function by catnaroek on Tuesday March 29, 2016 @01:32AM (#11379660)
In Rust, moving isn't a trait. It's the default, non-overridable behavior of assignment and argument passing. And everything is movable.
[ Parent | on HN ]