字串指標與字元陣列 (轉)

字串指標與字元陣列 (轉)[@more@]

很多剛從C轉C++的人都不明白，在C中這樣的程式碼

char *pChar="hELLO!";   //定義字元指標pChar，指向一個字元陣列首元素即h:namespace prefix = o ns = "urn:schemas--com::office" />

*pChar='H';             //問題所在行

到了C++中怎麼就不行了？你翻遍參考書，都會說，pChar指向的是常量，怎麼能允許改變呢？你又問了，怎麼我在C中執行的好好的？沒人回答你。於是，你只好自我安慰，這就是C++的保護機制吧。

我來做個總結吧，發現這個問題如果不深入研究一下，總是人云亦云，就像我以前那樣。於是，我用BC++3.1編譯這段程式碼後執行，無論是編DOS還是程式都是能執行的，結果也和你預期的一樣。沒什麼問題。但是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位系統一樣。