Re: basic_string<>::max_size - only 1MB?

[Benjamin Kosnik <bkoz@cygnus.com>]

> I discussed the matter on egcs-bugs list with Alexandre, and finally I 
> suspect a defect in the standard: what to do when an implementation
> is faced with the request to create an object of size greater than 
> numeric_limits<size_t>::max()?

Hmm. Well, if you take vector and string as our two examples, I would
think the goal would be to have some kind of consistent framework that
could be applied to both. Where both had checks for ctor (or other
member-function size-influencing functions) calls that tried to construct
a container greater than that paticular container's max_size(), and threw
length_error if this condition was violated. 

However, the standard as written isn't "down" with this kind of
simplicity. String checks npos, not max_size(). Deque doesn't check. List
doesn't check. Vector doesn't check. 

Anyway--for what it's worth, I like Gaby's idea of having max_size() for
the various containers (all?) just return a variant of:

numeric_limits<size_type>::max()



More babbling: 

For string the issue is even less well-defined, because
string::npos and string::max_size() have different, yet intertwined,
meanings. For instance, string ctors check for length error based on
npos, not max_size. This leads to problems if max_size is < npos: you can have a ctor trying to create a string of

string def_string;
string should_fail(def_string.max_size() + 1, 'c');

Anyway. This is a known defect. I could elaborate, but I think this is
pretty clear. One of the goals of the recent rounds of changes WRT string
was to resolve some validations problems where strings were seg faulting.
Perhaps I went overboard, but I thought the comments included indicated
the problem:

        // The maximum number of individual char_type elements of
        // an individual string is set to 1MB * sizeof(_CharT), which
        // is somewhat arbitrary, yet prevents blatant excess. An
        // invariant is that _S_max_size must be at least (1 *
        // sizeof(_CharT)) smaller than npos / sizeof(_CharT), so that
        // out_of_range errors and length qualifications take place
        // correctly. (As they currently exclude the terminating
        // character.) Keep in mind that npos == max size allocator can
        // allocate, _S_max_size == max size _CharT elements in a
        // basic_string.
        static const size_type  _S_max_size = sizeof(_CharT) * (1<<20); 


Note the "somewhat arbitrary" bits. 

-benjamin