operator = in allocators [英] operator= in allocators

查看:58
本文介绍了operator = in allocators的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在制作标准分配器方面又遇到了麻烦。什么

行为应该从分配运营商那里预期?什么时候会被叫到
?为什么它在那里,当你不能改变

容器中的分配器?


为了更深入一点,我有类似的课程这个:


类HeapAllocator

{

//满足分配器接口的所有要求:

// - 传递堆引用的构造函数

// - 一个返回对内部堆的引用的GetHeap函数

//(可以永远不会是0)


私人:

可变堆* heap_;

};


现在,我希望将heap_定义为Heap&,但我不能因为:


模板< class U>

HeapAllocator& operator =(HeapAllocator< U> const& ha)/ * throw()* /

{

heap_ = ha.heap_;

}


这是一个烦恼,但不是一个大问题。

对我来说是一个优雅和稳健的问题。在什么

的情况下我可以期望调用operator =(除了在一个容器中的
operator =)?在一个堆中分配的内存不能在另一个堆中释放(运算符==测试堆相等性)。我是否保证所有分配都将由正确的

分配器解除分配(或者更具体地说是分配器分配A

将只有A或其他分配器B解除分配B ==

A) - 即,这是一个要求吗?


我很小受到20.1.5.4中声明的干扰:


本国际标准中描述的容器实现

允许假设其Allocator模板参数符合

以下两个额外要求....


- 给定分配器类型的所有实例都需要

可互换且总是比较相等。


这是否意味着我基本上在浪费时间?


mark

解决方案

" Mark A. Gibbs" < X _ ********* @ rogers.com_x>写了

我在制作
标准分配器时又遇到了麻烦。分配运营商应该期待什么样的行为?什么时候会被叫?为什么它在那里呢?
你不能用容器改变分配器吗?

[休息时间]




复制分配器意味着什么?如果您的答案是,那就是

毫无意义 - 我希望如此 - 那么你不应该提供应对

操作。只需声明复制构造函数和operator = as private,并且

不要实现它们。并非所有对象都应该具有值语义,并且

分配器是一个很好的例子。


Claudio Puviani


< blockquote>


Claudio Puviani写道:

复制分配器意味着什么?如果你的回答是,它是无意义的 - 正如我希望的那样 - 那么你不应该提供应对措施。只需声明复制构造函数和operator = as private,并且不执行它们。并非所有对象都应该具有值语义,并且
分配器是一个很好的例子。




我同意,这实际上是我的问题的基础。 Aren''t operator =和

分配器接口所需的复制构造函数?


mark


" Mark A. Gibbs" < X _ ********* @ rogers.com_x>写了

我在制作
标准分配器时又遇到了麻烦。分配运营商应该期待什么样的行为?什么时候会被叫?为什么它在那里呢?
你不能用容器改变分配器吗?

[休息时间]




复制分配器意味着什么?如果您的答案是,那就是

毫无意义 - 我希望如此 - 那么你不应该提供应对

操作。只需声明复制构造函数和operator = as private,并且

不要实现它们。并非所有对象都应该具有值语义,并且

分配器是一个很好的例子。


Claudio Puviani


I''m having yet another headache with making a standard allocator. What
behaviour should be expected from the assigment operator? When would it
be called? Why is it there at all, when you can''t change allocators in
containers?

To give a little more depth, I have a class like this:

class HeapAllocator
{
// All requirements of the allocator interface are met along with:
// - A constructor to pass in a heap reference
// - A GetHeap function that returns a reference to the internal heap
// (which can never be 0)

private:
mutable Heap* heap_;
};

Now, I would have liked to define heap_ as a Heap&, but I can''t because of:

template <class U>
HeapAllocator& operator=(HeapAllocator<U> const& ha) /*throw()*/
{
heap_ = ha.heap_;
}

Which is an annoyance but otherwise not that big of an issue. The
problem for me is one of elegance and robustness. Under what
circumstances could I expect operator= to be called (aside from in
operator= in a container)? Memory allocated in one heap cannot be
deallocated in another (operator== tests for heap equality). Am I
guaranteed that all allocations would be deallocated by the correct
allocator (or to put it more specifically allocations by an allocator A
will only be deallocated by A or by another allocator B for which B ==
A) - ie, is this a requirement?

I''m a little disturbed by the statement in 20.1.5.4:

"Implementations of containers described in this International Standard
are permitted to assume that their Allocator template parameter meets
the following two additional requirements....

- All instances of a given allocator type are required to be
interchangeable and always compare equal to each other."

Does this mean that I am essentially wasting my time?

mark

解决方案

"Mark A. Gibbs" <x_*********@rogers.com_x> wrote

I''m having yet another headache with making a
standard allocator. What behaviour should be
expected from the assigment operator? When
would it be called? Why is it there at all, when
you can''t change allocators in containers?

[rest snipped]



What does copying an allocator mean to you? If your answer is, "it''s
meaningless" -- as I hope it is -- then you shouldn''t provide coping
operations. Just declare the copy constructor and operator= as private and
don''t implement them. Not all objects should have value semantics, and
allocators are a prime example.

Claudio Puviani




Claudio Puviani wrote:

What does copying an allocator mean to you? If your answer is, "it''s
meaningless" -- as I hope it is -- then you shouldn''t provide coping
operations. Just declare the copy constructor and operator= as private and
don''t implement them. Not all objects should have value semantics, and
allocators are a prime example.



I agree, that''s actually the basis for my question. Aren''t operator= and
the copy constructor required for the allocator interface?

mark


"Mark A. Gibbs" <x_*********@rogers.com_x> wrote

I''m having yet another headache with making a
standard allocator. What behaviour should be
expected from the assigment operator? When
would it be called? Why is it there at all, when
you can''t change allocators in containers?

[rest snipped]



What does copying an allocator mean to you? If your answer is, "it''s
meaningless" -- as I hope it is -- then you shouldn''t provide coping
operations. Just declare the copy constructor and operator= as private and
don''t implement them. Not all objects should have value semantics, and
allocators are a prime example.

Claudio Puviani


这篇关于operator = in allocators的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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