18video性欧美19sex,欧美高清videosddfsexhd,性少妇videosexfreexxx片中国,激情五月激情综合五月看花,亚洲人成网77777色在线播放

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

C++中的資源泄露問題

Linux愛好者 ? 來源:一個程序員的修煉之路 ? 作者:河邊一枝柳 ? 2021-09-30 17:03 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

在Modern C++之前,C++無疑是個更容易寫出坑的語言,無論從開發(fā)效率,和易坑性,讓很多新手望而卻步。比如內(nèi)存泄露問題,就是經(jīng)常會被寫出來的坑,本文就讓我們一起來看看,這些讓現(xiàn)在或者曾經(jīng)的C++程序員淚流滿面的內(nèi)存泄露場景吧。你是否有踩過?

1. 函數(shù)內(nèi)或者類成員內(nèi)存未釋放

這類問題可以稱之為out of scope的時候,并沒有釋放相應(yīng)對象的堆上內(nèi)存。有時候最簡單的場景,反而是最容易犯錯的。這個我想主要是因為經(jīng)常寫,哪有不出錯。下面場景一看就知道了,當(dāng)你在寫XXX_Class * pObj = new XXX_Class();這一行的時候,腦子里面還在默念記得要釋放pObj ,記得要釋放pObj, 可能因為重要的事情要說三遍,而你只喊了兩遍,最終還是忘記了寫delete pObj; 這樣去釋放對象。

void MemoryLeakFunction()

{

XXX_Class * pObj = new XXX_Class();

pObj-》DoSomething();

return;

}

下面這個場景,就是析構(gòu)函數(shù)中并沒有釋放成員所指向的內(nèi)存。這個我們就要注意了,一般當(dāng)你構(gòu)建一個類的時候,寫析構(gòu)函數(shù)一定要切記釋放類成員關(guān)聯(lián)的資源。

class MemoryLeakClass

{

public:

MemoryLeakClass()

{

m_pObj = new XXX_ResourceClass;

}

void DoSomething()

{

m_pObj-》DoSomething();

}

~MemoryLeakClass()

{

;

}

private:

XXX_ResourceClass* m_pObj;

};

上述這兩種代碼例子,是不是讓一個C++工程師如履薄冰,完全看自己的大腦在不在狀態(tài)。在boost或者C++ 11后,通過智能指針去進行包裹這個原始指針,這是一種RAII的思想(可以參閱本文末尾的關(guān)聯(lián)閱讀), 在out of scope的時候,釋放自己所包裹的原始指針指向的資源。將上述例子用unique_ptr改寫一下。

void MemoryLeakFunction()

{

std::unique_ptr《XXX_Class》 pObj = make_unique《XXX_Class》();

pObj-》DoSomething();

return;

}

2. delete []

大家知道C++中這樣一個語句XXX_Class * pObj = new XXX_Class(); 中的new我們一般稱其為C++關(guān)鍵字 (keyword), 就以這個語句為例做了兩個操作:

調(diào)用了operator new從堆上申請所需的空間

調(diào)用XXX_Class的構(gòu)造函數(shù)

那么當(dāng)你調(diào)用delete pObj;的時候,道理同new,剛好相反:

調(diào)用了XXX_Class的析構(gòu)函數(shù)

通過operator delete 釋放了內(nèi)存

一切似乎都沒有什么問題,然后又一個坑來了。但如果申請的是一個數(shù)組呢,入下述例子:

class MemoryLeakClass

{public:

MemoryLeakClass()

{

m_pStr = new char[100];

}

void DoSomething()

{

strcpy_s(m_pStr, 100, “Hello Memory Leak!”);

std::cout 《《 m_pStr 《《 std::endl;

}

~MemoryLeakClass()

{

delete m_pStr;

}

private:

char *m_pStr;

};

void MemoryLeakFunction()

{

const int iSize = 5;

MemoryLeakClass* pArrayObjs = new MemoryLeakClass [iSize];

for (int i = 0; i 《 iSize; i++)

{

(pArrayObjs+i)-》DoSomething();

}

delete pArrayObjs;

}

