Const C ++ DRY策略

为了避免与C ++ const无关的重复，在某些情况下const_cast可以工作，但返回非const的私有const函数不起作用？

在Scott Meyers的有效C ++项目3中，他建议将const_cast与静态强制转换结合使用可以是避免重复代码的有效且安全的方法，例如

const void* Bar::bar(int i) const
{
  ...
  return variableResultingFromNonTrivialDotDotDotCode;
}
void* Bar::bar(int i)
{
  return const_cast<void*>(static_cast<const Bar*>(this)->bar(i));
}

Meyers继续解释说，让const函数调用非const函数是危险的。

下面的代码是一个反例，显示：

• 与Meyers的建议相反，有时将const_cast与静态强制转换结合使用是危险的
• 有时让const函数调用非const的危险性较小
• 有时两种使用const_cast的方式都可能隐藏有用的编译器错误
• 避免const_cast并让其他const私有成员返回非const是另一种选择

避免代码重复的const_cast策略中的一种是否被视为良好实践？您愿意使用私有方法策略吗？在某些情况下，const_cast可以工作，但私有方法不能工作吗？还有其他选择（除了重复）吗？

我对const_cast策略的担心是，即使编写时代码正确，以后在维护期间代码也可能变得不正确，并且const_cast将隐藏有用的编译器错误。似乎普通的私有功能通常更安全。

class Foo
{
  public:
    Foo(const LongLived& constLongLived, LongLived& mutableLongLived)
    : mConstLongLived(constLongLived), mMutableLongLived(mutableLongLived)
    {}

    // case A: we shouldn't ever be allowed to return a non-const reference to something we only have a const reference to

    // const_cast prevents a useful compiler error
    const LongLived& GetA1() const { return mConstLongLived; }
    LongLived& GetA1()
    {
      return const_cast<LongLived&>( static_cast<const Foo*>(this)->GetA1() );
    }

    /* gives useful compiler error
    LongLived& GetA2()
    {
      return mConstLongLived; // error: invalid initialization of reference of type 'LongLived&' from expression of type 'const LongLived'
    }
    const LongLived& GetA2() const { return const_cast<Foo*>(this)->GetA2(); }
    */

    // case B: imagine we are using the convention that const means thread-safe, and we would prefer to re-calculate than lock the cache, then GetB0 might be correct:

    int GetB0(int i) { return mCache.Nth(i); }
    int GetB0(int i) const { return Fibonachi().Nth(i); }

    /* gives useful compiler error
    int GetB1(int i) const { return mCache.Nth(i); } // error: passing 'const Fibonachi' as 'this' argument of 'int Fibonachi::Nth(int)' discards qualifiers
    int GetB1(int i)
    {
      return static_cast<const Foo*>(this)->GetB1(i);
    }*/

    // const_cast prevents a useful compiler error
    int GetB2(int i) { return mCache.Nth(i); }
    int GetB2(int i) const { return const_cast<Foo*>(this)->GetB2(i); }

    // case C: calling a private const member that returns non-const seems like generally the way to go

    LongLived& GetC1() { return GetC1Private(); }
    const LongLived& GetC1() const { return GetC1Private(); }

  private:
    LongLived& GetC1Private() const { /* pretend a bunch of lines of code instead of just returning a single variable*/ return mMutableLongLived; }

    const LongLived& mConstLongLived;
    LongLived& mMutableLongLived;
    Fibonachi mCache;
};

class Fibonachi
{ 
    public:
      Fibonachi()
      {
        mCache.push_back(0);
        mCache.push_back(1);
      }

      int Nth(int n) 
      {
        for (int i=mCache.size(); i <= n; ++i)
        {
            mCache.push_back(mCache[i-1] + mCache[i-2]);
        }
        return mCache[n];
      }

      int Nth(int n) const
      {
          return n < mCache.size() ? mCache[n] : -1;
      }
    private:
      std::vector<int> mCache;
};

class LongLived {};

当实现仅根据返回的ptr / reference是否为const而有所不同的const和非const成员函数时，最佳的DRY策略是：

1. 如果编写访问器，请考虑您是否真的需要访问器，请参阅cmaster的答案和http://c2.com/cgi/wiki？
2. 如果琐碎，只需复制代码（例如，返回一个成员）
3. 永远不要使用const_cast来避免与const相关的重复
4. 为了避免非平凡的重复，请使用私有const函数，该函数将返回const和non-const公共函数都调用的非const

例如

public:
  LongLived& GetC1() { return GetC1Private(); }
  const LongLived& GetC1() const { return GetC1Private(); }
private:
  LongLived& GetC1Private() const { /* non-trivial DRY logic here */ }

我们将此称为返回非常量模式的私有const函数。

这是避免直接重复的最佳策略，同时仍允许编译器执行潜在有用的检查并报告与const相关的错误消息。

是的，您是对的：许多尝试const正确性的C ++程序都完全违反了DRY原理，即使返回非const的私有成员也有点过于舒适。

但是，您会错过一个观察结果：const正确性导致的代码重复仅在您向数据成员授予其他代码访问权限时才成为问题。这本身违反了封装。通常，这种代码重复大多发生在简单的访问器中（毕竟，您是将访问权移交给已经存在的成员，返回值通常不是计算的结果）。

我的经验是，好的抽象并不倾向于包含访问器。因此，我通过定义实际起作用的成员函数而不仅仅是提供对数据成员的访问，从而很大程度上避免了这个问题。我尝试对行为而不是数据进行建模。我的主要目的是实际上从我的类及其单个成员函数中获得一些抽象，而不是仅仅将我的对象用作数据容器。但是，这种样式在避免大量在大多数代码中如此常见的const / non-const重复单行访问器方面也很成功。