cinterop con le librerie C

A volte il codice necessario si trova in una semplice libreria C. Kotlin/Native può chiamarla direttamente tramite uno strumento chiamato cinterop. 🔌

cinterop legge gli header C e genera i binding Kotlin. Dopodiché, le funzioni e i tipi C appaiono come normali dichiarazioni Kotlin che può chiamare.

Descriva la libreria in un piccolo file def: quali header leggere e quale libreria collegare. Questa è la ricetta seguita da cinterop.

All'interno del blocco kotlin registri una voce cinterop per il target. Gradle esegue quindi lo strumento e aggiunge i binding generati alla compilazione.

Una volta generata, una funzione C è semplicemente una funzione Kotlin. La importi dal package definito nel file def e la chiami come qualsiasi altra funzione condivisa.

Un puntatore C grezzo corrisponde a CPointer in Kotlin. È tipizzato, quindi il compilatore sa a cosa punta, invece di lasciarla con un semplice indirizzo.

C non libera le risorse al posto suo. Allochi la memoria all'interno di un blocco memScoped, così Kotlin rilascia automaticamente la memoria nativa quando il blocco termina.

Usi gli helper per convertire le stringhe tra Kotlin e C. Una String Kotlin diventa un buffer C con cstr e viene riconvertita quando legge i risultati.

Le struct C corrispondono a classi Kotlin con accesso ai campi. Un tipo opaque che non ispeziona mai è semplicemente un puntatore da passare direttamente alla libreria.

I binding cinterop esistono solo per i target Kotlin/Native, come iOS. Racchiuda le chiamate dietro expect/actual, così commonMain resta indipendente dalla piattaforma.

Nasconda i puntatori e memScoped dietro una API Kotlin intuitiva. Chi effettua le chiamate usa tipi puliti e non accede mai direttamente ai dettagli C grezzi.

Ha visto che un file def insieme a Gradle genera binding Kotlin per una libreria C, che i puntatori corrispondono a CPointer e che memScoped gestisce la memoria nativa. 🎉