我一直在試圖製作一個遊戲引擎，並且我開始製作Mathmatical基礎（向量，矩陣和點類）。 我想創建一個靜態庫文件（.lib），它然後我可以在需要的地方使用我的遊戲引擎的其餘部分。靜態庫性能 - 可能內聯調用？
我想知道的是以下內容。由於庫中的大部分功能都需要儘可能快。我想看看例如一個Vector類被內聯的函數。編譯器能夠自動執行此操作嗎？或者需要某種提示？
我知道我可以將所有源代碼放在頭文件中，但我認爲這不是一個很好的解決方案，因爲某些函數可能太大而不能內聯。 （頭文件對於使用它們的人來說不會是凌亂的。）
我希望你們能幫我一把。
基督教
函數內聯時，才能保證當前的編譯器技術來工作，如果compileunit具有源代碼的可見性。一旦將代碼編譯到庫中，不管函數是什麼，它都不會內聯函數。
有一些「整體程序優化」方案（至少可以在MSVC和GCC中使用，也可能是其他編譯器），它們產生的「目標文件」只是機器碼的一部分，所以有些關於「源代碼需要什麼」的信息可用於最終的代碼生成/鏈接階段，以移動代碼，執行內聯等操作，但是這僅適用於所有源文件在編譯時可用的情況。一旦有東西變成了最終的目標代碼（你的靜態庫），它就不會成爲「內聯」部分。
顯然，如果你有類，它們將在頭文件中，所以如果你把適合內聯的函數放到頭文件中，編譯器會做正確的事情。
是的，你可以這樣做鏈接時間優化。如果你生成一個「胖」庫，它將包括編譯後的源代碼和一個可用於在鏈接時內聯函數的中間表單（實質上，在鏈接時完成最終編譯步驟，其中一切都可見）。
該技術有點脆弱，因爲您需要確保您在編譯和鏈接時使用相同的標誌，並且還有其他一些限制：它不是公開分發庫的好方法。如果它是爲了受控制的內部使用，它可能運作良好。
因此，實際製作最快的Math-Library的唯一可能方法是使其僅用於標題？整體程序優化與僅提供源文件相比有什麼優勢？我的意思是如果你需要第一個源文件，那麼爲什麼不馬上做第二個呢？ – 2013-05-05 14:00:30
我認爲MSVC能夠內聯調用靜態庫函數，只要該庫在啓用鏈接時間代碼生成的情況下編譯即可。 – Timo 2013-05-05 14:06:42
關於內聯，整個程序優化的重點僅僅是「對整個程序進行調整」的副作用，在最終代碼生成中可以將不同的編譯單元組合在一起。我不認爲你需要把它做成「僅頭部」。如果代碼非常短而且快速，內聯只有很多優點。一旦函數足夠大並且需要足夠長的時間才能運行，實際上它不會內聯，因爲代碼更小，並且如果從多個位置調用代碼，緩存中的代碼碰撞機會更好。 – 2013-05-05 14:09:30