上述例子通過MemoryLeakClass* pArrayObjs = new MemoryLeakClass [iSize];申請了一個MemoryLeakClass數(shù)組,那么調(diào)用不匹配的delete pArrayObjs;, 會產(chǎn)生內(nèi)存泄露。先看看下圖, 然后結(jié)合剛講的delete的行為:

那么其實調(diào)用delete pArrayObjs;的時候,釋放了整個pArrayObjs的內(nèi)存,但是只調(diào)用了pArrayObjs[0]析構(gòu)函數(shù)并釋放中的m_pStr指向的內(nèi)存。pArrayObjs 1~4并沒有調(diào)用析構(gòu)函數(shù),從而導(dǎo)致其中的m_pStr指向的內(nèi)存沒有釋放。所以我們要注意new和delete要匹配使用,當(dāng)使用的new []申請的內(nèi)存最好要用delete[]。那么留一個問題給讀者, 上面代碼delete m_pStr;會導(dǎo)致同樣的問題嗎?如果總是要讓我們自己去保證,new和delete的配對,顯然還是難以避免錯誤的發(fā)生的。這個時候也可以使用unique_ptr, 修改如下:

void MemoryLeakFunction()

{

const int iSize = 5;

std::unique_ptr《MemoryLeakClass[]》 pArrayObjs = std::make_unique《MemoryLeakClass[]》(iSize);

for (int i = 0; i 《 iSize; i++)

{

(pArrayObjs.get()+i)-》DoSomething();

}

}

3. delete (void*)

如果上一個章節(jié)已經(jīng)有理解,那么對于這個例子,就很容易明白了。正因為C++的靈活性,有時候會將一個對象指針轉(zhuǎn)換為void *,隱藏其類型。這種情況SDK比較常用,實際上返回的并不是SDK用的實際類型,而是一個沒有類型的地址,當(dāng)然有時候我們會為其親切的取一個名字,比如叫做XXX_HANDLE。那么繼續(xù)用上述為例MemoryLeakClass, SDK假設(shè)提供了下面三個接口

InitObj創(chuàng)建一個對象,并且返回一個PROGRAMER_HANDLE(即void *),對應(yīng)用程序屏蔽其實際類型

DoSomething 提供了一個功能去做一些事情,輸入的參數(shù),即為通過InitObj申請的對象

應(yīng)用程序使用完畢后,一般需要釋放SDK申請的對象,提供了FreeObj

typedef void * PROGRAMER_HANDLE;

PROGRAMER_HANDLE InitObj()

{

MemoryLeakClass* pObj = new MemoryLeakClass();

return (PROGRAMER_HANDLE)pObj;

}

void DoSomething(PROGRAMER_HANDLE pHandle)

{

((MemoryLeakClass*)pHandle)-》DoSomething();

}

void FreeObj(void *pObj)

{

delete pObj;

}

看到這里,也許有讀者已經(jīng)發(fā)現(xiàn)問題所在了。上述代碼在調(diào)用FreeObj的時候,delete看到的是一個void *, 只會釋放對象所占用的內(nèi)存,但是并不會調(diào)用對象的析構(gòu)函數(shù),那么對象內(nèi)部的m_pStr所指向的內(nèi)存并沒有被釋放,從而會導(dǎo)致內(nèi)存泄露。修改也是自然比較簡單的:

void FreeObj(void *pObj)

{

delete ((MemoryLeakClass*)pObj);

}

那么一般來說,最好由相對資深的程序員去進行SDK的開發(fā),無論從設(shè)計和實現(xiàn)上面,都盡量避免了各種讓人淚流滿滿的坑。

4. Virtual destructor

現(xiàn)在大家來看看這個很容易犯錯的場景, 一個很常用的多態(tài)場景。那么在調(diào)用delete pObj;會出現(xiàn)內(nèi)存泄露嗎?

class Father

{public:

virtual void DoSomething()

{

std::cout 《《 “Father DoSomething()” 《《 std::endl;

}

};

class Child : public Father

{

public:

Child()

{

std::cout 《《 “Child()” 《《 std::endl;

m_pStr = new char[100];

}

~Child()

{

std::cout 《《 “~Child()” 《《 std::endl;

delete[] m_pStr;

}

void DoSomething()

{

std::cout 《《 “Child DoSomething()” 《《 std::endl;

}

protected:

char* m_pStr;

};

