Jak usunąć duplikację kodu między podobnymi stałymi i nie stałymi funkcjami członka?

Powiedzmy, że mam następujące miejsce, w class Xktórym chcę zwrócić dostęp do członka wewnętrznego:

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
    }
};

Te dwie funkcje składowe X::Z()i X::Z() constmają identyczny kod wewnątrz szelki. Jest to zduplikowany kod i może powodować problemy z obsługą długich funkcji o złożonej logice .

Czy istnieje sposób na uniknięcie tego powielania kodu?

Szczegółowe wyjaśnienie znajduje się w tytule „Unikaj powielania w funkcjach innych constniż elementy constczłonkowskie” na s. 9. 23, w punkcie 3 „Używaj, constkiedy to możliwe”, w Effective C ++ , 3d wyd. Scott Meyers, ISBN-13: 9780321334879.

Oto rozwiązanie Meyersa (uproszczone):

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

Dwie rzutowania i wywołanie funkcji mogą być brzydkie, ale są poprawne. Meyers ma dokładne wyjaśnienie, dlaczego.

Tak, można uniknąć duplikacji kodu. Musisz użyć funkcji const członka, aby mieć logikę, a funkcja non-const członka wywoła funkcję const członka i ponownie wyśle ​​wartość zwracaną do odwołania non-const (lub wskaźnika, jeśli funkcje zwrócą wskaźnik):

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
};

UWAGA: Ważne jest, aby NIE umieszczać logiki w funkcji non-const, a funkcja const wywoła funkcję non-const - może to spowodować niezdefiniowane zachowanie. Powodem jest to, że instancja klasy stałej jest rzutowana jako instancja niestała. Niepodstawowa funkcja członkowska może przypadkowo zmodyfikować klasę, co spowoduje, że stany standardu C ++ spowodują niezdefiniowane zachowanie.

C ++ 17 zaktualizował najlepszą odpowiedź na to pytanie:

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

Ma to takie zalety, że:

• To oczywiste, co się dzieje
• Ma minimalny narzut kodu - mieści się w jednej linii
• Trudno się pomylić (można go rzucić tylko volatileprzez przypadek, ale volatilejest rzadkim kwalifikatorem)

Jeśli chcesz przejść pełną trasę dedukcyjną, możesz to osiągnąć, korzystając z funkcji pomocnika

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;

Teraz nie możesz nawet zepsuć się volatile, a wygląda to na użycie

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

Myślę, że rozwiązanie Scotta Meyersa można ulepszyć w C ++ 11 za pomocą funkcji pomocnika tymczasowego. To sprawia, że ​​intencja jest o wiele bardziej oczywista i może być ponownie wykorzystana dla wielu innych osób pobierających.

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)...));
}

Tej funkcji pomocnika można użyć w następujący sposób.

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);
   }
};

Pierwszym argumentem jest zawsze ten wskaźnik. Drugi to wskaźnik do funkcji członka, którą należy wywołać. Następnie można przekazać dowolną liczbę dodatkowych argumentów, aby można je było przekazać do funkcji. Wymaga to C ++ 11 z powodu różnych szablonów.

Trochę bardziej gadatliwy niż Meyers, ale mógłbym to zrobić:

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); }
};

Metoda prywatna ma niepożądaną właściwość polegającą na tym, że zwraca nie-stałą Z i dla stałej instancji, dlatego jest prywatna. Prywatne metody mogą łamać niezmienniki interfejsu zewnętrznego (w tym przypadku pożądanym niezmiennikiem jest „obiekt stały nie może być modyfikowany poprzez referencje uzyskane przez niego do obiektów, które posiada”).

Zauważ, że komentarze są częścią wzorca - interfejs _getZ określa, że ​​nigdy nie można go wywoływać (poza akcesoriami, oczywiście): i tak nie ma żadnych korzyści, ponieważ jest to 1 dodatkowy znak do wpisania i nie będzie skutkuje mniejszym lub szybszym kodem. Wywołanie metody jest równoważne z wywołaniem jednego z akcesorów za pomocą const_cast, a ty też tego nie chciałbyś zrobić. Jeśli martwisz się, że błędy będą oczywiste (a to uczciwy cel), nazwij to const_cast_getZ zamiast _getZ.

Nawiasem mówiąc, doceniam rozwiązanie Meyersa. Nie mam przeciwko temu filozoficznego sprzeciwu. Osobiście jednak wolę odrobinę kontrolowanego powtarzania i metodę prywatną, którą można wywołać tylko w ściśle ściśle kontrolowanych okolicznościach, niż metodę, która wygląda jak szum linii. Wybierz swoją truciznę i trzymaj się jej.

