That makes sense. You are right that unless it is necessary for some reason to use all the space at once, the use of the container would have that benefit. I was referring to the situation where it all had to be allocated at one time. Usually that's not the case, though.
One could check if the system memory still allowed further allocation, otherwise swap to a temp file. But operations on files are tricky, to say the least. You'd need to implement caching for virtual memory, reading chunks of file data into RAM and out into files again. Unless of course the OP isn't planning on using random access on the container.
The original issue does remind me of a question.
Why is that the decision was made to "wrap" out of range unsigned values, instead of generating a compiler error?
1) This assumes that the calling code might pass a negative value, which is pretty blatant abuse when you consider documentation and prototypes that explicitly state that an unsigned value is expected.
2) If you take a signed value and receive a negative, you should either throw an exception or return an error code. Don't ever terminate the program from a utility function. It's the job of the calling code to determine the severity of an error and act accordingly. Silently working with garbage data is generally frowned upon also.
>3. Any other suggestions/ideas
Use an object that doesn't require the calling code to know enough about the internal mechanisms to screw things up. :)