Comment supprimer la duplication de code entre des fonctions membres const et non const similaires?

Supposons que je dispose des éléments suivants class Xoù je souhaite retourner l'accès à un membre interne:

class Z
{
    // details
};

class X
{
    std::vector<Z> vecZ;

public:
    Z& Z(size_t index)
    {
        // massive amounts of code for validating index

        Z& ret = vecZ[index];

        // even more code for determining that the Z instance
        // at index is *exactly* the right sort of Z (a process
        // which involves calculating leap years in which
        // religious holidays fall on Tuesdays for
        // the next thousand years or so)

        return ret;
    }
    const Z& Z(size_t index) const
    {
        // identical to non-const X::Z(), except printed in
        // a lighter shade of gray since
        // we're running low on toner by this point
    }
};

Les deux fonctions membres X::Z()et X::Z() constont un code identique à l'intérieur des accolades. Il s'agit de code en double et peut entraîner des problèmes de maintenance pour les fonctions longues avec une logique complexe .

Existe-t-il un moyen d'éviter cette duplication de code?

Pour une explication détaillée, veuillez consulter la rubrique «Éviter la duplication dans les fonctions constnon constmembres», à la p. 23, dans le point 3 «Utiliser constautant que possible», dans Effective C ++ , 3ème éd par Scott Meyers, ISBN-13: 9780321334879.

Voici la solution de Meyers (simplifiée):

struct C {
  const char & get() const {
    return c;
  }
  char & get() {
    return const_cast<char &>(static_cast<const C &>(*this).get());
  }
  char c;
};

Les deux transtypages et l'appel de fonction peuvent être laids mais c'est correct. Meyers a une explication approfondie pourquoi.

Oui, il est possible d'éviter la duplication de code. Vous devez utiliser la fonction membre const pour avoir la logique et demander à la fonction membre non const d'appeler la fonction membre const et de recréer la valeur de retour en une référence non const (ou un pointeur si les fonctions renvoient un pointeur):

class X
{
   std::vector<Z> vecZ;

public:
   const Z& z(size_t index) const
   {
      // same really-really-really long access 
      // and checking code as in OP
      // ...
      return vecZ[index];
   }

   Z& z(size_t index)
   {
      // One line. One ugly, ugly line - but just one line!
      return const_cast<Z&>( static_cast<const X&>(*this).z(index) );
   }

 #if 0 // A slightly less-ugly version
   Z& Z(size_t index)
   {
      // Two lines -- one cast. This is slightly less ugly but takes an extra line.
      const X& constMe = *this;
      return const_cast<Z&>( constMe.z(index) );
   }
 #endif
};

Remarque: il est important que vous ne mettez pas la logique dans la fonction non-const et que la fonction const appelle la fonction non-const - cela peut entraîner un comportement non défini. La raison en est qu'une instance de classe constante est convertie en instance non constante. La fonction membre non const peut modifier accidentellement la classe, ce que les états standard C ++ entraîneront un comportement non défini.

C ++ 17 a mis à jour la meilleure réponse à cette question:

T const & f() const {
    return something_complicated();
}
T & f() {
    return const_cast<T &>(std::as_const(*this).f());
}

Cela présente les avantages suivants:

• Est évident ce qui se passe
• A une surcharge minimale de code - il tient dans une seule ligne
• Est difficile de se tromper (ne peut être rejeté que volatilepar accident, mais volatileest un qualificatif rare)

Si vous souhaitez suivre la voie de déduction complète, cela peut être accompli en ayant une fonction d'aide

template<typename T>
constexpr T & as_mutable(T const & value) noexcept {
    return const_cast<T &>(value);
}
template<typename T>
constexpr T * as_mutable(T const * value) noexcept {
    return const_cast<T *>(value);
}
template<typename T>
constexpr T * as_mutable(T * value) noexcept {
    return value;
}
template<typename T>
void as_mutable(T const &&) = delete;

Maintenant, vous ne pouvez même plus gâcher volatileet l'utilisation ressemble à

decltype(auto) f() const {
    return something_complicated();
}
decltype(auto) f() {
    return as_mutable(std::as_const(*this).f());
}

Je pense que la solution de Scott Meyers peut être améliorée en C ++ 11 en utilisant une fonction d'assistance tempate. Cela rend l'intention beaucoup plus évidente et peut être réutilisé pour de nombreux autres getters.

