Come rimuovo la duplicazione del codice tra funzioni simili const e non const?

Diciamo che ho il seguente class Xdove voglio restituire l'accesso a un membro interno:

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

Le due funzioni membro X::Z()e X::Z() consthanno codice identico all'interno delle parentesi graffe. Questo è un codice duplicato e può causare problemi di manutenzione per funzioni lunghe con logica complessa .

C'è un modo per evitare questa duplicazione del codice?

Per una spiegazione dettagliata, vedere l'intestazione "Evita duplicazione in conste constFunzione non membro", a pag. 23, nell'articolo 3 "Usa constogni volta che è possibile", in C ++ efficace , ed. 3d di Scott Meyers, ISBN-13: 9780321334879.

Ecco la soluzione di Meyers (semplificata):

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

I due cast e la funzione possono essere brutti ma sono corretti. Meyers ha una spiegazione approfondita del perché.

Sì, è possibile evitare la duplicazione del codice. È necessario utilizzare la funzione membro const per avere la logica e fare in modo che la funzione membro non const richiami la funzione membro const e rilasci il valore restituito in un riferimento non const (o puntatore se le funzioni restituiscono un puntatore):

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

NOTA: è importante NON inserire la logica nella funzione non const e fare in modo che la funzione const chiami la funzione non const - ciò può comportare un comportamento indefinito. Il motivo è che un'istanza di classe costante viene lanciata come un'istanza non costante. La funzione membro non const può modificare accidentalmente la classe, che gli stati standard C ++ comporteranno un comportamento indefinito.

C ++ 17 ha aggiornato la migliore risposta a questa domanda:

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

Questo ha i vantaggi che:

• È ovvio cosa sta succedendo
• Ha un sovraccarico di codice minimo: si adatta a una singola riga
• È difficile sbagliare (può essere gettato via solo volatileper caso, ma volatileè un raro qualificatore)

Se si desidera percorrere l'intero percorso di detrazione, ciò può essere realizzato con una funzione di supporto

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;

Ora non puoi nemmeno sbagliare volatilee l'uso sembra

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

Penso che la soluzione di Scott Meyers possa essere migliorata in C ++ 11 usando una funzione di supporto temporaneo. Questo rende l'intento molto più ovvio e può essere riutilizzato per molti altri giocatori.

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

Questa funzione di supporto può essere utilizzata nel modo seguente.

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

Il primo argomento è sempre questo puntatore. Il secondo è il puntatore alla funzione membro da chiamare. Successivamente è possibile passare una quantità arbitraria di argomenti aggiuntivi in ​​modo che possano essere inoltrati alla funzione. Ciò richiede C ++ 11 a causa dei modelli variadici.

Un po 'più prolisso di Meyers, ma potrei farlo:

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