[Edycja: Kevin słusznie zauważył, że _getZ może chcieć wywołać kolejną metodę (powiedzmy generateZ), która jest wyspecjalizowana w tej samej zasadzie co getZ. W takim przypadku _getZ zobaczyłby const Z i musiałby go const_cast przed powrotem. Nadal jest to bezpieczne, ponieważ akcesorium do płyty kotłowej porządkuje wszystko, ale nie jest szczególnie oczywiste, że jest bezpieczne. Ponadto, jeśli to zrobisz, a następnie zmienisz generatorZ, aby zawsze zwracał stałą, musisz również zmienić getZ, aby zawsze zwracał stałą, ale kompilator nie powie ci, że to zrobisz.

Ten ostatni punkt dotyczący kompilatora jest również zgodny z zalecanym wzorcem Meyersa, ale pierwszy punkt dotyczący nieoczywistego const_cast nie jest. Podsumowując, myślę, że jeśli _getZ okaże się, że potrzebuje const_cast dla jego wartości zwracanej, wówczas ten wzór traci dużo swojej wartości w porównaniu z wartością Meyersa. Ponieważ ma również wady w porównaniu do Meyersa, myślę, że w tej sytuacji przeszedłbym na jego. Refaktoryzacja od jednego do drugiego jest łatwa - nie wpływa na żaden inny poprawny kod w klasie, ponieważ tylko niepoprawny kod i płyta główna wywołują _getZ.]

Ładne pytanie i ładne odpowiedzi. Mam inne rozwiązanie, które nie używa rzutów:

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);
    }

};

Ma jednak brzydotę polegającą na wymaganiu członu statycznego i konieczności użycia instancezmiennej wewnątrz niego.

Nie rozważyłem wszystkich możliwych (negatywnych) implikacji tego rozwiązania. Daj mi znać, jeśli w ogóle.

Możesz to również rozwiązać za pomocą szablonów. To rozwiązanie jest nieco brzydkie (ale brzydota jest ukryta w pliku .cpp), ale zapewnia sprawdzanie ciągłości kompilatora i brak duplikacji kodu.

plik .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;
};

plik .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 );
}

Główną wadą, jaką widzę, jest to, że ponieważ cała złożona implementacja metody jest funkcją globalną, musisz albo zdobyć elementy X przy użyciu publicznych metod, takich jak GetVector () powyżej (z których zawsze musi istnieć const i non-const version) lub możesz uczynić tę funkcję przyjazną. Ale nie lubię przyjaciół.

[Edycja: usunięto niepotrzebne dołączenie cstdio dodane podczas testowania.]

Co powiesz na przeniesienie logiki do metody prywatnej i wykonywanie tylko czynności „pobierz referencję i zwróć” wewnątrz modułów pobierających? Właściwie byłbym dość zdezorientowany co do rzutów statycznych i stałych w prostej funkcji gettera i uważałbym to za brzydkie, z wyjątkiem wyjątkowo rzadkich okoliczności!

Czy używanie preprocesora jest oszustwem?

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

};

Nie jest tak fantazyjny jak szablony lub rzutowania, ale sprawia, że ​​twoja intencja („te dwie funkcje mają być identyczne”) jest dość wyraźna.

Zaskakuje mnie, że istnieje tak wiele różnych odpowiedzi, ale prawie wszystkie polegają na dużej magii szablonów. Szablony są potężne, ale czasami makra pobijają je w zwięzłości. Maksymalna wszechstronność jest często osiągana przez połączenie obu.

Napisałem makro, FROM_CONST_OVERLOAD()które można umieścić w funkcji non-const, aby wywołać funkcję const.

Przykładowe użycie:

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) );
    }
};

Prosta implementacja wielokrotnego użytku:

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)

Wyjaśnienie:

Jak napisano w wielu odpowiedziach, typowy wzorzec unikania duplikacji kodu w funkcji niezrzeszonej jest następujący:

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

Wiele z tej płyty kotłowej można uniknąć, korzystając z wnioskowania o typie. Po pierwsze, const_castmoże być enkapsulowany WithoutConst(), co określa typ jego argumentu i usuwa kwalifikator const. Po drugie, podobne podejście można zastosować WithConst()do stałej kwalifikacji thiswskaźnika, co umożliwia wywołanie metody przeciążenia const.

Reszta to proste makro, które poprzedza połączenie poprawnie zakwalifikowaną this->i usuwa const z wyniku. Ponieważ wyrażenie używane w makrze jest prawie zawsze prostym wywołaniem funkcji z argumentami przekazanymi w stosunku 1: 1, nie pojawiają się wady makr, takich jak wielokrotna ocena. Elipsa i __VA_ARGS__może być również używana, ale nie powinna być potrzebna, ponieważ przecinki (ponieważ separatory argumentów) występują w nawiasach.

Takie podejście ma kilka zalet:

