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

[Nathan Myers <ncm@best.com>]

Nico wrote:
> Benjamin Kosnik wrote:
> > 
> > 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
> 
> This is on the library issues list of the standard commitee already:
> 
>  83.  String::npos vs. string::max_size()
> 
>  Section: 21 lib.strings Status: Open   Submitter: Nico Josuttis  
>  Date:  29 Sep 98 
> 
>  Many string member functions throw if size is getting or exceeding npos.
> However, I wonder why they don't throw  if size is getting or exceeding
> max_size() instead of npos. May be npos is known at compile time, while
> max_size() is known at runtime. However, what happens if size exceeds
>  max_size() but not npos, then ? It seems the standard lacks some
>  clarifications here. 
> 
> The proposed solution will probably be that in this case length_error gets
> thrown.

A string of size npos is incompatible with the rest of the interface, 
so is a logic error.  Trying to create a string of size greater than 
max_size() is a length error, as noted.  Trying to create a string
of less that max_size() but more than operator new() will allow is a 
resource inadequacy, and letting operator new's throw pass is
correct.  Crashing because operator new failed to throw, in this
case, is a nonconformance.

The meanings of max_size and npos are not intertwined, in the
standard sense.  It happens that on a 32-bit UNIX system the 
range of addressable virtual memory available to a process
happens to match the range of an unsigned int.  It could
just as will be half that (any may be so on some UNIX systems).
The only relationship the standard defines is max_size() < npos.

Nathan Myers
ncm@cantrip.org