why is std::lock_guard not movable?
Why is std::lock_guard not movable, it would make code so much nicer:
auto locked = lock_guard(mutex);
instead of
std::lock_guard<std::mutex> locked(mutex);
Is there something wrong with creating your own version, like:
template <typename T> class lock_guard_
{
T* Mutex_;
lock_guard_(const lock_guard_&) = delete;
lock_guard_& operator=(const lock_guard_&) = delete;
public:
lock_guard_(T& mutex) : Mutex_(&mutex)
{
Mutex_->lock();
}
~lock_guard_()
{
if(Mutex_!=nullptr)
Mutex_->unlock();
}
lock_guard_(lock_guard_&& guard)
{
Mutex_ = guard.Mutex_;
guard.Mutex_ = nullptr;
}
};
template <typename T> lock_guard_<T> lock_guard(T& mutex)
{
return lock_guard_<T>(mutex);
}
?
Any fundamental reason it would be a bad idea to make it movable?
c++ multithreading c++11 standards movable
edited Nov 21 '18 at 11:46
Evg
3,80721334
asked Mar 19 '14 at 10:18
valoh
13836
add a comment |
Why is std::lock_guard not movable, it would make code so much nicer:
auto locked = lock_guard(mutex);
instead of
std::lock_guard<std::mutex> locked(mutex);
Is there something wrong with creating your own version, like:
template <typename T> class lock_guard_
{
T* Mutex_;
lock_guard_(const lock_guard_&) = delete;
lock_guard_& operator=(const lock_guard_&) = delete;
public:
lock_guard_(T& mutex) : Mutex_(&mutex)
{
Mutex_->lock();
}
~lock_guard_()
{
if(Mutex_!=nullptr)
Mutex_->unlock();
}
lock_guard_(lock_guard_&& guard)
{
Mutex_ = guard.Mutex_;
guard.Mutex_ = nullptr;
}
};
template <typename T> lock_guard_<T> lock_guard(T& mutex)
{
return lock_guard_<T>(mutex);
}
?
Any fundamental reason it would be a bad idea to make it movable?
c++ multithreading c++11 standards movable
edited Nov 21 '18 at 11:46
Evg
3,80721334
asked Mar 19 '14 at 10:18
valoh
13836
Well, you do haveunique_lock. It might just be to make the interface as simple as possible.
– ecatmur
Mar 19 '14 at 10:25
1
thanks, I have overlooked unique_lock :-) So I guess this answers my question: No there is no reason. Imo making it movable doesn't really make the interface more complicated but more usable and compatible with modern c++.
– valoh
Mar 19 '14 at 10:47
1
@valoh: If it was movable it would need to have a state where it doesn't hold a the lock. That makes it redundant, since it would offer exactly the same functionality asunique_lock(though I would argue that it is mostly redundant anyway). Therefore iflock_guardis desired as a seperate class it can't really be movable.
– Grizzly
Mar 19 '14 at 13:08
add a comment |
Why is std::lock_guard not movable, it would make code so much nicer:
auto locked = lock_guard(mutex);
instead of
std::lock_guard<std::mutex> locked(mutex);
Is there something wrong with creating your own version, like:
template <typename T> class lock_guard_
{
T* Mutex_;
lock_guard_(const lock_guard_&) = delete;
lock_guard_& operator=(const lock_guard_&) = delete;
public:
lock_guard_(T& mutex) : Mutex_(&mutex)
{
Mutex_->lock();
}
~lock_guard_()
{
if(Mutex_!=nullptr)
Mutex_->unlock();
}
lock_guard_(lock_guard_&& guard)
{
Mutex_ = guard.Mutex_;
guard.Mutex_ = nullptr;
}
};
template <typename T> lock_guard_<T> lock_guard(T& mutex)
{
return lock_guard_<T>(mutex);
}
?
Any fundamental reason it would be a bad idea to make it movable?
c++ multithreading c++11 standards movable
edited Nov 21 '18 at 11:46
Evg
3,80721334
asked Mar 19 '14 at 10:18
valoh
13836
Why is std::lock_guard not movable, it would make code so much nicer:
auto locked = lock_guard(mutex);
instead of
std::lock_guard<std::mutex> locked(mutex);
Is there something wrong with creating your own version, like:
template <typename T> class lock_guard_
{
T* Mutex_;
lock_guard_(const lock_guard_&) = delete;
lock_guard_& operator=(const lock_guard_&) = delete;
public:
lock_guard_(T& mutex) : Mutex_(&mutex)
{
Mutex_->lock();
}
~lock_guard_()
{
if(Mutex_!=nullptr)
Mutex_->unlock();
}
lock_guard_(lock_guard_&& guard)
{
Mutex_ = guard.Mutex_;
guard.Mutex_ = nullptr;
}
};
template <typename T> lock_guard_<T> lock_guard(T& mutex)
{
return lock_guard_<T>(mutex);
}
?
Any fundamental reason it would be a bad idea to make it movable?
c++ multithreading c++11 standards movable
c++ multithreading c++11 standards movable
edited Nov 21 '18 at 11:46
Evg
3,80721334
asked Mar 19 '14 at 10:18
valoh
13836
edited Nov 21 '18 at 11:46
Evg
3,80721334
asked Mar 19 '14 at 10:18
valoh
13836
edited Nov 21 '18 at 11:46
Evg
3,80721334
edited Nov 21 '18 at 11:46
Evg
3,80721334
edited Nov 21 '18 at 11:46
Evg
3,80721334
3,80721334
asked Mar 19 '14 at 10:18
valoh
13836
asked Mar 19 '14 at 10:18
valoh
13836
asked Mar 19 '14 at 10:18
valoh
13836
13836
Well, you do haveunique_lock. It might just be to make the interface as simple as possible.
– ecatmur
Mar 19 '14 at 10:25
1
thanks, I have overlooked unique_lock :-) So I guess this answers my question: No there is no reason. Imo making it movable doesn't really make the interface more complicated but more usable and compatible with modern c++.
– valoh
Mar 19 '14 at 10:47
1
@valoh: If it was movable it would need to have a state where it doesn't hold a the lock. That makes it redundant, since it would offer exactly the same functionality asunique_lock(though I would argue that it is mostly redundant anyway). Therefore iflock_guardis desired as a seperate class it can't really be movable.
– Grizzly
Mar 19 '14 at 13:08
add a comment |
Well, you do haveunique_lock. It might just be to make the interface as simple as possible.
– ecatmur
Mar 19 '14 at 10:25
1
thanks, I have overlooked unique_lock :-) So I guess this answers my question: No there is no reason. Imo making it movable doesn't really make the interface more complicated but more usable and compatible with modern c++.
– valoh
Mar 19 '14 at 10:47
1
@valoh: If it was movable it would need to have a state where it doesn't hold a the lock. That makes it redundant, since it would offer exactly the same functionality asunique_lock(though I would argue that it is mostly redundant anyway). Therefore iflock_guardis desired as a seperate class it can't really be movable.
– Grizzly
Mar 19 '14 at 13:08
Well, you do have
unique_lock. It might just be to make the interface as simple as possible.– ecatmur
Mar 19 '14 at 10:25
Well, you do have
unique_lock. It might just be to make the interface as simple as possible.– ecatmur
Mar 19 '14 at 10:25
1
1
thanks, I have overlooked unique_lock :-) So I guess this answers my question: No there is no reason. Imo making it movable doesn't really make the interface more complicated but more usable and compatible with modern c++.
– valoh
Mar 19 '14 at 10:47
thanks, I have overlooked unique_lock :-) So I guess this answers my question: No there is no reason. Imo making it movable doesn't really make the interface more complicated but more usable and compatible with modern c++.
– valoh
Mar 19 '14 at 10:47
1
1
@valoh: If it was movable it would need to have a state where it doesn't hold a the lock. That makes it redundant, since it would offer exactly the same functionality as
unique_lock (though I would argue that it is mostly redundant anyway). Therefore if lock_guard is desired as a seperate class it can't really be movable.– Grizzly
Mar 19 '14 at 13:08
@valoh: If it was movable it would need to have a state where it doesn't hold a the lock. That makes it redundant, since it would offer exactly the same functionality as
unique_lock (though I would argue that it is mostly redundant anyway). Therefore if lock_guard is desired as a seperate class it can't really be movable.– Grizzly
Mar 19 '14 at 13:08
add a comment |
2 Answers
2
active
oldest
votes
lock_guard is always engaged; it always holds a reference to a mutex and always unlocks it in its destructor. If it was movable then it would need to hold a pointer instead of a reference, and test the pointer in its destructor. This might seem a trivial cost, but it is C++ philosophy that you don't pay for what you don't use.
If you want a movable (and releaseable) lock you can use unique_lock.
You might be interested in n3602 Template parameter deduction for constructors, which removes the need for make_ functions. It won't be in C++14 but we can hope for C++17.
answered Mar 19 '14 at 11:21
ecatmur
113k15212301
N3602 is EWG issue 60. EWG is definitely in favor of the paper, but there are some issues that need ironing out.
– Casey
Mar 20 '14 at 0:24
add a comment |
You can do:
auto&& g = std::lock_guard<std::mutex> { mutex };
Obviously this isn’t entirely satisfactory as this performs no deduction. Your attempt at a deducing factory is almost there save for the fact that you need to use list-initialization to return a non-movable object:
template<typename Mutex>
std::lock_guard<Mutex> lock_guard(Mutex& mutex)
{
mutex.lock();
return { mutex, std::adopt_lock };
}
which allows for auto&& g = lock_guard(mutex);.
(The awkward dance with std::adopt_lock is due to the unary constructor being explicit. So we can’t do return { mutex }; as that’s a disallowed conversion, while return std::lock_guard<Mutex> { mutex }; performs list-initialization of a temporary — which we can’t then move into the return value.)
answered Mar 19 '14 at 11:38
Luc Danton
30.3k554105
1
This is nifty, slightly scary, and I might just steal it. :p
– Konrad Rudolph
Mar 19 '14 at 11:42
2
That's cool, but why the extra level of aggregation? It seems to work without it: ideone.com/KDs8qI
– Vaughn Cato
Mar 19 '14 at 12:33
@VaughnCato This may have been a misconception of mine, as the language that I thought applied only to aggregates seems to work for non-aggregates just as well. Admittedly those aren’t my favourite areas of the Standard, so I welcome any light shed on them. Thanks for the heads-up.
– Luc Danton
Mar 19 '14 at 13:14
1
I looked it up. According to 6.6.3p2, "A return statement with a braced-init-list initializes the object or reference to be returned from the function by copy-list-initialization (8.5.4) from the specified initializer-list.". Even though it is copy-list-initialization, that doesn't mean there is a copy made. The only thing I can see that makes copy-list-initialization special is that it doesn't allow the use of explicit constructors. Otherwise, it is regular list-initialization, and no copy is involved.
– Vaughn Cato
Mar 19 '14 at 13:54
add a comment |
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%2f22502606%2fwhy-is-stdlock-guard-not-movable%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
lock_guard is always engaged; it always holds a reference to a mutex and always unlocks it in its destructor. If it was movable then it would need to hold a pointer instead of a reference, and test the pointer in its destructor. This might seem a trivial cost, but it is C++ philosophy that you don't pay for what you don't use.
If you want a movable (and releaseable) lock you can use unique_lock.
You might be interested in n3602 Template parameter deduction for constructors, which removes the need for make_ functions. It won't be in C++14 but we can hope for C++17.
answered Mar 19 '14 at 11:21
ecatmur
113k15212301
N3602 is EWG issue 60. EWG is definitely in favor of the paper, but there are some issues that need ironing out.
– Casey
Mar 20 '14 at 0:24
add a comment |
lock_guard is always engaged; it always holds a reference to a mutex and always unlocks it in its destructor. If it was movable then it would need to hold a pointer instead of a reference, and test the pointer in its destructor. This might seem a trivial cost, but it is C++ philosophy that you don't pay for what you don't use.
If you want a movable (and releaseable) lock you can use unique_lock.
You might be interested in n3602 Template parameter deduction for constructors, which removes the need for make_ functions. It won't be in C++14 but we can hope for C++17.
answered Mar 19 '14 at 11:21
ecatmur
113k15212301
N3602 is EWG issue 60. EWG is definitely in favor of the paper, but there are some issues that need ironing out.
– Casey
Mar 20 '14 at 0:24
add a comment |
lock_guard is always engaged; it always holds a reference to a mutex and always unlocks it in its destructor. If it was movable then it would need to hold a pointer instead of a reference, and test the pointer in its destructor. This might seem a trivial cost, but it is C++ philosophy that you don't pay for what you don't use.
If you want a movable (and releaseable) lock you can use unique_lock.
You might be interested in n3602 Template parameter deduction for constructors, which removes the need for make_ functions. It won't be in C++14 but we can hope for C++17.
answered Mar 19 '14 at 11:21
ecatmur
113k15212301
lock_guard is always engaged; it always holds a reference to a mutex and always unlocks it in its destructor. If it was movable then it would need to hold a pointer instead of a reference, and test the pointer in its destructor. This might seem a trivial cost, but it is C++ philosophy that you don't pay for what you don't use.
If you want a movable (and releaseable) lock you can use unique_lock.
You might be interested in n3602 Template parameter deduction for constructors, which removes the need for make_ functions. It won't be in C++14 but we can hope for C++17.
answered Mar 19 '14 at 11:21
ecatmur
113k15212301
answered Mar 19 '14 at 11:21
ecatmur
113k15212301
answered Mar 19 '14 at 11:21
ecatmur
113k15212301
answered Mar 19 '14 at 11:21
ecatmur
113k15212301
113k15212301
N3602 is EWG issue 60. EWG is definitely in favor of the paper, but there are some issues that need ironing out.
– Casey
Mar 20 '14 at 0:24
add a comment |
N3602 is EWG issue 60. EWG is definitely in favor of the paper, but there are some issues that need ironing out.
– Casey
Mar 20 '14 at 0:24
N3602 is EWG issue 60. EWG is definitely in favor of the paper, but there are some issues that need ironing out.
– Casey
Mar 20 '14 at 0:24
N3602 is EWG issue 60. EWG is definitely in favor of the paper, but there are some issues that need ironing out.
– Casey
Mar 20 '14 at 0:24
add a comment |
You can do:
auto&& g = std::lock_guard<std::mutex> { mutex };
Obviously this isn’t entirely satisfactory as this performs no deduction. Your attempt at a deducing factory is almost there save for the fact that you need to use list-initialization to return a non-movable object:
template<typename Mutex>
std::lock_guard<Mutex> lock_guard(Mutex& mutex)
{
mutex.lock();
return { mutex, std::adopt_lock };
}
which allows for auto&& g = lock_guard(mutex);.
(The awkward dance with std::adopt_lock is due to the unary constructor being explicit. So we can’t do return { mutex }; as that’s a disallowed conversion, while return std::lock_guard<Mutex> { mutex }; performs list-initialization of a temporary — which we can’t then move into the return value.)
answered Mar 19 '14 at 11:38
Luc Danton
30.3k554105
1
This is nifty, slightly scary, and I might just steal it. :p
– Konrad Rudolph
Mar 19 '14 at 11:42
2
That's cool, but why the extra level of aggregation? It seems to work without it: ideone.com/KDs8qI
– Vaughn Cato
Mar 19 '14 at 12:33
@VaughnCato This may have been a misconception of mine, as the language that I thought applied only to aggregates seems to work for non-aggregates just as well. Admittedly those aren’t my favourite areas of the Standard, so I welcome any light shed on them. Thanks for the heads-up.
– Luc Danton
Mar 19 '14 at 13:14
1
I looked it up. According to 6.6.3p2, "A return statement with a braced-init-list initializes the object or reference to be returned from the function by copy-list-initialization (8.5.4) from the specified initializer-list.". Even though it is copy-list-initialization, that doesn't mean there is a copy made. The only thing I can see that makes copy-list-initialization special is that it doesn't allow the use of explicit constructors. Otherwise, it is regular list-initialization, and no copy is involved.
– Vaughn Cato
Mar 19 '14 at 13:54
add a comment |
You can do:
auto&& g = std::lock_guard<std::mutex> { mutex };
Obviously this isn’t entirely satisfactory as this performs no deduction. Your attempt at a deducing factory is almost there save for the fact that you need to use list-initialization to return a non-movable object:
template<typename Mutex>
std::lock_guard<Mutex> lock_guard(Mutex& mutex)
{
mutex.lock();
return { mutex, std::adopt_lock };
}
which allows for auto&& g = lock_guard(mutex);.
(The awkward dance with std::adopt_lock is due to the unary constructor being explicit. So we can’t do return { mutex }; as that’s a disallowed conversion, while return std::lock_guard<Mutex> { mutex }; performs list-initialization of a temporary — which we can’t then move into the return value.)
answered Mar 19 '14 at 11:38
Luc Danton
30.3k554105
1
This is nifty, slightly scary, and I might just steal it. :p
– Konrad Rudolph
Mar 19 '14 at 11:42
2
That's cool, but why the extra level of aggregation? It seems to work without it: ideone.com/KDs8qI
– Vaughn Cato
Mar 19 '14 at 12:33
@VaughnCato This may have been a misconception of mine, as the language that I thought applied only to aggregates seems to work for non-aggregates just as well. Admittedly those aren’t my favourite areas of the Standard, so I welcome any light shed on them. Thanks for the heads-up.
– Luc Danton
Mar 19 '14 at 13:14
1
I looked it up. According to 6.6.3p2, "A return statement with a braced-init-list initializes the object or reference to be returned from the function by copy-list-initialization (8.5.4) from the specified initializer-list.". Even though it is copy-list-initialization, that doesn't mean there is a copy made. The only thing I can see that makes copy-list-initialization special is that it doesn't allow the use of explicit constructors. Otherwise, it is regular list-initialization, and no copy is involved.
– Vaughn Cato
Mar 19 '14 at 13:54
add a comment |
You can do:
auto&& g = std::lock_guard<std::mutex> { mutex };
Obviously this isn’t entirely satisfactory as this performs no deduction. Your attempt at a deducing factory is almost there save for the fact that you need to use list-initialization to return a non-movable object:
template<typename Mutex>
std::lock_guard<Mutex> lock_guard(Mutex& mutex)
{
mutex.lock();
return { mutex, std::adopt_lock };
}
which allows for auto&& g = lock_guard(mutex);.
(The awkward dance with std::adopt_lock is due to the unary constructor being explicit. So we can’t do return { mutex }; as that’s a disallowed conversion, while return std::lock_guard<Mutex> { mutex }; performs list-initialization of a temporary — which we can’t then move into the return value.)
answered Mar 19 '14 at 11:38
Luc Danton
30.3k554105
You can do:
auto&& g = std::lock_guard<std::mutex> { mutex };
Obviously this isn’t entirely satisfactory as this performs no deduction. Your attempt at a deducing factory is almost there save for the fact that you need to use list-initialization to return a non-movable object:
template<typename Mutex>
std::lock_guard<Mutex> lock_guard(Mutex& mutex)
{
mutex.lock();
return { mutex, std::adopt_lock };
}
which allows for auto&& g = lock_guard(mutex);.
(The awkward dance with std::adopt_lock is due to the unary constructor being explicit. So we can’t do return { mutex }; as that’s a disallowed conversion, while return std::lock_guard<Mutex> { mutex }; performs list-initialization of a temporary — which we can’t then move into the return value.)
answered Mar 19 '14 at 11:38
Luc Danton
30.3k554105
edited Mar 19 '14 at 13:18
answered Mar 19 '14 at 11:38
Luc Danton
30.3k554105
answered Mar 19 '14 at 11:38
Luc Danton
30.3k554105
answered Mar 19 '14 at 11:38
Luc Danton
30.3k554105
30.3k554105
1
This is nifty, slightly scary, and I might just steal it. :p
– Konrad Rudolph
Mar 19 '14 at 11:42
2
That's cool, but why the extra level of aggregation? It seems to work without it: ideone.com/KDs8qI
– Vaughn Cato
Mar 19 '14 at 12:33
@VaughnCato This may have been a misconception of mine, as the language that I thought applied only to aggregates seems to work for non-aggregates just as well. Admittedly those aren’t my favourite areas of the Standard, so I welcome any light shed on them. Thanks for the heads-up.
– Luc Danton
Mar 19 '14 at 13:14
1
I looked it up. According to 6.6.3p2, "A return statement with a braced-init-list initializes the object or reference to be returned from the function by copy-list-initialization (8.5.4) from the specified initializer-list.". Even though it is copy-list-initialization, that doesn't mean there is a copy made. The only thing I can see that makes copy-list-initialization special is that it doesn't allow the use of explicit constructors. Otherwise, it is regular list-initialization, and no copy is involved.
– Vaughn Cato
Mar 19 '14 at 13:54
add a comment |
1
This is nifty, slightly scary, and I might just steal it. :p
– Konrad Rudolph
Mar 19 '14 at 11:42
2
That's cool, but why the extra level of aggregation? It seems to work without it: ideone.com/KDs8qI
– Vaughn Cato
Mar 19 '14 at 12:33
@VaughnCato This may have been a misconception of mine, as the language that I thought applied only to aggregates seems to work for non-aggregates just as well. Admittedly those aren’t my favourite areas of the Standard, so I welcome any light shed on them. Thanks for the heads-up.
– Luc Danton
Mar 19 '14 at 13:14
1
I looked it up. According to 6.6.3p2, "A return statement with a braced-init-list initializes the object or reference to be returned from the function by copy-list-initialization (8.5.4) from the specified initializer-list.". Even though it is copy-list-initialization, that doesn't mean there is a copy made. The only thing I can see that makes copy-list-initialization special is that it doesn't allow the use of explicit constructors. Otherwise, it is regular list-initialization, and no copy is involved.
– Vaughn Cato
Mar 19 '14 at 13:54
1
1
This is nifty, slightly scary, and I might just steal it. :p
– Konrad Rudolph
Mar 19 '14 at 11:42
This is nifty, slightly scary, and I might just steal it. :p
– Konrad Rudolph
Mar 19 '14 at 11:42
2
2
That's cool, but why the extra level of aggregation? It seems to work without it: ideone.com/KDs8qI
– Vaughn Cato
Mar 19 '14 at 12:33
That's cool, but why the extra level of aggregation? It seems to work without it: ideone.com/KDs8qI
– Vaughn Cato
Mar 19 '14 at 12:33
@VaughnCato This may have been a misconception of mine, as the language that I thought applied only to aggregates seems to work for non-aggregates just as well. Admittedly those aren’t my favourite areas of the Standard, so I welcome any light shed on them. Thanks for the heads-up.
– Luc Danton
Mar 19 '14 at 13:14
@VaughnCato This may have been a misconception of mine, as the language that I thought applied only to aggregates seems to work for non-aggregates just as well. Admittedly those aren’t my favourite areas of the Standard, so I welcome any light shed on them. Thanks for the heads-up.
– Luc Danton
Mar 19 '14 at 13:14
1
1
I looked it up. According to 6.6.3p2, "A return statement with a braced-init-list initializes the object or reference to be returned from the function by copy-list-initialization (8.5.4) from the specified initializer-list.". Even though it is copy-list-initialization, that doesn't mean there is a copy made. The only thing I can see that makes copy-list-initialization special is that it doesn't allow the use of explicit constructors. Otherwise, it is regular list-initialization, and no copy is involved.
– Vaughn Cato
Mar 19 '14 at 13:54
I looked it up. According to 6.6.3p2, "A return statement with a braced-init-list initializes the object or reference to be returned from the function by copy-list-initialization (8.5.4) from the specified initializer-list.". Even though it is copy-list-initialization, that doesn't mean there is a copy made. The only thing I can see that makes copy-list-initialization special is that it doesn't allow the use of explicit constructors. Otherwise, it is regular list-initialization, and no copy is involved.
– Vaughn Cato
Mar 19 '14 at 13:54
add a comment |
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f22502606%2fwhy-is-stdlock-guard-not-movable%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
Well, you do have
unique_lock. It might just be to make the interface as simple as possible.– ecatmur
Mar 19 '14 at 10:25
1
thanks, I have overlooked unique_lock :-) So I guess this answers my question: No there is no reason. Imo making it movable doesn't really make the interface more complicated but more usable and compatible with modern c++.
– valoh
Mar 19 '14 at 10:47
1
@valoh: If it was movable it would need to have a state where it doesn't hold a the lock. That makes it redundant, since it would offer exactly the same functionality as
unique_lock(though I would argue that it is mostly redundant anyway). Therefore iflock_guardis desired as a seperate class it can't really be movable.– Grizzly
Mar 19 '14 at 13:08