[Dune] allocators... dingleton vs. instance
Carsten Gräser
graeser at math.fu-berlin.de
Thu Oct 4 11:08:29 CEST 2012
Am 04.10.2012 10:40, schrieb Markus Blatt:
> Hi,
>
> On Wed, Oct 03, 2012 at 08:44:31PM +0200, Carsten Gräser wrote:
>
>> Am 02.10.2012 22:32, schrieb Christian Engwer:
>>> Dear all,
>>>
>>> I'm currently puzzled... and I couldn't find an answer in the
>>> standard.
>>>
>>> Assume the following:
>>>
>>> AllocatorType<Foo> alloc1;
>>> AllocatorType<Foo> alloc2;
>>> Foo * f = alloc1.allocate(1);
>>> alloc2.deallocate(f,1);
>>
>> Hello Christian,
>> the standard (98) does discuss the issue, however in a very
>> unsatisfying way:
>>
>> Section 20.1.5 (Allocator requirements) clause 2 says that two
>> allocators compare equal if storage allocated by one can be
>> deallocated by the other. But it does _in general_ not require
>> that two distinct instances compare equal.
>>
>> (*) However, clause 4 says that all container classes defined in
>> the stl are permitted to additionally require that two instances
>> of the same type always compare equal. Then clause 5 imposes
>> a very weak restriction to this exception:
>>
>> Implementors are encouraged to supply libraries that can accept
>> allocators that encapsulate more general memory models and
>> that support non-equal instances. [...]
>>
>> In C++11 exception (*) was removed.
>>
>> Conclusion:
>> Standard conforming allocators are not required to support your
>> use case. But an allocator that should work with any C++98 stl
>> implementation must support it. For C++11 the later is no longer
>> the case and so called 'stateful' allocators may become much more
>> likely.
>
> Thanks for citing this. I would interpret this even further:
>
> If the two instances of the allocator compare equal, then it is
> allowed to deallocate memory allocated from the other
> allocator. Otherwise it is a bug in the code.
That's what I intended to say. Of course you're right. Indeed
the standard (surprisingly) says 'iff':
http://www.csci.csusb.edu/dick/c++std/cd2/lib-utilities.html#lib.allocator.requirements
> But that is probably even harder to test?
Why should it be harder: You can always check for equality
before testing the deallocation.
However, you can never check the other way around (assuming that
'you cannot do XY' means 'the result of XY is undefined').
Best,
Carsten
>
> Cheers,
>
> Markus
>
More information about the Dune
mailing list