c++ - const_cast 的仁慈案例？

Question

我已经阅读了很多关于 C++ 中的 const_cast 被认为是错误和危险的讨论，除了向后兼容 C 代码之外，不应将其用于任何其他用途。我大体上同意。
但是最近我遇到了以下用例，这让我感到好奇。
我有一些模型对象，由 Controller 拥有，通常是非常量的。我将它传递给不应修改模型对象的 View ，因此在传递给 View 时将对象声明为 const 参数是合乎逻辑的。然而， View 也会对 Controller 进行委托(delegate)回调，将模型对象作为参数传递(例如，用户单击了此对象)。回调参数也必须是 const。在回调方法中， Controller 想要对模型进行更改，但是模型是 const 的，所以它做不到。
两种解决方案:

在 Controller 的回调方法中使用 const_cast ，因为它知道模型对象是非常量的 - 但它闻起来很臭。

传递给 View 时不要将模型声明为 const 参数 - 但是我不能使用像 const 声明这样有用的工具，这在这种情况下似乎非常相关。

想法？

Answer 1

有两种处理方式const .

事情是const如果 此代码不会直接更改它们 .

事情是const如果 此代码不会更改它们 .

在这种情况下， View 不会 直接改变对象。但是你想要它 间接改变对象。
在 (2) 下，这意味着对象不是 const . View 可以间接更改对象。它可以导致对象被更改。说是const意味着 View 与对象的交互纯粹是“读取状态”，而不是更改状态——但是单击对象的“删除”按钮并使其删除是一种变异操作。
在 (1) 下，您的引用应为 const ，因为你不是自己修改它。其他人在他们有权这样做的授权下。
这是一个冲突。并且 (1) 是一种可接受的使用方式 const .但是当使用 (1) 时，你应该有 替代路线将对象作为非 const .
我们可以在 vector.erase 下看到这个。 .它(现在)需要const_iterator s。即使这些迭代器本身不允许修改 vector ，非 const *this提供允许修改的替代访问路径。
在您的情况下， Controller 拥有该对象，因此应该有一个非 const该对象的访问路径。那是你应该用来做非 const 的路径。对象的修改。
当 View 进行委托(delegate)回调时，它可能会传递一个标识符而不是一个对象——或者， Controller 可能会以某种方式从对象中提取标识符，并在它自己的对象列表中查找它。