template <typename T>
struct NonConst {typedef T type;};
template <typename T>
struct NonConst<T const> {typedef T type;}; //by value
template <typename T>
struct NonConst<T const&> {typedef T& type;}; //by reference
template <typename T>
struct NonConst<T const*> {typedef T* type;}; //by pointer
template <typename T>
struct NonConst<T const&&> {typedef T&& type;}; //by rvalue-reference

template<typename TConstReturn, class TObj, typename... TArgs>
typename NonConst<TConstReturn>::type likeConstVersion(
   TObj const* obj,
   TConstReturn (TObj::* memFun)(TArgs...) const,
   TArgs&&... args) {
      return const_cast<typename NonConst<TConstReturn>::type>(
         (obj->*memFun)(std::forward<TArgs>(args)...));
}

Cette fonction d'assistance peut être utilisée de la manière suivante.

struct T {
   int arr[100];

   int const& getElement(size_t i) const{
      return arr[i];
   }

   int& getElement(size_t i) {
      return likeConstVersion(this, &T::getElement, i);
   }
};

Le premier argument est toujours le pointeur this. Le second est le pointeur sur la fonction membre à appeler. Après cela, une quantité arbitraire d'arguments supplémentaires peut être transmise afin qu'ils puissent être transmis à la fonction. Cela nécessite C ++ 11 en raison des modèles variadic.

Un peu plus verbeux que Meyers, mais je pourrais faire ceci:

class X {

    private:

    // This method MUST NOT be called except from boilerplate accessors.
    Z &_getZ(size_t index) const {
        return something;
    }

    // boilerplate accessors
    public:
    Z &getZ(size_t index)             { return _getZ(index); }
    const Z &getZ(size_t index) const { return _getZ(index); }
};

La méthode private a la propriété indésirable de renvoyer un Z & non const pour une instance const, c'est pourquoi elle est privée. Les méthodes privées peuvent casser les invariants de l'interface externe (dans ce cas, l'invariant souhaité est "un objet const ne peut pas être modifié via des références obtenues via lui vers les objets qu'il a-a").

Notez que les commentaires font partie du modèle - l'interface de _getZ spécifie qu'il n'est jamais valide de l'appeler (à part les accesseurs, évidemment): il n'y a aucun avantage concevable à le faire de toute façon, car c'est un caractère de plus à taper et ne le fera pas entraîner un code plus petit ou plus rapide. Appeler la méthode équivaut à appeler l'un des accesseurs avec un const_cast, et vous ne voudriez pas le faire non plus. Si vous craignez de rendre les erreurs évidentes (et c'est un objectif équitable), appelez-le const_cast_getZ au lieu de _getZ.

Soit dit en passant, j'apprécie la solution de Meyers. Je n'ai aucune objection philosophique à lui. Personnellement, cependant, je préfère un tout petit peu de répétition contrôlée et une méthode privée qui ne doit être appelée que dans certaines circonstances étroitement contrôlées, plutôt qu'une méthode qui ressemble à du bruit de ligne. Choisissez votre poison et respectez-le.

[Edit: Kevin a souligné à juste titre que _getZ pourrait vouloir appeler une autre méthode (disons generateZ) qui est const-spécialisée de la même manière que getZ. Dans ce cas, _getZ verrait un const Z & et devrait le const_cast avant de revenir. C'est toujours sûr, car l'accessoire passe-partout règle tout, mais il n'est pas extrêmement évident qu'il soit sûr. De plus, si vous faites cela et que vous modifiez ensuite generateZ pour toujours retourner const, vous devez également changer getZ pour toujours retourner const, mais le compilateur ne vous le dira pas.

Ce dernier point sur le compilateur est également vrai pour le modèle recommandé par Meyers, mais le premier point sur un const_cast non évident ne l'est pas. Donc, tout compte fait, je pense que si _getZ s'avère avoir besoin d'un const_cast pour sa valeur de retour, alors ce modèle perd beaucoup de sa valeur par rapport à Meyers. Puisqu'il souffre également d'inconvénients par rapport à Meyers, je pense que je passerais au sien dans cette situation. La refactorisation de l'un à l'autre est facile - elle n'affecte aucun autre code valide de la classe, car seul le code non valide et le passe-partout appellent _getZ.]

Belle question et belles réponses. J'ai une autre solution, qui n'utilise aucun casting:

