| Message ID | 20140601223536.GR6953@redhat.com |
|---|---|
| State | New |
| Headers | show |
2014-06-02 0:35 GMT+02:00 Jonathan Wakely <jwakely@redhat.com>: > 2014-06-01 Jonathan Wakely <jwakely@redhat.com> > > * include/bits/uses_allocator.h (__uses_allocator_helper): Simplify. > (__uses_allocator_arg): Remove unused type. > (__uses_alloc0): Turn into a trivial type. > (__uses_alloc): Add missing template parameter in primary template. > (__uses_alloc_impl): Rename to __uses_alloc_t. Some of the changes remove the explicit access-specifier (public) from base classes, such as : public false_type => : false_type In the affected examples this does not introduce a change of meaning (because the classes are declared as structs), but my understanding had been in the past that base class access specifiers should always been provided in gcc code bases to make the code robust against potential refactoring. Is this simply an incorrect understanding of mine that is not based by the gcc coding styles? I thought that Paolo taught me the "explicit-access-style", but I might err. - Daniel
On 02/06/14 00:46 +0200, Daniel Krügler wrote: >Some of the changes remove the explicit access-specifier (public) from >base classes, such as > >: public false_type >=> >: false_type > >In the affected examples this does not introduce a change of meaning >(because the classes are declared as structs), but my understanding >had been in the past that base class access specifiers should always >been provided in gcc code bases to make the code robust against >potential refactoring. > >Is this simply an incorrect understanding of mine that is not based by >the gcc coding styles? I thought that Paolo taught me the >"explicit-access-style", but I might err. I consider them to be redundant clutter, but I didn't realise we had such a rule, so I'm happy to put the access-specifiers back.
2014-06-02 0:50 GMT+02:00 Jonathan Wakely <jwakely@redhat.com>: > On 02/06/14 00:46 +0200, Daniel Krügler wrote: >> >> Some of the changes remove the explicit access-specifier (public) from >> base classes, such as >> >> : public false_type >> => >> : false_type >> >> In the affected examples this does not introduce a change of meaning >> (because the classes are declared as structs), but my understanding >> had been in the past that base class access specifiers should always >> been provided in gcc code bases to make the code robust against >> potential refactoring. >> >> Is this simply an incorrect understanding of mine that is not based by >> the gcc coding styles? I thought that Paolo taught me the >> "explicit-access-style", but I might err. > > I consider them to be redundant clutter, but I didn't realise we had > such a rule, so I'm happy to put the access-specifiers back. My formulation was intentionally tentative, because I never searched for that coding rule. Maybe Paolo could help to clarify. - Daniel
Hi, On 06/02/2014 12:52 AM, Daniel Krügler wrote: > My formulation was intentionally tentative, because I never searched > for that coding rule. Maybe Paolo could help to clarify. As far as I remember, we never explicitly discussed that coding rule, it's largely an historical accident. Thus I would not object to not using it (as long as we are consistent...) Paolo.
commit da76587f882eb9656b164b3ad25091fe41ef60ad
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Sun Jun 1 22:33:52 2014 +0100
* include/bits/uses_allocator.h (__uses_allocator_helper): Simplify.
(__uses_allocator_arg): Remove unused type.
(__uses_alloc0): Turn into a trivial type.
(__uses_alloc): Add missing template parameter in primary template.
(__uses_alloc_impl): Rename to __uses_alloc_t.
diff --git a/libstdc++-v3/include/bits/uses_allocator.h b/libstdc++-v3/include/bits/uses_allocator.h
index 10131c0..7281508 100644
--- a/libstdc++-v3/include/bits/uses_allocator.h
+++ b/libstdc++-v3/include/bits/uses_allocator.h
@@ -45,35 +45,33 @@ _GLIBCXX_HAS_NESTED_TYPE(allocator_type)
template<typename _Tp, typename _Alloc,
bool = __has_allocator_type<_Tp>::value>
struct __uses_allocator_helper
- : public false_type { };
+ : false_type { };
template<typename _Tp, typename _Alloc>
struct __uses_allocator_helper<_Tp, _Alloc, true>
- : public integral_constant<bool, is_convertible<_Alloc,
- typename _Tp::allocator_type>::value>
+ : is_convertible<_Alloc, typename _Tp::allocator_type>::type
{ };
/// [allocator.uses.trait]
template<typename _Tp, typename _Alloc>
struct uses_allocator
- : public integral_constant<bool,
- __uses_allocator_helper<_Tp, _Alloc>::value>
+ : __uses_allocator_helper<_Tp, _Alloc>::type
{ };
- template<typename _Tp, typename _Alloc, typename... _Args>
- struct __uses_allocator_arg
- : is_constructible<_Tp, _Alloc, _Args...>
- { static_assert( uses_allocator<_Tp, _Alloc>::value, "uses allocator" ); };
-
struct __uses_alloc_base { };
+
struct __uses_alloc0 : __uses_alloc_base
- { struct _Anything { _Anything(...) { } } _M_a; };
+ {
+ struct _Sink { void operator=(const void*) { } } _M_a;
+ };
+
template<typename _Alloc>
struct __uses_alloc1 : __uses_alloc_base { const _Alloc* _M_a; };
+
template<typename _Alloc>
struct __uses_alloc2 : __uses_alloc_base { const _Alloc* _M_a; };
- template<bool, typename _Alloc, typename... _Args>
+ template<bool, typename _Tp, typename _Alloc, typename... _Args>
struct __uses_alloc;
template<typename _Tp, typename _Alloc, typename... _Args>
@@ -89,15 +87,14 @@ _GLIBCXX_HAS_NESTED_TYPE(allocator_type)
: __uses_alloc0 { };
template<typename _Tp, typename _Alloc, typename... _Args>
- struct __uses_alloc_impl
- : __uses_alloc<uses_allocator<_Tp, _Alloc>::value, _Tp, _Alloc, _Args...>
- { };
+ using __uses_alloc_t =
+ __uses_alloc<uses_allocator<_Tp, _Alloc>::value, _Tp, _Alloc, _Args...>;
template<typename _Tp, typename _Alloc, typename... _Args>
- __uses_alloc_impl<_Tp, _Alloc, _Args...>
+ inline __uses_alloc_t<_Tp, _Alloc, _Args...>
__use_alloc(const _Alloc& __a)
{
- __uses_alloc_impl<_Tp, _Alloc, _Args...> __ret;
+ __uses_alloc_t<_Tp, _Alloc, _Args...> __ret;
__ret._M_a = &__a;
return __ret;
}