================
Comment at: include/mutex:445
@@ -444,3 +444,3 @@
_LIBCPP_INLINE_VISIBILITY
-void call_once(once_flag&, _Callable);
----------------
EricWF wrote:
> This change is being made in order to support non-copyable Callable objects,
> right? I'm not convinced that always adding const is the correct thing to do.
> Without the const the new signature won't accept rvalues as input but adding
> const requires Callable to be const-callable.
>
> Why not provide two signatures? It's not perfect but I think it is better.
> ```
> void call_once(once_flag&, _Callable&); // accepts non-const lvalues.
> void call_once(once_flag&, _Callable const&); // accepts rvalues and const
> lvalues.
> ```
>
> Thoughts?
>
>
I initially considered adding a perfectly forwarding non-variadic version when
rvalue-refs are supported, and the two overloads you suggest above otherwise.
This would add quite a lot of noise (each signature is present thrice). I
guestimated const-ref to be enough, but I will add as many overloads and
workarounds as you deem necessary.
================
Comment at:
test/std/thread/thread.mutex/thread.once/thread.once.callonce/call_once.pass.cpp:160
@@ +159,3 @@
+ // GCC 4.8 complains about the following being private
+public:
+ NonCopyable(const NonCopyable&)
----------------
EricWF wrote:
> That seems like it might indicate a problem. Do you know what is going on
> here? Are you sure you want to work around this?
If you expand the context a bit you will see that I took it from `MoveOnly`
right above, I have not experienced the issue myself.
================
Comment at:
test/std/thread/thread.mutex/thread.once/thread.once.callonce/call_once.pass.cpp:224
@@ -206,1 +223,3 @@
}
+ // check LWG2442: call_once() shouldn't DECAY_COPY()
+ {
----------------
EricWF wrote:
> Could you also add tests for the following:
> 1. We don't copy the function.
> 2. We accept a temporary as a function.
> 3. If given a Function object with `operator()(...) &` and `operator()(...)
> &&` do we call the correct one depending on the value category of the given
> functor?
> Could you also add tests for the following:
> We don't copy the function.
> We accept a temporary as a function.
This is already the case, `NonCopyable()` is the function.
> If given a Function object with operator()(...) & and operator()(...) && do
> we call the correct one depending on the value category of the given functor?
Good idea, will do.
http://reviews.llvm.org/D10191
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits