Am 15.11.2015 um 15:05 schrieb
hamparawa@googlemail.com:
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 allocator, 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?
It doesn't look like an error of the corresponding implementation to me,
because the requirements imposed by the Standard don't seem to be
specific enough to prevent it to from being an infeasible
implementation.
For a contiguous container (such as std::vector), such a choice seems
rather reasonable, but given your use-case of a typical node-based
container such as std::list, this choice seems not very appropriate. I
see the following options for you:
1) You could make a feature request to your Library vendor(s) to use a different implementation of std::list<>::max_size() that would cover
this kind of use-case as well. You might have luck, when the vendor
agrees, but in any case this would not be something that you could rely
on when switching between implementations.
2) You could consider to submit a library issue (as described on
https://isocpp.org/std/submit-issue when it refers to standard library
issues), requesting that the standard should at least for some dedicated
container types (such as std::list), specify the semantics of the
container's max_size() function in a more specific way, that would
support your example. Since this could me considered as a feature-like
request, your attempt might be rejected by the committee as being
not-a-defect (NAD). This strongly depends on the clarity of your issue description and argumentation.
3) You could write a proposal (see
https://isocpp.org/std/submit-a-proposal), that argues why the current specification of max_size() at least for some containers should be
changed to a more specific requirement, that would support examples like
yours. As described on the referenced page, you should start with a new discussion on the std-proposals news group (
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-pro posals).
For any of these options it is always a good idea to have a better
suggestion how to implement max_size() for e.g. std::list and if so, to
try to convince implementations to accept such an alternative. You could
for example try to make a contribution to gcc's libstdc++ in regard to
this. Existing implementations are often a good argumentation base for requesting a change of the existing specification.
HTH & Greetings from Bremen,
Daniel Krügler
--
[ See
http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)