std::list with custom allocator

[Saliya Hamparawa]

Hi,
I have a custom allocator which supports only one element per allocation. I am trying to making the allocator complaint with the STL containers.

As per the standard, I need to provide allocator::max_size() function, which should Return the maximum theoretically possible value of n, for which the call allocate(n, 0) could succeed.

In my case it is 1, as I only support one object per allocation.

However, with that implementation, I'm finding it problematic to use the allocator with std::list.

std::list also provides a function std::list::max_size(), which should return the maximum number of elements the container is able to hold due to system or library implementation limitations. In theory, this should not be related with the number of elements the allocator can allocate per call, but GCC 4.82 has implemented it in this way.

/** Returns the size() of the largest possible %list. */
size_type
max_size() const _GLIBCXX_NOEXCEPT
{ return _M_get_Node_allocator().max_size(); }

And in MSVC12,

size_type max_size() const _NOEXCEPT
{ // return maximum possible length of sequence
return (this->_Getal().max_size());
}

In my case the std::list::max_size() function returns 1, which I believe is wrong. Is this a bug in the implementation, or am I missing something obvious?

Thanks,
Saliya.

[Alf P. Steinbach]

On 11/15/2015 2:18 PM, Saliya Hamparawa wrote:
>
> I have a custom allocator which supports only one element per allocation. I am trying
> to making the allocator complaint with the STL containers.
>
> As per the standard, I need to provide allocator::max_size() function, which should
> Return the maximum theoretically possible value of n, for which the call allocate(n, 0)
> could succeed.
>
> In my case it is 1, as I only support one object per allocation.
>
> However, with that implementation, I'm finding it problematic to use the allocator with
> std::list.
>
> std::list also provides a function std::list::max_size(), which should return the
> maximum number of elements the container is able to hold due to system or library

> implementationlimitations. In theory, this should not be related with the number of

> elements the allocator can allocate per call, but GCC 4.82 has implemented it in this
> way.
>
> /** Returns the size() of the largest possible %list. */
> size_type
> max_size() const _GLIBCXX_NOEXCEPT
> { return _M_get_Node_allocator().max_size(); }
>
> And in MSVC12,
>
> size_type max_size() const _NOEXCEPT
> { // return maximum possible length of sequence
> return (this->_Getal().max_size());
> }
>
> In my case the std::list::max_size() function returns 1, which I believe is wrong. Is
> this a bug in the implementation, or am I missing something obvious?

Sounds like a bug to me. The maximum array size the allocator can handle
has no relation to the maximum size of a linked list.


Cheers,

- Alf

[Mr Flibble]

I had this issue several years ago and brought the problem up with
Microsoft and P. J. Plauger but didn't get anywhere.

/Flibble

[Juha Nieminen]

Saliya Hamparawa <hamp...@googlemail.com> wrote:
> /** Returns the size() of the largest possible %list. */
> size_type
> max_size() const _GLIBCXX_NOEXCEPT
> { return _M_get_Node_allocator().max_size(); }

Curiously, in libc++ (which is mainly used by clang) it's defined as:

size_type max_size() const _NOEXCEPT
{return numeric_limits<difference_type>::max();}

which, I believe, is the correct implementation.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---