quote:Original post by Deyja
My code might be off; but you get the idea. Now, two might actually equal "b string".

CoW was one of the things that came to mind... buuuut calling .begin() is a good sign that the user intends to do something to the string, so CoW ought to be invoked upon calling it.

Elements of a std::vector (possibly except std::vector, not sure about that) are indeed required by the standard to be stored in contiguous memory, so it's safe to use &v[0] (or &*v.begin()) as a pointer to the vector data. The explicit requirement was added in a technical corrigenda (which means it's now part of the standard).

To allow for standard library implementation trade-offs there's no similar requirement for std::string. You can get a pointer to the contents in contiguous memory through std::string::data() and std::string::c_str(), but that may be a copy and must not be modified.

[edited by - spock on September 2, 2003 11:08:27 PM]

This is one of those things that gets the people on the newsgroups to all chime in "WELL IF YOU LOOK AT SECTION 2891.213.11.AC appendix 3 it doesn''t guarantee that it will work!!!!" Except, it does on a lot of compilers. I wouldn''t think twice when you had to use it if you marked it as a hack. It is one of the things I complain about when I complain about std::string.

Like I said in another thread, for a *basic* string (which it is, it is even named that) there is NO reason why the storage wouldn''t be contiguous. Only something more elaborate like an SGI rope would be spread out.

I''m starting to think that languages developed by committee (cough, C++) are just so darn slow to change that it''s detrimental to the programmer. Being able to read directly into the buffer would be a whole lot more useful than making an input buffer and then building a string from it. It''s an example of taking encapsulation way too far, where you actually make more work for the programmer. I think the people developing the language need to come down and see what some common problems are with it.