class X {

private:

    std::vector<Z> v;

    template<typename InstanceType>
    static auto get(InstanceType& instance, std::size_t i) -> decltype(instance.get(i)) {
        // massive amounts of code for validating index
        // the instance variable has to be used to access class members
        return instance.v[i];
    }

public:

    const Z& get(std::size_t i) const {
        return get(*this, i);
    }

    Z& get(std::size_t i) {
        return get(*this, i);
    }

};

Cependant, il a la laideur d'exiger un membre statique et la nécessité d'utiliser la instancevariable à l'intérieur.

Je n'ai pas considéré toutes les implications (négatives) possibles de cette solution. Faites-le moi savoir s'il y en a.

Vous pouvez également résoudre ce problème avec des modèles. Cette solution est légèrement laide (mais la laideur est cachée dans le fichier .cpp) mais elle permet au compilateur de vérifier la constance, et pas de duplication de code.

Fichier .h:

#include <vector>

class Z
{
    // details
};

class X
{
    std::vector<Z> vecZ;

public:
    const std::vector<Z>& GetVector() const { return vecZ; }
    std::vector<Z>& GetVector() { return vecZ; }

    Z& GetZ( size_t index );
    const Z& GetZ( size_t index ) const;
};

Fichier .cpp:

#include "constnonconst.h"

template< class ParentPtr, class Child >
Child& GetZImpl( ParentPtr parent, size_t index )
{
    // ... massive amounts of code ...

    // Note you may only use methods of X here that are
    // available in both const and non-const varieties.

    Child& ret = parent->GetVector()[index];

    // ... even more code ...

    return ret;
}

Z& X::GetZ( size_t index )
{
    return GetZImpl< X*, Z >( this, index );
}

const Z& X::GetZ( size_t index ) const
{
    return GetZImpl< const X*, const Z >( this, index );
}

Le principal inconvénient que je peux voir est que parce que toute l'implémentation complexe de la méthode est dans une fonction globale, vous devez soit saisir les membres de X en utilisant des méthodes publiques comme GetVector () ci-dessus (dont il doit toujours y avoir un version const et non const) ou vous pourriez faire de cette fonction un ami. Mais je n'aime pas les amis.

[Modifier: suppression de l'inclusion inutile de cstdio ajoutée pendant le test.]

Que diriez-vous de déplacer la logique dans une méthode privée, et de ne faire que les choses "obtenir la référence et retourner" à l'intérieur des getters? En fait, je serais assez confus au sujet des transtypages statiques et const à l'intérieur d'une simple fonction getter, et je considérerais cela laid, sauf dans des circonstances extrêmement rares!

Est-ce de la triche d'utiliser le préprocesseur?

struct A {

    #define GETTER_CORE_CODE       \
    /* line 1 of getter code */    \
    /* line 2 of getter code */    \
    /* .....etc............. */    \
    /* line n of getter code */       

    // ^ NOTE: line continuation char '\' on all lines but the last

   B& get() {
        GETTER_CORE_CODE
   }

   const B& get() const {
        GETTER_CORE_CODE
   }

   #undef GETTER_CORE_CODE

};

Ce n'est pas aussi sophistiqué que les modèles ou les transtypages, mais cela rend votre intention ("ces deux fonctions doivent être identiques") assez explicite.

C'est surprenant pour moi qu'il y ait tant de réponses différentes, mais presque toutes reposent sur une magie de modèle lourde. Les modèles sont puissants, mais parfois les macros les battent avec concision. La polyvalence maximale est souvent obtenue en combinant les deux.

J'ai écrit une macro FROM_CONST_OVERLOAD()qui peut être placée dans la fonction non-const pour invoquer la fonction const.

Exemple d'utilisation:

class MyClass
{
private:
    std::vector<std::string> data = {"str", "x"};

public:
    // Works for references
    const std::string& GetRef(std::size_t index) const
    {
        return data[index];
    }

    std::string& GetRef(std::size_t index)
    {
        return FROM_CONST_OVERLOAD( GetRef(index) );
    }


    // Works for pointers
    const std::string* GetPtr(std::size_t index) const
    {
        return &data[index];
    }

    std::string* GetPtr(std::size_t index)
    {
        return FROM_CONST_OVERLOAD( GetPtr(index) );
    }
};

Implémentation simple et réutilisable:

template <typename T>
T& WithoutConst(const T& ref)
{
    return const_cast<T&>(ref);
}

template <typename T>
T* WithoutConst(const T* ptr)
{
    return const_cast<T*>(ptr);
}

template <typename T>
const T* WithConst(T* ptr)
{
    return ptr;
}

#define FROM_CONST_OVERLOAD(FunctionCall) \
  WithoutConst(WithConst(this)->FunctionCall)

Explication:

Comme indiqué dans de nombreuses réponses, le modèle typique pour éviter la duplication de code dans une fonction membre non const est le suivant:

return const_cast<Result&>( static_cast<const MyClass*>(this)->Method(args) );

Une grande partie de ce passe-partout peut être évitée en utilisant l'inférence de type. Tout d'abord, const_castpeut être encapsulé dans WithoutConst(), ce qui infère le type de son argument et supprime le qualificatif const. Deuxièmement, une approche similaire peut être utilisée WithConst()pour qualifier const le thispointeur, ce qui permet d'appeler la méthode const-overloaded.

Le reste est une simple macro qui préfixe l'appel avec le bon qualifié this->et supprime const du résultat. Étant donné que l'expression utilisée dans la macro est presque toujours un simple appel de fonction avec des arguments transmis 1: 1, les inconvénients des macros telles que l'évaluation multiple ne se déclenchent pas. Les points de suspension et __VA_ARGS__peuvent également être utilisés, mais ne devraient pas être nécessaires car des virgules (comme les séparateurs d'arguments) apparaissent entre parenthèses.

