Как сгенерировать неконстантный метод из константного метода?

Другой способ - написать шаблон, который вызывает функцию (используя CRTP) и наследует ее.

template<typename D>
struct const_forward {
protected:
  // forbid deletion through a base-class ptr
  ~const_forward() { }

  template<typename R, R const*(D::*pf)()const>
  R *use_const() {
    return const_cast<R *>( (static_cast<D const*>(this)->*pf)() );
  }

  template<typename R, R const&(D::*pf)()const>
  R &use_const() {
    return const_cast<R &>( (static_cast<D const*>(this)->*pf)() );
  }
};

class Bar;

class Foo : public const_forward<Foo> {
public:
  const Bar* bar() const { /* code that gets a Bar somewhere */ }
  Bar* bar() { return use_const<Bar, &Foo::bar>(); }
};

Обратите внимание, что при вызове не происходит потери производительности: поскольку указатель на член передается как параметр шаблона, вызов может быть встроен как обычно.

Используйте следующий трюк:

class Bar;
class Foo {
public:  
  Bar* bar() { 
    // non-const case
    /* code that does something */ 
  }  
  const Bar* bar() const {    
      return This().bar();  // use non-const case
   }

private:
  //trick: const method returns non-const reference
  Foo & This() const { return const_cast<Foo &>(*this); } 
};

Обратите внимание, что можно использовать уникальную функцию This для любых константных / неконстантных функций.

Альтернативное решение без static_cast (но я предпочитаю первое):

class Bar;
class Foo {
public:  
  const Bar* bar() const { /* code that does something */ }  
  Bar* bar() { return const_cast<Bar*>(cthis().bar()); } // use const case
private:
  const Foo & cthis() const { return *this; } 
};

Вы можете сделать что-то вроде этого:

class Bar;

class Foo {
public:
  const Bar* bar() const { return getBar(); }

  Bar* bar() {
   return getBar();
  }

  private:
    Bar* getBar() const {/* Actual code */ return NULL;}
};

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

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

К вашему сведению. Код, опубликованный OP, является предпочтительным методом, приведенным в «Эффективном C ++ - третье издание» Скотта Мейерса. См. Пункт № 3.

Ответ я придумал сам, немного поразмыслив. Однако я думаю, что могу улучшить его, используя идеи из ответа litb, который я опубликую позже. Итак, мое решение пока выглядит так:

class ConstOverloadAdapter {
protected:

  // methods returning pointers 

  template< 
    typename R, 
    typename T >
  R* ConstOverload(
    const R* (T::*mf)(void) const) {
      return const_cast< R* >(
        (static_cast< const T* >(this)->*mf)());
    }

  // and similar templates for methods with parameters 
  // and/or returning references or void
};

class Bar;

class Foo : public ConstOverloadAdapter {
public:
  const Bar* bar() const { 
    /* implementation */ }

  Bar* bar(void* = 0) {  // the dummy void* is only needed for msvc
                         // since it cannot distinguish method overloads
                         // based on cv-type. Not needed for gcc or comeau.
    return ConstOverload(&Foo::bar); }
};

Предполагая, что вы принимаете константную корректность как метод, я думаю, это означает, что вы предпочитаете константную корректность, проверенную компилятором, а не лаконичность. Итак, вы хотите, чтобы компилятор проверил две вещи:

1. Когда "this" не является константой, вызывающий объект может безопасно изменить ссылочный номер возвращаемого вами указателя.
2. Когда "this" является константным, любая работа, которую вы выполняете, не выполняет никаких неконстантных операций с "this".

Если версия с константой вызывает неконстантную, вы не получите (2). Если неконстантная версия вызывает константную и const_cast результат, то вы не получите (1). Например, предположим, что Bar на самом деле char, и код, который вы пишете, возвращает (в некоторых случаях) строковый литерал. Это будет компилироваться (и -Wwrite-strings не выдает предупреждения), но ваш вызывающий объект получает неконстантный указатель на строковый литерал. Это противоречит «вы предпочитаете, чтобы константная корректность проверялась компилятором».

Если они оба вызывают вспомогательную функцию-член Bar *getBar() const, вы получаете и (1), и (2). Но если можно написать эту вспомогательную функцию, то зачем вы вообще возитесь с константными и неконстантными версиями, когда совершенно нормально изменять Bar, возвращаемый из const Foo? Иногда, возможно, некоторые детали реализации означают, что вы реализуете интерфейс с двумя средствами доступа, даже если вам нужен только один. В противном случае либо помощник не может быть записан, либо две функции могут быть заменены одним единственным помощником.

Пока размер кода не вызывает беспокойства, я думаю, что лучший способ достичь и (1), и (2) - это заставить компилятор действительно учитывать оба случая:

struct Bar { int a; };
struct Foo {
          Bar *bar()       { return getBar<Bar>(this); }
    const Bar *bar() const { return getBar<const Bar>(this); }

    Bar *bar2() const { return getBar<Bar>(this); } // doesn't compile. Good.
    Bar *bar3() const { return getBar<const Bar>(this); } // likewise

    private:
    template <typename B, typename F>
    static B *getBar(F *self) {
        // non-trivial code, which can safely call other functions with 
        // const/non-const overloads, and we don't have to manually figure out
        // whether it's safe to const_cast the result.
        return &self->myBar;
    }
    Bar myBar;
};

Если код тривиален, например operator[], который обращается к некоторому массиву, принадлежащему объекту, то я бы просто продублировал код. В какой-то момент вышеупомянутый шаблон функции требует меньше усилий по кодированию, чем дублирование, и в этот момент используйте шаблон.

Я думаю, что подход const_cast, хотя и умный и, казалось бы, стандартный, просто бесполезен, потому что он предпочитает краткость проверенной компилятором корректности const. Если код в методе тривиален, вы можете его продублировать. Если это нетривиально, то вам или специалисту по сопровождению кода нелегко убедиться, что const_cast действительно действителен.

Ваш код подразумевает, что const bar () на самом деле создает и возвращает новый Bar, и я нахожу это странным, если вы так много делаете.

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

Если ваш экземпляр Bar является переменной-членом, рассмотрите возможность возврата вместо этого ссылки.

Влияет ли постоянство Bar на постоянство вашего Foo? Или вы просто делаете это потому, что нет возможности отличить версии const Bar * от Bar *? В последнем случае у меня будет только один bar (), который вернет Bar *, и с ним покончено. В конце концов, что-то, что принимает константу Bar *, в любом случае вполне может принять Bar *. Не забывайте, что постоянство методов bar () касается Foo, а не Bar.

Кроме того, если вы предлагаете как константную, так и неконстантную Bar * и счастливы, что Foo не является константой, волей-неволей, то константность вашего Foo (и, следовательно, методов bar ()), очевидно, не так важна , вы просто заполняете константные и неконстантные версии. В этом случае, если вы разрешите неконстантную версию, снова просто предложите / only / эту, потребители const с радостью примут неконстантную. Просто то, как у вас есть const и non-const, похоже, не имеет большого значения для программы.

Если вы хотите, чтобы объекты const Foo могли возвращать как константные, так и неконстантные Bar s, просто сделайте bar () const и верните неконстантный Bar.

Я не знаю, мне нужно было бы увидеть больше, чтобы дать реальный ответ.

Однако подумайте, какие константы действительно связаны и нужны ли вашей программе как const Foo, так и неконстантные Foo. Допуская все возможности волей-неволей, кажется, что вы не продумали, что требует программа.