[v3 PATCH] Implement make_array and to_array from the Fundamentals v2 TS draft

[Jonathan Wakely]

On 07/08/15 09:37 +0100, Jonathan Wakely wrote:
>On 13/07/15 13:55 +0300, Ville Voutilainen wrote:
>>+template <typename _Up>
>>+struct __is_reference_wrapper : false_type
>>+{ };
>
>Please indent the class-head and the body.
>
>>+template <typename _Up>
>>+struct __is_reference_wrapper<reference_wrapper<_Up>> : true_type
>>+{ };
>
>Likewise.
>
>>+template <typename _D = void, typename... _Types>
>>+constexpr auto make_array(_Types&&... __t)
>
>Same here, everything after the 'template<...>' should be indented.
>
>Maybe consider putting a newline after 'auto' too
>
>And the single character name _D makes me nervous again :-)
>
>
>>+  -> array<conditional_t<is_void_v<_D>,
>>+                         common_type_t<_Types...>,
>>+                         _D>,
>>+           sizeof...(_Types)>
>>+{
>>+  static_assert(__or_<
>>+                  __not_<is_void<_D>>,
>>+                  __and_<__not_<__is_reference_wrapper<decay_t<_Types>>>...>>
>>+                ::value,
>>+                "make_array cannot be used without an explicit target type "
>>+                "if any of the types given is a reference_wrapper");
>
>I wonder if that would be more efficient to instantiate written as:
>
> __not_<__and_<is_void<_D>, __or_<__is_reference_wrapper<decay_t<_Types>>...>>>
>
>>+  return {{forward<_Types>(__t)...}};
>>+}
>>+
>>+template <typename _Tp, size_t _N, size_t... _Idx>
>
>_N is a common macro in some C libs, please rename to something like _Nm.
>(_D isn't listed in the docs as a name to avoid, so should be OK).
>
>>diff --git a/libstdc++-v3/testsuite/experimental/array/make_array.cc b/libstdc++-v3/testsuite/experimental/array/make_array.cc
>>new file mode 100644
>>index 0000000..8456c37
>>--- /dev/null
>>+++ b/libstdc++-v3/testsuite/experimental/array/make_array.cc
>>@@ -0,0 +1,47 @@
>>+// { dg-options "-std=gnu++14" }
>>+// { dg-do run }
>
>Does this need to be dg-do run? It doesn't seem to run anything
>interesting so could be dg-do compile.


P.S. I should have said it's OK for trunk with those changes.

Up to you if you want to change the __or_<> condition or not, I didn't
do a proper analysis of which might perform better. Also up to you if
you want to change _D to stop me being nervous.