c++ - 构建依赖于非 const-correct 库的 const-correct (C++) 库

Question

我正在用 C++ 构建一个库(主要是为了好玩)，我已经研究了一段时间(多年，哈哈，这只是一种爱好)

我最近将一些基础(阅读、库依赖)切换到了另一个库。不幸的是，该库根本不关心“const-correctness”。我有点强制症，我喜欢挑战自己以“正确的方式™”做事，所以我想让我的库 const-correct。我已经开始了几次，有些部分是；我知道最好从一开始就开始 const-correct 但这并不真正相关或值得辩论。事实上，我有兴趣再次认真地尝试它，但另一个图书馆阻止我这样做。

你可能会问，这是怎么回事？

好吧，如果我正在调用一个显然应该是 const 的方法(实际上并没有改变任何东西)，并且我的方法也是 const-ing(新词)的候选者，我无法确保我的方法是 const-ness直到另一个方法也是常量。

示例:

// Bad third-party library

struct Foo
{
    void should_be_const() {}
};

// My library

struct Bar
{
    Foo my_foo;
    void should_be_const() const
    {
        my_foo.should_be_const(); // ERROR!  Not a const function!
    }
};

只有根据经验证据以及我对常量性的研究和理解，这对我来说才显而易见。然而，这可能是一种错误形成的理解，所以我对它的错误和其他表现持开放态度(并且充满希望？)(尽管这会动摇我对 const-ness 的理解基础哈哈)

如果他(或她)想要编写一个合适的库但依赖项不是那样写的，那么可怜的人该怎么办？

我希望这是一个适合 SO 的问题。请(我相信你会的)让我知道它是否不是，或者是否有更好的 StackExchange 网站可以发布它。

附言我找到了 this SO question ，但我希望可以详细说明主题/解决方案。

Answer 1

您提到的另一个问题很好地说明了问题所在，但我不同意这个答案。您的子库中的界面将分为四种情况。

1. 不是 const 的东西，也不能期望是。
2. 正确声明为 const 的事物

3. 逻辑上应该是常量的东西，以及

   3a。如此实现但未如此声明

   3b。不是这样实现的

情况 1 很简单 - 如果您希望您的是 const，那么您需要在调用该接口(interface)之前复制输入。 Actor 只是错误的，最终会导致崩溃或其他错误。情况 2 不是问题。所以案例 3 是。

不幸的是，实际情况是案例 3a 和 3b 应该与案例 1 一样对待，因为它们无法区分。实现可能因平台或版本而异。所以，你应该创建一个拷贝，然后调用接口(interface)。注意我说的是“应该”。事实上，我们大多数人会使用 const_cast 来调用我们认为我们理解的接口(interface)(例如 strcmp)。它成为我们对实现的信心程度的判断。就个人而言，我不会担心 strcmp。几乎任何更高级别的东西都可以使用类似 strtok 的东西，它会破坏东西。