Cette approche présente plusieurs avantages:

• Syntaxe minimale et naturelle - il suffit d'envelopper l'appel FROM_CONST_OVERLOAD( )
• Aucune fonction de membre supplémentaire requise
• Compatible avec C ++ 98
• Implémentation simple, pas de métaprogrammation de modèle et aucune dépendance
• Extensible: d' autres relations de const peuvent être ajoutés (comme const_iterator, std::shared_ptr<const T>, etc.). Pour cela, il suffit de surcharger WithoutConst()les types correspondants.

Limitations: cette solution est optimisée pour les scénarios où la surcharge non const fait exactement la même chose que la surcharge const, de sorte que les arguments peuvent être transmis 1: 1. Si votre logique diffère et que vous n'appelez pas la version const via this->Method(args), vous pouvez envisager d'autres approches.

Pour ceux (comme moi) qui

• utiliser c ++ 17
• voulez ajouter le moins de passe-partout / répétition et
• ça ne me dérange pas d'utiliser des macros (en attendant les méta-classes ...),

voici une autre prise:

#include <utility>
#include <type_traits>

template <typename T> struct NonConst;
template <typename T> struct NonConst<T const&> {using type = T&;};
template <typename T> struct NonConst<T const*> {using type = T*;};

#define NON_CONST(func)                                                     \
    template <typename... T> auto func(T&&... a)                            \
        -> typename NonConst<decltype(func(std::forward<T>(a)...))>::type   \
    {                                                                       \
        return const_cast<decltype(func(std::forward<T>(a)...))>(           \
            std::as_const(*this).func(std::forward<T>(a)...));              \
    }

