将u8string_view转换为char数组而不违反严格混叠? 前提问题动机我尝试过的

问题描述

前提

  • 我的内存中有一堆二进制数据,表示为char*(可以从文件中读取,也可以通过网络传输)。
  • 我知道它包含一个以UTF8编码的文本字段,该文本字段在一定的偏移处具有一定的长度。

问题

我如何(安全且方便地)获得u8string_view来表示此文本字段的内容?

动机

将字段作为u8string_view传递给下游代码的动机是:

  • string_view不同,它非常清楚地表明该文本字段是UTF8编码的。
  • 它避免了将其返回为u8string的代价(可能是免费商店分配和复制)。

我尝试过的

做到这一点的天真的方法是:

char* data = ...;
size_t field_offset = ...;
size_t field_length = ...;

char8_t* field_ptr = reinterpret_cast<char8_t*>(data + field_offset);
u8string_view field(field_ptr,field_length);

但是,如果我正确理解C ++严格别名规则,则这是未定义的行为,因为它通过char*返回的char8_t*指针访问reinterpret_cast缓冲区的内容,并且char8_t不是别名类型。

是真的吗?

有安全的方法吗?

解决方法

当您访问带有acceptable type以外的glvalue的对象时,就会发生严格的别名规则。

首先考虑一个明确定义的案例:

char* data = reinterpret_cast <char *> (new char8_t[10]{})
size_t field_offset = 0;
size_t field_length = 10;
char8_t* field_ptr = reinterpret_cast<char8_t*>(data + field_offset);
u8string_view field(field_ptr,field_length);
field [0]+field[1];

这里没有UB。创建一个char8_t数组,然后访问该数组的元素。

如果data所引用的内存对象是由另一个程序创建的,那该怎么办?根据标准,这是UB,因为该对象不是由specified way to create it之一创建的。

但是,标准尚未支持您的代码这一事实在这里不是问题。所有编译器都支持此代码。否则,您将无法进行最简单的系统调用,因为程序与任何内核之间的大部分通信都是通过char数组进行的。因此,只要在程序内部,您就可以通过data+field_offset类型的glvalue访问data+field_offset+field_lengthchar8_t之间的内存,您的代码将按预期工作。

,

同样的问题有时也会在其他情况下发生,例如使用共享内存。

使用“原始”内存中的位创建对象而不分配内存的一个技巧是通过memcpy创建本地对象,然后在“原始”内存上创建该本地对象的动态副本。示例:

char* begin_raw = data + field_offset;
char8_t* last {};
for(std::ptrdiff_t i = 0; i < field_length; i++) {
    char* current = begin_raw + i;
    char8_t local {};
    std::memcpy(&local,current,sizeof local);
    last = new (current) char8_t(local);
}
char8_t* begin = last - (field_length - 1);
std::u8string_view field(begin,field_length);

在您不想复制对象之前,请注意,最终结果不会导致“原始”内存的表示形式发生任何变化。编译器也可以注意到这一点,并且可以将整个循环编译为零指令(在我的测试中,GCC和Clang使用-O2实现了此目的)。我们所做的全部工作就是通过在内存中创建动态对象来满足语言的对象生存期规则。

相关问答

依赖报错 idea导入项目后依赖报错,解决方案:https://blog....
错误1:代码生成器依赖和mybatis依赖冲突 启动项目时报错如下...
错误1:gradle项目控制台输出为乱码 # 解决方案:https://bl...
错误还原:在查询的过程中,传入的workType为0时,该条件不起...
报错如下,gcc版本太低 ^ server.c:5346:31: 错误:‘struct...