因此，例如，我手中有一個全新的編譯語言，但沒有標準庫。我想為這種語言實作一個 malloc 函式。我想到的一種方法是用我的語言將函式撰寫為 extern，并在編譯時鏈接到一個共享庫，該共享庫包含一個簡單地呼叫 malloc 的函式。我想除非我添加行內功能，否則由于包裝的函式呼叫，它可能會導致速度變慢。但是，如果沒有行內，這條路線仍然可以接受嗎？還是從頭開始實施更好？
這確實適用于所有標準庫函式，malloc 只是我使用的一個示例，因此將不勝感激從這個角度回答。
（另外，不是 SO 的狂熱用戶，所以我真的不知道要標記這個問題，歡迎在評論中進行更正，我將編輯問題以包含正確的標簽）
uj5u.com熱心網友回復：
根據我的經驗，一種尺寸并不適合所有人。
您可以使用運行時庫的較小子集以您的語言撰寫一些運行時庫。
您也可以在 LLVM IR 中手動撰寫其中的一些內容，現在 LLVM 具有無型別指標，這要簡單得多。
您可以撰寫撰寫 IR 的 C 。通常，編譯器會根據已決議的源代碼創建 IR，但沒有什么能阻止您使用幾乎沒有輸入的直線代碼創建 IR。
最后，您可以使用 C 等語言撰寫標準庫的部分內容，具有嚴格而怪異的編碼風格，并使用 clang 和自定義 LLVM 傳遞將 C 代碼映射到適合您的語言的 IR。如果您的語言是 OO 語言，則該傳遞會將某個 C 變數映射到
thisorself等??。
我已經使用或看到了所有這些，而且我還沒有看到任何將自身限制為僅一種技術的編譯器。
uj5u.com熱心網友回復：
malloc是 C 庫的一部分。您可以用您的語言實作自己的 malloc，而不是呼叫 libc，這將直接呼叫內核。所有其他 C 函式也是如此。
uj5u.com熱心網友回復：
malloc 通常很慢，簡單的嵌套呼叫不會破壞銀行。
但是這種情況不會是唯一的，因此最好檢查一下您是否無法升級 FFI 處理（外部函式介面）以直接呼叫 extern libcmalloc函式，從而為您節省一個額外的庫來分發和維護。
例如，對于諸如讀取和寫入（檔案/tty 的位元組）之類的呼叫，時間方面也可能比 malloc 造成的傷害更大。
它也不完全是非此即彼，您可以在一個（例如*nix）平臺上使用例如crt/libc 函式，而不是在另一個（例如Dos/Windows）上。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/479743.html