C 的智慧型指標不就基本解決了野指標問題了嗎 為什麼還要吹捧rust的記憶體安全

時間 2021-05-07 11:43:30

1樓:News

Rust的記憶體安全解決方案是系統、戰略性的,從總體把握了整個記憶體安全方面的問題。

c++的智慧型指標解決了野指標問題,它只是乙個方法,沒有整體的解決了記憶體安全方面的所有問題

Rust 的記憶體安全,給出的是一套完整的解決方案。

2樓:gunir

我不明白為啥要捧一踩一。天下沒有免費的午餐,你不想手動釋放資源就要消耗效能。

兩者兼得就要增加語法結構如c#。更多人是見到啥用啥。別論這些沒用的。

3樓:

c++的智慧型指標沒有解決懸垂指標的問題:因為在電腦程式的執行過程中,指向乙個非法位址的指標是合法存在的。而c++語言的所有機制,都是面向編譯時程式設計的,即使會程式設計一些機制,通過一些編譯邏輯上的推算保證執行時合法,但絕對不可能對執行時的譬如指標的安全,記憶體洩露等問題進行管理,因為c++不干預執行時,只向編譯時程式設計。

4樓:王潛公升

我覺得可以再加上一條,prefer at to

問題是現實世界中沒有那麼多有經驗的C++程式設計師,所以在編譯期做到記憶體安全還是很有現實價值吧

5樓:zhtz

除了其它答主舉得防不勝防的例子,還有一些簡單的例子:

auto

foo()

auto foo()

auto foo() -> std::string &// 假設 obj.foo() 返回的是乙個右值for (auto val:

obj.foo().bar這些錯誤很明顯但也不是每個人都能理解,對於初學者特別是不關心編譯器警告的,簡直防不勝防。

而用 Rust ,編譯器就會直接教你做人。

6樓:小島上的做題家

拿shared_ptr說,shared_ptr解決的問題僅僅是在所有shared pointers都被釋放之後,一定會執行一次delete,僅此而已。

它並不能保證在你擁有shared ptr的時候你指向的東西不會被release掉,比如在我還有活著的shared pointer的時候,別人的地方是可以執行delete。它同樣不能禁止在shared ptr之外,有raw指標指向同乙個物件,很多legacy都只吃raw ptr,經常會在code見到必須用`ptr.get()`的時候。

手動delete heap記憶體的雖然不常見,但我相信很多人都見過這樣的code(我就見過3個不同的人,我們公司以C++著稱),

std::

shared_ptr

>getClient();

}shared pointers只能保證大多數情況下這片兒記憶體可以正常的死,但完全無法保證這片內存在你需要的時候一定還活著。

7樓:坐下坐下基本操作

1.智慧型指標解決的問題,在rust裡通過lifetime標記,傳遞指標/借用能解決一部分,並且rust還提供了Box Cell RefCell等多種選擇,讓你更加細膩的控制你的記憶體。

2.再拿sharedptr舉例子,現在被A,B兩個thread持有,他們分別是你的兩位同事編寫的,這就很容易有datarace。

rust所謂的記憶體安全,其實是管理unsafe,同時利用語言的借用,引用來解決datarace,雖然限制多了點,但是的確奏效。

用c++就是跟同事(包括自己)和編譯器對線,而用rust就簡單了,你只需要不停的跟編譯器對線

8樓:向陽

智慧型指標更多的是解決啥時候釋放的問題,例如shared_ptr、M$家的CCOMPtr。而空指標、莫名其妙的越界訪問等等,智慧型指標就有點無能為力了。

胡思亂想一下,來嘗試一下考慮什麼叫做記憶體安全呢?個人認為的記憶體安全不單是執行時不會莫名其妙來個0xc0000005這樣的記憶體訪問錯誤,而是能保證不會破壞掉這個程式的資料,能不考慮細節就去追溯到各個操作帶來的影響。從這個角度來看,這個問題的答案就清晰了

9樓:cqwrteur

智慧型指標就是個屑。我說所有智慧型指標都是濫用也不為過。智慧型指標只會讓程式設計師偷懶不寫五法則類。智慧型指標濫用一大原因就是物件導向。物件導向就是盧瑟才用的。

10樓:蔬菜

智慧型指標是一種執行期的機制,相比之下rust編譯時的檢查負擔要大,這個負擔在有些情況下顯得過於昂貴甚至無法承受的,從工程的角度看問題發現的越早代價越小

2. 智慧型指標是靠人把它用好,而rust是靠編譯器。機器檢查比人靠譜,從工程的角度看越能降低開發者的心智負擔價值越高

11樓:「已登出」

rust的記憶體安全對標的應該是c++的sanitizer而不是對標智慧型指標,而且智慧型指標只是將記憶體的資源分配與物件的生命週期相契合,並沒有完全解決記憶體安全,甚至沒有完全解決野指標的問題

12樓:扶餘城裡小老二

目的是分化瓦解cpp人群,讓c加加後繼無人。把這些人趕到商業陣地裡做炮灰。

35歲以後,想想黑人抬棺,原來抬的是自己。

只有年輕人會學的程式語言,可不就是青春飯嗎?

我今年41了,還在努力學習cpp20,根本就沒想考慮什麼go啊 rust這類的由商業公司運營的語言。商人重利輕別離。它自己都倒閉了,還管你的生死。

當你35那年,你想想你的學弟們還在學cpp,而你為了利益去搞其他程式語言而被輕易取代,那一刻恐怕你已經不會後悔了,而是加入了引導學弟們去學你用的程式語言了。

這是輪迴。等學弟們醒了,恐怕你的境遇會很艱難了

