Perfect forwarding of a callable
I came up with the following code to transform a R()-like into a void()-like callable:
#include <utility>
template<class Callable>
auto discardable(Callable&& callable)
{ return [&]() { (void) std::forward<Callable>(callable)(); }; }
// ^-- is it ok?
int main()
{
auto f = discardable([n=42]() mutable { return n--; });
f();
}
I'm worried about the capture by reference.
- Is it well-defined?
- Am I guaranteed that
callableis never copied and never used after its lifetime has ended?
This is taggued C++14, but applies to all following standards.
c++ lambda c++14 perfect-forwarding
add a comment |
I came up with the following code to transform a R()-like into a void()-like callable:
#include <utility>
template<class Callable>
auto discardable(Callable&& callable)
{ return [&]() { (void) std::forward<Callable>(callable)(); }; }
// ^-- is it ok?
int main()
{
auto f = discardable([n=42]() mutable { return n--; });
f();
}
I'm worried about the capture by reference.
- Is it well-defined?
- Am I guaranteed that
callableis never copied and never used after its lifetime has ended?
This is taggued C++14, but applies to all following standards.
c++ lambda c++14 perfect-forwarding
3
Sincecallablecan be an xvalue there is a chance that it gets destroyed before the lambda capture, hence leaving you with a dangling reference in the capture.
– Maxim Egorushkin
2 hours ago
add a comment |
I came up with the following code to transform a R()-like into a void()-like callable:
#include <utility>
template<class Callable>
auto discardable(Callable&& callable)
{ return [&]() { (void) std::forward<Callable>(callable)(); }; }
// ^-- is it ok?
int main()
{
auto f = discardable([n=42]() mutable { return n--; });
f();
}
I'm worried about the capture by reference.
- Is it well-defined?
- Am I guaranteed that
callableis never copied and never used after its lifetime has ended?
This is taggued C++14, but applies to all following standards.
c++ lambda c++14 perfect-forwarding
I came up with the following code to transform a R()-like into a void()-like callable:
#include <utility>
template<class Callable>
auto discardable(Callable&& callable)
{ return [&]() { (void) std::forward<Callable>(callable)(); }; }
// ^-- is it ok?
int main()
{
auto f = discardable([n=42]() mutable { return n--; });
f();
}
I'm worried about the capture by reference.
- Is it well-defined?
- Am I guaranteed that
callableis never copied and never used after its lifetime has ended?
This is taggued C++14, but applies to all following standards.
c++ lambda c++14 perfect-forwarding
c++ lambda c++14 perfect-forwarding
edited 2 hours ago
YSC
asked 2 hours ago
YSCYSC
21.9k350103
21.9k350103
3
Sincecallablecan be an xvalue there is a chance that it gets destroyed before the lambda capture, hence leaving you with a dangling reference in the capture.
– Maxim Egorushkin
2 hours ago
add a comment |
3
Sincecallablecan be an xvalue there is a chance that it gets destroyed before the lambda capture, hence leaving you with a dangling reference in the capture.
– Maxim Egorushkin
2 hours ago
3
3
Since
callable can be an xvalue there is a chance that it gets destroyed before the lambda capture, hence leaving you with a dangling reference in the capture.– Maxim Egorushkin
2 hours ago
Since
callable can be an xvalue there is a chance that it gets destroyed before the lambda capture, hence leaving you with a dangling reference in the capture.– Maxim Egorushkin
2 hours ago
add a comment |
3 Answers
3
active
oldest
votes
Lambdas are anonymous structs with an operator(), the capture list is a fancy way of specifying the type of its members. Capturing by reference really is just what it sounds like: you have reference members. It isn't hard to see the reference dangles.
This is a case where you specifically don't want to perfectly forward: you have different semantics depending on whether the argument is a lvalue or rvalue reference.
template<class Callable>
auto discardable(Callable& callable)
{
return [&] { (void) callable(); };
}
template<class Callable>
auto discardable(Callable&& callable)
{
return [callable = std::forward<Callable>(callable)] { // move, don't copy
(void) std::move(callable)(); // If you want rvalue semantics
};
}
1
Are you sureforwardandmoveshould not be reversed?
– Maxim Egorushkin
17 mins ago
add a comment |
Your program is UB as you use dangling reference of the captured lambda.
So to perfect forward capture in lambda, you may use
return [f = std::conditional_t<
std::is_lvalue_reference<Callable>::value,
std::reference_wrapper<std::remove_reference_t<Callable>>,
Callable>{std::forward<Callable>(callable)}]
{
std::forward<Callable>(f)();
};
It move-constructs the temporary lambda.
1
Is forwarding captured variable really necessary?
– bartop
2 hours ago
6
Ahhh what a beautiful language
– Lightness Races in Orbit
1 hour ago
add a comment |
Since callable can be an xvalue there is a chance that it gets destroyed before the lambda capture, hence leaving you with a dangling reference in the capture. To prevent that, if an argument is an r-value it needs to be copied.
A working example:
template<class Callable>
auto discardable(Callable&& callable) { // This one makes a copy of the temporary.
return [callable = std::move(callable)]() mutable {
static_cast<void>(static_cast<Callable&&>(callable)());
};
}
template<class Callable>
auto discardable(Callable& callable) {
return [&callable]() mutable {
static_cast<void>(callable());
};
}
You can still face lifetime issues if callable is an l-value reference but its lifetime scope is smaller than that of the lambda capture returned by discardable. So, it may be the safest and easiest to always copy callable.
As a side note, although there are new specialised utilities that perfect-forward the value category of the function object, like std::apply, the standard library algorithms always copy function objects by accepting them by value. So that if one overloaded both operator()()& and operator()()&& the standard library would always use operator()()&.
Does it needstd::movein the capture thingie? So as to avoid a copy if unnecessary? Genuine question; I am a little behind on the latest gadgets.
– Lightness Races in Orbit
1 hour ago
2
@LightnessRacesinOrbit Someone may declareoperator()()&&along withoperator()()&. IMO, that is brittle, but conceivable. Although the standard library just makes copies of function objects and is not concerned with such trifles.
– Maxim Egorushkin
1 hour ago
1
Just seems like a wasted copy for nothing. You can still invokeoperator()()&&on it
– Lightness Races in Orbit
1 hour ago
2
"the standard library always copies function objects by accepting them by value". That's what STL did when forwarding references didn't exist. std::apply uses forwarding reference as counter-example.
– Jarod42
1 hour ago
1
So, why would you copy when you can move? I totally don't get it.return [callable = std::move(callable)]() mutable {…}
– Arne Vogel
36 mins ago
|
show 6 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54418941%2fperfect-forwarding-of-a-callable%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Lambdas are anonymous structs with an operator(), the capture list is a fancy way of specifying the type of its members. Capturing by reference really is just what it sounds like: you have reference members. It isn't hard to see the reference dangles.
This is a case where you specifically don't want to perfectly forward: you have different semantics depending on whether the argument is a lvalue or rvalue reference.
template<class Callable>
auto discardable(Callable& callable)
{
return [&] { (void) callable(); };
}
template<class Callable>
auto discardable(Callable&& callable)
{
return [callable = std::forward<Callable>(callable)] { // move, don't copy
(void) std::move(callable)(); // If you want rvalue semantics
};
}
1
Are you sureforwardandmoveshould not be reversed?
– Maxim Egorushkin
17 mins ago
add a comment |
Lambdas are anonymous structs with an operator(), the capture list is a fancy way of specifying the type of its members. Capturing by reference really is just what it sounds like: you have reference members. It isn't hard to see the reference dangles.
This is a case where you specifically don't want to perfectly forward: you have different semantics depending on whether the argument is a lvalue or rvalue reference.
template<class Callable>
auto discardable(Callable& callable)
{
return [&] { (void) callable(); };
}
template<class Callable>
auto discardable(Callable&& callable)
{
return [callable = std::forward<Callable>(callable)] { // move, don't copy
(void) std::move(callable)(); // If you want rvalue semantics
};
}
1
Are you sureforwardandmoveshould not be reversed?
– Maxim Egorushkin
17 mins ago
add a comment |
Lambdas are anonymous structs with an operator(), the capture list is a fancy way of specifying the type of its members. Capturing by reference really is just what it sounds like: you have reference members. It isn't hard to see the reference dangles.
This is a case where you specifically don't want to perfectly forward: you have different semantics depending on whether the argument is a lvalue or rvalue reference.
template<class Callable>
auto discardable(Callable& callable)
{
return [&] { (void) callable(); };
}
template<class Callable>
auto discardable(Callable&& callable)
{
return [callable = std::forward<Callable>(callable)] { // move, don't copy
(void) std::move(callable)(); // If you want rvalue semantics
};
}
Lambdas are anonymous structs with an operator(), the capture list is a fancy way of specifying the type of its members. Capturing by reference really is just what it sounds like: you have reference members. It isn't hard to see the reference dangles.
This is a case where you specifically don't want to perfectly forward: you have different semantics depending on whether the argument is a lvalue or rvalue reference.
template<class Callable>
auto discardable(Callable& callable)
{
return [&] { (void) callable(); };
}
template<class Callable>
auto discardable(Callable&& callable)
{
return [callable = std::forward<Callable>(callable)] { // move, don't copy
(void) std::move(callable)(); // If you want rvalue semantics
};
}
answered 1 hour ago
Passer ByPasser By
9,30132454
9,30132454
1
Are you sureforwardandmoveshould not be reversed?
– Maxim Egorushkin
17 mins ago
add a comment |
1
Are you sureforwardandmoveshould not be reversed?
– Maxim Egorushkin
17 mins ago
1
1
Are you sure
forward and move should not be reversed?– Maxim Egorushkin
17 mins ago
Are you sure
forward and move should not be reversed?– Maxim Egorushkin
17 mins ago
add a comment |
Your program is UB as you use dangling reference of the captured lambda.
So to perfect forward capture in lambda, you may use
return [f = std::conditional_t<
std::is_lvalue_reference<Callable>::value,
std::reference_wrapper<std::remove_reference_t<Callable>>,
Callable>{std::forward<Callable>(callable)}]
{
std::forward<Callable>(f)();
};
It move-constructs the temporary lambda.
1
Is forwarding captured variable really necessary?
– bartop
2 hours ago
6
Ahhh what a beautiful language
– Lightness Races in Orbit
1 hour ago
add a comment |
Your program is UB as you use dangling reference of the captured lambda.
So to perfect forward capture in lambda, you may use
return [f = std::conditional_t<
std::is_lvalue_reference<Callable>::value,
std::reference_wrapper<std::remove_reference_t<Callable>>,
Callable>{std::forward<Callable>(callable)}]
{
std::forward<Callable>(f)();
};
It move-constructs the temporary lambda.
1
Is forwarding captured variable really necessary?
– bartop
2 hours ago
6
Ahhh what a beautiful language
– Lightness Races in Orbit
1 hour ago
add a comment |
Your program is UB as you use dangling reference of the captured lambda.
So to perfect forward capture in lambda, you may use
return [f = std::conditional_t<
std::is_lvalue_reference<Callable>::value,
std::reference_wrapper<std::remove_reference_t<Callable>>,
Callable>{std::forward<Callable>(callable)}]
{
std::forward<Callable>(f)();
};
It move-constructs the temporary lambda.
Your program is UB as you use dangling reference of the captured lambda.
So to perfect forward capture in lambda, you may use
return [f = std::conditional_t<
std::is_lvalue_reference<Callable>::value,
std::reference_wrapper<std::remove_reference_t<Callable>>,
Callable>{std::forward<Callable>(callable)}]
{
std::forward<Callable>(f)();
};
It move-constructs the temporary lambda.
edited 2 hours ago
answered 2 hours ago
Jarod42Jarod42
115k12102182
115k12102182
1
Is forwarding captured variable really necessary?
– bartop
2 hours ago
6
Ahhh what a beautiful language
– Lightness Races in Orbit
1 hour ago
add a comment |
1
Is forwarding captured variable really necessary?
– bartop
2 hours ago
6
Ahhh what a beautiful language
– Lightness Races in Orbit
1 hour ago
1
1
Is forwarding captured variable really necessary?
– bartop
2 hours ago
Is forwarding captured variable really necessary?
– bartop
2 hours ago
6
6
Ahhh what a beautiful language
– Lightness Races in Orbit
1 hour ago
Ahhh what a beautiful language
– Lightness Races in Orbit
1 hour ago
add a comment |
Since callable can be an xvalue there is a chance that it gets destroyed before the lambda capture, hence leaving you with a dangling reference in the capture. To prevent that, if an argument is an r-value it needs to be copied.
A working example:
template<class Callable>
auto discardable(Callable&& callable) { // This one makes a copy of the temporary.
return [callable = std::move(callable)]() mutable {
static_cast<void>(static_cast<Callable&&>(callable)());
};
}
template<class Callable>
auto discardable(Callable& callable) {
return [&callable]() mutable {
static_cast<void>(callable());
};
}
You can still face lifetime issues if callable is an l-value reference but its lifetime scope is smaller than that of the lambda capture returned by discardable. So, it may be the safest and easiest to always copy callable.
As a side note, although there are new specialised utilities that perfect-forward the value category of the function object, like std::apply, the standard library algorithms always copy function objects by accepting them by value. So that if one overloaded both operator()()& and operator()()&& the standard library would always use operator()()&.
Does it needstd::movein the capture thingie? So as to avoid a copy if unnecessary? Genuine question; I am a little behind on the latest gadgets.
– Lightness Races in Orbit
1 hour ago
2
@LightnessRacesinOrbit Someone may declareoperator()()&&along withoperator()()&. IMO, that is brittle, but conceivable. Although the standard library just makes copies of function objects and is not concerned with such trifles.
– Maxim Egorushkin
1 hour ago
1
Just seems like a wasted copy for nothing. You can still invokeoperator()()&&on it
– Lightness Races in Orbit
1 hour ago
2
"the standard library always copies function objects by accepting them by value". That's what STL did when forwarding references didn't exist. std::apply uses forwarding reference as counter-example.
– Jarod42
1 hour ago
1
So, why would you copy when you can move? I totally don't get it.return [callable = std::move(callable)]() mutable {…}
– Arne Vogel
36 mins ago
|
show 6 more comments
Since callable can be an xvalue there is a chance that it gets destroyed before the lambda capture, hence leaving you with a dangling reference in the capture. To prevent that, if an argument is an r-value it needs to be copied.
A working example:
template<class Callable>
auto discardable(Callable&& callable) { // This one makes a copy of the temporary.
return [callable = std::move(callable)]() mutable {
static_cast<void>(static_cast<Callable&&>(callable)());
};
}
template<class Callable>
auto discardable(Callable& callable) {
return [&callable]() mutable {
static_cast<void>(callable());
};
}
You can still face lifetime issues if callable is an l-value reference but its lifetime scope is smaller than that of the lambda capture returned by discardable. So, it may be the safest and easiest to always copy callable.
As a side note, although there are new specialised utilities that perfect-forward the value category of the function object, like std::apply, the standard library algorithms always copy function objects by accepting them by value. So that if one overloaded both operator()()& and operator()()&& the standard library would always use operator()()&.
Does it needstd::movein the capture thingie? So as to avoid a copy if unnecessary? Genuine question; I am a little behind on the latest gadgets.
– Lightness Races in Orbit
1 hour ago
2
@LightnessRacesinOrbit Someone may declareoperator()()&&along withoperator()()&. IMO, that is brittle, but conceivable. Although the standard library just makes copies of function objects and is not concerned with such trifles.
– Maxim Egorushkin
1 hour ago
1
Just seems like a wasted copy for nothing. You can still invokeoperator()()&&on it
– Lightness Races in Orbit
1 hour ago
2
"the standard library always copies function objects by accepting them by value". That's what STL did when forwarding references didn't exist. std::apply uses forwarding reference as counter-example.
– Jarod42
1 hour ago
1
So, why would you copy when you can move? I totally don't get it.return [callable = std::move(callable)]() mutable {…}
– Arne Vogel
36 mins ago
|
show 6 more comments
Since callable can be an xvalue there is a chance that it gets destroyed before the lambda capture, hence leaving you with a dangling reference in the capture. To prevent that, if an argument is an r-value it needs to be copied.
A working example:
template<class Callable>
auto discardable(Callable&& callable) { // This one makes a copy of the temporary.
return [callable = std::move(callable)]() mutable {
static_cast<void>(static_cast<Callable&&>(callable)());
};
}
template<class Callable>
auto discardable(Callable& callable) {
return [&callable]() mutable {
static_cast<void>(callable());
};
}
You can still face lifetime issues if callable is an l-value reference but its lifetime scope is smaller than that of the lambda capture returned by discardable. So, it may be the safest and easiest to always copy callable.
As a side note, although there are new specialised utilities that perfect-forward the value category of the function object, like std::apply, the standard library algorithms always copy function objects by accepting them by value. So that if one overloaded both operator()()& and operator()()&& the standard library would always use operator()()&.
Since callable can be an xvalue there is a chance that it gets destroyed before the lambda capture, hence leaving you with a dangling reference in the capture. To prevent that, if an argument is an r-value it needs to be copied.
A working example:
template<class Callable>
auto discardable(Callable&& callable) { // This one makes a copy of the temporary.
return [callable = std::move(callable)]() mutable {
static_cast<void>(static_cast<Callable&&>(callable)());
};
}
template<class Callable>
auto discardable(Callable& callable) {
return [&callable]() mutable {
static_cast<void>(callable());
};
}
You can still face lifetime issues if callable is an l-value reference but its lifetime scope is smaller than that of the lambda capture returned by discardable. So, it may be the safest and easiest to always copy callable.
As a side note, although there are new specialised utilities that perfect-forward the value category of the function object, like std::apply, the standard library algorithms always copy function objects by accepting them by value. So that if one overloaded both operator()()& and operator()()&& the standard library would always use operator()()&.
edited 20 mins ago
answered 1 hour ago
Maxim EgorushkinMaxim Egorushkin
86.8k11101184
86.8k11101184
Does it needstd::movein the capture thingie? So as to avoid a copy if unnecessary? Genuine question; I am a little behind on the latest gadgets.
– Lightness Races in Orbit
1 hour ago
2
@LightnessRacesinOrbit Someone may declareoperator()()&&along withoperator()()&. IMO, that is brittle, but conceivable. Although the standard library just makes copies of function objects and is not concerned with such trifles.
– Maxim Egorushkin
1 hour ago
1
Just seems like a wasted copy for nothing. You can still invokeoperator()()&&on it
– Lightness Races in Orbit
1 hour ago
2
"the standard library always copies function objects by accepting them by value". That's what STL did when forwarding references didn't exist. std::apply uses forwarding reference as counter-example.
– Jarod42
1 hour ago
1
So, why would you copy when you can move? I totally don't get it.return [callable = std::move(callable)]() mutable {…}
– Arne Vogel
36 mins ago
|
show 6 more comments
Does it needstd::movein the capture thingie? So as to avoid a copy if unnecessary? Genuine question; I am a little behind on the latest gadgets.
– Lightness Races in Orbit
1 hour ago
2
@LightnessRacesinOrbit Someone may declareoperator()()&&along withoperator()()&. IMO, that is brittle, but conceivable. Although the standard library just makes copies of function objects and is not concerned with such trifles.
– Maxim Egorushkin
1 hour ago
1
Just seems like a wasted copy for nothing. You can still invokeoperator()()&&on it
– Lightness Races in Orbit
1 hour ago
2
"the standard library always copies function objects by accepting them by value". That's what STL did when forwarding references didn't exist. std::apply uses forwarding reference as counter-example.
– Jarod42
1 hour ago
1
So, why would you copy when you can move? I totally don't get it.return [callable = std::move(callable)]() mutable {…}
– Arne Vogel
36 mins ago
Does it need
std::move in the capture thingie? So as to avoid a copy if unnecessary? Genuine question; I am a little behind on the latest gadgets.– Lightness Races in Orbit
1 hour ago
Does it need
std::move in the capture thingie? So as to avoid a copy if unnecessary? Genuine question; I am a little behind on the latest gadgets.– Lightness Races in Orbit
1 hour ago
2
2
@LightnessRacesinOrbit Someone may declare
operator()()&& along with operator()()&. IMO, that is brittle, but conceivable. Although the standard library just makes copies of function objects and is not concerned with such trifles.– Maxim Egorushkin
1 hour ago
@LightnessRacesinOrbit Someone may declare
operator()()&& along with operator()()&. IMO, that is brittle, but conceivable. Although the standard library just makes copies of function objects and is not concerned with such trifles.– Maxim Egorushkin
1 hour ago
1
1
Just seems like a wasted copy for nothing. You can still invoke
operator()()&& on it– Lightness Races in Orbit
1 hour ago
Just seems like a wasted copy for nothing. You can still invoke
operator()()&& on it– Lightness Races in Orbit
1 hour ago
2
2
"the standard library always copies function objects by accepting them by value". That's what STL did when forwarding references didn't exist. std::apply uses forwarding reference as counter-example.
– Jarod42
1 hour ago
"the standard library always copies function objects by accepting them by value". That's what STL did when forwarding references didn't exist. std::apply uses forwarding reference as counter-example.
– Jarod42
1 hour ago
1
1
So, why would you copy when you can move? I totally don't get it.
return [callable = std::move(callable)]() mutable {…}– Arne Vogel
36 mins ago
So, why would you copy when you can move? I totally don't get it.
return [callable = std::move(callable)]() mutable {…}– Arne Vogel
36 mins ago
|
show 6 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54418941%2fperfect-forwarding-of-a-callable%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
Since
callablecan be an xvalue there is a chance that it gets destroyed before the lambda capture, hence leaving you with a dangling reference in the capture.– Maxim Egorushkin
2 hours ago