stl string的COW问题

在网上反复看到一些文章关于STL string的COW(copy_on_write)问题，当初为了效率的问题极可能采取这种方式。但是在最新的vs2008上实验后，发现事实并不是这样，或者已经改版了。

vs出现intellisense问题，很是让人头疼..暂时查看不了basic_string的源代码，但是简单的实验就可以证明。

void String_Test() { string k = "sdf"; string k1(k); cout<<&(k)<<endl; cout<<&(k1)<<endl; k[1]='f'; cout<<&(k)<<endl; cout<<&(k1)<<endl; }

 

输出显示两者并没有共享内存，表明在string的拷贝构造函数里或者已经对内存的分配做了对老版的修改。

 

---------->再次修订，以上的证明方式错误。string在stl中并不是一个基础类型，字符串只是string的一个成员变量。在初始化或者赋值string变量时，string会在栈上申请个buffer或者在堆上存储字符串然后用指针指向（根据字符串的大小而定，16是个数的界限，为的是效率和资源的考虑），直接&K取的是这个string类的地址，而不是实际字符串的地址。实际字符串地址为string::_Bx::_buf或者string::_Bx::_ptr所指地址，由于是protected属性，无法输出，可以通过运行时鼠标点击变量属性看到。但结果是一样的，就是两者的地址还是不一样。

也就是说stl string并不支持cow了。在string的构造或者赋值函数里能看出来，用的是直接copy方式，跟原c字符串的地址已经没有任何关系了。看来在硬件发达的现在，效率和资源没有以前那么重要了...

 

---------->再次修订，string类存储字符串的过程是这样的，在构造函数中，string会初始化其中的成员变量

union _bx{

_Elem _Buf[_BUF_SIZE];

_Elem *_Ptr;

}. 根据字符串的长度来判断是用union中的buf还是指针来存储（对于长度大于16的用指针来管理，可能会更有优势吧），然后用algorithm中的replace来实现构造和assign的。

 

------->疑问。string类存储字符串的位置。也就是_bx的位置在栈上还是堆上？？理论上如果没有new string，那么应该是在栈上，但是构造string是一种动态的构造，也就是说字符串的长度是未知的，这就应该决定了没办法静态地分配数组。如果动态就需要new在堆上，那么就是说string构造的时候，对象中的字符串已经存储在了堆上？？？？/

 

 

--------》惊人的strcpy.

const char* ptr = "abc";

char* m_buf = new char[strlen(ptr)];

strcpy(m_buf,ptr,strlen(ptr));

delete[] m_buf;

 

到delete[]时会才跑出个write after a heap buffer的异常，写时溢出...