紧接着上篇博客讲解的内容：

　　将Char型数组转换为string类型还有下面的这种方法

　　但是我在测试的时候遇到了一些问题，并在下面进行了解释和总结

先说出我的总结

　　其实我们在学习编程的时候（比如我之前学习C的时候），一直有书或者博客上有建议说声明一个变量之后，一定要初始化，否则可能出现一些意想不到的错误。虽然这里的buf 也进行了初始化，但是初始化不完全（并没有考虑到字符串应该以#0 作为结尾），所以就出现了这样的问题。

　　另外，在编程的时候，难免因为很多问题没有考虑到而出现这样那样的问题，这个时候不要瞎猜，可以为自己的程序设置几个断点来调试一下、去看看运行时候的变量的值……

　　　　Delphi的调试就类似与上面所讲的，更详细的可以看http://www.cnblogs.com/xumenger/p/4443975.html

　　　　C/C++里面也有，我比较喜欢Linux环境下的GDB调试器，GDB教程参考：http://www.cnblogs.com/xumenger/p/4214068.html

 再开始讲解整个过程

　　Char数组与String存储方式一样（还是有不一样的，具体的String的存储结构见：http://www.cnblogs.com/xumenger/p/4427957.html），只不过string是以 \'/0\' 结尾的char数组（这样理解是可以的，但是不是很精确）。所以可以把Char数组强制转换为string类型。

程序一

procedure TForm1.Button1Click(Sender: TObject);
var
  buf: array[0..255] of Char;
  s :string;
  i: Integer;
begin
  for i:=0 to 10 do
    buf[i]:= \'f\';

  s:= string(buf);

  ShowMessage(s);
end;

　　编译之后，点击按钮会看到这样的效果

程序二

　　但是，如果 buf 数组中间有某一位是 \'/0\'（在Delphi里面是 #0），转换时以第一个出现的\'/0\'前面的内容转换为s的内容，如果第一个字符即为\'/0\'（即#0）,buf[0]=char(0),则s的内容为空字符串。下面有一个例子

procedure TForm1.Button1Click(Sender: TObject);
var
  buf: array[0..255] of Char;
  s :string;
  i: Integer;
begin
  for i:=0 to 10 do
    buf[i]:= \'f\';

  buf[11]:= #0;

  for i:=12 to 15 do
    buf[i]:= \'c\';

  s:= string(buf);

  ShowMessage(s);
end;

　　编译之后，点击按钮会看到这样的效果。字符串s 只会有字符数组的 #0 之前的内容，#0 之后的就不会有，因为string是以#0 结尾的

程序三

　　但是还要注意一个问题，我在编写这样的代码的时候

procedure TForm1.Button1Click(Sender: TObject);
var
  buf: array[0..255] of Char;
  s :string;
  i: Integer;
begin
  for i:=0 to 10 do
    buf[i]:= \'f\';

  buf[11]:= \'p\';

  for i:=12 to 15 do
    buf[i]:= \'c\';

  s:= string(buf);

  ShowMessage(s);
end;

　　出现下面的问题

　　为什么我将buf 的从 0到 10赋值为\'f\'，11赋值为\'p\'， 12到15赋值为\'c\'，这些显示都没有问题，但是为什么后面多了那几个乱七八糟的字符

　　所以设置断点，进行单步调试查看到底是为什么

　　如图，在  s:= string(buf); 这行设置断点（F5）

　　再按F9运行，在这行停住，再看buf的内容（Ctrl+鼠标左键），如下图

　　可以看到buf的元素从0 到15都确实是自己在程序中赋值的内容，但是为什么后面会出现这些乱七八糟的东西，回想第一个程序为什么能正确显示 fffffffffff，所以又回去将本博客中的第一个程序进行了断点调试

　　还是在  s:= string(buf); 这行设置断点（F5），如图

　　再按F9运行，到断点处，再看 buf的值

、

