現代編譯器是在決定什麼應該內聯比程序員更好,什麼不應該。就像register
一樣,不應該內聯函數僅僅是編譯器的工作,並且被認爲是不成熟的優化?
4
A
回答
7
inline
有雙重含義,一些是未察覺的 - 它允許如果從各個翻譯單元內定義的報頭中的未結合的功能,幷包括它被在一個以上翻譯單元(即定義的函數,則是被迫宣佈它內聯或鏈接器會抱怨雙重定義的符號)。
第二個含義是向編譯器提示此函數可能會從調用者站點內聯機器代碼中獲益。你是對的,現代編譯器/優化器應該能夠獨立解決這個問題。
我的建議是隻在需要時使用inline
(第一種情況),並且永遠不要將優化提示傳遞給編譯器。這樣,你的源代碼就解決了這個瘋狂的雙重含義。
3
inline
僅與優化切線相關。
如果您需要的一個定義規則的例外情況,您應該選擇將inline
應用於函數,如果您不需要,則將其忽略。大多數情況下,您可以依靠編譯器來執行適當的優化,而不管函數是否被聲明爲inline
。
0
退房這樣的回答:Inlining this function or not?
本質上說,是的,內聯是在這一點上,編譯器的任務。內聯最初是爲了向編譯器表明它應該嘗試而創建的。關鍵字是指示 - 編譯器可以選擇是否將函數內聯。
相關問題
- 1. 儘早破壞事物是否過早優化?
- 2. Java內聯優化是否正確?
- 3. MySQL的優化過早殺
- 4. C++內聯優化
- 5. 在慢速機器上開發是否過早優化?
- 6. 多列優化Postgresql內部聯接(特別是自聯接)
- 7. 什麼時候優化過早?
- 8. 優化內部聯接
- 9. 在編碼時考慮內存碎片:過早優化與否?
- 10. 優化 「不是在」 查詢
- 11. JIT編譯器是否優化(內聯)不必要的變量聲明?
- 12. 優化LINQ EF。使用哪裏而不是聯接?
- 13. gcc是否優化了內核代碼?
- 14. JIT優化器是否優化乘法?
- 15. 優化SQLite內部聯接查詢 - Android
- 16. MySQL查詢優化與內部聯接
- 17. 如何優化多個內部聯接
- 18. 通過函數指針優化和內聯調用
- 19. 何時通過代碼優化「內聯」屬性
- 20. 如果$(window).load(function(){});是不是太早
- 21. 專家混合 - fminunc優化過早停止
- 22. 從JDBC SQL中省略列SELECT選擇過早優化?
- 23. 在C++函數中使用內聯優化的注意事項是什麼?
- 24. 是否可以在C#中進行內聯,從而優化字符串連接?
- 25. 的Rails:優化的,而不是循環
- 26. 查詢優化,而不是在
- 27. C++優化,使用>而不是<=
- 28. requireJS優化:「Uncaught TypeError:undefined不是函數」
- 29. Java是否優化不可變對象?
- 30. MYSQL查詢,優化LIKE,而不是在
...但您可以將其應用到您的代碼中_邏輯完成後。那麼它不會過早:P – progo 2011-03-05 22:45:28
據我所知,inline關鍵字只被認爲是編譯器的一個提示,編譯器可能決定無視它。 – Kai 2011-03-05 22:48:16
「inline」關鍵字不僅用於內聯函數。實際上,當你考慮它時,根本不是內聯函數! :-) – 2011-03-05 22:48:54