13樓:韓樸宇

事實就是chromium和Firefox這種巨型C++專案,每個月都有幾個CVE,微軟和Google都得出70%的安全漏洞來自記憶體安全問題的結論,所以C++這一套不強制使用也不檢查是否有誤用的智慧型指標是治標不治本。

只有rust這種直接把誤用報成編譯錯誤的方式,才能迫使人們注意到潛在的bug。

再者C++不能解決執行緒安全,而rust可以,這也是為什麼Mozilla會贊助自己員工的rust專案並發起Servo瀏覽器引擎專案。

14樓:鬧鐘

我百分之百同意你的提問。

事實上,智慧型指標(背後是RAII)能夠解決百分之80的問題至少,而其他20%的問題,本來就是需要你精心設計方案的。其實Swift的ARC就是這樣,你聽說大家廣泛抱怨Swift記憶體不安全了嗎?壓根沒有。

Rust太複雜了,當然它提供了很好的東西,但這種很好的東西把日常工作的負擔變大了,可能最終事實上還不如C++、Swift的方案。因為C++和Swift的整個機制,對於乙個平均水平的程式設計師,是不難理解的。

15樓:

本質上,就是 「方案」 和 「方法」 的區別。

「方案」是系統性、戰略性的。「方法」是區域性的、戰術的。

Rust 的記憶體安全,給出的是一整套解決方案。

關於 Rust 記憶體安全網上的文章已經很多了,可以自行去了解了解吧,解釋累了都。

16樓:

跨模組合作基本無解。

你在這uniqueptr,sharedptr美滋滋。

架不住你隔壁部門招了個菜雞只會寫c with class,拿著shared_ptr自己天天get()和reset()。你傳個物件進去記憶體越界的媽都不認識了。

體制問題體制問題。

17樓:歐文韜

智慧型指標只是一種設計模式,並不能解決所有的記憶體管理問題。

比如你用unique_ptr,假設乙個元件要返回內部的物件給外面用,如果你返回unique:ptr的話你沒法阻止它在外面被move掉,如果你返回原始指標的話外層不知道在使用過程中這個元件會什麼時候釋放這個資源。

rust的核心在於提供了編譯期的生命週期管理,相當於給了外層這個記憶體物件能不能轉移和生命週期的保證。使用者就不容易出錯

18樓:暮無井見鈴

智慧型指標解決的更多是獨佔/共享所有權指標的傳播、釋放問題。

至於記憶體安全……野指標以外的記憶體安全問題多了去了。而且自動儲存期變數(「棧」)、容器也可能產生野指標,這時顯然無法用智慧型指標。

19樓:d41d8c

不是所有東西都能包裝成智慧型指標。比如

auto& f(const std::vector& v)auto&& r = f();

int x = r;

這種問題,大概不能簡單地用智慧型指標改寫。

再比如class A {

void f();

void g(std::vector>& vv.push_back([this] { this->f

這如果想用智慧型指標,要繞些彎子。而且可能是增加複雜度,而沒有實際收益。

智慧型指標也不能解決所有問題。即使不考慮效率、只用shared_ptr、不亂用.get()、不考慮迴圈引用、所有物件都用全域性operator new,也還是要小心多執行緒。

20樓:歐子安

vector 能大多數情況替代 new,最後剩下的一點點情況,才用shared_ptr。

不用指標,不就沒有指標問題了嗎?(:

21樓:漁父

解決和解決是不一樣的,設計C語言的時候也號稱解決了彙編需要程式設計師自己管理記憶體的問題。但實際上空間上解決了(一部分),不用乙個位元組乙個位元組的決定了,時間上則完全沒解決。智慧型指標通過RAII,在時間上解決了一部分,但要用到真正嚴謹的程度太繁瑣,很少有人能做到。

所以有了rust,強制你做到,做不到就不讓你生成可執行檔案。其實給C++加上這個強制系統可以達到類似的效果,只是和C++充分相信程式設計師的哲學相悖。

22樓:

總有輔導班打著保分班,包過班的旗號收學費。

農村到處都是包治肝炎的廣告。

商場到處都是如假包換,假一賠十。

只說記憶體安全確實沒有怎麼誇張!

畢竟程式設計這麼複雜的事,人家只說改進了乙個點。

王婆賣瓜,自賣自誇。

不然指望啥?

c 11智慧型指標unique ptr和shared ptr除了用法以外還有哪些不為人知的不同之處?

你這個例子的確ok,但我還不清楚為什麼,有木有大佬能解釋下?我知道的是,如果要動態分配物件,並用基類指標持有物件,那麼基類的析構函式必須是虛的,否則釋放時候可能未定義。我覺得你不能依賴這個例子來決定以後就不把基類的析構宣告為虛的。更新下。這樣寫能正確呼叫析構函式 std shared ptr p s...

用 C 語言或者限制使用智慧型指標的 C 開發的系統,不用智慧型指標怎麼做記憶體管理?

權少 C語言就自己寫個MALLOC和FREE,每次申請都記住位置,配合記憶體池。C 98就用boost的或者自己寫個,一千幾百行的事。 weisonx 最近在看Linux核心原始碼,就寫寫Linux核心如何做記憶體管理的 大概 首先資源的分配基本是在專門的初始化函式中進行 若分配中途失敗了,還要及時...

如何修改shared ptr智慧型指標,讓他支援多執行緒?

歐文韜 用atomic shared ptr std experimental atomic shared ptr cppreference.com 不過如果你不改shared ptr的指向內容,僅僅使用它的引用計數維護生命週期的話,它也是執行緒安全的。 陳波 雖然借用shared ptr來實現執行...