　　确实从0到10是 fffffffffff，11是#0，但是到16开始又有一些乱七八糟的东西出现了。所以就说明了初始化的重要性：进行初始化的内容就会确定是初始化时候的值，而没有初始化的部分可能是随机的值，这样就存在潜在的危险，因为对于不确定的东西就很难进行明确的控制

　　但是还有一种情况，就是将一个char型数组的所有元素都赋值为非 #0 的字符，在进行类型转换为string 类型会出现什么情况呢

程序四

procedure TForm1.btn1Click(Sender: TObject);
var
  s: string;
  a: array[0..2] of Char;
  i: Integer;
begin
  for i:=0 to 2 do
    a[i]:= \'j\';
  s:= string(a);
  ShowMessage(s[1]+\' \'+s[2]+ \' \'+s[3] +\' \'+ IntToStr(Integer(s[4])));
end;

　　补充：Char数组根据定义可以是从0开始，也可以是从1开始，也可以是从其他任何数开始（这点和C/C++中的数组不同），但是String的字符存储要从 1 开始

　　显示的结果如图

　　所以可以看出，将一个所有元素都为非 #0 的字符数组，强制转换为string，那么这个string会拷贝这个元素，并且自动添加一个 #0在string中作为结尾

　　如果这个字符数组中某一个元素为 #0 ，那么强制转化为 string之后，就只会保留#0 及其之前的字符串

　　使用PChar分配动态内存，并将一个PChar里面的所有元素都赋值为非 #0 的字符，在进行类型转换为string 类型和上面的效果一样

procedure TForm1.btn1Click(Sender: TObject);
var
  s: string;
  a: array[0..2] of Char;
  p: PChar;
  i: Integer;
begin
  GetMem(p, 3);
  for i:=0 to 2 do
    p[i]:= \'j\';
  s:= string(p);
  ShowMessage(s[1]+\' \'+s[2]+ \' \'+s[3] +\' \'+ IntToStr(Integer(s[4])));
end;

　　原因

　　在程序三中，我们声明了字符数组 buf，buf分配了255字节的内存，这时候buf 并没有显式声明，所以buf的内容就是其分配的内存中原来的那些乱七八糟的东西（对本程序是完全没有意义的），但是第一个程序显式声明了从0到10的元素，第三个程序显示声明了0 到15 的元素，可是第一个程序的11 个元素及其之后的元素还是原来那些乱七八糟的东西，第三个程序的16个元素及其之后的元素也还是原来那些乱七八糟的东西。

　　不过第一个程序比较巧合的是第11 个元素碰巧是 #0，所以在这个程序最终的效果碰巧正确（但是这里是隐藏着隐患的），而第三个程序就没有那么巧合了，所以就又显示了一个乱七八糟的字符。这并不是意味着第一个程序正确，只是它比较“幸运”罢了。但是项目开发并不是开玩笑，不能靠巧合和运气，必须要确定和稳定

　　所以不论上面谈到的什么情况，要想避免可能出现的错误，唯一的原则就是：显式的声明想要结束的地方为 #0，这样就不会出错了，这样的代码就比较可靠，不会因为上面的那种巧合来出现“正确的”效果或者“错误的”效果

　　总结

　　首先，其实我们在学习编程的时候，一直有书或者博客上有建议说声明一个变量之后，一定要初始化，否则可能出现一些意想不到的错误。虽然这里的buf 也进行了初始化，但是初始化不完全（并没有考虑到字符串应该以#0 作为结尾），所以就出现了这样的问题。在C/C++里面也是和Delphi一样的。

　　另外，在编程的时候，难免因为很多问题没有考虑到而出现这样那样的问题，这个时候不要瞎猜，可以为自己的程序设置几个断点来调试一下、去看看运行时候的变量的值……

　　　　Delphi的调试就类似与上面所讲的，更详细的可以看http://www.cnblogs.com/xumenger/p/4443975.html

　　　　C/C++里面也有，我就比较喜欢Linux环境下的GDB调试器，GDB的简单使用教程，参考：http://www.cnblogs.com/xumenger/p/4214068.html