
On Tue, Sep 2, 2014 at 10:13 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 02/09/14 17:34, Roland Bock a écrit :
On 2014-09-02 14:08, Sebastian Redl wrote:
On 02 Sep 2014, at 8:58, Roland Bock <rbock@eudoxos.de> wrote:
On 2014-09-02 03:27, Lorenzo Caminiti wrote:
You could use inheritance. If the condition is true, you inherit from a struct that provides the data member, otherwise you inherit from a struct that does not. Ugly, I know, but it works if inheritance is an option for you.
That’s what I’m doing, but as you say, it is ugly:
template <typename Policy> using proxy_base_t = std::conditional_t< has(Policy::requirements, features::raw_access), proxy_raw_access<proxy_nodot<Policy>>, proxy_nodot<Policy>>;
template <typename Policy> class proxy : public proxy_detail::proxy_base_t<Policy> { … };
Sebastian
Yep, same here :-)
An here https://github.com/boostorg/thread/blob/develop/include/boost/thread/concurr....
Hello all, I was thinking about the problem of disabling data member declarations a bit more. I have a couple of questions on C++14 template variables (these are not Boost related but given I was trying to solve a problem raised by this mail thread I hope you all do not mind if I ask them here instead of say comp.lang.c++). 1. Why is not possible to use enabled_if with template variables? For example, I'd expect this declaration to be ignored by the compiler when B is 0 and the use of n<0> to fail at (b). Instead clang 3.4.2 errors at (a) saying I cannot use enable_if there when B is 0. #include <type_traits> template< bool B > typename std::enable_if<B, bool>::type n = B; // (a) int main ( ) { n<1>; n<0>; // (b) return 0; } 2. Why is not possible to use template variables for data members? For example, this does not compile on clang 3.4.2 saying the member is declared as a template (implying that is illegal). struct x { template< typename T > T m; }; I am sure this is just the way C++14 template variables are supposed to work by spec, but at first glance I do not understand the reason for these "limitations". Thanks a lot! --Lorenzo