程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> C語言 >> 關於C語言 >> C++中為什麼使用指針比使用對象本身更好?

C++中為什麼使用指針比使用對象本身更好?

編輯:關於C語言
 

最近開始學習使用C++中的對象。有個問題我一直覺得很困惑:那就是為什麼人們更喜歡使用指向對象的指針而不是對象本身。比如:

這樣聲明:Object *myObject = new Object;

而不是:Object myObject;

使用函數的時候也是如此,假設有個函數為testFunc(),使用時可以這樣:

myObject.testFunc();

但一般這樣調用:

myObject->testFunc();

但是我不知道為什麼要這樣做,我想可能是因為我們直接訪問了內存地址,所以能提高效率和運行速度。我理解的對嗎?

最佳答案:

很不幸,你看的很多講的都是動態分配。這只能說明存在很多根本不精通C++的程序員。從某種意義上說,你的問題其實可以分成兩個小問題。第一個是應該何時使用動態分配(即使用new關鍵字)?第二個問題是應該何時使用指針?

使用合適的工具通常是做好一項工作的關鍵。在大部分情況下,存在比使用一般的動態分配或者原指針更合適、更安全的方法。

動態分配

在你的問題裡,你用了兩種方式創建對象。這兩種方式主要的不同在於對象的存儲時間。當執行Object myObject;這句代碼時,它作為自動變量被創建,這意味著當對象出了作用域時也會自動銷毀。而當你使用new Object()這種方式時,對象所擁有的內存是動態分配的,這表示直到你調用delete()方法對象才會被銷毀,否則一直存在。當需要用動態分配內存來處理時,你應該只使用動態分配的方式,也就是說,當你可以使用動態分配內存的時候就不要使用自動變量。

以下是可能會使用到動態分配的兩種常見情況:

1.當想讓對象在出了作用域後依然存在——且確實就是之前存儲在該內存中的對象,而不是對象的拷貝。如果你可以接受使用對象的拷貝或者移動(大部分情況下你應該這樣),那麼你更應該使用自動存儲方式。

2. 當需要大量內存時,這種情況下極易導致棧溢出。當然如果這對你來說根本不是問題就更好了(大部分情況下這是不可能的)。這顯然超出了C++的管轄范圍,但是不幸的是,我們必須處理我們開發的系統中存在的這種現實問題。

當你確實需要使用動態分配時,你應該將它封裝到一個智能指針中或者其他能具有RAII特性的類型(例如標准容器)。智能指針提供動態分配內存的對象的所有權語義。例如std::unique_ptr和std::shared_ptr。如果你能夠合適的使用它,你基本上不需要自己管理內存(參見Rule of Zero這篇文章)。

指針

事實上,指針除了用來實現動態分配內存外還有很多其它的用法,但是其中大部分也都存在比它們更好的選擇。就像前面說過的那樣,除非你必須用到指針,否則不要貿然使用。

需要使用引用的情況:有的時候,你想調用的函數需要訪問你當前的對象本身(而不是它的拷貝),那麼你就需要使用指針作為參數進行傳遞(暫不論它是如何分配的)。然而,在大部分情況下,使用引用會比指針更好,這也正是引用被設計的理由。注意一下,這裡不需要像上面所說的那樣去延長對象的生命周期。前面已經說過了,如果你能接受使用對象的拷貝,那麼你就沒必要再使用引用了。

需要使用多態的情況:通常你只能通過對象的指針或者引用來實現多態(也就是根據對象的動態類型來調用函數)。如果這就是你想要的,那麼你就需要使用指針或者引用。同樣,以指針為優先選擇。

當對象可忽略時,通過傳遞一個空指針來實現對象是可選的屬性:如果它是一個參數的話,你應該優先使用默認參數或者函數重載的方法。否則你應該選擇一種可以封裝這種行為的類型,例如boost::optional(或者是std::optional)。

當你想降低文件間的編譯依存關系從而節省時間:指針的一大特點在於你只需要在前面聲明一下指針指向的類型(而如果要使用實際的對象,你還需要定義一下)。這樣你就能降低你的編譯單元之間的耦合性從而減少編譯時間。參考Pimpl idiom.

當你想調用C或者類似C風格的函數庫的接口時:在這種情況下,你不得不使用指針進行操作。你唯一能做的事情就是要保證你的指針在不使用時要被釋放。你也能通過智能指針來操作原指針,例如通過它來調用成員函數。如果被調用庫已經為你申請了空間而又希望你通過句柄來釋放的話,利用智能指針封裝起句柄並利用定制的析構器來釋放內存無疑是一種合理的選擇。

 
  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved