很多刚从C转C++的人都不明白，在C中这样的代码
char *pChar="hELLO!"; //定义字符指针pChar，指向一个字符数组首元素即h
*pChar='H'; //问题所在行
到了C++中怎么就不行了？你翻遍参考书，都会说，pChar指向的是常量，怎么能允许改变呢？你又问了，怎么我在C中运行的好好的？没人回答你。于是，你只好自我安慰，这就是C++的保护机制吧。
我来做个总结吧，发现这个问题如果不深入研究一下，总是人云亦云，就像我以前那样。于是，我用BC++3.1编译这段代码后运行，无论是编DOS程序还是Windows程序都是能运行的，结果也和你预期的一样。没什么问题。但是VC++6运行时就会出错，错误你想必相当熟悉（XX内存不能写）。但这只是编译器的问题的吗？
你可以把你在VC++中编译的程序拿到纯DOS下运行，哪怕他是Console程序，他也会说“Can not run in DOS”，因为他是32位的。而BC++3.1哪怕是编一个Windows程序，也只是16位的。所以问题的关键在于内存的管理上。32位系统对于应用程序使用的内存定义了操作权限，能读还是能写，或者是其他什么。而16位的系统缺乏这种安全机制，哪怕你说这段数据只能读，但是写一下也没什么关系。
这种代码之所以能在C中运行的很好，就是因为那时C的编译器都是16位的；现在在C++中不行了，是因为你用的C++编译器是32位的——能找到BC++3.1这种古董还真不容易，相对而言TC2.0更好找。我反汇编TC2.0生成的这两条语句char *p = “hellow”;char p[] = “hellow”;发现他们的实现并不相同，相对而言，char *p = “hellow”;生成的代码更简洁一些。虽然C也想定义常量字符串，但由于16位的欠缺保护，这种想法被人误解了；几乎所有学习过C的人都曾耗费力气去理解如上的代码，然后泛滥的使用。不为别的，只因为这种代码效率高，从反汇编结果能看出来。于是使用char p[] = “hellow”;这种语法的人被嘲笑，但事实上，这种语法才是本意，那种语法只是钻了个空子，于是，在32位程序中，他被剥夺了生存的权利。
这让我想起了C中很多怪异的写法，虽然他们让人很费解，但是确实，他们的效率要比容易看懂的写法来得高，当然，我不知道这其中有没有钻空子的例子；从C设计的本意来说，他们有存在的意义，但是从现在的程序设计潮流来看，代码的可读性要求超过了他的效率。不知道这些语法能不能算是程序员中的一种外语——想写高效的程序吗，掌握我吧，哪怕是死记硬背。
PS：32位系统运行16位程序采用的是模拟仿真的方法，就是说和运行在16位系统一样。
