问题标签 [const-cast]

$5.2.11/7 - "[注意：根据对象的类型，通过指针、左值或指向数据成员的指针的写操作由 const_cast 产生，该 const_cast 丢弃了 const-qualifier68)可能会产生未定义的行为 (7.1. 5.1).]"

本节 (C++03) 的措辞令我惊讶。令人惊讶的是两件事。

a) 首先，使用“may”。为什么是“可能”？标准中的其他地方对未定义的行为非常明确

b）为什么放弃最初的 const 对象的 const 性不是立即“未定义的行为”。为什么触发UB需要写入？

我有一个简单的 const 方法想要生成一个随机数

这会导致您的标准（如果已模板化）const 违规错误

/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/tr1/random.tcc:910:4：错误: 传递 'const std::tr1::mersenne_twister' 作为 'result_type std::tr1::mersenne_twister<_UIntType, __w, __n, __m, __r, __a, __u, __s, __b, __t, __c, __l>::operator()() [with _UIntType = long unsigned int, int __w = 32, int __n = 624, int __m = 397, int __r = 31, _UIntType __a = 2567483615ul, int __u = 11, int __s = 7, _UIntType __b = 2636928640ul, int __t = 15, _UIntType __c = 4022730752ul, int __l = 18, result_type = long unsigned int]' 丢弃限定符

这在没有const_caston的情况下可行this吗？

根据我的小测试，此代码有效。但是，它有未定义的行为吗？在我之前的测试中，通过使用 const_cast 修改 const 对象导致了运行时访问冲突，但我不记得它们有何不同。那么，这里是否存在根本性的问题？

（请注意 sizeof(bigLut_t) 太大而无法放入堆栈。）

编辑：我实际上最喜欢 ybungalobill 的小评论中的想法，最适合初始化这些大对象的方法：

const_cast我有一个关于 STL 容器的简单问题和最佳实践。考虑以下，其中类Foo有一个私有 STL std::mapfrom Widget*to int：

宣言：

定义：

鉴于hasWidget将引用 const 作为其参数，因此在调用时需要丢弃 const map::find（wiget_map从Wiget*to int）。据我所知，这种方法既明智又可取——但如果没有更有经验的 C++ 程序员的反馈，我不愿意接受它。

在我看来，这是为数不多的const_cast适当使用的案例之一，因为我们将强制转换的结果传递给 STL 方法。我对么？

我意识到这个问题的其他排列已经提出（例如，const_cast for vector with object）但似乎没有一个直接解决上述问题。

提前致谢。

我有以下代码：

为什么'a'的值没有变成29？这是否意味着在 const_casting b 时不会删除 a 的 const 性？

可能重复：
为什么简单的 C 代码会收到分段错误？

为什么代码片段 2 的行为不像片段 1？

PS 原谅我的无知。

谁能告诉我在主要传递给 g 时会发生什么，是 static_cast 吗？

我确信没有复制，因为上面的代码类似于下面的代码：

提前致谢 ：）

我有一个看起来像这样的遗留函数：

我需要在该遗留代码中调用一个函数，使其现在看起来像这样：

问题是我收到了这个错误：

现在我知道为了修复这个错误，我可以创建newCall()一个 const 函数。但是后来我必须进行几个newCall()函数调用，所以现在我必须将所有这些函数调用都设为 const。依此类推，直到最终我觉得我的程序的一半将是 const。

我的问题：有没有办法在 Random() 中调用不是 const 的函数？或者是否有人对如何newCall()在Random()不使我的程序一半变为常量的情况下实现内部有任何想法。

谢谢

-乔希

如果我做：

未定义的行为到底在哪里（哪一行）？

我在 SO 上搜索了很多，但没有找到任何明确和准确的答案（或者至少没有我能理解的答案）。

也相关：如果我使用提供这种功能的外部库：

可以这样写：

既然我确定read_string()永远不会尝试写信给str?

谢谢你。

最近我偶然发现了这样的代码：

显然，开发人员不知道他在做什么，但如果编译器没有默默地接受 c-style-cast 并且至少需要一个正确的const_cast，他可能会在提交之前两次。

所以这让我想到，是否有任何现代编译器有一个开关来防止const_castc 样式转换的语义？

阻止所有 c-style-casts 的发生根本不切实际，允许它们static_和reinterpret_语义（如果仅适用于某些库代码）是必要的邪恶，但我的印象是，c-style-casts 的合法使用被抛弃constness 在C++代码库中非常罕见，所以也许应该可以完全禁用它？