Как удалить дублирование кода между похожими константными и неконстантными функциями-членами?

Да, можно избежать дублирования кода. Вам необходимо использовать константную функцию-член, чтобы иметь логику и чтобы неконстантная функция-член вызывала константную функцию-член и повторно преобразовывала возвращаемое значение в неконстантную ссылку (или указатель, если функции возвращают указатель):

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

ПРИМЕЧАНИЕ: Важно, чтобы вы сделали НЕТ, поместили логику в неконстантную функцию и заставили константную функцию вызывать неконстантную функцию - это может привести к неопределенному поведению. Причина в том, что экземпляр константного класса приводится к непостоянному экземпляру. Неконстантная функция-член может случайно изменить класс, что в соответствии со стандартом C++ приведет к неопределенному поведению.

Эта статья DDJ показывает способ использования специализации шаблона, который не требует использования const_cast. Однако для такой простой функции это действительно не нужно.

boost :: any_cast (в какой-то момент его больше нет) использует const_cast из константной версии, вызывая неконстантную версию, чтобы избежать дублирования. Вы не можете навязать константную семантику неконстантной версии, поэтому вы должны быть осторожны с очень.

В конце концов, некоторое дублирование кода является нормально, если два фрагмента находятся непосредственно друг над другом.

Обычно функции-члены, для которых нужны константные и неконстантные версии, являются геттерами и сеттерами. В большинстве случаев они однострочные, поэтому дублирование кода не является проблемой.

Подробное объяснение см. В заголовке «Избегайте дублирования в функциях-членах const и не-const» на стр. 23, в пункте 3 «По возможности используйте const» в Эффективный C++, 3-е изд. Скотта Мейерса, ISBN-13: 9780321334879.

Вот решение Мейерса (упрощенное):

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

Два приведения типов и вызов функции могут быть уродливыми, но они верны для метода, отличного от const, поскольку это подразумевает, что объект изначально не был const. (Мейерс подробно обсуждает это.)

Немного более подробный, чем Мейерс, но я могу сделать следующее:

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

У частного метода есть нежелательное свойство, заключающееся в том, что он возвращает неконстантный Z & для константного экземпляра, поэтому он частный. Частные методы могут нарушать инварианты внешнего интерфейса (в этом случае желаемый инвариант - это «константный объект не может быть изменен через полученные через него ссылки на объекты, которые он имеет-a»).

Обратите внимание, что комментарии являются частью шаблона - интерфейс _getZ указывает, что его нельзя вызывать (кроме средств доступа, очевидно): в любом случае нет никакой мыслимой выгоды от этого, потому что это еще 1 символ для ввода и не будет приводит к меньшему или более быстрому коду. Вызов метода эквивалентен вызову одного из методов доступа с const_cast, и вы бы тоже не захотели этого делать. Если вы беспокоитесь о том, что ошибки очевидны (и это справедливая цель), назовите его const_cast_getZ вместо _getZ.

Кстати, я ценю решение Мейерса. У меня нет никаких философских возражений против этого. Лично я предпочитаю немного контролируемого повторения и частный метод, который должен вызываться только в определенных строго контролируемых обстоятельствах, а не методу, который выглядит как линейный шум. Выберите свой яд и придерживайтесь его.

[Обновлено: Кевин справедливо указал, что _getZ может захотеть вызвать другой метод (скажем, generateZ), который специализируется на константе так же, как и getZ. В этом случае _getZ увидит const Z & и должен будет преобразовать его в const_cast перед возвратом. Это по-прежнему безопасно, поскольку шаблонный аксессуар контролирует все, но не совсем очевидно, что это безопасно. Кроме того, если вы сделаете это, а затем измените generateZ, чтобы он всегда возвращал const, вам также нужно изменить getZ, чтобы он всегда возвращал const, но компилятор не скажет вам, что вы это делаете.

Последний пункт о компиляторе также верен для рекомендованного Мейерса шаблона, но первый пункт о неочевидном const_cast - нет. Итак, в целом, я думаю, что если _getZ окажется, что для его возвращаемого значения требуется const_cast, то этот шаблон теряет большую часть своего значения по сравнению с шаблоном Мейерса. Поскольку он также имеет недостатки по сравнению с устройством Мейерса, я думаю, что в этой ситуации я бы переключился на его. Выполнить рефакторинг с одного кода на другой просто - он не влияет на любой другой допустимый код в классе, поскольку только недопустимый код и шаблон вызывает _getZ.]

Как насчет того, чтобы переместить логику в частный метод и делать только "получить ссылку и вернуть" внутри геттеров? На самом деле, я был бы довольно озадачен приведениями static и const внутри простой функции-получателя, и я бы счел это уродливым, за исключением чрезвычайно редких обстоятельств!

Вы также можете решить эту проблему с помощью шаблонов. Это решение немного уродливо (но уродство скрыто в файле .cpp), но оно обеспечивает проверку компилятором константности и отсутствие дублирования кода.

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

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

Главный недостаток, который я вижу, заключается в том, что поскольку вся сложная реализация метода находится в глобальной функции, вам нужно либо получить доступ к членам X, используя общедоступные методы, такие как GetVector () выше (из которых всегда должен быть const и неконстантная версия), или вы можете подружиться с этой функцией. Но я не люблю друзей.

[Edit: удалено ненужное включение cstdio, добавленного во время тестирования.]

Я думаю, что решение Скотта Мейерса можно улучшить в C++ 11, используя временную вспомогательную функцию. Это делает намерение более очевидным и может быть повторно использовано для многих других геттеров.

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

Эту вспомогательную функцию можно использовать следующим образом.

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

Первым аргументом всегда является указатель this. Второй - указатель на вызываемую функцию-член. После этого можно передать произвольное количество дополнительных аргументов, чтобы их можно было передать функции. Для этого нужен C++ 11 из-за вариативных шаблонов.