void MemoryLeakVirualDestructor()

{

Father * pObj = new Child;

pObj-》DoSomething();

delete pObj;

}

會的,因為Father沒有設(shè)置Virtual 析構(gòu)函數(shù),那么在調(diào)用delete pObj;的時候會直接調(diào)用Father的析構(gòu)函數(shù),而不會調(diào)用Child的析構(gòu)函數(shù),這就導(dǎo)致了Child中的m_pStr所指向的內(nèi)存,并沒有被釋放,從而導(dǎo)致了內(nèi)存泄露。并不是絕對,當(dāng)有這種使用場景的時候,最好是設(shè)置基類的析構(gòu)函數(shù)為虛析構(gòu)函數(shù)。修改如下:

class Father

{public:

virtual void DoSomething()

{

std::cout 《《 “Father DoSomething()” 《《 std::endl;

}

virtual ~Father() { ; }

};

class Child : public Father

{

public:

Child()

{

std::cout 《《 “Child()” 《《 std::endl;

m_pStr = new char[100];

}

virtual ~Child()

{

std::cout 《《 “~Child()” 《《 std::endl;

delete[] m_pStr;

}

void DoSomething()

{

std::cout 《《 “Child DoSomething()” 《《 std::endl;

}

protected:

char* m_pStr;

};

5. 對象循環(huán)引用

看下面例子,既然為了防止內(nèi)存泄露,于是使用了智能指針shared_ptr;并且這個例子就是創(chuàng)建了一個雙向鏈表,為了簡單演示,只有兩個節(jié)點作為演示,創(chuàng)建了鏈表后,對鏈表進行遍歷。

那么這個例子會導(dǎo)致內(nèi)存泄露嗎?

struct Node

{

Node(int iVal)

{

m_iVal = iVal;

}

~Node()

{

std::cout 《《 “~Node(): ” 《《 “Node Value: ” 《《 m_iVal 《《 std::endl;

}

void PrintNode()

{

std::cout 《《 “Node Value: ” 《《 m_iVal 《《 std::endl;

}

std::shared_ptr《Node》 m_pPreNode;

std::shared_ptr《Node》 m_pNextNode;

int m_iVal;

};

void MemoryLeakLoopReference()

{

std::shared_ptr《Node》 pFirstNode = std::make_shared《Node》(100);

std::shared_ptr《Node》 pSecondNode = std::make_shared《Node》(200);

pFirstNode-》m_pNextNode = pSecondNode;

pSecondNode-》m_pPreNode = pFirstNode;

//Iterate nodes

auto pNode = pFirstNode;

while (pNode)

{

pNode-》PrintNode();

pNode = pNode-》m_pNextNode;

}

}

先來看看下圖,是鏈表創(chuàng)建完成后的示意圖。有點暈乎了,怎么一個雙向鏈表畫的這么復(fù)雜,黃色背景的均為智能指針或者智能指針的組成部分。其實根據(jù)雙向鏈表的簡單性和下圖的復(fù)雜性,可以想到,智能指針的引入雖然提高了安全性,但是損失的是性能。所以往往安全性和性能是需要互相權(quán)衡的。 我們繼續(xù)往下看,哪里內(nèi)存泄露了呢?

如果函數(shù)退出,那么m_pFirstNode和m_pNextNode作為棧上局部變量,智能指針本身調(diào)用自己的析構(gòu)函數(shù),給引用的對象引用計數(shù)減去1(shared_ptr本質(zhì)采用引用計數(shù),當(dāng)引用計數(shù)為0的時候,才會刪除對象)。此時如下圖所示,可以看到智能指針的引用計數(shù)仍然為1, 這也就導(dǎo)致了這兩個節(jié)點的實際內(nèi)存,并沒有被釋放掉, 從而導(dǎo)致內(nèi)存泄露。

你可以在函數(shù)返回前手動調(diào)用pFirstNode-》m_pNextNode.reset();強制讓引用計數(shù)減去1, 打破這個循環(huán)引用。

