operator= in allocators

[Mark A. Gibbs]

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=(HeapA llocator<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:

"Implementation s 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

[Claudio Puviani]

"Mark A. Gibbs" <x_*********@ro gers.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

[Mark A. Gibbs]

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

[Claudio Puviani]

"Mark A. Gibbs" <x_*********@ro gers.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

[Mark A. Gibbs]

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

[Claudio Puviani]

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

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?

20.1.5 ("Allocator requirements") doesn't state copyability as a
requirement. Comparison, yes, but definitely not copying.

Claudio Puviani

[Mark A. Gibbs]

Claudio Puviani wrote:

20.1.5 ("Allocator requirements") doesn't state copyability as a
requirement. Comparison, yes, but definitely not copying.

But that makes no logical sense if containers own their allocator.

vector<int, SomeAllocator> foo()
{
SomeAllocator a;
vector<int, SomeAllocator> v(a);
return v;
}

void bar()
{
vector<int, SomeAllocator> v = foo();
// Undefined behaviour
}

And how can the containers not own their own allocator?

mark

[Howard Hinnant]

In article
<De************ *******@news01. bloor.is.net.ca ble.rogers.com> ,
"Mark A. Gibbs" <x_*********@ro gers.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?

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=(HeapA llocator<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:

"Implementation s 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?

Not at all. But it does mean you have stumbled into implementation
defined territory. Your experience could contribute to the next C++
standard.

Allocators are not required to be assignable, so you could just omit the
operator=. However, allocators are required to be equal. But however
again, implementors are encouraged to deal with non-equal allocators
(and several do).

Non-equal allocators mainly come into play during resource transferring
operations such as swap or splice, but not during container assignment.
There is an open lwg issue concerning swap here:

http://anubis.dkuug.dk/jtc1/sc22/wg2...ctive.html#431

Here is a response I have written to that issue:

http://anubis.dkuug.dk/jtc1/sc22/wg2...004/n1599.html

Neither the issue, nor the response have yet been discussed in
committee. I point them out just fyi, and also so that you have the
opportunity to join in the discussion.

-Howard

[Claudio Puviani]

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

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?

20.1.5 ("Allocator requirements") doesn't state copyability as a
requirement. Comparison, yes, but definitely not copying.

Claudio Puviani

[Mark A. Gibbs]

Claudio Puviani wrote:

20.1.5 ("Allocator requirements") doesn't state copyability as a
requirement. Comparison, yes, but definitely not copying.

But that makes no logical sense if containers own their allocator.

vector<int, SomeAllocator> foo()
{
SomeAllocator a;
vector<int, SomeAllocator> v(a);
return v;
}

void bar()
{
vector<int, SomeAllocator> v = foo();
// Undefined behaviour
}

And how can the containers not own their own allocator?

mark