sokol-odin VS mvb-opencv

* etc

There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs.

And Odin's `foreign` system allows [1] for a lot of really nice things that most other languages cannot do so tersely. Here are two examples of demonstrating bindings of C libraries that feel as if they were native Odin libraries WITHOUT any wrappers:

* https://github.com/floooh/sokol-odin/blob/main/sokol/gfx/gfx... (and the rest)

I maintain auto-generated bindings for my C libraries for Zig and Nim (and Odin and Rust - although the Rust bindings definitely need some love to make them a lot more idiomatic).

I think looking at the examples (which is essentially the same code in different languages) gives you a high level idea, but they only scratch the surface when it comes to language features (things like the Zig code not using comptime features):

Zig: https://github.com/floooh/sokol-zig/tree/master/src/examples

Nim: https://github.com/floooh/sokol-nim/tree/master/examples

Odin: https://github.com/floooh/sokol-odin/tree/main/examples

Rust: https://github.com/floooh/sokol-rust/tree/main/examples

I'm actually dabbling with Odin a bit in the scope of language bindings for the sokol headers:

https://github.com/floooh/sokol-odin

It's a very enjoyable language!

I recently wrote a bindings generator to Odin for my C libraries, and the FFI is very well thought out, down to defining things like linker dependencies in the code. For instance see here:

https://github.com/floooh/sokol-odin/blob/main/sokol/gfx/gfx...

The only minor downside (compared to Zig) is that Odin still requires a separate C/C++ toolchain to actually build the C dependencies. But I guess that's a typical 1st-world-problem ;)

(but AFAIK Odins FFI system isn't in any way related or depending on LLVM).

I don't know if my particular version is noteworthy, but I recently started making updated Nim bindings for OpenCV and it was kinda fun. I don't consider myself an advanced C++ programmer, but Nim made the process easier than I had feared it would be. https://github.com/tapsterbot/mvb-opencv