Il metodo privato ha la proprietà indesiderabile che restituisce una Z non costante e per un'istanza const, motivo per cui è privata. I metodi privati ​​possono spezzare gli invarianti dell'interfaccia esterna (in questo caso l'invariante desiderato è "un oggetto const non può essere modificato tramite riferimenti ottenuti attraverso di esso con oggetti che ha-a").

Nota che i commenti fanno parte del modello - l'interfaccia di _getZ specifica che non è mai valido chiamarlo (a parte gli accessi, ovviamente): non c'è comunque alcun vantaggio immaginabile farlo, perché è 1 carattere in più da digitare e non lo farà risulta in un codice più piccolo o più veloce. Chiamare il metodo equivale a chiamare uno degli accessor con un const_cast e non vorrai farlo neanche tu. Se sei preoccupato di rendere evidenti gli errori (e questo è un obiettivo equo), chiamalo const_cast_getZ invece di _getZ.

A proposito, apprezzo la soluzione di Meyers. Non ho obiezioni filosofiche. Personalmente, però, preferisco un po 'di ripetizione controllata e un metodo privato che deve essere chiamato solo in determinate circostanze strettamente controllate, rispetto a un metodo che assomiglia al rumore di linea. Scegli il tuo veleno e attaccalo.

[Modifica: Kevin ha giustamente sottolineato che _getZ potrebbe voler chiamare un ulteriore metodo (diciamo generateZ) che è specializzato nello stesso modo di getZ. In questo caso, _getZ visualizzerà una const Z e dovrà trasmetterla prima di tornare. È ancora sicuro, dal momento che l'accessorio della piastra di caldaia controlla tutto, ma non è straordinariamente ovvio che sia sicuro. Inoltre, se lo fai e successivamente cambi generateZ per restituire sempre const, allora devi anche cambiare getZ per restituire sempre const, ma il compilatore non ti dirà che lo fai.

Quest'ultimo punto sul compilatore è vero anche per il modello raccomandato da Meyers, ma il primo punto su un const_cast non ovvio non lo è. Quindi, a conti fatti, penso che se _getZ risulta avere bisogno di un const_cast per il suo valore di ritorno, allora questo modello perde molto del suo valore rispetto a quello di Meyers. Dato che soffre anche di svantaggi rispetto a quelli di Meyers, penso che passerei al suo in quella situazione. Il refactoring dall'uno all'altro è semplice: non influisce su nessun altro codice valido nella classe, poiché solo il codice non valido e la piastra della caldaia chiamano _getZ.]

Bella domanda e belle risposte. Ho un'altra soluzione, che non usa cast:

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

};

Tuttavia, ha la bruttezza di richiedere un membro statico e la necessità di utilizzare il file instance variabile al suo interno.

Non ho considerato tutte le possibili implicazioni (negative) di questa soluzione. Per favore fatemi sapere se ce ne sono.

Puoi anche risolverlo con i template. Questa soluzione è leggermente brutta (ma la bruttezza è nascosta nel file .cpp) ma fornisce il controllo della costanza del compilatore e nessuna duplicazione del codice.

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

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

Lo svantaggio principale che posso vedere è che poiché tutta la complessa implementazione del metodo è in una funzione globale, è necessario acquisire i membri di X utilizzando metodi pubblici come GetVector () sopra (di cui è sempre necessario essere un const e non const) o potresti rendere questa funzione un'amica. Ma non mi piacciono gli amici.

[Modifica: rimosso non necessario includere di cstdio aggiunto durante il test.]

Che ne dici di spostare la logica in un metodo privato e fare solo le cose "ottieni il riferimento e restituisci" all'interno dei getter? In realtà, sarei abbastanza confuso riguardo ai cast statici e const all'interno di una semplice funzione getter, e lo considererei brutto tranne che per circostanze estremamente rare!

Usare il preprocessore è imbarazzante?

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

};

Non è elegante come modelli o cast, ma rende esplicito il tuo intento ("queste due funzioni devono essere identiche").

Mi sorprende che ci siano così tante risposte diverse, ma quasi tutte si basano su una pesante magia di template. I modelli sono potenti, ma a volte le macro li battono in concisione. La massima versatilità si ottiene spesso combinando entrambi.

Ho scritto una macro FROM_CONST_OVERLOAD() che può essere inserita nella funzione non const per invocare la funzione const.

Esempio di utilizzo:

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

Implementazione semplice e riutilizzabile:

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)

Spiegazione:

Come pubblicato in molte risposte, il modello tipico per evitare la duplicazione del codice in una funzione membro non const è questo:

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

Gran parte di questa piastra di caldaia può essere evitata usando l'inferenza di tipo. Innanzitutto, const_castpuò essere incapsulato in WithoutConst(), che determina il tipo del suo argomento e rimuove il qualificatore const. In secondo luogo, un approccio simile può essere utilizzato WithConst()per qualificare il thispuntatore const , che consente di chiamare il metodo const-overload.

Il resto è una semplice macro che antepone la chiamata con la qualifica corretta this->e rimuove const dal risultato. Poiché l'espressione utilizzata nella macro è quasi sempre una semplice chiamata di funzione con argomenti inoltrati 1: 1, gli svantaggi di macro come la valutazione multipla non entrano in gioco. Le ellissi e __VA_ARGS__potrebbero anche essere utilizzate, ma non dovrebbero essere necessarie perché virgole (come separatori di argomenti) tra parentesi.

Questo approccio ha diversi vantaggi:

