问题标签 [const-correctness]

有很多问题讨论了 C 和 C++ 处理指针到 const 删除的细节，即free()不接受它们，delete并且delete[]这样做并且 const 不会阻止对象破坏。

我感兴趣的是您是否认为这样做是一种好习惯，而不是语言（C 和 C++）所允许的。

指向常量删除的参数包括：

• kfree()与 C 不同， Linus Torvalds'free()需要void const*争论，因为他认为释放内存不会影响指向的内容。
• free()是在引入 const 关键字之前设计的。
• C++ 的删除操作符允许删除 const 数据。

反对它的论点包括：

• 程序员在将指向 const 的指针传递给数据时，并不期望数据会被修改（或删除）。
• 许多人认为指向 const 的指针意味着不获得数据的所有权（但不是非 const 意味着获得所有权）。
• 这是大多数库和现有代码中常见的做法。

请在您的回答中好好论证，并可能参考当局。我的意图不是在这里开始投票。

我有一个函数（请不要关心通过引用返回临时。这只是解释问题的一个例子），

这显然不会编译。我正在寻找一种方法来确保调用者不会更改T. foo我怎样才能确保这一点？

我已经看到了类似的行为boost::shared_ptr。shared_ptr<T>可转换为const shared_ptr<const T>。我无法弄清楚它是如何做到的。

任何帮助都会很棒。

请考虑以下代码。

t是一个const变量，value()是一个返回的常量成员函数const T&。AFAIK，一个const类型不能分配给一个非常量类型。但是如何foo* f = t.value();编译得很好。这是如何发生的，我如何确保value()只能分配给const foo*？

编辑

我发现，这是在使用模板时发生的。以下代码按预期工作。

为什么使用模板时会出现问题？

这个问题与我的上一个问题有关。我正在尝试使用 traits<T> and解决问题traits<T*>。请考虑以下代码。

所以看起来编译器没有考虑指针的特征特化，而是采用value()asconst foo而不是返回类型const foo*。我在这里做错了什么？

任何帮助都会很棒！

boost::optional我有一个用于保存值的容器类。这是代码的样子，

它适用于除const. const使用类型时出现错误（const foo*工作正常）。

1. 是否boost::optional支持常量类型？如果不是，我该如何解决这个问题？
2. 是否有现成的可用特征实现可供我使用，而不是定义我自己的特征？

任何帮助都会很棒！

结构 Foo { char * DataPtr; };

Foo::DataPtr是指向对象的内部缓冲区的指针ISomeInterface。有没有办法确保Foo::DataPtrconst 版本返回的ISomeInterface::GetFoo是 a const char *？

你觉得有帮助吗？

我有以下棘手的问题：我已经实现了一个（相当复杂的）类，它在多小波基础上表示数学函数。由于像 +、- 和 * 这样的操作在这种情况下是很自然的，所以我为这个类实现了重载运算符：

这些运算符在简单的非链接操作中工作得更好，甚至在某些情况下链接运算符时。像这样的陈述

编译并且看起来工作正常。第一行实际上没问题，但第二行让 valgrind 告诉你关于在已释放区域内释放内存和访问未初始化变量的可怕故事。此外，像这样的声明

甚至不会编译，因为我还没有定义（一个模棱两可的运算符将一个实际的对象，而不是一个引用作为参数）。当然，解决方案很明确：所有参数和方法都应该设为 const，甚至可能返回一个 const 对象或引用。不幸的是，这是不可能的，因为在操作期间所涉及的对象都不是恒定的！这听起来可能很奇怪，但这是所涉及的数学不可避免的结果。我可以伪造它，使用 const_cast，但代码仍然是错误的！

有没有办法解决这个问题？我目前唯一的解决方案是将返回对象设为 const，从而有效地禁用运算符链接。

问候，.jonas。

我最近与另一位 C++ 开发人员就以下用法进行了交流const：

他觉得const以这种方式使用是一种很好的做法。

我认为它对函数的调用者没有任何作用（因为要传递参数的副本，所以在覆盖方面没有额外的安全保证）。此外，这样做可以防止实现者Foo修改参数的私有副本。因此，它既规定又宣传实施细节。

不是世界末日，但肯定不是值得推荐的好做法。

我很好奇其他人对这个问题的看法。

编辑：

好的，我没有意识到参数的常量性并没有考虑到函数的签名。因此，可以将参数标记为const实现 (.cpp)，而不是标头 (.h) - 编译器对此很好。既然如此，我想将局部变量设为 const 的策略应该是相同的。

有人可能会说，在头文件和源文件中具有不同外观的签名会混淆其他人（因为它会让我感到困惑）。虽然我尝试在写任何东西时遵循最小惊讶原则，但我想期望开发人员认为这是合法和有用的是合理的。

大约六年前，一位名叫 Harri Porten 的软件工程师写了这篇文章，提出了一个问题：“成员函数什么时候应该有 const 限定符，什么时候不应该？” 我发现这是我能找到的关于这个问题的最好的文章，我最近一直在努力解决这个问题，我认为在我发现的关于 const 正确性的大多数讨论中都没有很好地涵盖这个问题。由于当时没有像 SO 这样强大的软件信息共享网站，所以我想在这里重新提出这个问题。