Qt/C++面試【速通筆記一】

Qt 信號與槽機制

什么是信號（Signal）和槽（Slot）？

在Qt中，信號（Signal）和槽（Slot）是實現對象之間通信的一種機制。信號是對象在某些事件發生時發出的通知，而槽是響應這些通知的函數。信號和槽之間是松耦合的，意味著你不需要直接調用某個函數來響應事件，只需要連接信號和槽即可。

信號（Signal）：
信號是一個事件，當某個條件滿足時，它會被觸發。例如，用戶點擊按鈕時，按鈕會發出clicked()信號。信號本身不包含任何行為，它只是表示某個特定的事件發生了。
槽（Slot）：
槽是一個普通的成員函數，用來響應信號。當信號被觸發時，槽會被自動調用，執行特定的邏輯。槽可以在對象內部定義，并且與一個或多個信號關聯。信號和槽的連接是自動的，無需手動調用。
如何工作：
通過Qt的connect()函數，我們將一個信號與一個槽連接起來。當信號發出時，連接的槽函數會被調用。信號和槽之間的連接不依賴于它們的對象類型和層級結構，甚至可以跨線程使用。
舉個例子，如果按鈕被點擊了，就會發出一個信號，點擊按鈕的操作會觸發與之連接的槽函數，執行一些操作。

示例代碼：

#include <QApplication>
#include <QPushButton>class MyWindow : public QWidget {Q_OBJECTpublic:MyWindow() {QPushButton *button = new QPushButton("Click me", this);connect(button, &QPushButton::clicked, this, &MyWindow::onButtonClick);}public slots:void onButtonClick() {qDebug() << "Button clicked!";}
};int main(int argc, char *argv[]) {QApplication app(argc, argv);MyWindow window;window.show();return app.exec();
}

在上面的例子中，當點擊按鈕時，QPushButton::clicked信號被發出，它與onButtonClick()槽函數連接，因此會輸出“Button clicked!”。

QObject類是如何實現了信號與槽機制的？

QObject是Qt的基類，幾乎所有的Qt對象都繼承自QObject。Qt的信號與槽機制是通過QObject類實現的。QObject提供了一個connect()函數，用來連接信號和槽。

底層實現依賴于Qt的元對象系統（Meta-Object System），通過QMetaObject和QMetaMethod來動態查找并連接信號和槽。QObject還提供了一個signals和slots的聲明，用來標識哪些成員是信號或槽。

實現過程：

QObject類：
QObject類是Qt中所有對象的基類，提供了信號與槽機制的基礎功能。QObject類中的connect()函數是建立信號與槽連接的核心方法。
Q_OBJECT宏：
要使用Qt的信號與槽機制，類必須包含Q_OBJECT宏。這會告訴Qt的元對象系統，類中的信號與槽需要被處理。Q_OBJECT宏會使得類能夠使用元對象特性，包括信號與槽的管理。
moc（元對象編譯器）：
在編譯過程中，Qt使用moc工具對包含Q_OBJECT宏的類進行預處理。moc會生成額外的代碼，包括信號與槽的聲明和實現。具體來說，moc生成的代碼包括信號的聲明，以及一個名為qt_static_metacall的函數，這個函數用于動態調用信號和槽。
connect函數：
QObject::connect()函數用于將信號和槽進行綁定。它接受發送者對象、信號、接收者對象和槽函數作為參數。當信號被觸發時，connect()會確保相應的槽函數被調用。

Qt的信號與槽的底層實現是什么？原理是什么？

底層原理基于Qt的元對象系統。每個繼承自QObject的類都會自動包含一個元對象信息（QMetaObject），它包含了類的信號和槽的相關信息。信號與槽機制的工作過程大致如下：

當信號被發出時，Qt通過QMetaObject查找連接到該信號的槽函數。
信號和槽連接后，Qt會將信號的參數傳遞給槽函數。
底層通過事件循環機制和隊列來傳遞信號和槽，確保它們異步觸發。

信號與槽機制原理

Qt的信號與槽機制依賴于事件系統，信號是通過QObject::connect函數連接的，當信號發出時，Qt會自動將信號傳遞給與之連接的槽。Qt實現了信號和槽的解耦，這意味著對象可以不直接互相調用函數，而是通過信號和槽進行通信。

信號是事件，而槽是響應事件的函數。
信號與槽是松耦合的，減少了代碼之間的依賴。

底層原理：