還是之前那句話,如果通過手動去控制難免會出現(xiàn)遺漏的情況, C++提供了weak_ptr。

struct Node

{

Node(int iVal)

{

m_iVal = iVal;

}

~Node()

{

std::cout 《《 “~Node(): ” 《《 “Node Value: ” 《《 m_iVal 《《 std::endl;

}

void PrintNode()

{

std::cout 《《 “Node Value: ” 《《 m_iVal 《《 std::endl;

}

std::shared_ptr《Node》 m_pPreNode;

std::weak_ptr《Node》 m_pNextNode;

int m_iVal;

};

void MemoryLeakLoopRefference()

{

std::shared_ptr《Node》 pFirstNode = std::make_shared《Node》(100);

std::shared_ptr《Node》 pSecondNode = std::make_shared《Node》(200);

pFirstNode-》m_pNextNode = pSecondNode;

pSecondNode-》m_pPreNode = pFirstNode;

//Iterate nodes

auto pNode = pFirstNode;

while (pNode)

{

pNode-》PrintNode();

pNode = pNode-》m_pNextNode.lock();

}

}

看看使用了weak_ptr之后的鏈表結(jié)構(gòu)如下圖所示,weak_ptr只是對管理的對象做了一個弱引用,其并不會實際支配對象的釋放與否,對象在引用計數(shù)為0的時候就進行了釋放,而無需關(guān)心weak_ptr的weak計數(shù)。注意shared_ptr本身也會對weak計數(shù)加1.

那么在函數(shù)退出后,當(dāng)pSecondNode調(diào)用析構(gòu)函數(shù)的時候,對象的引用計數(shù)減一,引用計數(shù)為0,釋放第二個Node,在釋放第二個Node的過程中又調(diào)用了m_pPreNode的析構(gòu)函數(shù),第一個Node對象的引用計數(shù)減1,再加上pFirstNode析構(gòu)函數(shù)對第一個Node對象的引用計數(shù)也減去1,那么第一個Node對象的引用計數(shù)也為0,第一個Node對象也進行了釋放。

如果將上述代碼改為雙向循環(huán)鏈表,去除那個循環(huán)遍歷Node的代碼,那么最后Node的內(nèi)存會被釋放嗎?這個問題留給讀者。

6. 資源泄露

如果說些作文的話,這一章節(jié),可能有點偏題了。本章要講的是廣義上的資源泄露,比如句柄或者fd泄露。這些也算是內(nèi)存泄露的一點點擴展,寫作文的一點點延伸吧。

看看下述例子, 其在操作完文件后,忘記調(diào)用CloseHandle(hFile);了,從而導(dǎo)致內(nèi)存泄露。

void MemroyLeakFileHandle()

{

HANDLE hFile = CreateFile(LR“(C: estdoc.txt)”,

GENERIC_READ

FILE_SHARE_READ,

NULL,

OPEN_EXISTING,

FILE_ATTRIBUTE_NORMAL,

NULL);

if (INVALID_HANDLE_VALUE == hFile)

{

std::cerr 《《 “Open File error!” 《《 std::endl;

return;

}

const int BUFFER_SIZE = 100;

char pDataBuffer[BUFFER_SIZE];

DWORD dwBufferSize;

if (ReadFile(hFile,

pDataBuffer,

BUFFER_SIZE,

&dwBufferSize,

NULL))

{

std::cout 《《 dwBufferSize 《《 std::endl;

}

}

上述你可以用RAII機制去封裝hFile從而讓其在函數(shù)退出后,直接調(diào)用CloseHandle(hFile);。C++智能指針提供了自定義deleter的功能,這就可以讓我們使用這個deleter的功能,改寫代碼如下。不過本人更傾向于使用類似于golang defer的實現(xiàn)方式,讀者可以參閱本文相關(guān)閱讀部分。

void MemroyLeakFileHandle()

