c++ - 为什么Glib::VariantBase::store方法破坏了给定缓冲区的开始

Question

使用Glib::VariantBase的乐趣可能是无价的。但同时也带来了许多障碍。我很难理解为什么最基本的Glib::VariantBase::store方法会更改缓冲区的开始。

请假设我有足够的缓冲区分配，最好记下来:

my_beautiful_buffer = static_cast<char*>(std::malloc(1024));

然后我想在其开头添加一个uint64_t变量:

uint64_t my_humble_var = 1;
*reinterpret_cast<uint64_t*>(my_beautiful_buffer) = my_humble_var;

让我们用printf读取缓冲区

for (int i = 0; i < 8; i++) printf("0x%x ", *(unsigned char*)(my_beautiful_buffer+i));

+++++++++my_beautiful_buffer+++
0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0

让我们创建一个相当复杂的GlibVariable

using myStrangeVarType = Glib::Variant<std::map<Glib::ustring,std::map<Glib::ustring, std::tuple<Glib::VariantBase, std::uint64_t>>>>
myStrangeVarType data = createData(); // createData method statically defines variable and and copies

现在让我们存储这个新创建的变量

data.store((my_beautiful_buffer + sizeof(std::uint64_t)));

我们能否在漂亮的缓冲区中读取所有数据

for (int i = 0; i < data.get_size() + sizeof(std::uint64_t); i++) printf("0x%x ", *(unsigned char*)(m_buffer+i));

    +++++++++Data Written+++++++
    0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x61 0x70 0x70 0x49 0x64 0x31 0x2f 0x64 0x61 0x74 0x61 0x62
0x61 0x73 0x65 0x31 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x6b 0x65 0x79 0x31 0x0 0x0 0x0 0x0 0x73
0x74 0x72 0x69 0x6e 0x67 0x20 0x76 0x61 0x6c 0x75 0x65 0x0 0x0 0x73 0x0 0x62 0x67 0xbc 0x0 0x0
0x0 0x0 0x0 0xf 0x5 0x0 0x0 0x0 0x0 0x0 0x0 0x6b 0x65 0x79 0x32 0x0 0x0 0x0 0x0 0xd2 0x4 0x0
0x6e 0x0 0x0 0x0 0x0 0x62 0x67 0xbc 0x0 0x0 0x0 0x0 0x0 0x4 0x5 0x22 0x42 0x11 0x0

好吧，这时我的前8个字节发生了什么，为什么第一个字节0x1消失了？

Answer 1

通过对createData方法进行一些更改，解决了该问题。
该方法正在生成具有a{sa{s(vt)}}类型的Glib::VariantBase，显然打包和解压缩自定义类型并不是Glib::Variant真正的强项。

我必须将对象转换为v类型。问题已经解决。
这就是我改变类型的方式:

GVariant* gVariant = g_variant_new("v", value.gobj());
Glib::VariantBase variantValue = Glib::VariantBase(gVariant);
return variantValue;

更早之前，我只是在不进行任何转换的情况下返回值。

解决该问题的另一种方法是只调用 value.get_size();，然后将其返回。

value.get_size();
return value;

显然，该调用在内部导致变体被序列化。