Re: functional and type_traits cleanup
On 04/06/2013 10:43 PM, Jonathan Wakely wrote:
That wouldn't hurt, but I agree it shouldn't prevent the patch going
in. François, please go ahead and commit it, thanks.
Attached patch applied then. Not exactly the one submitted the 2nd time
because I hadn't fix dg-error line numbers at that time.
2013-04-07 François Dumont
* include/std/functional (_Derives_from_unary_function): Remove.
(_Derives_from_binary_function): Remove.
* include/std/type_traits (__sfinae_types): Remove.
(__is_assignable_helper): Adapt.
(__is_convertible_helper): Adapt.
(_GLIBCXX_HAS_NESTED_TYPE): Adapt.
Remove several explicit instantiations of integral_constant.
* testsuite/20_util/reference_wrapper/typedefs-3.cc: Adapt.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Adapt dg-error line number.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/declval/requirements/1_neg.cc: Likewise.
* testsuite/20_util/bind/ref_neg.cc: Likewise.
François
Index: include/std/functional
===
--- include/std/functional (revision 197550)
+++ include/std/functional (working copy)
@@ -185,38 +185,6 @@
: _Weak_result_type_impl::type>
{ };
- /// Determines if the type _Tp derives from unary_function.
- template
-struct _Derives_from_unary_function : __sfinae_types
-{
-private:
- template
- static __one __test(const volatile unary_function<_T1, _Res>*);
-
- // It's tempting to change "..." to const volatile void*, but
- // that fails when _Tp is a function type.
- static __two __test(...);
-
-public:
- static const bool value = sizeof(__test((_Tp*)0)) == 1;
-};
-
- /// Determines if the type _Tp derives from binary_function.
- template
-struct _Derives_from_binary_function : __sfinae_types
-{
-private:
- template
- static __one __test(const volatile binary_function<_T1, _T2, _Res>*);
-
- // It's tempting to change "..." to const volatile void*, but
- // that fails when _Tp is a function type.
- static __two __test(...);
-
-public:
- static const bool value = sizeof(__test((_Tp*)0)) == 1;
-};
-
/**
* Invoke a function object, which may be either a member pointer or a
* function object. The first parameter will tell which.
Index: include/std/type_traits
===
--- include/std/type_traits (revision 197550)
+++ include/std/type_traits (working copy)
@@ -127,12 +127,6 @@
: public integral_constant
{ };
- struct __sfinae_types
- {
-typedef char __one;
-typedef struct { char __arr[2]; } __two;
- };
-
// For several sfinae-friendly trait implementations we transport both the
// result information (as the member type) and the failure information (no
// member type). This is very similar to std::enable_if, but we cannot use
@@ -161,8 +155,7 @@
/// is_void
template
struct is_void
-: public integral_constant::type>::value)>
+: public __is_void_helper::type>::type
{ };
template
@@ -244,8 +237,7 @@
/// is_integral
template
struct is_integral
-: public integral_constant::type>::value)>
+: public __is_integral_helper::type>::type
{ };
template
@@ -273,8 +265,7 @@
/// is_floating_point
template
struct is_floating_point
-: public integral_constant::type>::value)>
+: public __is_floating_point_helper::type>::type
{ };
/// is_array
@@ -301,8 +292,7 @@
/// is_pointer
template
struct is_pointer
-: public integral_constant::type>::value)>
+: public __is_pointer_helper::type>::type
{ };
/// is_lvalue_reference
@@ -337,8 +327,8 @@
/// is_member_object_pointer
template
struct is_member_object_pointer
-: public integral_constant::type>::value)>
+: public __is_member_object_pointer_helper<
+typename remove_cv<_Tp>::type>::type
{ };
template
@@ -352,8 +342,8 @@
/// is_member_function_pointer
template
struct is_member_function_pointer
-: public integral_constant::type>::value)>
+: public __is_member_function_pointer_helper<
+typename remove_cv<_Tp>::type>::type
{ };
/// is_enum
@@ -422,8 +412,7 @@
// __is_nullptr_t (extension).
template
struct __is_nullptr_t
-: public integral_constant::type>::value)>
+: public __is_nullptr_t_helper::type>::type
{ };
// Composite type categories.
@@ -480,8 +469,7 @@
/// is_member_pointer
template
struct is_member_pointer
-: public integral_constant::type>::value)>
+: public __is_member_pointer_helper::type>::type
{ };
// Type properties.
@@ -567,7 +555,7 @@
/// is_signed
template
struct is_signed
-: public integral_constant::value>
+: public __is_signed_helper<_Tp>::type
{ };
/// is_unsigned
@@
Re: functional and type_traits cleanup
Hi, On 04/06/2013 10:43 PM, Jonathan Wakely wrote: My response was more like a general comment: My apprehension is that I after these changes not all predicate type traits do satisfy the Library requirement anymore that they still derive from std::integral_constant. But I have not checked that individually. They should all do, because the types that used to define a 'value' member all now define a 'type' as a typedef for either true_type or false_type. When I saw the patch I had the same concern, but indeed the nice simplification seems worth the less transparent conformance. Personally, I would be much less nervous if for too we could have typedef checks for each and every trait (like we do for the ). By the way, we should also check that the value_type operator is there... Thanks! Paolo.
Re: functional and type_traits cleanup
On 6 April 2013 21:03, Daniel Krügler wrote: > 2013/4/6 Jonathan Wakely >> > >> > But the version with the default template parameter is fine and more >> > consistent with the other helpers implementation so, adopted! Here is an >> > other version of the patch for validation. >> > >> > Daniel, I agree that inheritance with integral_constant is not as >> > obvious as before but it is still there and it is just what the compiler >> > need. >> >> I assume Daniel's reply was an HTML mail and didn't make it to the >> list, was there an objection to the change or a general comment? > > Yes, I got a reply that my response was not accepted due to html > content. I hope this one gets into it. It did: http://gcc.gnu.org/ml/libstdc++/2013-04/msg00031.html > My response was more like a > general comment: My apprehension is that I after these changes not all > predicate type traits do satisfy the Library requirement anymore that > they still derive from std::integral_constant. But I have not checked > that individually. They should all do, because the types that used to define a 'value' member all now define a 'type' as a typedef for either true_type or false_type. > Thanks Jonathan. The text above more or less reflects the content of > my previous comment. I think I have no formal objection to the > changes, but after they have been applied I would like to do a more > rigorous test of the inheritance requirement. That wouldn't hurt, but I agree it shouldn't prevent the patch going in. François, please go ahead and commit it, thanks.
Re: functional and type_traits cleanup
2013/4/6 Jonathan Wakely > > > But the version with the default template parameter is fine and more > > consistent with the other helpers implementation so, adopted! Here is an > > other version of the patch for validation. > > > > Daniel, I agree that inheritance with integral_constant is not as > > obvious as before but it is still there and it is just what the compiler > > need. > > I assume Daniel's reply was an HTML mail and didn't make it to the > list, was there an objection to the change or a general comment? Yes, I got a reply that my response was not accepted due to html content. I hope this one gets into it. My response was more like a general comment: My apprehension is that I after these changes not all predicate type traits do satisfy the Library requirement anymore that they still derive from std::integral_constant. But I have not checked that individually. > > I even hope that it also simplified a (very) little bit the job for > > the compiler. > > I don't know if the compiler's job is easier or not, but I think with > your change the template instantiation depth is increased by one, with > your change we get false_type instantiated by the instantiation of > is_convertible, rather than being done after it using its value > member. > > > Ok to commit ? > > I'd like to hear Daniel's comment first, but if we don't hear from him > please commit it in 24 hours. Thanks. Thanks Jonathan. The text above more or less reflects the content of my previous comment. I think I have no formal objection to the changes, but after they have been applied I would like to do a more rigorous test of the inheritance requirement. - Daniel
Re: functional and type_traits cleanup
On 5 April 2013 21:12, François Dumont wrote:
>
> In fact my first attempt was a very simple one:
>
> template
> class __is_convertible_helper<_From, _To, false>
> {
> template
> static true_type
> __test(_To1);
>
> template
> static false_type
> __test(...);
>
> public:
> typedef decltype(__test<_To>(std::declval<_From>())) type;
> };
>
> But some tests failed like:
> In file included from
> /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/move.h:57:0,
> from
> /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:59,
> from
> /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/utility:70,
> from
> /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:38,
> from
> /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/functional:55,
> from
> /home/fdt/dev/gcc/src/libstdc++-v3/testsuite/20_util/bind/38889.cc:23:
> /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:
> In instantiation of 'struct std::__is_convertible_helper std::tuple >&, std::_Placeholder<1>, false>':
> /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1321:12:
> required from 'struct std::is_convertible std::tuple >&, std::_Placeholder<1> >'
> /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:111:12:
> required from 'struct std::__and_ std::tuple >&, std::_Placeholder<1> > >'
> /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:400:40:
> required from 'struct std::_Bind))(int)>'
> /home/fdt/dev/gcc/src/libstdc++-v3/testsuite/20_util/bind/38889.cc:28:41:
> required from here
> /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1316:30:
> error: 'std::_Placeholder<1>' is an inaccessible base of
> 'std::tuple >'
>typedef decltype(__test<_To>(std::declval<_From>())) type;
> ^
> /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1309:2:
> error: initializing argument 1 of 'static std::true_type
> std::__is_convertible_helper<_From, _To, false>::__test(_To1) [with _To1 =
> std::_Placeholder<1>; _From = const std::tuple >&; _To
> = std::_Placeholder<1>; std::true_type = std::integral_constant true>]'
> __test(_To1);
> ^
>
> From my point of view this is an other example of use case for which gcc is
> not SFINAE friendly enough, no ?
No, I don't think this is a GCC problem. In this code the
derived-to-base conversion does not happen in the context of the
function template argument deduction but happens afterwards, so the
access failure is not part of argument deduction and so is a hard
error not a substitution failure.
> But the version with the default template parameter is fine and more
> consistent with the other helpers implementation so, adopted! Here is an
> other version of the patch for validation.
>
> Daniel, I agree that inheritance with integral_constant is not as
> obvious as before but it is still there and it is just what the compiler
> need.
I assume Daniel's reply was an HTML mail and didn't make it to the
list, was there an objection to the change or a general comment?
> I even hope that it also simplified a (very) little bit the job for
> the compiler.
I don't know if the compiler's job is easier or not, but I think with
your change the template instantiation depth is increased by one, with
your change we get false_type instantiated by the instantiation of
is_convertible, rather than being done after it using its value
member.
> Ok to commit ?
I'd like to hear Daniel's comment first, but if we don't hear from him
please commit it in 24 hours. Thanks.
Re: functional and type_traits cleanup
On 04/05/2013 12:20 AM, Jonathan Wakely wrote:
On 4 April 2013 21:16, François Dumont wrote:
I think this is mostly very good, thanks for cleaning it up. The
indentiation of the closing brace for __is_assignable_helper looks
wrong. Is there a reason that __is_assignable_helper::__test uses a
default template argument but __is_convertible_helper::__test uses
decltype(expr, type) in the function return type? I think the
decltype(__test_aux<_Tp1>(...)) expression would work as a default
template argument too, which I find easier to read because it doesn't
clutter up the return type.
In fact my first attempt was a very simple one:
template
class __is_convertible_helper<_From, _To, false>
{
template
static true_type
__test(_To1);
template
static false_type
__test(...);
public:
typedef decltype(__test<_To>(std::declval<_From>())) type;
};
But some tests failed like:
In file included from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/move.h:57:0,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:59,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/utility:70,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:38,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/functional:55,
from
/home/fdt/dev/gcc/src/libstdc++-v3/testsuite/20_util/bind/38889.cc:23:
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:
In instantiation of 'struct std::__is_convertible_helperstd::tuple >&, std::_Placeholder<1>, false>':
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1321:12:
required from 'struct std::is_convertiblestd::tuple >&, std::_Placeholder<1> >'
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:111:12:
required from 'struct std::__and_std::tuple >&, std::_Placeholder<1> > >'
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:400:40:
required from 'struct std::_Bind))(int)>'
/home/fdt/dev/gcc/src/libstdc++-v3/testsuite/20_util/bind/38889.cc:28:41: required
from here
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1316:30:
error: 'std::_Placeholder<1>' is an inaccessible base of
'std::tuple >'
typedef decltype(__test<_To>(std::declval<_From>())) type;
^
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1309:2:
error: initializing argument 1 of 'static std::true_type
std::__is_convertible_helper<_From, _To, false>::__test(_To1) [with _To1
= std::_Placeholder<1>; _From = const std::tuple
>&; _To = std::_Placeholder<1>; std::true_type =
std::integral_constant]'
__test(_To1);
^
From my point of view this is an other example of use case for which
gcc is not SFINAE friendly enough, no ?
But the version with the default template parameter is fine and more
consistent with the other helpers implementation so, adopted! Here is an
other version of the patch for validation.
Daniel, I agree that inheritance with integral_constant is not as
obvious as before but it is still there and it is just what the compiler
need. I even hope that it also simplified a (very) little bit the job
for the compiler.
Ok to commit ?
François
Index: include/std/functional
===
--- include/std/functional (revision 197307)
+++ include/std/functional (working copy)
@@ -185,38 +185,6 @@
: _Weak_result_type_impl::type>
{ };
- /// Determines if the type _Tp derives from unary_function.
- template
-struct _Derives_from_unary_function : __sfinae_types
-{
-private:
- template
- static __one __test(const volatile unary_function<_T1, _Res>*);
-
- // It's tempting to change "..." to const volatile void*, but
- // that fails when _Tp is a function type.
- static __two __test(...);
-
-public:
- static const bool value = sizeof(__test((_Tp*)0)) == 1;
-};
-
- /// Determines if the type _Tp derives from binary_function.
- template
-struct _Derives_from_binary_function : __sfinae_types
-{
-private:
- template
- static __one __test(const volatile binary_function<_T1, _T2, _Res>*);
-
- // It's tempting to change "..." to const volatile void*, but
- // that fails when _Tp is a function type.
- static __two __test(...);
-
-public:
- static const bool value = sizeof(__test((_Tp*)0)) == 1;
-};
-
/**
* Invoke a function object, which may be either a member pointer or a
* function object. The first parameter will tell which.
Index: include/std/type_traits
===
--- include/std/type_t
