当前位置：文江博客话题详情

什么是 std::pair？

发布于 2024-07-05 10:22:43 字数 90 浏览 5 评论 0原文

std::pair 是什么，为什么要使用它，以及 boost::compressed_pair 带来什么好处？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

成熟稳重的好男人 2024-07-12 10:22:43

compressed_pair 使用一些模板技巧来节省空间。在 C++ 中，一个对象（小 o）不能与另一个对象具有相同的地址。

所以即使你有

struct A { };

A 的大小也不会是 0，因为 then:

A a1;
A a2;
&a1 == &a2;

会成立，这是不允许的。

但是许多编译器会执行所谓的“空基类优化”：

struct A { };
struct B { int x; };
struct C : public A { int x; };

在这里，B 和 C 具有相同的值就可以了大小，即使 sizeof(A) 不能为零。

因此，boost::compressed_pair 利用了这种优化，并且在可能的情况下，从该对中的一个或另一个类型（如果该类型为空）继承。

所以 std::pair 可能看起来像（我已经省略了很多，ctors 等）：

template<typename FirstType, typename SecondType>
struct pair {
   FirstType first;
   SecondType second;
};

这意味着如果 FirstType 或 SecondType 是 A，您的 pair 必须大于 sizeof(int)。

但如果您使用 compressed_pair，其生成的代码将类似于：

 struct compressed_pair<A,int> : private A {
    int second_;
    A first() { return *this; }
    int second() { return second_; }
 };

并且 compressed_pair 将仅与 sizeof(int) 一样大。

compressed_pair uses some template trickery to save space. In C++, an object (small o) can not have the same address as a different object.

So even if you have

struct A { };

A's size will not be 0, because then:

A a1;
A a2;
&a1 == &a2;

would hold, which is not allowed.

But many compilers will do what is called the "empty base class optimization":

struct A { };
struct B { int x; };
struct C : public A { int x; };

Here, it is fine for B and C to have the same size, even if sizeof(A) can't be zero.

So boost::compressed_pair takes advantage of this optimization and will, where possible, inherit from one or the other of the types in the pair if it is empty.

So a std::pair might look like (I've elided a good deal, ctors etc.):

template<typename FirstType, typename SecondType>
struct pair {
   FirstType first;
   SecondType second;
};

That means if either FirstType or SecondType is A, your pair<A, int> has to be bigger than sizeof(int).

But if you use compressed_pair, its generated code will look akin to:

 struct compressed_pair<A,int> : private A {
    int second_;
    A first() { return *this; }
    int second() { return second_; }
 };

And compressed_pair<A,int> will only be as big as sizeof(int).

回复收藏 0 原文

江城子 2024-07-12 10:22:43

std::pair 是一种数据类型将两个值组合在一起作为一个对象。 std::map 使用它作为键，值对。

当您学习 pair 时，您可能查看元组。它类似于pair，但用于对任意数量的值进行分组。 tuple 是 TR1 的一部分，许多编译器已将其包含在其标准库实现中。

另外，请查看 Pete Becker 所著的《C++ 标准库扩展：教程和参考》一书的第 1 章“元组”，ISBN-13：9780321412997，以获得全面的解释。

替代文本

回复收藏 0 原文

篱下浅笙歌 2024-07-12 10:22:43

有时您需要从函数返回 2 个值，而为此创建一个类通常是多余的。

std:pair 在这些情况下会派上用场。

我认为 boost:compressed_pair 能够优化掉大小为 0 的成员。
这对于图书馆中的重型模板机械最有用。

如果您直接控制类型，那就无关紧要了。

回复收藏 0 原文

水晶透心 2024-07-12 10:22:43

听到压缩对关心几个字节听起来很奇怪。但当人们考虑在哪里可以使用compressed_pair时，它实际上很重要。例如，让我们考虑一下这段代码：

boost::function<void(int)> f(boost::bind(&f, _1));

在上面的情况下使用compressed_pair可能会突然产生很大的影响。如果 boost::bind 将函数指针和占位符 _1 存储为本身的成员或本身的 std::pair 中，会发生什么？好吧，它可能会膨胀到 sizeof(&f) + sizeof(_1)。假设函数指针有 8 个字节（对于成员函数来说并不罕见）并且占位符有 1 个字节（请参阅 Logan 的回答了解原因），那么我们可能需要 9 个字节用于绑定对象。由于对齐，这在通常的 32 位系统上可能会膨胀多达 12 个字节。

boost::function 鼓励其实现应用小对象优化。这意味着对于小型仿函数，直接嵌入到boost::function对象中的一个小缓冲区用于存储仿函数。对于较大的函子，必须通过使用运算符 new 来使用堆来获取内存。在 boost 版本 1.34 左右，决定采用此优化，因为人们认为可以获得一些非常好的性能优势。

现在，对于如此小的缓冲区来说，合理的（但可能仍然很小）限制是 8 个字节。也就是说，我们非常简单的绑定对象无法放入小缓冲区中，并且需要存储operator new。如果上面的绑定对象使用 compressed_pair，它实际上可以将其大小减少到 8 个字节（对于非成员函数指针通常为 4 个字节），因为占位符只不过是一个空对象。

因此，看似仅仅为了几个字节而浪费大量思考实际上可能会对性能产生重大影响。

It can sound strange to hear that compressed_pair cares about a couple of bytes. But it can actually be important when one considers where compressed_pair can be used. For example let's consider this code:

boost::function<void(int)> f(boost::bind(&f, _1));

It can suddenly have a big impact to use compressed_pair in cases like above. What could happen if boost::bind stores the function pointer and the place-holder _1 as members in itself or in a std::pair in itself? Well, it could bloat up to sizeof(&f) + sizeof(_1). Assuming a function pointer has 8 bytes (not uncommon especially for member functions) and the placeholder has one byte (see Logan's answer for why), then we could have needed 9 bytes for the bind object. Because of aligning, this could bloat up to 12 bytes on a usual 32bit system.

boost::function encourages its implementations to apply a small object optimization. That means that for small functors, a small buffer directly embedded in the boost::function object is used to store the functor. For larger functors, the heap would have to be used by using operator new to get memory. Around boost version 1.34, it was decided to adopt this optimization, because it was figured one could gain some very great performance benefits.

Now, a reasonable (yet, maybe still quite small) limit for such a small buffer would be 8 bytes. That is, our quite simple bind object would not fit into the small buffer, and would require operator new to be stored. If the bind object above would use a compressed_pair, it can actually reduce its size to 8 bytes (or 4 bytes for non-member function pointer often), because the placeholder is nothing more than an empty object.

So, what may look like just wasting a lot of thought for just only a few bytes actually can have a significant impact on performance.

回复收藏 0 原文