2016-09-05 1 views
2

Quelles sont les règles pour l'instanciation de gabarit lorsque nous transmettons une classe (multi) dérivée à une fonction gabarit attendant une classe de base? Par exemple:instanciation de gabarit avec héritage de gabarit multiple

#include <iostream> 

template <int x> 
struct C {}; 

struct D : C<0>, C<1> {}; 

template <int x> 
void f (const C<x> &y) { std::cout << x << "\n"; } 

int main() 
{ 
    f (D()); 
} 

MSVC 2015 0 impressions, clang 3,8 à 1 et gcc 6.2 donne erreur du compilateur (Demo). Et même si vous SFINAE emporter tous sauf un des surcharges, le résultat sera toujours différent:

#include <iostream> 

template <int x> struct C {}; 

template<> 
struct C<0> { using type = void; }; 

struct D : C<0>, C<1> {}; 

template <int x, typename = typename C<x>::type> 
void f (const C<x> &y) { std::cout << x << "\n"; } 

int main() 
{ 
    f (D()); 
} 

Maintenant, il compile uniquement avec MSVC, et si vous échangez C<0> et C<1> seulement clang va compiler. Le problème est que MSVC essaye seulement d'instancier la première base, les erreurs d'impression clang-last et gcc trop tôt. Quel compilateur a raison?

+0

me semble comme s'ils ont tous tort. Ne devrait-il pas être un appel de fonction ambigu? –

+0

* "MSVC imprime 0, clang - 1 et gcc donne une erreur de compilation." *, Quel MSVC, quel gcc et quel clang? –

+0

@PiotrSkotnicki Les numéros de version ajoutés, mais tous se comportent de la même manière –

Répondre

1

gcc 5.4:

/tmp/gcc-explorer-compiler11685-58-1h67lnf/example.cpp: In function 'int main()': 
13 : error: no matching function for call to 'f(D)' 
f (D()); 
^ 
9 : note: candidate: template<int x> void f(const C<x>&) 
void f (const C<x> &y) { std::cout << x << "\n"; } 
^ 
9 : note: template argument deduction/substitution failed: 
13 : note: 'const C<x>' is an ambiguous base class of 'D' 
f (D()); 
^ 
Compilation failed 

Ce qui me semble être le bon résultat, puisque C < 0> et C < 1> sont également spécialisés.

Même résultat pour gcc 6.2

clang 3.8.1 compile, qui à mon avis est un bug du compilateur.

mise à jour:

Je ne sais pas le cas d'utilisation réelle mais je me demande si cela pourrait fonctionner pour vous:

#include <utility> 
#include <iostream> 

template<class T> 
struct has_type 
{ 
    template<class U> static auto test(U*) -> decltype(typename U::type{}, std::true_type()); 
    static auto test(...) -> decltype(std::false_type()); 
    using type = decltype(test((T*)0)); 
    static const auto value = type::value; 
}; 

template <int x> struct C {}; 

template<> 
struct C<0> { using type = int; }; 

template<int...xs> 
struct enumerates_C : C<xs>... 
{ 
}; 

struct D : enumerates_C<0, 1> {}; 

template<int x, std::enable_if_t<has_type<C<x>>::value>* = nullptr> 
void f_impl(const C<x>& y) 
{ 
    std::cout << x << "\n"; 
} 

template<int x, std::enable_if_t<not has_type<C<x>>::value>* = nullptr> 
void f_impl(const C<x>& y) 
{ 
    // do nothing 
} 

template <int...xs> 
void f (const enumerates_C<xs...> &y) 
{ 
    using expand = int[]; 
    void(expand { 0, 
     (f_impl(static_cast<C<xs> const &>(y)),0)... 
    }); 
} 

int main() 
{ 
    f (D()); 
} 

résultat attendu (testé sur clang pomme):

0 
+0

Dans le premier exemple - oui, je pense qu'il devrait être ambigu, dans la seconde - non, seule la surcharge pour C <0> doit être activée. –

+0

"* Seule la surcharge de C doit être activée *" Qu'est-ce qui vous fait penser que le compilateur devrait essayer d'utiliser chaque "x" possible? la première déduction a lieu, ce qui échoue –

+0

@PiotrSkotnicki Je pose cette question pour savoir comment cela doit être fait. Si vous écrivez manuellement ces fonctions, alors il fonctionnera comme prévu: https://gist.github.com/telishev/a52483833ae6850df69e1e6953f6b277 –