当（反）序列化 Boost 的多精度整数时，我们很清楚有两种可能性。
-
方法一 - 依赖当前后端的实现
if (bytes.size() < 32) { // 解压存档容器
字节.resize(32);
memcpy(bytes.data() + (32 - bytes.size()), bytes.data(),
字节大小());
}
if (bytes.size() % sizeof(mp::limb_type))
抛出 std::Exception("len % sizeof(mp::limb_type)");
BigInt 我;
uint32_t 大小 = (uint32_t)bytes.size() / sizeof(mp::limb_type);
i.backend().resize(大小, 大小);
memcpy(i.backend().limbs(), bytes.data(), bytes.size());
i.backend().normalize();
返回我；
- 。
<预><代码> BigInt i;
{
std::vector;字符{bytes.begin(), bytes.end()};
io::stream_buffer; bb(chars.data(), chars.size());
升压::存档::binary_iarchive ia(
bb, ba::no_header | bb, ba::no_header | ba::no_tracking | ba::no_tracking | ba::no_codecvt);
ia>>我;
}
方法一是不可接受的，因为它依赖于当前的本机字节序和 Boost 的当前实现（正如我们所学到的困难方法）。
第二种方法，除了在序列化时产生奇怪的头字节（我们可以去掉 0，这没有问题），但这也依赖于当前 Boost 的实现。
我们想要的是能够在纯字节向量之间来回执行整数（反）序列化，而无需额外的元数据，以便我们可以对该向量执行任意操作，并放心我们正在操作的是一个普通的、小端编码的整数。再次强调，该方法应保证是 Little Endian 且与当前后端的实现无关。最后，我们希望能够抛出该（Big-Endian 编码）字节向量，并使其再次成为 Boost 的大整数。
当使用序列化接口时，我们不能简单地放置一个 32 字节整数（如一个字节向量）进入反序列化接口，因为它似乎需要额外的元数据/Boost特定格式。
此外，我们不能使用依赖于后端的方法 1，因为我们需要了解当前 Boost 的后端实现和本机字节序。
我们可以在知道本机字节序的情况下手动反转字节序，但是，依赖 Boost 当前后端实现的黑客方法是不可接受的（我们已经通过惨痛的教训了解到它可能会改变）。
文档说
那么您将需要创建一个迭代器适配器，将其呈现在
本机顺序（请参阅 Boost.Endian）。
导致空白页。
boosts 文档具体指出：
请注意，此函数针对数据可以的情况进行了优化
从源到整数进行 memcpy - 在这种情况下都是
迭代器大多是指针，并且所有内容都必须是小尾数
可能的解决方案（单行）：
export_bits(i, std::back_inserter(字节), 8);
用于序列化
和
import_bits(j, bytes.begin(), bytes.end());
用于反序列化。
在 Boost 的代码注释中，上面的代码始终首先输出最高有效字节（意味着大端字节序……我们需要小端字节序）。然而..你瞧，同一页面上的相同文档指出，根据平台（Boost.Endian）要使用额外的设备
，上面保证可以在任何平台上输出Big-Endian字节以及 Boost 的未来和过去版本（也许要求太多，但你明白我们的意思）。我们只是依靠特定于后端的解决方案来查看生成的公钥，而不是预期的那样......
然后我们似乎缺少的是输入和输出迭代器的示例在写入每个块之前进行自定义转换。
事实证明...export_bits 和 import_bits 函数有一个 msv_first 标志；只是等待根据一个人想要的字节序被轻弹。
再一次，等待@Sehe，好人的到来..
We are well aware of two possibilities when (de)serializing Boost's multi-precision integers.
-
method one - rely on the current backends' implementation
if (bytes.size() < 32) { // unpack the archived container
bytes.resize(32);
memcpy(bytes.data() + (32 - bytes.size()), bytes.data(),
bytes.size());
}
if (bytes.size() % sizeof(mp::limb_type))
throw std::exception("len % sizeof(mp::limb_type)");
BigInt i;
uint32_t size = (uint32_t)bytes.size() / sizeof(mp::limb_type);
i.backend().resize(size, size);
memcpy(i.backend().limbs(), bytes.data(), bytes.size());
i.backend().normalize();
return i;
-
by using the serialization interface.
BigInt i;
{
std::vector<char> chars{bytes.begin(), bytes.end()};
io::stream_buffer<io::array_source> bb(chars.data(), chars.size());
boost::archive::binary_iarchive ia(
bb, ba::no_header | ba::no_tracking | ba::no_codecvt);
ia >> i;
}
Method one is unacceptable as it relies on both the current native endianness and the current implementation of Boost (as we've learned the Hard Way).
The second method, besides producing strange header bytes when serializing (we can get rid of 0s that's no problem) but yet again this also relies on current Boost's implementation.
What we want is the ability to perform back and forth (de)serialization of integers, to and from a plain byte vector, with no additional meta-data, so that we could perform arbitrary operations on that vector and rest assured that what we're manipulating is a plain, little endian-encoded integer. Yet again, the method shall be guaranteed to be both Little Endian and current back-end's implementation agnostic. At the end, we want to be able to throw that (Big-Endian encoded) byte vector and make it a Boost's Big Integer yet again.
When using the serialize interface we can't simply put a 32byte integer (as a byte vector) into the deserialize interface as it seemingly expects additional meta-data/Boost-specific format.
Also we can't use method 1 relying on backend as we would need to be aware o both the current Boost's backend implementation and the native endianness.
We could reverse endianness manually knowing the native endianness, still, the hacky approach of relying on Boost's current backends' implementation in not acceptable (we've already learned the hard way that it MAY change).
The documentation says
then you will need to create an iterator adaptor that presents it in
native order (see Boost.Endian).
leading to a blank page.
The boosts documentation states specifically:
Note that this function is optimized for the case where the data can
be memcpy'ed from the source to the integer - in this case both
iterators much be pointers, and everything must be little-endian
Possible solution (a one-liner):
export_bits(i, std::back_inserter(bytes), 8);
for serialization
and
import_bits(j, bytes.begin(), bytes.end());
for deserialization.
In Boost's in-code comments state that the above outputs Most-Significant bytes first ALWAYS (meaning Big Endian ... we need little endian). YET.. lo and behold same documentation on the vert same page states that additional apparatus is to be used depending on platform (the Boost.Endian)
is the above guaranteed to output Big-Endian bytes on any platform and across future and past versions of Boost (maybe asking too much but you get our point). We just relied on the backend-specific solution just to see public-keys generated not as they were expected to be...........
What we seem to be missing then is an example of both input and output iterators doing custom conversion before each chunk is written.
As it turns out... the export_bits and import_bits functions have a msv_first flag ; just waiting to be flicked depending on the endianness one desires.
Yet again, waiting for @Sehe, the Good Folk to come around..
发布评论
评论（1）
暂时假设 BigInt 是 boost::multi precision::cpp_int 的别名：
Prints
当然，加载也是类似的。遗憾的是，我们必须向 Boost Multi precision 传授有关
big_uint32_t1 的知识：但它只是：
现场演示
Live On Compiler Explorer
打印
1 注意：不要专门化
std::make_unsigned: “添加专门化的程序的行为make_unsigned 未定义”Assuming for the moment that BigInt is an alias for
boost::multiprecision::cpp_int:Prints
Of course, loading is similar. Sadly, we have to teach Boost Multiprecision about
big_uint32_t¹:But then it is just:
Live Demo
Live On Compiler Explorer
Prints
¹ beware: do NOT specialize
std::make_unsigned: "The behavior of a program that adds specializations for make_unsigned is undefined"