Názory k článku Programovací jazyk Rust: použití FFI při předávání struktur

Hezký článek ;) Pro zajímavost také stojí za to si přečíst blog jednoho z vývojářů Librsvg (URL zrovna po ruce nemám - viz google). Postupně přepisují knihovnu z C do Rustu, ovšem po částech, takže interoperabilita mezi oběma jazyky (oběma směry) je pro ně zásadně důležitá.

Jinak drobnost: pokud se nepletu (ale možná ano), tak typy uint8_t, uint32_t apod. jsou teprve od C99, takže pozor na volby překladače.

Ano je to tak, <stdint> je az v C99, takze pozor na -ansi atd.

Na ten blog se podivam, diky za info.

hmm mohl jsem to vlastne dat do clanku, tak aspon tady:
http://en.cppreference.com/w/c/types/integer

Schválně jsem zkusil kompilovat smyčku s čítačem jako int, int8_t a int_fast_t. GCC, přinejmenším verze 6.3 v Ubuntu zesty, na to kašle totálně, ve všech případech použije 32bitový registr (int je defaultně 32 bitů i na amd64) a s nějakým extra nulováním vyšších bajtů se nepárá. Jediný rozdíl je, když bude podmínka řekněmě i<300, což je u int8 evidentně pravda vždycky, tak z toho GCC udělá nekonečnou smyčku bez podmínky, ale pokud se hodnota i uvnitř smyčky ještě k něčemu používá, tak ji tentokrát (a jen tentokrát) ještě šoupne do jiného registru pomocí movsbl de facto jako rychlé mod 256.

Tak u lokálních proměnných a čítačů cyklů je to skoro jedno, tam je kompilátor schopen klidně počítat v opačném pořadí, unrollovat atd. Spíš bych řekl, že to má význam u proměnných ve strukturách, některé procesory (Alpha v prvních verzích) například neuměly číst z paměti 16 bitů apod. Takže int_fast16_t mohl být násobně rychlejší než int16_t.

Pokud vím, tak ne, typy jako u32, u64 apod. mají povinně stanovenou délku (resp. nemůzou být delší) a u indexů, všelijakých čítačů apod. se zase vynucuje usize (popř. isize). Je to rigidnější, na druhou stranu nevím, jestli je int_fast* doopravdy užitečná věc. Pozor - neříkám nutně, že není, spíš by mě zajímal nějaký takový příklad.