This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
- From: "pcarlini at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Sep 2006 23:26:44 -0000
- Subject: [Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
- References: <bug-29134-13273@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #2 from pcarlini at suse dot de 2006-09-18 23:26 -------
(In reply to comment #1)
> And what does the C++ standard say about this case?
As far as I can see, the standard is very vague about the relationship between
the two max_size. About allocator::max_size, it says "the largest value that
can meaningfully be passed to X::allocate" and, given that way allocate
forwards to the underlying memory allocation facilities, size_type(-1) /
sizeof(T) seems certainly conforming. As regards container::max_size, we have
the same value for vector - the only one which always allocates a single chunk
of memory at a time - and simply size_type(-1) for the other containers. Again,
I don't see how those values could be non-conforming to the text in the
standard, which only says "size() of the largest possible container". Maybe, as
a matter of QoI something more accurate could be returned, basing on
non-trivial interactions with the underlying OS, but I don't think we have any
hard bug here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134