Il s'agit essentiellement d'un mélange des réponses de @Pait, @DavidStone et @ sh1 ( EDIT : et une amélioration de @cdhowie). Ce qu'il ajoute au tableau, c'est que vous vous en sortez avec une seule ligne de code supplémentaire qui nomme simplement la fonction (mais pas d'argument ou de duplication de type de retour):

class X
{
    const Z& get(size_t index) const { ... }
    NON_CONST(get)
};

Remarque: gcc ne parvient pas à compiler cela avant 8.1, clang-5 et plus ainsi que MSVC-19 sont satisfaits (selon l'explorateur du compilateur ).

Voici une version C ++ 17 de la fonction d'assistance statique du modèle, avec et un test SFINAE facultatif.

#include <type_traits>

#define REQUIRES(...)         class = std::enable_if_t<(__VA_ARGS__)>
#define REQUIRES_CV_OF(A,B)   REQUIRES( std::is_same_v< std::remove_cv_t< A >, B > )

class Foobar {
private:
    int something;

    template<class FOOBAR, REQUIRES_CV_OF(FOOBAR, Foobar)>
    static auto& _getSomething(FOOBAR& self, int index) {
        // big, non-trivial chunk of code...
        return self.something;
    }

public:
    auto& getSomething(int index)       { return _getSomething(*this, index); }
    auto& getSomething(int index) const { return _getSomething(*this, index); }
};

Version complète: https://godbolt.org/z/mMK4r3

J'ai trouvé une macro qui génère automatiquement des paires de fonctions const / non const.

class A
{
    int x;    
  public:
    MAYBE_CONST(
        CV int &GetX() CV {return x;}
        CV int &GetY() CV {return y;}
    )

    //   Equivalent to:
    // int &GetX() {return x;}
    // int &GetY() {return y;}
    // const int &GetX() const {return x;}
    // const int &GetY() const {return y;}
};

Voir la fin de la réponse pour l'implémentation.

L'argument de MAYBE_CONSTest dupliqué. Dans la première copie, CVest remplacé par rien; et dans le deuxième exemplaire, il est remplacé par const.

Il n'y a pas de limite au nombre de fois qui CVpeuvent apparaître dans l'argument macro.

Il y a cependant un léger inconvénient. Si CVapparaît entre parenthèses, cette paire de parenthèses doit être préfixée avec CV_IN:

// Doesn't work
MAYBE_CONST( CV int &foo(CV int &); )

// Works, expands to
//         int &foo(      int &);
//   const int &foo(const int &);
MAYBE_CONST( CV int &foo CV_IN(CV int &); )

La mise en oeuvre:

#define MAYBE_CONST(...) IMPL_CV_maybe_const( (IMPL_CV_null,__VA_ARGS__)() )
#define CV )(IMPL_CV_identity,
#define CV_IN(...) )(IMPL_CV_p_open,)(IMPL_CV_null,__VA_ARGS__)(IMPL_CV_p_close,)(IMPL_CV_null,

#define IMPL_CV_null(...)
#define IMPL_CV_identity(...) __VA_ARGS__
#define IMPL_CV_p_open(...) (
#define IMPL_CV_p_close(...) )

#define IMPL_CV_maybe_const(seq) IMPL_CV_a seq IMPL_CV_const_a seq

#define IMPL_CV_body(cv, m, ...) m(cv) __VA_ARGS__

#define IMPL_CV_a(...) __VA_OPT__(IMPL_CV_body(,__VA_ARGS__) IMPL_CV_b)
#define IMPL_CV_b(...) __VA_OPT__(IMPL_CV_body(,__VA_ARGS__) IMPL_CV_a)

#define IMPL_CV_const_a(...) __VA_OPT__(IMPL_CV_body(const,__VA_ARGS__) IMPL_CV_const_b)
#define IMPL_CV_const_b(...) __VA_OPT__(IMPL_CV_body(const,__VA_ARGS__) IMPL_CV_const_a)

Implémentation pré-C ++ 20 qui ne prend pas en charge CV_IN:

#define MAYBE_CONST(...) IMPL_MC( ((__VA_ARGS__)) )
#define CV ))((

#define IMPL_MC(seq) \
    IMPL_MC_end(IMPL_MC_a seq) \
    IMPL_MC_end(IMPL_MC_const_0 seq)

#define IMPL_MC_identity(...) __VA_ARGS__
#define IMPL_MC_end(...) IMPL_MC_end_(__VA_ARGS__)
#define IMPL_MC_end_(...) __VA_ARGS__##_end

#define IMPL_MC_a(elem) IMPL_MC_identity elem IMPL_MC_b
#define IMPL_MC_b(elem) IMPL_MC_identity elem IMPL_MC_a
#define IMPL_MC_a_end
#define IMPL_MC_b_end

#define IMPL_MC_const_0(elem)       IMPL_MC_identity elem IMPL_MC_const_a
#define IMPL_MC_const_a(elem) const IMPL_MC_identity elem IMPL_MC_const_b
#define IMPL_MC_const_b(elem) const IMPL_MC_identity elem IMPL_MC_const_a
#define IMPL_MC_const_a_end
#define IMPL_MC_const_b_end

En règle générale, les fonctions membres pour lesquelles vous avez besoin de versions const et non const sont des getters et setters. La plupart du temps, il s'agit de lignes uniques, la duplication de code n'est donc pas un problème.

J'ai fait cela pour un ami qui a justifié à juste titre l'utilisation de const_cast... sans le savoir, j'aurais probablement fait quelque chose comme ça (pas vraiment élégant):

#include <iostream>

class MyClass
{

public:

    int getI()
    {
        std::cout << "non-const getter" << std::endl;
        return privateGetI<MyClass, int>(*this);
    }

    const int getI() const
    {
        std::cout << "const getter" << std::endl;
        return privateGetI<const MyClass, const int>(*this);
    }

private:

    template <class C, typename T>
    static T privateGetI(C c)
    {
        //do my stuff
        return c._i;
    }

    int _i;
};

int main()
{
    const MyClass myConstClass = MyClass();
    myConstClass.getI();

    MyClass myNonConstClass;
    myNonConstClass.getI();

    return 0;
}

Je suggère un modèle de fonction statique d'assistance privée, comme ceci:

class X
{
    std::vector<Z> vecZ;

    // ReturnType is explicitly 'Z&' or 'const Z&'
    // ThisType is deduced to be 'X' or 'const X'
    template <typename ReturnType, typename ThisType>
    static ReturnType Z_impl(ThisType& self, size_t index)
    {
        // massive amounts of code for validating index
        ReturnType ret = self.vecZ[index];
        // even more code for determining, blah, blah...
        return ret;
    }

public:
    Z& Z(size_t index)
    {
        return Z_impl<Z&>(*this, index);
    }
    const Z& Z(size_t index) const
    {
        return Z_impl<const Z&>(*this, index);
    }
};

Cet article DDJ montre une manière d'utiliser la spécialisation de modèle qui ne vous oblige pas à utiliser const_cast. Pour une fonction aussi simple, elle n'est cependant pas vraiment nécessaire.

boost :: any_cast (à un moment donné, il n'en a plus) utilise un const_cast de la version const appelant la version non-const pour éviter la duplication. Vous ne pouvez pas imposer de sémantique const à la version non-const, donc vous devez être très prudent avec cela.

En fin de compte, une certaine duplication de code est correcte tant que les deux extraits sont directement l'un sur l'autre.

Pour ajouter à la solution jwfearn et kevin fournie, voici la solution correspondante lorsque la fonction retourne shared_ptr:

struct C {
  shared_ptr<const char> get() const {
    return c;
  }
  shared_ptr<char> get() {
    return const_pointer_cast<char>(static_cast<const C &>(*this).get());
  }
  shared_ptr<char> c;
};

Je n'ai pas trouvé ce que je cherchais, alors j'en ai roulé quelques-uns ...

Celui-ci est un peu verbeux, mais a l'avantage de gérer de nombreuses méthodes surchargées du même nom (et type de retour) à la fois:

struct C {
  int x[10];

  int const* getp() const { return x; }
  int const* getp(int i) const { return &x[i]; }
  int const* getp(int* p) const { return &x[*p]; }

  int const& getr() const { return x[0]; }
  int const& getr(int i) const { return x[i]; }
  int const& getr(int* p) const { return x[*p]; }

  template<typename... Ts>
  auto* getp(Ts... args) {
    auto const* p = this;
    return const_cast<int*>(p->getp(args...));
  }

  template<typename... Ts>
  auto& getr(Ts... args) {
    auto const* p = this;
    return const_cast<int&>(p->getr(args...));
  }
};

Si vous n'avez qu'une seule constméthode par nom, mais encore beaucoup de méthodes à dupliquer, vous préférerez peut-être ceci:

  template<typename T, typename... Ts>
  auto* pwrap(T const* (C::*f)(Ts...) const, Ts... args) {
    return const_cast<T*>((this->*f)(args...));
  }

  int* getp_i(int i) { return pwrap(&C::getp_i, i); }
  int* getp_p(int* p) { return pwrap(&C::getp_p, p); }

Malheureusement, cela tombe en panne dès que vous commencez à surcharger le nom (la liste des arguments de l'argument du pointeur de fonction semble être non résolue à ce stade, donc il ne peut pas trouver de correspondance pour l'argument de fonction). Bien que vous puissiez également définir un moyen de vous en sortir:

  template<typename... Ts>
  auto* getp(Ts... args) { return pwrap<int, Ts...>(&C::getp, args...); }

Mais les arguments de référence à la constméthode ne correspondent pas aux arguments apparemment par valeur du modèle et il se casse. Pas certain de pourquoi. Voici pourquoi .