信號和槽的函數指針：
每個信號和槽都對應一個函數指針，信號的發出實際上是通過調用一個函數來通知所有連接的槽。信號與槽的連接過程實際上是將信號與槽的函數指針進行綁定。
元對象和QMetaObject：
每個QObject派生的對象都有一個對應的QMetaObject對象，它包含了該類的元數據，包括信號、槽函數的名稱、參數類型等。QMetaObject提供了查詢和管理信號與槽的功能。
connect函數：
QObject::connect()函數用于建立信號和槽之間的連接。當調用connect()時，它將信號與槽函數的ID（由QMetaObject管理）綁定在一起，確保信號能夠正確觸發相應的槽函數。
信號發射：
信號的發射是通過QObject::active_signal()函數觸發的，它會查找與該信號相連接的槽，并調用相應的槽函數。
信號和槽的傳遞：
信號與槽的傳遞是通過調用QObject::connect()函數中實現的內部接口connectInternal()來完成的。connectInternal()通過查詢信號和槽的元對象信息，完成槽函數的調用。

信號與槽機制的優勢和不足

優勢：

松耦合：信號與槽的機制使得對象之間的耦合度非常低。對象只關心信號的發出，而不關心接收信號的槽函數。
易于維護：信號與槽機制使得代碼結構清晰，避免了復雜的函數調用。
線程安全：Qt的信號與槽機制支持跨線程通信。可以在一個線程中發出信號，而在另一個線程中接收并處理這個信號。

缺點：

運行速度較慢：
與直接調用函數相比，信號和槽機制的運行速度較慢，可能慢10倍左右。原因包括：
- 需要在運行時動態查找接收信號的對象。
- 需要遍歷所有槽函數。
- 參數需要進行封裝和解封裝。
- 在多線程中，信號需要排隊等待。
但是：
這種性能損失通常對于實時應用程序是可以忽略的，而對于復雜的UI應用來說，這些性能開銷是可以接受的。

信號與槽與函數指針的比較

信號與槽機制與函數指針有一些相似之處，因為它們都允許動態調用函數。區別在于：

松耦合：信號與槽機制是一種松耦合的設計，信號與槽的連接是在運行時進行的，而函數指針通常在編譯時就已經確定。
自動類型安全：Qt的信號與槽機制提供了自動的類型檢查，只有匹配的信號和槽才能連接，而函數指針需要手動進行類型匹配。
跨線程支持：Qt的信號與槽機制原生支持跨線程的通信，而函數指針通常無法直接實現這一點。

回調函數和函數指針：
回調函數通常使用函數指針來實現，多個類需要監聽一個類的變化時，需要維護一個函數指針列表，手動管理類之間的關系。這種方法較為冗長和不靈活。
Qt的信號與槽機制：
Qt使用信號與槽來簡化回調函數的管理。一個類只需聲明自己的信號和槽，并通過connect()函數將它們連接起來。Qt框架會自動管理信號和槽的調用關系。
優勢：
- 清晰簡潔：
  信號與槽機制使得代碼邏輯更清晰，易于管理和擴展。
- 降低耦合度：
  發出信號的對象不需要知道哪個對象會處理信號，而槽也不需要知道哪個信號發出，降低了對象之間的耦合度。
- 靈活性：
  一個信號可以連接多個槽函數，多個信號也可以連接同一個槽。

QT中connect函數的第五個參數是什么？有什么作用？

connect()函數的第五個參數是Qt::ConnectionType，它用來指定信號和槽連接的方式。這個參數控制信號發射時槽的執行時機。常見的值有：

Qt::AutoConnection（默認值）：
根據信號發出的線程和槽所在的線程，自動選擇最合適的連接方式。如果信號和槽在同一線程，直接調用槽；如果信號和槽在不同線程，使用事件隊列傳遞信號。
Qt::DirectConnection：
無論信號和槽是否在同一線程，信號發出時直接調用槽函數。適用于在同一線程內的連接。
Qt::QueuedConnection：
如果信號和槽在不同線程中，信號會被排入接收線程的事件隊列，等到事件循環運行時調用槽函數。這樣可以避免在不同線程間直接調用，減少線程同步的問題。
Qt::BlockingQueuedConnection：
這個連接類型在信號和槽在不同線程時使用，信號發出后，發送者線程會被阻塞，直到槽執行完畢。

Qt 信號槽機制的優勢和不足

優點：

類型安全：
信號和槽的簽名必須匹配，即信號的參數類型和個數必須與槽的參數一致。如果不一致，編譯器會報錯，避免運行時錯誤。
松散耦合：
信號和槽機制減少了對象之間的耦合。發出信號的對象不需要知道哪個對象的哪個槽函數接收信號，只需發出信號即可。即使接收槽的對象在運行時被刪除，也不會導致崩潰。
靈活性：
一個信號可以連接多個槽函數，多個信號也可以連接同一個槽。這使得信號和槽的使用變得非常靈活。

缺點：

運行速度較慢：
與直接調用函數相比，信號和槽機制的運行速度較慢，可能慢10倍左右。原因包括：
- 需要在運行時動態查找接收信號的對象。
- 需要遍歷所有槽函數。
- 參數需要進行封裝和解封裝。
- 在多線程中，信號需要排隊等待。
但是：
這種性能損失通常對于實時應用程序是可以忽略的，而對于復雜的UI應用來說，這些性能開銷是可以接受的。