{

HANDLE hFile = CreateFile(LR“(C: estdoc.txt)”,

GENERIC_READ,

FILE_SHARE_READ,

NULL,

OPEN_EXISTING,

FILE_ATTRIBUTE_NORMAL,

NULL);

std::unique_ptr《 HANDLE, std::function《void(HANDLE*)》》 phFile(

&hFile,

[](HANDLE* pHandle) {

if (nullptr != pHandle)

{

std::cout 《《 “Close Handle” 《《 std::endl;

CloseHandle(*pHandle);

}

});

if (INVALID_HANDLE_VALUE == *phFile)

{

std::cerr 《《 “Open File error!” 《《 std::endl;

return;

}

const int BUFFER_SIZE = 100;

char pDataBuffer[BUFFER_SIZE];

DWORD dwBufferSize;

if (ReadFile(*phFile,

pDataBuffer,

BUFFER_SIZE,

&dwBufferSize,

NULL))

{

std::cout 《《 dwBufferSize 《《 std::endl;

}

}

責(zé)任編輯:haq

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 內(nèi)存
    +關(guān)注

    關(guān)注

    8

    文章

    3159

    瀏覽量

    75976
  • 函數(shù)
    +關(guān)注

    關(guān)注

    3

    文章

    4401

    瀏覽量

    66544
  • C++
    C++
    +關(guān)注

    關(guān)注

    22

    文章

    2120

    瀏覽量

    76577

原文標(biāo)題:6. 資源泄露

