[Dune-devel] [Dune-Commit] [Commit] dune-common - f78ce3a: [poolallocator, release] Use a non-static memory pool.

[Carsten Gräser]

Hi,

Am 03.02.2014 11:45, schrieb Steffen Müthing:
> Am 03.02.2014 um 11:03 schrieb Markus Blatt <markus at dr-blatt.de>:
>> On Thu, Jan 30, 2014 at 04:29:25PM +0100, Carsten Gräser wrote:

[...]
>>> While an stl conforming allocator is in principle allowed to be
>>> stateful, the standard also explicitly allows that stl implementations
>>> may require that the allocator is stateless.
>>>
>>
>> Is that really the case? I tried to find this in the C++11 standard,
>> but to no avail. It even seems to be contrary to me, as there are
>> interface methods like operator==(other) for testing whether memory
>> allocated by one allocator might be deallocated by the other.
>>
>> Seems like this was different in previous standards. But most
>> implementations do support them:
>> http://stackoverflow.com/questions/6861046/compiler-support-for-stateful-allocators-in-stl-containers
this has indeed changed in C++11. For those interested I've attached
the corresponding (strange) clause from C++98 below. However we do not
follow C++11 in many places yet.

>>> Strictly speaking, you can no longer use the pool allocator
>>> with stl containers unless you know that your specific stl
>>> implementation supports stateful allocators.
>>>
>>
>> Is anybody doing that? Poolallocator only allows to allocate 1 element
>> at a time which rules out quite a few containers. At least in the core
>> modules it only used in dune-istl's AMG and that is where it makes
>> trouble.
As I said, I'm not proposing to revert the change. I just wanted to
point out this interface change.

[...]
>> If we agree that stateful allocator are supported by c++11 and above
>> we could at least apply this behaviour for compilers which support
>> that.
> 
> Well, Stroustrup says they are stateful in C++11 (see http://www.stroustrup.com/C++11FAQ.html#scoped-allocator,
> and the paragraph about containers directly above). I think the support is needed for the new-fangled scoped
> allocators.
> 
> On the other hand, they are definitely *not* allowed to be stateful in C++03 (even though, as you point out, most
> library implementations have some support for that).
> 
> So I think adding support for C++11-compliant compilers is a good compromise.
IMHo it would also be OK to change this in general. Anyways we
have to add this interface change to the release notes.

Best,
Carsten



From clause 20.1.5 in C++98 (actually a draft):

  4 Implementations of containers described in this International Standard
    are permitted to assume that their Allocator template parameter  meets
    the following two additional requirements beyond those in Table 6.
  
    --All  instances  of  a given allocator type are required to be inter-
      changeable and always compare equal to each other.
  
    --The typedef members pointer, const_pointer, size_type,  and  differ-
      ence_type  are  required  to be T*, T const*, size_t, and ptrdiff_t,
      respectively.
  
  5 Implementors are encouraged to supply libraries that can accept  allo-
    cators  that  encapsulate  more general memory models and that support
    non-equal  instances.   In  such  implementations,  any   requirements
    imposed  on  allocators  by  containers beyond those requirements that
    appear in Table 6, and the semantics of containers and algorithms when
    allocator instances compare non-equal, are implementation-defined.


A nice comment (stolen from Wikipedia)

  In short, this paragraph (...) is the Standard's "I have a dream"
  speech for allocators. Until that dream becomes common reality,
  programmers concerned about portability will limit themselves to
  custom allocators with no state

—Scott Meyers, Effective STL



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20140204/23a4df85/attachment.sig>