• Minimalna i naturalna składnia - wystarczy zawinąć połączenie FROM_CONST_OVERLOAD( )
• Nie jest wymagana dodatkowa funkcja członka
• Kompatybilny z C ++ 98
• Prosta implementacja, brak metaprogramowania szablonu i zerowe zależności
• Przesuwne: inne stosunki const można dodawać (jak const_iterator, std::shared_ptr<const T>itp). W tym celu wystarczy przeciążenie WithoutConst()odpowiednich typów.

Ograniczenia: to rozwiązanie jest zoptymalizowane do scenariuszy, w których przeciążenie ciągłe działa dokładnie tak samo jak przeciążenie ciągłe, dzięki czemu argumenty można przekazywać 1: 1. Jeśli Twoja logika jest this->Method(args)inna i nie wywołujesz stałej wersji przez , możesz rozważyć inne podejścia.

Dla tych (jak ja), którzy

• użyj c ++ 17
• chcesz dodać najmniejszą liczbę płyt / powtórzeń i
• nie przejmuj się używaniem makr (czekając na meta-klasy ...),

oto kolejne ujęcie:

#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)...));              \
    }

Jest to w zasadzie połączenie odpowiedzi z @Pait, @DavidStone i @ sh1 ( EDYCJA : i ulepszenie z @cdhowie). To, co dodaje do tabeli, polega na tym, że unikasz tylko jednego dodatkowego wiersza kodu, który po prostu nazywa nazwę funkcji (ale nie ma powielania argumentów ani typów zwracanych):

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

Uwaga: gcc nie kompiluje tego przed wersją 8.1, clang-5 i nowsze wersje, a także MSVC-19 są zadowoleni (według eksploratora kompilatora ).

Oto wersja C ++ 17 szablonu statycznej funkcji pomocniczej z opcjonalnym testem SFINAE.

#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); }
};

Pełna wersja: https://godbolt.org/z/mMK4r3

Wymyśliłem makro, które automatycznie generuje pary funkcji 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;}
};

Zobacz koniec odpowiedzi na wdrożenie.

Argument argumentu MAYBE_CONSTjest zduplikowany. W pierwszym egzemplarzu CVzostaje zastąpiony niczym; aw drugiej kopii zastąpiono go const.

Nie ma ograniczenia, ile razy CVmoże występować w argumencie makra.

Jest jednak niewielka niedogodność. Jeśli CVpojawia się w nawiasach, ta para nawiasów musi być poprzedzona 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 &); )

Realizacja:

#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)

Implementacja wcześniejsza niż C ++ 20, która nie obsługuje 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

Zazwyczaj funkcje składowe, dla których potrzebujesz wersji const i non-const, to gettery i setters. Przeważnie są one jednowarstwowe, więc duplikacja kodu nie stanowi problemu.

Zrobiłem to dla przyjaciela, który słusznie uzasadnił użycie const_cast... nie wiedząc o tym, prawdopodobnie zrobiłbym coś takiego (niezbyt elegancko):

#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;
}

Sugerowałbym szablon funkcji statycznej pomocnika prywatnego, taki jak ten:

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);
    }
};

W tym artykule DDJ pokazano sposób korzystania ze specjalizacji szablonów, która nie wymaga użycia const_cast. Jednak dla tak prostej funkcji tak naprawdę nie jest ona potrzebna.

boost :: any_cast (w pewnym momencie już nie używa) używa const_cast z wersji const wywołującej wersję non-const, aby uniknąć powielania. Nie możesz jednak nałożyć stałej semantyki na wersję inną niż const, więc musisz być bardzo ostrożny.

W końcu pewne powielanie kodu jest w porządku, o ile dwa fragmenty znajdują się bezpośrednio nad sobą.

Aby dodać do dostarczonego rozwiązania jwfearn i kevin, oto odpowiednie rozwiązanie, gdy funkcja zwróci 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;
};

Nie znalazłem tego, czego szukałem, więc wyrzuciłem kilka własnych ...

Ten jest trochę niewygodny, ale ma tę zaletę, że obsługuje wiele przeciążonych metod o tej samej nazwie (i typie zwracanym) jednocześnie:

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...));
  }
};

Jeśli masz tylko jedną constmetodę na nazwę, ale nadal istnieje wiele metod do powielenia, możesz wybrać:

  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); }

Niestety to się psuje, gdy tylko zaczniesz przeciążać nazwę (lista argumentów argumentu wskaźnika funkcji wydaje się w tym momencie nierozwiązana, więc nie może znaleźć dopasowania dla argumentu funkcji). Chociaż możesz również rozwiązać ten problem:

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

Ale argumenty odwołujące się do constmetody nie pasują do argumentów najwyraźniej według wartości do szablonu i psuje się. Nie pewny dlaczego. Oto dlaczego .