> Why not just implement `shared_mutex` in terms of `shared_timed_mutex`
> instead of factoring out common functionality?
I'd rather do it the other way, since `shared_timed_mutex` is a superset of the
functionality of `shared_mutex`. But I can't, due to ABI concerns.
================
Comment at: include/shared_mutex:175
@@ +174,3 @@
+
+#if _LIBCPP_STD_VER > 14
+class _LIBCPP_TYPE_VIS shared_mutex
----------------
EricWF wrote:
> Why > 14 and not >= 17? I don't have a preference, just a question.
Because we don't know that the next version of the standard will be "17". It
could slip to 2018 (say). All you know is that it is post-c++14. FWIW, if you
specify `-std=c++1z` in clang, you get a `_LIBCPP_STD_VER` that is "15".
================
Comment at: include/shared_mutex:196
@@ +195,3 @@
+
+// typedef __shared_mutex_base::native_handle_type native_handle_type;
+// _LIBCPP_INLINE_VISIBILITY native_handle_type native_handle() { return
__base::unlock_shared(); }
----------------
EricWF wrote:
> Why are these commented out/not getting committed?
In the standard, they are optional.
http://reviews.llvm.org/D10480
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
