a thought on string

[sysabod]

hi,every body around here watching my topic.
Today, was reading the Effective STL book where i encountered a
obscure statement in Item 16 .Here is the quote.

The approach to getting a pointer to container data that works for vectors isn't reliable for strings, because (1) the data for strings are not guaranteed to be stored in
contiguous memory.

so my problem is why there is any chance the data for strings are not guaranteed to be stored in contiguous memory. I have been deep-rootedly believing it is.
Any help is pretty appreciated!

[helios]

Because the standard doesn't require it, apparently. I was under the impression it did, too, but what do you know?

[Galik]

Interesting. I thought that the data() member function meant that internally a string was a character array. But now that I check it is only required that data() returns an array of characters with the "same content" as the string.

So yay, here's to strings being implemented as linked lists of characters!

[sysabod]

i check out the string manual and find the description of the data() member funciton
here it goes

Returns a pointer to an array of characters (not necessarily null-terminated) representing the string's contents.

while the c_str() member function returns a guaranteed null-terminated array of characters.

[Duthomhas]

All known implementations simply keep the data as a null-terminated char array, so the data() and c_str() simply return a pointer to it. It is simplest to do it that way.

[1yR4jE8b]

So yay, here's to strings being implemented as linked lists of characters!

Who DOESN'T do it that way ;-P

[helios]

If you don't mind the digression, a then-coworker once asked one of the stupidest questions ever: how does the HDD know that a byte comes after the last? We then started joking "it's a linked list of bytes".

(Obviously, at the most basic level, it's a linked list of bundles of sectors.)