Хороший вопрос и хорошие ответы. У меня есть другое решение, которое не использует приведения:

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

};

Однако у него есть уродство, заключающееся в том, что он требует статического члена и необходимости использовать внутри него переменную instance.

Я не учел всех возможных (отрицательных) последствий этого решения. Пожалуйста, дайте мне знать, если таковые имеются.

Чтобы добавить к решению, предоставленному jwfearn и kevin, вот соответствующее решение, когда функция возвращает 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;
};

Я сделал это для друга, который справедливо оправдал использование const_cast ... не зная об этом, я, вероятно, сделал бы что-то вроде этого (не очень элегантно):

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

Я бы предложил шаблон статической функции частного помощника, например:

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

Не нашел то, что искал, поэтому накатил пару собственных ...

Это немного многословно, но имеет преимущество одновременной обработки множества перегруженных методов с одним и тем же именем (и типом возвращаемого значения):

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

Если у вас есть только один метод const на имя, но все еще много методов для дублирования, вы можете предпочесть следующее:

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

К сожалению, это выходит из строя, как только вы начинаете перегружать имя (список аргументов аргумента указателя функции кажется неразрешенным в этот момент, поэтому он не может найти совпадение для аргумента функции). Хотя вы тоже можете спланировать свой выход из этого:

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

Но ссылочные аргументы к методу const не соответствуют аргументам шаблона, явно по значению, и он ломается. Не знаю почему.Вот почему.

Использование препроцессора - это обман?

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

};

Это не так изящно, как шаблоны или приведение типов, но оно делает ваше намерение («эти две функции должны быть идентичными») довольно явным.

C++ 17 обновил лучший ответ на этот вопрос:

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

Это имеет следующие преимущества:

• Очевидно, что происходит
• Имеет минимальные накладные расходы на код - помещается в одну строку
• Трудно ошибиться (может только случайно отбросить volatile, но volatile - редкий квалификатор)

Если вы хотите пройти полный путь вывода, это можно сделать с помощью вспомогательной функции

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;

Теперь вы даже не можете испортить volatile, а его использование выглядит как

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

Для тех (как я), кто

• использовать C++ 17
• хотите добавить наименьшее количество шаблонов / повторение и
• не против использовать макросы (ожидая мета-классов ...),

вот еще один дубль:

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

По сути, это смесь ответов от @Pait, @DavidStone и @ sh1 (РЕДАКТИРОВАТЬ: и улучшение от @cdhowie). Что он добавляет в таблицу, так это то, что вы получаете только одну дополнительную строку кода, которая просто называет функцию (но без дублирования аргументов или возвращаемого типа):

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

Примечание: gcc не может скомпилировать это до 8.1, clang-5 и выше, а также MSVC-19 счастливы (согласно обозреватель компилятора).

Меня удивляет, что существует так много разных ответов, но почти все они полагаются на тяжелую магию шаблонов. Шаблоны мощные, но иногда макросы превосходят их по лаконичности. Максимальная универсальность часто достигается за счет сочетания того и другого.

Я написал макрос FROM_CONST_OVERLOAD(), который можно поместить в неконстантную функцию для вызова константной функции.

Пример использования:

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

Простая и многоразовая реализация:

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)

Объяснение:

Как указано во многих ответах, типичный шаблон, позволяющий избежать дублирования кода в неконстантной функции-члене, заключается в следующем:

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

Многих из этих шаблонов можно избежать, используя вывод типа. Во-первых, const_cast может быть инкапсулирован в WithoutConst(), который определяет тип своего аргумента и удаляет квалификатор const. Во-вторых, аналогичный подход может быть использован в WithConst() для определения константного указателя this, что позволяет вызывать метод, перегруженный константой.

Остальное - это простой макрос, который ставит перед вызовом правильно квалифицированный this-> и удаляет const из результата. Поскольку выражение, используемое в макросе, почти всегда представляет собой простой вызов функции с перенаправленными аргументами 1: 1, недостатки макросов, такие как множественное вычисление, не проявляются. Можно также использовать многоточие и __VA_ARGS__, но они не нужны, потому что запятые ( как разделители аргументов) заключаются в круглые скобки.

У этого подхода есть несколько преимуществ:

• Минимальный и естественный синтаксис - просто оберните вызов в FROM_CONST_OVERLOAD( )
• Никаких дополнительных функций-членов не требуется
• Совместим с C++ 98
• Простая реализация, без метапрограммирования шаблонов и нулевых зависимостей
• Расширяемый: могут быть добавлены другие константные отношения (например, const_iterator, std::shared_ptr<const T> и т. д.). Для этого просто перегрузите WithoutConst() для соответствующих типов.

Ограничения: это решение оптимизировано для сценариев, в которых неконстантная перегрузка делает то же самое, что и константная перегрузка, поэтому аргументы можно пересылать 1: 1. Если ваша логика отличается и вы не вызываете константную версию через this->Method(args), вы можете рассмотреть другие подходы.

Я придумал макрос, который автоматически генерирует пары константных / неконстантных функций.

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

См. Конец ответа для реализации.

Аргумент MAYBE_CONST дублируется. В первом экземпляре CV ничем не заменен; а во втором экземпляре заменен на const.

Нет ограничений на то, сколько раз CV может появляться в аргументе макроса.

Хотя есть небольшое неудобство. Если CV стоит внутри круглых скобок, перед этой парой скобок должен стоять префикс 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 &); )

Выполнение:

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

Реализация до C++ 20, не поддерживающая 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

Вот версия C++ 17 статической вспомогательной функции шаблона с дополнительным тестом 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); }
};

Полная версия: https://godbolt.org/z/mMK4r3