2012年9月26日
#
在使用不同編程語言進(jìn)行軟件聯(lián)合開發(fā)的時(shí)候，需要統(tǒng)一函數(shù)、變量、數(shù)據(jù)類型、常量等鏈接規(guī)范，特別是在不同模塊之間共享的接口部分，當(dāng)開發(fā)程序庫(kù)的時(shí)候，明確鏈接規(guī)范也是必須遵循的一條規(guī)則。
對(duì)COM接口及其使用的數(shù)據(jù)類型來說，是否采用統(tǒng)一的鏈接規(guī)范，對(duì)其二進(jìn)制兼容性和可移植性都沒有影響。因?yàn)檫B接規(guī)范主要影響到名字改編方案的不同，這樣即使接口兩端對(duì)接口本身的解釋不通，只要它們使用一致的成員對(duì)齊方式和布局方案、一致的函數(shù)調(diào)用規(guī)范、一致virtual function實(shí)現(xiàn)方式，總是就是一致的C++對(duì)象模型。并且保證COM組件升級(jí)時(shí)不改變?cè)瓉淼慕涌诤蛿?shù)據(jù)類型定義，則所有方法的運(yùn)行時(shí)綁定都不會(huì)存在問題（所有方法的調(diào)試都被轉(zhuǎn)換為通過對(duì)象指針對(duì)vptr和vtable及函數(shù)指針的操作，這種間接性不再需要任何方法名即函數(shù)名的參與，而接口名和方法名只是為了讓客戶端的代碼能夠順利通過編譯，但是連接時(shí)就完全不在需要了。）
但是對(duì)于定義于普通靜態(tài)鏈接庫(kù)和動(dòng)態(tài)鏈接庫(kù)中的全局?jǐn)?shù)據(jù)類型、全局函數(shù)、全局變量甚至全局常量，它們的連接規(guī)范必須在兩端保持一致、否則客戶程序會(huì)出現(xiàn)連接問題。這是因?yàn)槠胀ǖ姆庋b為DLL的函數(shù)庫(kù)或者類庫(kù)，客戶程序在創(chuàng)建使一般都需要與它們的導(dǎo)出庫(kù)進(jìn)行連接，除非使用loadlibrary()和getprocaddress()函數(shù)對(duì)來獲得DLL中函數(shù)的地址，通用的連接規(guī)范要屬C連接規(guī)范：extern‘C’。
具體使用方法，里仁教育嵌入式培訓(xùn)職業(yè)講師詳情講解：
Extern’C’void WinMainCRTStartup()；
Extern’C’const CLSID CLSID_DataConvert()；
Extern’C’struct Student{.......}；
Extern’C’student g_student;
如果是對(duì)一段代碼指定連接規(guī)范：
#ifdef _cplusplus
Extern ‘C’{
#endif
Const int MAX_AGE=200；
#pragma pack(push,4)
Typedef struct _person
{
Char *m_Name;
Int m_Age;
}person,*personPtr;
#pragma pack(pop)
Person g_Me;
Int _cdecl memcmp(const void*,const void*,size_t)；
Void * _cdecl memcpy(void,const void*,size_t)；
Void* _cdecl memset(void*,int,size_t)；
#ifdef _cplusplus
}
#endif
嵌入式行業(yè)資訊：全套基礎(chǔ)：
http://www.lirenedu.org/index.php?ack=lanmu&id=82
2012年9月18日
#
有些進(jìn)程在運(yùn)行時(shí)會(huì)占用大量的CPU，有些進(jìn)程會(huì)導(dǎo)致X死掉，有些進(jìn)程會(huì)吞噬掉大量的內(nèi)存，這些進(jìn)程直接影響了用戶的正常工作，最直接的現(xiàn)象就是系統(tǒng)運(yùn)行緩慢，死機(jī)等現(xiàn)象，處理這些進(jìn)程一般的方法就是結(jié)束這個(gè)進(jìn)程，就是所說的把它KILL掉。下面介紹幾種消滅進(jìn)程的方法。
l 使用Kill命令來消滅進(jìn)程
如果運(yùn)行了某個(gè)程序?qū)е铝怂罊C(jī)，那么就應(yīng)該切換到其他的控制臺(tái)下，按下ctrl+alt+fx，其中x可以是1·5，這取決于用戶的try的多少。
用ps顯示這個(gè)程序的進(jìn)程ID。
這里以xchat為例。
$ps aux |grep xchat
Wanglin 12063 0.0 1.8 89536 19028 ?S1 apr06 2:40 xchat
其中12063就是它的ID。
也可以使用pgrep來顯示ID，如下：
$pgrep xchar
12063
使用Kill來消滅這個(gè)進(jìn)程
使用kil來消滅進(jìn)程，如果消滅不掉，還要加參數(shù)-9，它可以強(qiáng)制結(jié)束進(jìn)程。
$ kill 12063
$ kill -9 12063
l 使用pkill或者killall來消滅進(jìn)程
它們的共同點(diǎn)就是都可以用程序的名稱作為參數(shù)。
$ pkill -9 xchat
$ killall xchat
l 使用圖形化的方式來消滅進(jìn)程
$xkill
會(huì)出現(xiàn)一個(gè)X形的光標(biāo)，單擊需要消滅的窗口，就可以消滅這個(gè)程序。www.lirenedu.org
Patch的主要用途就是更新源代碼到新的版本，避免下載整個(gè)源代碼，下載一個(gè)有效的補(bǔ)丁僅僅需要下載發(fā)生變化的那些代碼行就可以了，patch的幫助文檔中羅列了眾多的用法，其實(shí)大多數(shù)的時(shí)間只要下面兩個(gè)命令參數(shù)就能滿足大家的需要。下面講解patch的用法，以Ubuntu7.10系統(tǒng)為例。
1. 命令格式
#patch -p1<[patchfile]
或者
#patch -R <[patchfile]
上面兩個(gè)格式任選一條就可以了。
2.使用方法
#patch -p1<[patchfile]
要求補(bǔ)丁文件要放到源代碼目錄下，然后在運(yùn)行這條命令。
例如：給xchat2.6.0打補(bǔ)丁， 補(bǔ)丁文件是xc260-fetext.diff。
首先選入 xchat2.6.0的目錄， 并且將xc260-fix-fetext.diff文件復(fù)制到這個(gè)目錄，然后運(yùn)行：
#patch -p1<xc260-fix-fetext.diff
如果出現(xiàn)提示信息：patching file src/text/fe-text/fe-text.c 這說明打補(bǔ)丁成功了。
#patch -R<[pathfile]
這個(gè)命令運(yùn)行后，還要指定被補(bǔ)丁的文件的路徑和文件名.www.lirenedu.org
2012年9月12日
#
在Ubuntu系統(tǒng)下工作，只掌握?qǐng)D形化的配置工具還是不夠的，系統(tǒng)在出現(xiàn)故障的時(shí)候往往使用的是終端的操作模式，下面里仁3G培訓(xùn)講師介紹在終端下如何配置網(wǎng)絡(luò)。
臨時(shí)改變網(wǎng)絡(luò)參數(shù)
l .Ifconfig:查看和配置IP地址。
$ifconfig eth0
$sudo ifconfig eth0 192.168.9.23 netmask 255.255.255.0
route:配置路由參數(shù)
$sudo route add default gw 192.168.9.1 eth0 #設(shè)置默認(rèn)網(wǎng)關(guān)
使參數(shù)立即生效
$sudo/etc/init.d/networking restart
修改網(wǎng)絡(luò)配置文件
設(shè)置DNS服務(wù)器。
$sudo echo‘nameserver=219.150.32.132>/etc/resolv.conf’
編輯/etc/network/interfaces。
$sudo vim /etc/network/interfaces
Auto lo
Iface lo inet loopback
Iface eth0 inet static #設(shè)置eth0,靜態(tài)IP
Address 192.168.8.45
Netmask 255.255.255.0
Gateway 192.168.8.1
Iface eht1inet dhcp #設(shè)置eth1為dhcp模式
l 可以通過下面的命令設(shè)置路由。
Up route add default gw 192.168.8.1 eth1
Up route add –net 192.168.8.0/24 gw 192.168.8.1 eth0
Down route del –net 192.168.8.0/24 gw 192.168.8.1 eth0
其中，當(dāng)網(wǎng)絡(luò)接口up時(shí)，執(zhí)行它后面的命令；當(dāng)網(wǎng)絡(luò)接口down時(shí)，執(zhí)行它后面的命令。
使用參數(shù)立即生效。
$sudo /etc/init.d/networking restart 轉(zhuǎn)：www.lirenedu.org
許多學(xué)員都使用linux來完成各種工作，包括學(xué)習(xí)、辦公、編程、網(wǎng)絡(luò)維護(hù)等，但對(duì)所使用系統(tǒng)的一些基本信息知了甚少，有的連自己顯卡的型號(hào)、CPU的具體型號(hào)、硬盤的使用情況、內(nèi)存的使用情況網(wǎng)絡(luò)的使用情況都不清楚，一旦系統(tǒng)出現(xiàn)故障，就無從下手，所以在此里仁3G嵌入式培訓(xùn)講師有必要給大家介紹如何準(zhǔn)確地獲得自己的系統(tǒng)信息。
1. 系統(tǒng)信息
l 查看內(nèi)核信息。 $uname -a
l 查看操作系統(tǒng)的版本。 $head –n 1/etc/issue
l 查看CPU的信息。 $cat /proc/cpuinfo
l 查看計(jì)算機(jī)名稱。 $hostname
l 列出所有PCI設(shè)備信息。 $lspci –tv
l 列出所有USB設(shè)備信息。 $lsusb –tv
l 列出系統(tǒng)加載的模塊信息。 $lsmod
2. 系統(tǒng)資源的使用信息。
l 查看內(nèi)存和交換區(qū)分的使用量。 $free –m
l 查看硬盤分區(qū)的使用情況。 $df –h
l 查看某個(gè)目錄的大小。 $du –sh<目錄>
l 查看內(nèi)存總量和空閑內(nèi)存量。
$grep memTotal /proc/meminfo
$grep memfree /proc/meminfo
l 查看系統(tǒng)運(yùn)行時(shí)間、用戶數(shù)和負(fù)載。$uptime
l 查看系統(tǒng)負(fù)載。$cat /proc/loadavg www.lirenedu.org
2012年9月3日
#
編譯器無法預(yù)期一個(gè)程序在執(zhí)行過程中會(huì)在何時(shí)創(chuàng)建一些什么對(duì)象，而只能根據(jù)當(dāng)時(shí)的上下文要求創(chuàng)建，對(duì)象的初始化最好能夠通過運(yùn)行時(shí)執(zhí)行一個(gè)函數(shù)來完成，而且是在對(duì)象創(chuàng)建的同時(shí)，這個(gè)函數(shù)就是構(gòu)造函數(shù)，同樣，對(duì)象在完成其使命的時(shí)候能夠通過一個(gè)函數(shù)來銷毀，這就是析構(gòu)函數(shù)。
當(dāng)給一個(gè)對(duì)象分配好原始內(nèi)存空間的時(shí)候，這個(gè)對(duì)象就應(yīng)該算創(chuàng)建起來了。只不過它還處于一種“原始狀態(tài)”，即末初始化的，不良的狀態(tài)，如果把這樣的內(nèi)存直接拿來使用，除非第一個(gè)操作是賦值，否則極有可能出錯(cuò)。例如：
Long long1; //局部變量
Count<
Char*pstr=(char*)malloc(1024);
Cout<
因此，創(chuàng)建一個(gè)變量或動(dòng)態(tài)對(duì)象時(shí)一定不要忘記初始化。 初始化就是在對(duì)象創(chuàng)建的同時(shí)使用初值直接填充對(duì)象的內(nèi)存單元，因此，不會(huì)有數(shù)據(jù)類型轉(zhuǎn)換等中間過程，也就不會(huì)產(chǎn)生臨時(shí)對(duì)象，而賦值則是在對(duì)象創(chuàng)建好后任何時(shí)候都可以調(diào)用的而且可以多次調(diào)用的函數(shù)，由于它調(diào)用的是“=”運(yùn)算符，因此可能需要進(jìn)行類型轉(zhuǎn)換，即會(huì)產(chǎn)生臨時(shí)對(duì)象。
C++對(duì)象可以使用構(gòu)造函數(shù)來初始化，構(gòu)造函數(shù)是任何對(duì)象創(chuàng)建時(shí)自動(dòng)調(diào)用的第一個(gè)成員函數(shù)，也是為每個(gè)對(duì)象僅調(diào)用一次的成員函數(shù)，所以構(gòu)造函數(shù)的作用就是：當(dāng)對(duì)象的內(nèi)存分配好后把它原始狀態(tài)變成良好的可用的狀態(tài)。
有的程序員可能認(rèn)為：雖然我沒有在構(gòu)造函數(shù)中初始化數(shù)據(jù)成員，但是我在聲明一個(gè)對(duì)象后馬上調(diào)用它的set-XXX()函數(shù)來初始化它的每一個(gè)成員，效果也是一樣的。
最好為每個(gè)類顯式地定義構(gòu)造函數(shù)和析構(gòu)函數(shù)，即使它們暫時(shí)空著，尤其是當(dāng)類含有指針成員或引用成員的時(shí)候。
構(gòu)造函數(shù)的另一重要用途就是給一些可能可能存在的隱含成員如vptr創(chuàng)造一個(gè)初始化的機(jī)會(huì)，否則虛擬機(jī)將不能保證實(shí)現(xiàn)，每當(dāng)此時(shí)，如果程序員沒有為一個(gè)多態(tài)類顯式地定義默認(rèn)構(gòu)造函數(shù)、拷貝構(gòu)造函數(shù)、析構(gòu)函數(shù)或拷貝賦值函數(shù)，那么編譯器會(huì)自動(dòng)得生成相應(yīng)的函數(shù)，它們都是public inline的，并在其中插入正確初始化或修改vptr數(shù)據(jù)成員值的代碼，而且確保基類對(duì)象和派生類對(duì)象構(gòu)造時(shí)及在它們之間拷貝時(shí)vptr能夠指向或重新指向恰當(dāng)?shù)膙table，這樣的4個(gè)函數(shù)分布叫非平凡默認(rèn)構(gòu)造函數(shù)、非平凡拷貝構(gòu)造函數(shù)、非平凡析構(gòu)函數(shù)和非平凡拷貝賦值函數(shù)。www.lirenedu.org
與函數(shù)堆棧使用密切相關(guān)的就是函數(shù)調(diào)用規(guī)范，即調(diào)用約定(Calling Convenion)。函數(shù)調(diào)用規(guī)范決定了函數(shù)調(diào)用的實(shí)參壓棧、退棧及堆棧釋放的方式以及函數(shù)名改編的方案，windows環(huán)境下常用的調(diào)用規(guī)范有：
1) _cedcl:這是C++/C函數(shù)的默認(rèn)調(diào)用規(guī)范，參數(shù)從右向左傳遞壓入堆棧，由調(diào)用函數(shù)復(fù)雜堆棧的清退，因此這種方式利于傳遞個(gè)數(shù)可變的參數(shù)給被調(diào)用函數(shù)。如printf()就是這樣的函數(shù)。
2) _stdcall:這是Win API函數(shù)使用的調(diào)用規(guī)范，參數(shù)從右向左依次傳遞并壓入堆棧，由被調(diào)用函數(shù)復(fù)雜堆棧的清退。該規(guī)范生成的函數(shù)代碼比_cdecl更小，但當(dāng)函數(shù)有可變個(gè)數(shù)的參數(shù)時(shí)會(huì)轉(zhuǎn)為_cdecl規(guī)范。在Windows中，宏WINAPI、CALLBACK都定義為_stdcall。
3) _thiscall:是C++非靜態(tài)成員函數(shù)的默認(rèn)調(diào)用規(guī)范，不能使用個(gè)數(shù)可變的參數(shù)。當(dāng)調(diào)用非靜態(tài)成員函數(shù)的時(shí)候，this指針直接保存在ECX寄存器中而壓入函數(shù)堆棧，其他方面與_stdcall相同。
4) _fastcall:該規(guī)范所修飾的函數(shù)的實(shí)參將被直接傳遞到CPU寄存器中而不是內(nèi)存堆棧中，堆棧清退由被調(diào)用函數(shù)負(fù)責(zé)，該規(guī)范不能用于成員函數(shù)。
函數(shù)必須制定的一個(gè)調(diào)用規(guī)范，特別是在模塊之間的邏輯接口中，每個(gè)函數(shù)原型的調(diào)用規(guī)范必須與其實(shí)的調(diào)用規(guī)范保持一致，否則會(huì)出現(xiàn)編譯連接錯(cuò)誤。如果你調(diào)用了在某個(gè)DLL中實(shí)現(xiàn)的COM對(duì)象的方法，而這些方法在創(chuàng)建時(shí)卻沒顯式地制定調(diào)用規(guī)范，那么它們會(huì)使用環(huán)境默認(rèn)的調(diào)用規(guī)范，雖然你的程序可以通過編譯和連接，但是在運(yùn)行時(shí)就可能導(dǎo)致程序崩潰。
所以，凡是接口函數(shù)都必須顯式地制定其調(diào)用規(guī)范，除非接口函數(shù)是類的非靜態(tài)成員函數(shù)，如果不顯式制定調(diào)用規(guī)范，類的靜態(tài)成員函數(shù)和全局函數(shù)將采用C++/C默認(rèn)的函數(shù)調(diào)用規(guī)范或者由工程設(shè)置指定的調(diào)用規(guī)范，因此最好也為靜態(tài)成員函數(shù)顯式地指定調(diào)用規(guī)范。
注意：類的靜態(tài)成員函數(shù)的默認(rèn)調(diào)用規(guī)范不是thiscall，類的友元函數(shù)的調(diào)用也不是thiscall，它們都是由函數(shù)本身指定或者由工程設(shè)定的。COM接口的方法都指定_stdcall調(diào)用規(guī)范，而我們自己開發(fā)COM對(duì)象及接口時(shí)也可以指定其他的調(diào)用規(guī)范。
一定要知道C基礎(chǔ)的基本概念：
認(rèn)識(shí)函數(shù)堆棧：http://www.lirenedu.org/index.php?ack=xinwen&id=1026
基于C語言基礎(chǔ)概念：http://www.lirenedu.org/index.php?ack=xinwen&id=1024
操作系統(tǒng)幾個(gè)基本要點(diǎn)：http://www.lirenedu.org/index.php?ack=xinwen&id=1029
2012年8月27日
#
一、可默認(rèn)構(gòu)造的，也即具有public的default constructor，不論是用戶顯式定義還是編譯器默認(rèn)的，但是用戶定義的帶參數(shù)constructor會(huì)仰制編譯器合成default constructor，實(shí)際上并非任何情況下任意一種容器要求其元素類型滿足這一條件，特別是關(guān)聯(lián)式容器，因?yàn)橹挥行蛄惺饺萜鞯哪承┖瘮?shù)才可能明確地或隱含地使用元素類型的default constructor，如果你不調(diào)用這樣的成員函數(shù)，編譯器就不需要元素類型的默認(rèn)構(gòu)造函數(shù)。
二、可拷貝構(gòu)造和拷貝賦值的，既具有public的copy constructor和copy assignment operator，不論是編譯器默認(rèn)還是operator，如果沒有顯式定義它的話，這個(gè)條件可歸結(jié)為：元素必須是拷貝的，但實(shí)際上拷貝賦值的要求也不是強(qiáng)制的，原因和default constructor類似。
三、具有public的destructor，不論是編譯器默認(rèn)的還是用戶顯式定義的。
四、對(duì)于關(guān)聯(lián)式容器，要求其元素必須是可比較的。
Auto_ptr滿足上述條件嗎？至少滿足前三條，因此至少可以作為序列式容器的元素，如果為auto-ptr定義了比較運(yùn)算符的話，應(yīng)該還可以把它作為關(guān)聯(lián)式容器的元素。
但是auto_ptr的特點(diǎn)是接管和轉(zhuǎn)移擁有權(quán)，而不是像原始指針那樣可以共享實(shí)值對(duì)象，即auto_ptr在初始化時(shí)接管實(shí)值對(duì)象和擁有權(quán)，而在拷貝時(shí)會(huì)交出實(shí)值對(duì)象及其擁有權(quán)。
因此，auto_ptr對(duì)象和它的拷貝不會(huì)共享實(shí)值它的拷貝并不相同，然而根據(jù)STL容器值語義的要求，可拷貝構(gòu)造意味著一個(gè)著把一個(gè)對(duì)象賦值給另一個(gè)同類型對(duì)象將產(chǎn)生兩個(gè)相同的對(duì)象，顯然，auto_ptr不能滿足這一要求，與上面結(jié)論矛盾！那么問題出在哪里呢？
在揭開auto_ptr的之前需要了解copy constructor和copy assignment operator，的幾種合法形式，任何一個(gè)類都允許兩種形式的copy constructor：
C(const C©)；
C（C©）；
同樣，copy assignment operator允許類似的兩種形式。
C& operator=（const C ©）；
C& operator=（C & copy）；
實(shí)際上，由于copy assignment operator為普通的運(yùn)算符重載成員函數(shù)，因此還可以定義下列形式賦值函數(shù)；
C&operator=（C copy）；
如果要防止用戶把一些不合適的對(duì)象放入容器中，就要求對(duì)象的設(shè)計(jì)和是實(shí)現(xiàn)者使用一些語言支持但不常用的特征，也就是說，要能夠在編譯階段就阻止這種具有潛在危險(xiǎn)性的行為，常用的方法就是迫使其違反C++靜態(tài)類型安全規(guī)則。
源處：
http://www.lirenedu.org/index.php?ack=xinwen&id=1178
2012年8月23日
#
傳統(tǒng)的錯(cuò)誤處理是用不同的數(shù)值來表示不同類型的錯(cuò)誤，其表達(dá)能力很有限，因?yàn)橐粋€(gè)數(shù)字包含的信息量太少，而C++異常處理機(jī)制將異常類型化，顯然一個(gè)類型要比一個(gè)數(shù)字包含的信息量大得多。
比如我們常用的函數(shù)fopen(),當(dāng)打開文件失敗是返回NULL，按照傳統(tǒng)的錯(cuò)誤處理方法，在調(diào)用Fopen()后立即檢查其返回值，如果為NULL就進(jìn)行錯(cuò)誤處理，如果將返回NULL改為拋出異常OpenFailed，那么我們就不用在調(diào)用fopen()后馬上檢查返回值，而是在調(diào)用函數(shù)內(nèi)部或者更高層的調(diào)用者那里設(shè)置異常處理器來捕獲這個(gè)異常，C++保證：如果一個(gè)異常在拋出點(diǎn)沒有得到處理，那么它將一直拋向上層調(diào)用者，直至main()函數(shù)，直到找到一個(gè)類型匹配的異常處理器，否則調(diào)用terminate()結(jié)束程序。
可以看出：異常處理機(jī)制實(shí)際上是一種運(yùn)行時(shí)通知機(jī)制。
Class DevidedByZero{}；
Double Devide（double a，double b）
{
If（abs(b)：：numeric_limits：：epsilon()）
{
Throw DevidedByZero()；//提前檢測(cè)異常發(fā)生條件并拋出自定義異常
Return a/b; //這才是可能真正發(fā)出錯(cuò)誤的地方
}
Void test()
{
Double x=100,y=20.5
Try{
Cout<拋出異常DevidedByZero
}
Catch（DevidedByZero&）{
Cerr<< “ Devided by zero!”<
}
}
2012年8月21日
#
如果在申請(qǐng)動(dòng)態(tài)內(nèi)存時(shí)找不到足夠大的連續(xù)字節(jié)內(nèi)存塊，malloc()和new()會(huì)使用不同的方式宣告內(nèi)存申請(qǐng)失敗，通常有如下幾種方式處理“內(nèi)存耗盡”問題：
1. 判斷指針是否為NULL，如果是則立刻用return語句終止本函數(shù)。例如：
Void Func(void)
{
A *a=new(nothrow) A；
If（a==NULL）return；
……
}
2. 判斷指針是否為NULL，如果是則立刻用exit(1)終止整個(gè)程序的運(yùn)行，例如：
Void Func（void）
{
A *a=new(nothrow) A；
If（a==NULL）exit(1)；
}
3. 為new和malloc()預(yù)設(shè)異常處理函數(shù)，例如，Visual C++可以用_set_new_hander函數(shù)為new設(shè)置用戶自定義異常處理函數(shù)，也可以讓malloc()享用與new相同的異常處理函數(shù)。
4. 捕獲new拋出的異常，并嘗試從中恢復(fù)。
上述(1)和（2）兩種方式使用最普通。如果一個(gè)函數(shù)內(nèi)有多處需要?jiǎng)討B(tài)申請(qǐng)內(nèi)存，那么方式(1)就顯得力不從心，應(yīng)該用方式（2）來處理。不過在C++中我們提倡使用方式(4)。
有一個(gè)很重要的現(xiàn)象要告訴大家：
對(duì)于32位以上的應(yīng)用程序而言，一般情況下使用malloc()和new幾乎不可能導(dǎo)致‘內(nèi)存耗盡’。我在windows98下用Visual C++編寫了測(cè)試程序：
這個(gè)程序無休地運(yùn)行下去，根本不會(huì)終止，因?yàn)?/span>32位操作系統(tǒng)支持‘虛存’，內(nèi)存用完了，自動(dòng)用硬件空間頂替。
Void main（）
{
Int *p=NULL；
Unsigned int len=1024*1024；
While（1）{
P=new(nothrow) int[len]； //或者 malloc(sizeof(int)*len)；
If(!p){
Len>>=1; //len縮小一半
If（len==0）
Exit(1)；
Continue；
}
Cout<<“Allocated：”<<“（len*sizeof(int)）”<<“bytes.”<<endl；
}
}
可以得出一個(gè)結(jié)論：
對(duì)于32位以上應(yīng)用程序，內(nèi)存耗盡錯(cuò)誤處理程序幾乎毫無用處，但是必須強(qiáng)調(diào)不加錯(cuò)誤處理將導(dǎo)致程序的質(zhì)量很差，千萬不可因小失大。