分配器感知的容器分配是如何实现的? [英] How is allocator-aware container assignment implemented?

查看:29
本文介绍了分配器感知的容器分配是如何实现的?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

例如,来自 C++ 参考中的 std::deque::operator =:
(1) 复制赋值 (const std::deque &other)

For example, from std::deque::operator = in C++ Reference:
(1) Copy Assignment (const std::deque &other)

用其他内容的副本替换内容.
如果std::allocator_traits::propagate_on_container_copy_assignment() 是true,目标分配器被源的副本替换分配器.如果目标分配器和源分配器不比较相等,目标(*this)分配器用于释放内存,然后其他的分配器用于在复制之前分配它元素.

Replaces the contents with a copy of the contents of other.
If std::allocator_traits::propagate_on_container_copy_assignment() is true, the target allocator is replaced by a copy of the source allocator. If the target and the source allocators do not compare equal, the target (*this) allocator is used to deallocate the memory, then other's allocator is used to allocate it before copying the elements.

如果this->get_allocator() == other.get_allocator(),如果需要,我可以简单地销毁和释放this'元素,或者分配和构造元素如果需要,或者如果需要,将元素从 other 复制分配到 *this.
但如果不是呢?上面的引用是否意味着我不能复制分配元素,所以我必须首先使用 this->get_allocator() 销毁和释放所有元素,然后分配和构造元素,使用 other.get_allocator()?
但如果是这样,我为什么要使用 other.get_allocator() 进行分配?
以后会不会导致一些运行时错误,因为this 不会正确释放内存?

If this->get_allocator() == other.get_allocator(), I can simply destroy and deallocate this' elements if needed, or allocate and construct elements if needed, or copy-assign the elements from other to *this if needed.
But what if not? Does the quote above mean that I can't copy-assign the elements, so I have to destroy and deallocate ALL the elements first, using this->get_allocator(), and then allocate and construct the elements, using other.get_allocator()?
But if that is the case, why should I use other.get_allocator() for the allocation?
Won't it cause some runtime error later, as this won't deallocate the memory properly?

(2) 移动分配 (std::deque &&other)

替换其他内容使用移动语义(即 other 中的数据从 other 移动到这个容器).之后 other 处于有效但未指定的状态.如果std::allocator_traits::propagate_on_container_move_assignment()为真,目标分配器被源的副本替换分配器.如果它是 false 并且源和目标分配器都这样做不比较相等,目标不能获得源的所有权内存并且必须单独移动分配每个元素,分配根据需要使用自己的分配器额外的内存.无论如何,所有最初出现在 *this 中的元素要么被破坏要么被替换通过元素移动赋值.

Replaces the contents with those of other using move semantics (i.e. the data in other is moved from other into this container). other is in a valid but unspecified state afterward. If std::allocator_traits::propagate_on_container_move_assignment() is true, the target allocator is replaced by a copy of the source allocator. If it is false and the source and the target allocators do not compare equal, the target cannot take ownership of the source memory and must move-assign each element individually, allocating additional memory using its own allocator as needed. In any case, all element originally present in *this are either destroyed or replaced by elementwise move-assignment.

如果this->get_allocator() == other.get_allocator(),这是一个简单的任务.
但如果不是,则遵循上述相同的问题,除了在这种情况下使用移动赋值.

If this->get_allocator() == other.get_allocator(), this is an easy task.
But if not, the same questions above follow, except in this case move-assignment is used.

在这两种情况下,我还有一个问题.
如果元素既不能复制分配也不能移动分配,是否可以销毁它并从其他元素构造?如果是,我应该使用谁的分配器?

In both cases, I have an additional question.
If the elements can neither be copy-assigned or move-assigned, is it okay to destroy it and construct from other? If it is, whose allocator should I use?

推荐答案

POCCA (propagate-on-container-copy-assignment) 分配器作为容器复制分配的一部分进行复制分配.同样,当容器的移动被分配时,一个 POCMA 分配器被移动分配.

A POCCA (propagate-on-container-copy-assignment) allocator is copy-assigned as part of the container's copy assignment. Likewise, a POCMA allocator is move-assigned when the container's move assigned.

上面的引用是否意味着我不能复制分配元素,所以我必须首先使用 this->get_allocator() 销毁和释放所有元素,然后分配并使用 other.get_allocator()?

Does the quote above mean that I can't copy-assign the elements, so I have to destroy and deallocate ALL the elements first, using this->get_allocator(), and then allocate and construct the elements, using other.get_allocator()?

正确.

但如果是这样,我为什么要使用 other.get_allocator 进行分配?以后会不会导致一些运行时错误,因为 this->get_allocator() 不会正确释放内存?

But if that is the case, why should I use other.get_allocator for the allocation? Won't it cause some runtime error later, as this->get_allocator() won't deallocate the memory properly?

因为赋值会传播分配器:赋值之后,this->get_allocator()other.get_allocator()的副本,所以可以安全deallocate由它分配的内存.

Because the assignment propagates the allocator: after the assignment, this->get_allocator() is a copy of other.get_allocator(), so it can safely deallocate memory allocated by it.

如果this->get_allocator() == other.get_allocator(),这是一个简单的任务.但如果不是,则遵循上述相同的问题,除了在这种情况下使用移动赋值.

If this->get_allocator() == other.get_allocator(), this is an easy task. But if not, the same questions above follow, except in this case move-assignment is used.

实际上,这是完全不同的.使用 POCMA 分配器进行移动分配是微不足道的:您销毁 *this 中的所有元素,释放内存,并掠夺 other 的内存和分配器.

Actually, this is completely different. Move assignment with a POCMA allocator is trivial: you destroy all the elements in *this, free the memory, and plunder the memory and allocator of other.

容器移动分配必须求助于元素移动分配/构造的唯一情况是当您有一个非 POCMA 分配器并且分配器比较不相等时.在这种情况下,所有分配和构造都使用 this->get_allocator() 完成,因为您不传播任何内容.

The only case where container move assignment has to resort to element-wise move assignment/construction is when you have a non-POCMA allocator and the allocators compare unequal. In that case, all allocation and construction are done with this->get_allocator() since you don't propagate anything.

在这两种情况下,我还有一个问题.如果元素既不能复制分配也不能移动分配,是否可以销毁它并从其他元素构造?如果是,我应该使用谁的分配器?

In both cases, I have an additional question. If the elements can neither be copy-assigned or move-assigned, is it okay to destroy it and construct from other? If it is, whose allocator should I use?

使用它最初构造的分配器销毁它;使用将被销毁的分配器构造它.换句话说,如果您正在传播分配器,则使用目标分配器销毁它并使用源分配器构造它.

Destroy it using the allocator it was originally constructed with; construct it using the allocator it will be destroyed with. In other words, if you are propagating the allocator, then destroy it with the target allocator and construct with the source allocator.

这篇关于分配器感知的容器分配是如何实现的?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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