O gerador de ligações poliglotas para sua biblioteca.
Escreva uma biblioteca robusta em Rust, acesse-a facilmente em sua segunda linguagem favorita:
Projete um único .dll
/ .so
no Rust e consuma-o de qualquer lugar.
Obtenha recursos de QV (por exemplo, classes, strings) em linguagens que os possuem.
Sempre tenha uma API sensata e compatível com C.
Fluxo de trabalho indolor, sem necessidade de ferramentas externas.
Fácil de suportar mais idiomas, backends totalmente desacoplados do projeto principal.
Nós nos esforçamos para que nossas vinculações geradas tenham custo zero . Eles devem ser tão idiomáticos quanto você mesmo poderia tê-los escrito, mas nunca mágicos ou ocultando a interface que você realmente deseja expor.
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: Vec2) {println! ("{}", input.x);}// Defina nossa interface FFI como `ffi_inventory` contendo // uma única função `minha_função`. Os tipos são inferidos.pub fn ffi_inventory() -> Inventory {InventoryBuilder::new().register(function!(my_function)).validate().inventory()}
Linguagem | Caixa | Exemplo de saída 1 |
---|---|---|
C# | interoptopus_backend_csharp | Interop.cs |
C | interoptopus_backend_c | meu_header.h |
Pitão | interoptopus_backend_cpython | referência.py |
Outro | Escreva seu próprio back-end 2 | - |
1 Para o projeto de referência.
2 Adicione suporte para um novo idioma em apenas algumas horas. Nenhuma solicitação pull necessária. Promessa de Pinkie.
Se você quiser ...
comece a ver o olá mundo ,
produza seu projeto , veja o layout real do projeto ,
entenda o que é possível , veja o projeto de referência ,
suporte a um novo idioma , copie o back-end C.
Veja o projeto de referência para uma visão geral:
funções (funções independentes e delegados)
tipos (compostos, enums, opacos, referências, ...)
constantes (constantes primitivas; resultados da avaliação const)
padrões (ponteiros ASCII, opções, fatias, classes, ...)
As ligações de baixo nível geradas são ligações feitas à mão com custo zero para esse idioma.
Dito isto, mesmo as ligações artesanais encontram alguma sobrecarga específica do alvo no limite FFI (por exemplo, empacotamento ou fixação em linguagens gerenciadas). Para C#, esse custo geralmente é de nanossegundos, para Python CFFI pode ser de microssegundos.
Embora, em última análise, não haja nada que você possa fazer em relação ao desempenho FFI de uma linguagem, estar ciente dos custos das chamadas pode ajudá-lo a projetar APIs melhores.
Tabelas detalhadas de custos de chamadas podem ser encontradas aqui:
Sobrecarga de chamada C#
Sobrecarga de chamada Python
Para uma visão geral rápida, esta tabela lista os tipos de chamadas mais comuns em ns/call :
Construir | C# | Pitão |
---|---|---|
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 |
Bloqueados por sinalizadores de recursos , eles permitem:
derive
- macros Proc como ffi_type
, ...
serde
- Atributos Serde em tipos internos.
log
- Invoca o log em erros de FFI.
v0.15 - Limpeza massiva, correção de bugs, revisão de UX (+syn2).
v0.14 - Melhor UX de inventário.
v0.13 - O backend Python usa ctypes
agora.
v0.12 - Melhor compatibilidade usando #[ffi_service_method]
.
v0.11 - C# alterna ctors para métodos estáticos.
v0.10 - C# sabores DotNet
e Unity
(incl. Burst).
v0.9 - Fatias C# 150x mais rápidas, dicas do tipo Python.
v0.8 - Funções de teste movidas para os respectivos backends.
v0.7 - Faça macros de proc de padrões para melhores documentos FFI.
v0.6 - Muitos padrões foram renomeados e esclarecidos.
v0.5 - Uso de fatia mais ergonômico em Rust e FFI.
v0.4 - Habilite o suporte de registro em chamadas FFI geradas automaticamente.
v0.3 - Melhor compatibilidade com genéricos.
v0.2 - Introduzidos "padrões"; trabalhando interoperabilidade para C#.
v0.1 - Primeira versão.
Consulte também nossas instruções de atualização.
Perguntas frequentes e guias de segurança.
PRs são bem-vindos.
Envie pequenas correções de bugs diretamente. Grandes mudanças devem ser questões em primeiro lugar.
Qualquer coisa que faça com que as ligações anteriormente funcionais mudem o comportamento ou parem de compilar é uma grande mudança;
Isso não significa que nos opomos a quebrar coisas, apenas que gostaríamos de conversar sobre isso antes que aconteça.
Novos recursos ou padrões devem ser materializados no projeto de referência e acompanhados por um teste de interoperabilidade (ou seja, um teste de back-end executando C#/Python em uma DLL que invoca esse código) em pelo menos um back-end incluído.