• Sintassi minima e naturale: basta avvolgere la chiamata FROM_CONST_OVERLOAD( )
• Nessuna funzione di membro extra richiesta
• Compatibile con C ++ 98
• Implementazione semplice, nessuna metaprogrammazione del modello e zero dipendenze
• Extensible: altri rapporti const possono essere aggiunti (come const_iterator, std::shared_ptr<const T>e così via). Per questo, è sufficiente sovraccaricare WithoutConst()i tipi corrispondenti.

Limitazioni: questa soluzione è ottimizzata per gli scenari in cui il sovraccarico non costante sta facendo esattamente lo stesso del sovraccarico const, in modo che gli argomenti possano essere inoltrati 1: 1. Se la tua logica è diversa e non stai chiamando la versione const tramite this->Method(args), puoi prendere in considerazione altri approcci.

Per quelli (come me) che

• usa c ++ 17
• desidera aggiungere la minima quantità di boilerplate / ripetizione e
• non preoccuparti di usare le macro (mentre aspetti meta-classi ...),

ecco un'altra interpretazione:

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

È fondamentalmente un mix di risposte da @Pait, @DavidStone e @ sh1 ( EDIT : e un miglioramento da @cdhowie). Ciò che aggiunge alla tabella è che si ottiene solo una riga di codice aggiuntiva che semplicemente nomina la funzione (ma nessun argomento o duplicazione del tipo restituito):

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

Nota: gcc non riesce a compilare questo prima di 8.1, clang-5 e versioni successive e MSVC-19 sono felici (secondo l'esploratore del compilatore ).

Ecco una versione C ++ 17 della funzione helper statica modello, con e test SFINAE opzionale.

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

Versione completa: https://godbolt.org/z/mMK4r3

Mi è venuta in mente una macro che genera automaticamente coppie di funzioni 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;}
};

Vedi la fine della risposta per l'implementazione.

L'argomento di MAYBE_CONSTè duplicato. Nella prima copia, CVviene sostituito con nulla; e nella seconda copia viene sostituito con const.

Non c'è limite al numero di volte che CVpossono apparire nell'argomento macro.

C'è un leggero inconveniente però. Se CVappare tra parentesi, questa coppia di parentesi deve essere preceduta da 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 &); )

Implementazione:

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

Implementazione pre-C ++ 20 che non supporta 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

In genere, le funzioni membro per le quali sono necessarie le versioni const e non const sono getter e setter. Il più delle volte sono a una riga, quindi la duplicazione del codice non è un problema.

L'ho fatto per un amico che giustamente ha giustificato l'uso di const_cast... non sapendolo avrei probabilmente fatto qualcosa del genere (non molto elegante):

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

Suggerirei un modello di funzione statica helper privato, come questo:

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

Questo articolo DDJ mostra come utilizzare la specializzazione del modello che non richiede l'utilizzo di const_cast. Per una funzione così semplice, in realtà non è necessario.

boost :: any_cast (a un certo punto, non lo fa più) usa un const_cast dalla versione const che chiama la versione non const per evitare la duplicazione. Non puoi imporre semantica const sulla versione non const, quindi devi essere molto attento.

Alla fine, la duplicazione del codice va bene purché i due frammenti siano direttamente uno sopra l'altro.

Per aggiungere alla soluzione fornita da jwfearn e kevin, ecco la soluzione corrispondente quando la funzione restituisce 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;
};

Non ho trovato quello che cercavo, quindi ho arrotolato un paio dei miei ...

Questo è un po 'prolisso, ma ha il vantaggio di gestire contemporaneamente molti metodi sovraccarichi con lo stesso nome (e tipo di ritorno):

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

Se hai solo un constmetodo per nome, ma hai ancora molti metodi da duplicare, potresti preferire questo:

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

Sfortunatamente questo si interrompe non appena si inizia a sovraccaricare il nome (l'elenco degli argomenti dell'argomento del puntatore alla funzione sembra non essere risolto a quel punto, quindi non riesce a trovare una corrispondenza per l'argomento della funzione). Anche se puoi modellarti anche tu:

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

Ma gli argomenti di riferimento al constmetodo non corrispondono agli argomenti apparentemente per valore al modello e si interrompe. Non so perché. Ecco perché .