给定对副本构造的要求,如何在C ++ 11中编写有状态的分配器? [英] How can I write a stateful allocator in C++11, given requirements on copy construction?

查看:100
本文介绍了给定对副本构造的要求,如何在C ++ 11中编写有状态的分配器?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

据我所知,C ++ 11标准第17.6.3.5节的表28列出了与STL
容器一起使用的分配器的要求。

As far as I can tell, the requirements on an allocator to be used with STL containers are laid out in Table 28 of section 17.6.3.5 of the C++11 standard.

我对其中一些需求之间的相互作用有些困惑。
给定类型 X 是类型 T 的分配器,类型 Y ,即类型 U ,实例 a 对应分配器类 c>, a1 a2
X ,以及实例 b Y 的实例,该表显示:

I'm a bit confused about the interaction between some of these requirements. Given a type X that is an allocator for type T, a type Y that is "the corresponding allocator class" for type U, instances a, a1, and a2 of X, and an instance b of Y, the table says:


  1. 表达式 a1 == a2 的计算结果为 true 只有从 a1 分配的
    可以由 a2 释放的存储,反之亦然。

  1. The expression a1 == a2 evaluates to true only if storage allocated from a1 can be deallocated by a2, and vice versa.

表达式 X a1(a); 格式正确,不会通过异常退出,
及其后 a1 == a 是真的。

The expression X a1(a); is well-formed, doesn't exit via an exception, and afterward a1 == a is true.

表达式 X a(b)格式正确,不会通过异常退出,并且之后
a == b

The expression X a(b) is well-formed, doesn't exit via an exception, and afterward a == b.

我的意思是,所有分配器都必须以
的方式可复制构造,从而使副本可与o互换原始的。更糟糕的是,跨类型边界的
相同。这似乎是一个相当繁重的要求。据我所知,
使得不可能使用大量类型的分配器。

I read this as saying that all allocators must be copy-constructible in such a way that the copies are interchangeable with the originals. Worse, the same true across type boundaries. This seems to be a pretty onerous requirement; as far as I can tell, it makes impossible a large number of types of allocators.

例如,说我有一个想要的自由列表类在我的分配器
中使用,以缓存释放的对象。除非缺少某些内容,否则
不能在分配器中包含该类的实例,因为 T U 可能有所不同,因此自由列表条目与
不兼容。

For example, say I had a freelist class that I wanted to use in my allocator, in order to cache freed objects. Unless I'm missing something, I couldn't include an instance of that class in the allocator, because the sizes or alignments of T and U might differ and therefore the freelist entries are not compatible.

我的问题:


  1. 我上面的解释正确吗?

  1. Are my interpretations above correct?

我读过在某些地方,C ++ 11改进了对有状态
分配器的支持。鉴于这些限制,情况如何?

I've read in a few places that C++11 improved support for "stateful allocators". How is that the case, given these restrictions?

您对我要尝试的事情有什么建议吗?
做?也就是说,如何在分配器中包括特定于分配类型的状态?

Do you have any suggestions for how to do the sort of thing I'm trying to do? That is, how do I include allocated-type-specific state in my allocator?

通常,分配器周围的语言似乎很草率。 (例如,表28的
序言假定 a 的类型为 X& ,但是某些
表达式重新定义了 a 。)此外,至少GCC的支持不合格。
是什么导致这种围绕分配器的怪异?

In general, the language around allocators seems sloppy. (For example, the prologue to Table 28 says to assume that a is of type X&, but some of the expressions redefine a.) Also, at least GCC's support is non-conformant. What accounts for this weirdness around allocators? Is it just an infrequently used feature?


推荐答案


1)我的上述解释正确吗?

1) Are my interpretations above correct?

您是对的,您的自由列表可能不是一个好选择适合分配器,它需要能够处理多个大小(和对齐方式)以适合分配器。对于自由列表来说,这是一个问题。

You are right that your free-list might not be a good fit for allocators, it need be able to handle multiple sizes (and alignments) to fit. That's a problem for the free-list to solve.


2)我在一些地方读到了C ++ 11改进的支持用于有状态分配器。鉴于这些限制,情况如何?

2) I've read in a few places that C++11 improved support for "stateful allocators". How is that the case, given these restrictions?

这不是天生的进步。在C ++ 03中,该标准仅推动实现者提供支持非相等实例和实现者的分配器,从而有效地使有状态分配器不可移植。

It is not so much improved, than born. In C++03 the standard only nudged implementers toward providing allocators which could support non-equal instances and implementers, effectively making stateful allocators non-portable.


3)您对我想做的事情有什么建议吗?也就是说,如何在分配器中包括特定于分配类型的状态?

3) Do you have any suggestions for how to do the sort of thing I'm trying to do? That is, how do I include allocated-type-specific state in my allocator?

您的分配器可能必须灵活,因为您不应该确切知道应该分配什么内存(和什么类型)。要使您(用户)与使用分配器的某些容器的内部隔离,例如 std :: list std,此要求是必需的:: set std :: map

Your allocator may have to be flexible, because you are not supposed to know exactly what memory (and what types) it is supposed to allocate. This requirement is necessary to insulate you (the user) from the internals of some of the container that uses the allocator such as std::list, std::set or std::map.

您仍然可以使用此类分配器使用简单的容器,例如 std :: vector std :: deque

You can still use such allocators with simple containers such as std::vector or std::deque.

是的,这是一个昂贵的要求。

Yes, it is a costly requirement.


4)通常,分配器周围的语言似乎很草率。 (例如,表28的序言假设a是X&类型,但某些表达式重新定义了a。)而且,至少GCC的支持不合格。是什么导致这种围绕分配器的怪异?

4) In general, the language around allocators seems sloppy. (For example, the prologue to Table 28 says to assume that a is of type X&, but some of the expressions redefine a.) Also, at least GCC's support is non-conformant. What accounts for this weirdness around allocators? Is it just an infrequently used feature?

通常,该标准并不完全容易理解,不仅仅是分配器。您必须要小心。

The Standard in general is not exactly easy to read, not only allocators. You do have to be careful.

要想学究,gcc不支持分配器(它是编译器)。我猜想您是在谈论libstdc ++(gcc附带的标准库实现)。 libstdc ++是 old ,因此它是针对C ++ 03量身定制的。它已针对C ++ 11进行了修改,但尚未完全符合要求(例如,仍对字符串使用写时复制)。原因是libstdc ++十分关注二进制兼容性,而C ++ 11要求进行的许多更改都会破坏这种兼容性。因此必须仔细介绍它们。

To be pedant, gcc does not support allocators (it's a compiler). I surmise that you are speaking about libstdc++ (the Standard Library implementation shipped with gcc). libstdc++ is old, and thus it was tailored to C++03. It has been adapted toward C++11, but is not fully conformant yet (still uses Copy-On-Write for strings, for example). The reason is that libstdc++ has a huge focus on binary compatibility, and a number of changes required by C++11 would break this compatibility; they must therefore be introduced carefully.

这篇关于给定对副本构造的要求,如何在C ++ 11中编写有状态的分配器?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