【问题标题】:Unexpected behavior involving const_cast涉及 const_cast 的意外行为
【发布时间】:2019-10-14 11:23:28
【问题描述】:

我想出了下面的例子,它暴露了一些意想不到的行为。 我希望在 push_back 之后,向量中的任何内容都在那里。 看起来编译器以某种方式决定重用 str 使用的内存。

有人能解释一下这个例子中发生了什么吗? 这是有效的 c++ 代码吗?

最初的问题来自负责序列化/反序列化消息的代码,它使用 const_cast 来删除 constness。 在注意到该代码的一些意外行为后,我创建了这个简化的示例,试图演示该问题。

#include <vector>
#include <iostream>
#include <string>
using namespace std;
int main()
{
    auto str = std::string("XYZ"); // mutable string
    const auto& cstr(str);         // const ref to it

    vector<string> v;
    v.push_back(cstr);

    cout << v.front() << endl;  // XYZ is printed as expected

    *const_cast<char*>(&cstr[0])='*'; // this will modify the first element in the VECTOR (is this expected?)
    str[1]='#';  //

    cout << str << endl;  // prints *#Z as expected
    cout << cstr << endl; // prints *#Z as expected
    cout << v.front() << endl; // Why *YZ is printed, not XYZ and not *#Z ?

    return 0;
}

【问题讨论】:

  • 你确定?像我期望的那样为我打印 XYZ - 因为您没有修改 v 的字符串...
  • ideone.com/5EnKAZ 不能复制,但这不是 const_cast 的用途。
  • 我使用了 g++ 5.4.0 和 clang++ 4.0.0。两者都给出相同的结果~~~ ~/tmp$ g++ -std=c++14 x.cpp ~/tmp$ ./a.out XYZ *#Z *#Z *YZ ~~~
  • clang 4.0: godbolt.org/z/SoNVEk g++ 5.4: godbolt.org/z/rE73lI 仍然没有发生。
  • 我认为这里没有未定义的行为。只要数据未声明为 const,const_cast 就可以工作。据我所知,std::string 不会将其数据存储为 const 数组。

标签: c++ constants stdstring const-cast copy-on-write


【解决方案1】:

了解错误

出现意外行为的原因是 std::string 的已弃用实现中的怪癖。 旧版本的 GCC 使用 copy-on-write 语义实现了 std::string。这是一个聪明的主意,但它会导致像你看到的那样的错误。这意味着 GCC 试图定义 std::string 以便仅在修改新的 std::string 时才复制内部字符串缓冲区。例如:

std::string A = "Hello, world";
std::string B = A; // No copy occurs (yet)
A[3] = '*'; // Copy occurs now because A got modified.

但是,当您使用常量指针时,不会发生复制,因为库假定不会通过该指针修改字符串:

std::string A = "Hello, world"; 
std::string B = A;
std::string const& A_ref = A;

const_cast<char&>(A_ref[3]) = '*'; // No copy occurs (your bug)

您已经注意到,copy-on-write 语义往往会导致错误。正因为如此,并且因为复制字符串非常便宜(考虑到所有因素),std::string 的复制 copy-on-write 实现在 GCC 中被折旧和删除 5.

那么,如果您使用的是 GCC 5,为什么会看到这个错误?您很可能正在编译和链接旧版本的 C++ 标准库(即写时复制的库)依然是std::string的实现)。这就是导致您的错误的原因。

检查您正在编译的 C++ 标准库的版本,如果可能,请更新您的编译器。

我如何知道我的编译器正在使用std::string 的哪个实现?

  • 新的 GCC 实现:sizeof(std::string) == 32(针对 64 位编译时)
  • 旧 GCC 实现:sizeof(std::string) == 8(编译为 64 位时)

如果您的编译器使用的是旧的std::string 实现,那么sizeof(std::string)sizeof(char*) 相同,因为std::string 被实现为指向内存块的指针。内存块是实际包含字符串大小和容量等内容的内存块。

struct string { //Old data layout
    size_t* _data; 
    size_t size() const {
        return *(data - SIZE_OFFSET); 
    }
    size_t capacity() const {
        return *(data - CAPACITY_OFFSET); 
    }
    char const* data() const {
        return (char const*)_data; 
    }
};

另一方面,如果您使用的是std::string 的较新实现,那么sizeof(std::string) 应该是32 字节(在64 位系统上)。这是因为较新的实现将字符串的大小和容量存储在 std::string 本身中,而不是在它指向的数据中:

struct string { // New data layout
    char* _data;
    size_t _size;
    size_t _capacity; 
    size_t _padding; 
    // ...
}; 

新实施有什么好处?新实施有很多好处:

  • 可以更快地访问大小和容量(因为优化器更有可能将它们存储在寄存器中,或者至少它们很可能存储在缓存中)
  • 因为std::string 是32 字节,我们可以利用小字符串优化。小字符串优化允许将长度小于 16 个字符的字符串存储在通常由 _capacity_padding 占用的空间内。这避免了堆分配,并且对于大多数用例来说更快。

我们可以在下面看到 GDB 使用了 std::string 的旧实现,因为 sizeof(std::string) 返回 8 个字节:

【讨论】:

  • 谢谢!我还添加了一种区分旧实现和新实现的方法,这样你就可以知道哪个正在使用
  • 我深信 COW 字符串在许多层面上都是一个严重缺陷的想法(事实上,在基本块和任何简单类中的任何巧妙优化都是一个坏主意)但这显然不能一个令人信服的论点。对涉及const_cast 的错误代码的修复是避免强制转换,尊重 const 安全性,并且不要通过指针弄乱字符串数据。
  • COW 行为已被贬低和删除,并且 const_cast 在某些情况下是一个有效的决定。更新编译器将修复 COW 行为,因此我推荐它。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-01-23
  • 1970-01-01
  • 2014-06-06
相关资源
最近更新 更多