文章出處:【微信號:LinuxHub,微信公眾號:Linux愛好者】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    C/C++代碼靜態(tài)測試工具Perforce QAC 2025.3的新特性

    ?Perforce Validate??QAC?項目的相對/根路徑的支持。C++?分析也得到了增強,增加了用于檢測 C++?并發(fā)問題的新檢查,并改進了實體名稱和實
    的頭像 發(fā)表于 10-13 18:11 ?145次閱讀
    <b class='flag-5'>C</b>/<b class='flag-5'>C++</b>代碼靜態(tài)測試工具Perforce QAC 2025.3的新特性

    技能+1!如何在樹莓派上使用C++控制GPIO?

    和PiGPIO等庫,C++可用于編程控制樹莓派的GPIO引腳。它提供了更好的性能和控制能力,非常適合對速度和精度要求較高的硬件項目。在樹莓派社區(qū),關(guān)于“Python
    的頭像 發(fā)表于 08-06 15:33 ?3212次閱讀
    技能+1!如何在樹莓派上使用<b class='flag-5'>C++</b>控制GPIO?

    C++ 與 Python:樹莓派上哪種語言更優(yōu)?

    Python是樹莓派上的首選編程語言,我們的大部分教程都使用它。然而,C++在物聯(lián)網(wǎng)項目中同樣廣受歡迎且功能強大。那么,在樹莓派項目中選擇哪種語言更合適呢?Python因其簡潔性、豐富的庫和資源而被
    的頭像 發(fā)表于 07-24 15:32 ?520次閱讀
    <b class='flag-5'>C++</b> 與 Python:樹莓派上哪種語言更優(yōu)?

    在OpenVINO? C++代碼啟用 AddressSanitizer 時的內(nèi)存泄漏怎么解決?

    在 OpenVINO? C++代碼啟用 AddressSanitizer 時遇到內(nèi)存泄漏: \"#0 0xaaaab8558370 in operator new(unsigned
    發(fā)表于 06-23 07:16

    主流的 MCU 開發(fā)語言為什么是 C 而不是 C++?

    在單片機的地界兒里,C語言穩(wěn)坐中軍帳,C++想分杯羹?難嘍。咱電子工程師天天跟那針尖大的內(nèi)存空間較勁,C++那些花里胡哨的玩意兒,在這兒真玩不轉(zhuǎn)。先說內(nèi)存這道坎兒。您當(dāng)stm32f4的256kRAM
    的頭像 發(fā)表于 05-21 10:33 ?709次閱讀
    主流的 MCU 開發(fā)語言為什么是 <b class='flag-5'>C</b> 而不是 <b class='flag-5'>C++</b>?

    創(chuàng)建了用于OpenVINO?推理的自定義C++和Python代碼,從C++代碼獲得的結(jié)果與Python代碼不同是為什么?

    創(chuàng)建了用于OpenVINO?推理的自定義 C++ 和 Python* 代碼。 在兩個推理過程中使用相同的圖像和模型。 從 C++ 代碼獲得的結(jié)果與 Python* 代碼不同。
    發(fā)表于 03-06 06:22

    基于OpenHarmony標(biāo)準(zhǔn)系統(tǒng)的C++公共基礎(chǔ)類庫案例:ThreadPoll

    1、程序簡介該程序是基于OpenHarmony標(biāo)準(zhǔn)系統(tǒng)的C++公共基礎(chǔ)類庫的線程池處理:ThreadPoll。本案例完成如下工作:創(chuàng)建1個線程池,設(shè)置該線程池內(nèi)部有1024個線程空間。啟動5個線程
    的頭像 發(fā)表于 02-10 18:09 ?528次閱讀
    基于OpenHarmony標(biāo)準(zhǔn)系統(tǒng)的<b class='flag-5'>C++</b>公共基礎(chǔ)類庫案例:ThreadPoll

    Spire.XLS for C++組件說明

    Spire.XLS for C++ 是一款專業(yè)的 C++ Excel 組件,可以用在各種 C++ 框架和應(yīng)用程序。Spire.XLS for C+
    的頭像 發(fā)表于 01-14 09:40 ?1211次閱讀
    Spire.XLS for <b class='flag-5'>C++</b>組件說明

    EE-112:模擬C++的類實現(xiàn)

    電子發(fā)燒友網(wǎng)站提供《EE-112:模擬C++的類實現(xiàn).pdf》資料免費下載
    發(fā)表于 01-03 15:15 ?0次下載
    EE-112:模擬<b class='flag-5'>C++</b><b class='flag-5'>中</b>的類實現(xiàn)

    同樣是函數(shù),在CC++中有什么區(qū)別

    同樣是函數(shù),在 CC++ 中有什么區(qū)別? 第一個返回值。 C語言的函數(shù)可以不寫返回值類型,編譯器會默認(rèn)為返回 int。 但是 C++ 的函數(shù),除了構(gòu)造和析構(gòu)這兩個特殊的函數(shù),必須
    的頭像 發(fā)表于 11-29 10:25 ?1172次閱讀

    C7000 C/C++優(yōu)化指南用戶手冊

    電子發(fā)燒友網(wǎng)站提供《C7000 C/C++優(yōu)化指南用戶手冊.pdf》資料免費下載
    發(fā)表于 11-09 15:00 ?0次下載
    <b class='flag-5'>C</b>7000 <b class='flag-5'>C</b>/<b class='flag-5'>C++</b>優(yōu)化指南用戶手冊

    TMS320C6000優(yōu)化C/C++編譯器v8.3.x

    電子發(fā)燒友網(wǎng)站提供《TMS320C6000優(yōu)化C/C++編譯器v8.3.x.pdf》資料免費下載
    發(fā)表于 11-01 09:35 ?1次下載
    TMS320<b class='flag-5'>C</b>6000優(yōu)化<b class='flag-5'>C</b>/<b class='flag-5'>C++</b>編譯器v8.3.x

    TMS320C28x優(yōu)化C/C++編譯器v22.6.0.LTS

    電子發(fā)燒友網(wǎng)站提供《TMS320C28x優(yōu)化C/C++編譯器v22.6.0.LTS.pdf》資料免費下載
    發(fā)表于 10-31 10:10 ?0次下載
    TMS320<b class='flag-5'>C</b>28x優(yōu)化<b class='flag-5'>C</b>/<b class='flag-5'>C++</b>編譯器v22.6.0.LTS

    C語言和C++結(jié)構(gòu)體的區(qū)別

    同樣是結(jié)構(gòu)體,看看在C語言和C++中有什么區(qū)別?
    的頭像 發(fā)表于 10-30 15:11 ?1001次閱讀

    C7000優(yōu)化C/C++編譯器

    電子發(fā)燒友網(wǎng)站提供《C7000優(yōu)化C/C++編譯器.pdf》資料免費下載
    發(fā)表于 10-30 09:45 ?0次下載
    <b class='flag-5'>C</b>7000優(yōu)化<b class='flag-5'>C</b>/<b class='flag-5'>C++</b>編譯器