適用於您的程式庫的多語言綁定產生器。
用 Rust 編寫一個強大的庫,從您第二喜歡的語言輕鬆存取它:
在 Rust 中設計單一.dll
/ .so
,從任何地方使用它。
以具有 QoL 功能(例如,類別、字串)的語言取得這些功能。
始終擁有一個健全的、與 C 相容的 API。
無痛工作流程,無需外部工具。
易於支援更多語言,後端與主項目完全解耦。
我們努力使我們產生的綁定零成本。它們應該像您自己合理編寫的那樣符合慣用法,但絕不是魔術或隱藏您真正想要公開的介面。
use interoptopus::{ffi_function, ffi_type, Inventory, InventoryBuilder, function};#[ffi_type]pub struct Vec2 {pub x: f32,pub y: f32,}#[ffi_function]pub fn my_function(input: V2)}#[ffi_function]pub fn my_function(input: V2) {print ("{}", input.x);}// 將我們的FFI 介面定義為`ffi_inventory`,其中包含//單一函數`my_function`。類型為 inferred.pub fn ffi_inventory() -> Inventory {InventoryBuilder::new().register(function!(my_function)).validate().inventory()}
語言 | 箱 | 樣本輸出1 |
---|---|---|
C# | interoptopus_backend_csharp | 互通性cs |
C | interoptopus_backend_c | my_header.h |
Python | interoptopus_backend_cpython | 參考.py |
其他 | 寫出自己的後端2 | - |
1供參考項目。
2在短短幾個小時內增加對新語言的支援。無需拉取請求。萍琪派承諾。
如果你想 ...
開始看看你好世界,
產品化您的項目,查看真實的項目佈局,
了解什麼是可能的,請參閱參考項目,
支援新語言,複製C後端。
請參閱參考項目以了解概述:
職能(獨立職能和代表)
型別(複合、枚舉、不透明、引用…)
常數(原始常數;const 求值的結果)
模式(ASCII 指標、選項、切片、類別…)
產生的低階綁定是針對該語言手工製作的綁定的零成本。
也就是說,即使是手工製作的綁定也會在 FFI 邊界處遇到一些特定於目標的開銷(例如,託管語言中的編組或固定)。對於 C#,此成本通常為奈秒,對於 Python CFFI 則可能為微秒。
雖然最終您對語言的 FFI 效能無能為力,但了解呼叫成本可以幫助您設計更好的 API。
詳細的通話費用表可以在這裡找到:
C# 呼叫開銷
Python 呼叫開銷
為了快速概覽,此表列出了ns / call中最常見的呼叫類型:
構造 | C# | Python |
---|---|---|
primitive_void() | 7 | 第272章 |
primitive_u32(0) | 8 | 第392章 |
many_args_5(0, 0, 0, 0, 0) | 10 | 第786章 |
callback(x => x, 0) | 43 | 1168 |
在功能標誌後面進行門控,這些功能可以:
derive
- Proc 宏,例如ffi_type
,...
serde
- 內部類型的 Serde 屬性。
log
- 呼叫 FFI 錯誤日誌。
v0.15 - 大規模清理、錯誤修復、使用者體驗大修(+syn2)。
v0.14 - 更好的庫存使用者體驗。
v0.13 - Python 後端現在使用ctypes
。
v0.12 - 使用#[ffi_service_method]
更好地相容。
v0.11 - C# 將 ctor 切換為靜態方法。
v0.10 - C# 風格的DotNet
和Unity
(包括 Burst)。
v0.9 - C# 切片速度提高 150 倍,Python 類型提示。
v0.8 - 將測試功能移至各自的後端。
v0.7 - 為更好的 FFI 文件製作模式流程巨集。
v0.6 - 重新命名並澄清了許多模式。
v0.5 - Rust 和 FFI 中較符合人體工學的切片使用。
v0.4 - 在自動產生的 FFI 呼叫中啟用日誌記錄支援。
v0.3 - 與泛型更好的兼容性。
v0.2 - 引入「模式」; C# 的工作互通。
v0.1 - 第一版。
另請參閱我們的升級說明。
常見問題和安全指南。
歡迎 PR。
直接提交小錯誤修復。重大變化首先應該是問題。
任何使先前工作的綁定改變行為或停止編譯的事情都是重大變化;
這並不意味著我們反對破壞東西,只是我們想在它發生之前討論它。
新功能或模式必須在參考項目中具體化,並至少在一個包含的後端中進行互通測試(即針對呼叫該程式碼的 DLL 執行 C#/Python 的後端測試)。