一、inline內聯函數#
特征
- 相當于把內聯函數里面的內容寫在調用內聯函數處；
- 相當于不用執行進入函數的步驟，直接執行函數體；
- 相當于宏，卻比宏多了類型檢查，真正具有函數特性；
- 編譯器一般不內聯包含循環、遞歸、switch 等復雜操作的內聯函數；
- 在類聲明中定義的函數，除了虛函數的其他函數都會自動隱式地當成內聯函數；
- 內聯關鍵字是在編譯時建議編譯器內聯，是不是內聯函數取決于編譯器，一個好的編譯器將會根據函數的定義體，自動地取消不值得的內聯（是否內聯：1、可以通過多次調用函數，查看執行文件大小，如果變大了，就證明是內聯函數；2、通過反匯編查看數據）。
1.1 使用#
- inline是一種“用于實現的關鍵字”，而不是一種“用于聲明的關鍵字”，也就是說，如果只在生命中使用inline是沒有用的，若要成為inline函數必須在定義函數的時候添加該關鍵字。在聲明中加不加inline關鍵字都沒關系，但是為了閱讀方便，還是建議聲明和定義都加上；
- C++在類中定義函數的時候，當函數不包含循環、遞歸、switch 等復雜操作時，編譯器會進行隱式內聯。
- C++在類外定義函數，因為與非inline函數不同：inline函數對編譯器而言必須是可見的，以便它能夠在調用點展開該函數，inline函數必須在調用該函數的每個文本文件中定義。所以內聯函數的聲明和定義建議都放在同一個頭文件，這樣另一個.cpp文件#include該頭文件的時候，就把該內聯函數的定義也包含進來了，這就可以正常使用內聯函數了。
聲明
|
1
2
|
// 聲明1（加 inline，建議使用）inline int functionName(int first, int second,...); |
定義
|
1
2
|
// 定義inline int functionName(int first, int second,...) {/****/}; |
類內定義
|
1
2
3
4
|
// 類內定義，隱式內聯class A {int doA() { return 0; } // 隱式內聯} |
類外定義
|
1
2
3
4
5
|
// 類外定義，需要顯式內聯class A {int doA();}inline int A::doA() { return 0; } // 需要顯式內聯 |
1.2 編譯器對 inline 函數處理步驟#
- 將 inline 函數體復制到 inline 函數調用點處；
- 為所用 inline 函數中的局部變量分配內存空間；
- 將 inline 函數的的輸入參數和返回值映射到調用方法的局部變量空間中；
- 如果 inline 函數有多個返回點，將其轉變為 inline 函數代碼塊末尾的分支（使用 GOTO）。
1.3 優缺點#
1.3.1 優點#
- 內聯函數同宏函數一樣將在被調用處進行代碼展開，省去了參數壓棧、棧幀開辟與回收，結果返回等，從而提高程序運行速度。
- 內聯函數相比宏函數來說，在代碼展開時，會做安全檢查或自動類型轉換（同普通函數），而宏定義則不會。
- 在類中聲明同時定義的成員函數，自動轉化為內聯函數，因此內聯函數可以訪問類的成員變量，宏定義則不能。
- 內聯函數在運行時可調試，而宏定義不可以。
1.3.2 慎用內聯#
- 內聯是以代碼膨脹為代價，僅僅是省去了函數調用的開銷，從而提高了函數的執行效率。如果執行函數體內代碼的時間，相比于函數調用的開銷較大，那么效率的收獲會很小。另一個方面，每一處內聯函數調用都要復制代碼，將使程序總代碼量增大，消耗更多的內存空間。
- 類的構造函數和析構函數容易讓人誤解成使用內聯函數更有效。要當心構造函數和析構函數可能會隱藏一些行為，如”偷偷地“執行基類或成員對象的構造函數和析構函數。所以不要隨便地將構造函數和析構函數的定義體放在類的定義中。
1.3.3 不宜使用內聯#
- 如果函數體內的代碼比較長，使用內聯將導致內存消耗代價比較高；
- 如果函數體內出現循環，那么執行函數體內代碼的時間要比函數調用的開銷大；
1.4 虛函數（virtual）可以是內聯函數（inline）嗎？#
- 虛函數可以是內聯函數，內聯是可以修飾虛函數的，但是當虛函數表現多態性的時候不能內聯。
- 內聯是在編譯器建議編譯器內聯，而虛函數的多態性在運行期，編譯器無法知道運行期調用哪個代碼，因此虛函數表現為多態性時（運行期）不可以內聯。
- inline virtual 唯一可以內聯的時候是：編譯器知道所調用的對象是哪個類（如 Base::who()），這只有在編譯器具有實際對象而不是對象的指針或引用時才會發生。
如下例程：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
#include <iostream>using namespace std;class Base{ public: inline virtual void who() { cout << "I am Base\n"; } virtual ~Base() {}}; class Derived : public Base{ public: inline void who() // 不寫inline時隱式內聯 { cout << "I am Derived\n"; }};int main(){// 此處的虛函數 who()，是通過類（Base）的具體對象（b）來調用的，編譯期間就能確定了，所以它可以是內聯的，但最終是否內聯取決于編譯器。Base b;b.who();// 此處的虛函數是通過指針調用的，呈現多態性，需要在運行時期間才能確定，所以不能為內聯。Base *ptr = new Derived();ptr->who();// 因為Base有虛析構函數（virtual ~Base() {}），所以 delete 時，會先調用派生類（Derived）析構函數，再調用基類（Base）析構函數，防止內存泄漏。delete ptr;ptr = nullptr;system("pause");return 0;} |
二、回調函數和普通函數#
更詳細的回調函數理解可以查看本地的這個文章【【知識點】10張圖讓你徹底理解回調函數】
2.1 什么是回調函數？#
把a函數指針像參數傳遞那樣傳給b函數，而這個a函數會在某個時刻被b函數調用執行，這就叫做回調，a函數稱為回調函數。如果回調函數立即被執行就稱為同步回調，如果在之后晚點的某個時間再執行，則稱之為異步回調。
2.2 為什么要使用回調函數？#
先拋出答案：回調函數的好處和作用，那就是解耦，對，就是這么簡單的答案，就是因為這個特點，普通函數代替不了回調函數。
如下代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
int Callback_1(){ printf("Hello"); printf("This is Callback_1 "); return 0;}int Callback_2() { printf("Hello"); printf("This is Callback_2 "); return 0;} |
發現以上代碼是可以解耦的，因為兩個函數都執行了printf("Hello")，這個時候我們可以通過回調的方式進行解耦，如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
#include<stdio.h>int Callback_1() // Callback Function 1{ printf("This is Callback_1 "); return 0;}int Callback_2() // Callback Function 2{ printf("This is Callback_2 "); return 0;}int Handle(int (*Callback)()){ printf("Entering Handle Function. "); Callback(); printf("Leaving Handle Function. ");}int main(){ printf("Entering Main Function. "); Handle(Callback_1); Handle(Callback_2); printf("Leaving Main Function. "); return 0;} |
像這樣我們就減少了重復代碼啦，也就是解耦。這是使用普通函數調用無法做到的。
回調函數和普通函數有什么區別？
1、對普通函數的調用：調用程序發出對普通函數的調用后，程序執行立即轉向被調用函數執行，直到被調用函數執行完畢后，再返回調用程序繼續執行。從發出調用的程序的角度看，這個過程為“調用-->等待被調用函數執行完畢-->繼續執行”。
2、對回調函數調用：調用程序發出對回調函數的調用后，不等函數執行完畢，立即返回并繼續執行。這樣，調用程序執和被調用函數同時在執行。當被調函數執行完畢后，被調函數會反過來調用某個事先指定函數，以通知調用程序：函數調用結束。這個過程稱為回調（Callback），這正是回調函數名稱的由來。
總結
到此這篇關于C++知識點之inline函數、回調函數和普通函數的文章就介紹到這了,更多相關inline函數、回調函數和普通函數內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家！
原文鏈接：https://www.cnblogs.com/lcgbk/p/15000506.html
