本文共 947 字，大约阅读时间需要 3 分钟。
自认为C和C++基础知识还行， 于是以为下面程序的结果都是3， 看看：
#include结果大跌眼镜， 其实， 看了上述注释后， 就明白真相了。#include using namespace std;int main(){ char szTest[100] = "abc\0def"; // 右边串提前被'\0'截断 cout << strlen(szTest) << endl; string s; s.assign(szTest, 7); // s不会被'\0'截断 cout << s.length() << endl; return 0;}
之所以发现这个问题， 是因为最近玩了一下google protocol buffer， 序列化的接口是：
bool SerializeToString(string* output) const;
看到这个接口后， 我瞬间就懵逼了， 输出怎么会是一个string呢？ 怎么没有长度呢？ 如何应对序列化后的'\0'字符呢？ 不是要被无情截断了么？ 难道是buffer长度已经套在buffer之中（以头的形式呈现）？ 疑问重重!
应该采用pBuf加长度len才能避免这个问题啊！于是， 我感觉这可能是google的一个bug, 但又感觉这个bug不可能存在这么久还没有被发现啊。
于是在网上看看别人别人是怎么传这个string的， 然后就看到了网上普遍用s.length()来计算长度，于是怀疑自己对string和length的理解有误， 测试了一下， 果然是自己长期理解错误， 这个错误理解是源于C中字符串被'\0'截断。
错误理解： C++ string遇到'\0'会被截断。
正确理解： C++ string和'\0'没有半分钱的关系, 不会被截断。 string是个容器， 它对其中的字符透明， 你爱填啥就是啥！
所以， 上述程序的结果应该为3和7， 不足为怪。 所以， protobuf序列化到string中去， 并不会有错， 也不用担心'\0', 只是， 程序员取长度的时候要注意（string转char *的时候， 尤其要注意）， 否则很容易采坑（长度少了）。
转载地址：http://dggvi.baihongyu.com/