Wayland's Weston Sees Patches For FreeBSD, Fractional HiDPI, Rust Bindings

[phoronix]

Phoronix: Wayland's Weston Sees Patches For FreeBSD, Fractional HiDPI, Rust Bindings

A new contributor to the Wayland/Weston camp has been working on several improvements to the Weston reference compositor...

http://www.phoronix.com/scan.php?page=news_item&px=Weston-FreeBSD-HiDPI-Rust

[miabrahams]

Fractional HiDPI I am very excited about.

[microcode]

It'd be nice to see a FreeBSD developer on the lists and maybe with commit access, that'd be the correct way to support it. ;- )

Also, as OpenBSD's DRM is coming along, I suspect Wayland compositors should start working there as well. Exciting times. :- )

[kaprikawn]

Could someone explain what 'bindings' are please, I'm starting to see references to that around a lot more now, especially in relation to Rust and I don't actually know what it means

[DanL]

If you're not a programmer, you probably don't care. https://en.wikipedia.org/wiki/Language_binding

[starshipeleven]

Could someone explain what 'bindings' are please, I'm starting to see references to that around a lot more now, especially in relation to Rust and I don't actually know what it means

Bindings are interfaces to call libraries or programs written in language X from programs written in language Y.

They help making tools and libraries in a specific language more useful as more programs can now call them and use them.

If bindings didn't exist, the only way to use a library is to call it from a program written in the same language, or by using commandline or inter-program communication interfaces that are not anywhere near as performant as a true binding.

[kaprikawn]

Thanks both, makes sense. I am actually a programmer, but I'm still not sure if I care

So I write in C++, and I use SDL2 (which I believe is C), am I already using these bindings then? Does C++ need bindings to link to C code?

[birdie]

Thanks both, makes sense. I am actually a programmer, but I'm still not sure if I care

So I write in C++, and I use SDL2 (which I believe is C), am I already using these bindings then? Does C++ need bindings to link to C code?

Usually C++ doesn't need bindings for C code while the opposite is false.

[starshipeleven]

So I write in C++, and I use SDL2 (which I believe is C), am I already using these bindings then?

C++ is an expanded C so it is a special case and you don't need bindings, for pretty much anything else (including calling C++ from C) you'd need bindings.

Most common use cases I know is having Python bindings on some GUI-less tool. This allows people to create easy GUIs to operate the tool on any platform Python itself runs in, and lets you keep separate the high-performance code from the high-abstraction (faster to write complex stuff but it is low-performance) GUI part.

[nslay]

Thanks both, makes sense. I am actually a programmer, but I'm still not sure if I care

So I write in C++, and I use SDL2 (which I believe is C), am I already using these bindings then? Does C++ need bindings to link to C code?

It's easy to think of C++ as a superset of C (and it is in most, but not all, ways!). I see that the forum has provided this mistaken answer to your questions.

The answer to your question is: Yes

But bindings for C++ from C merely amount to preventing the C++ compiler from mangling symbol names so that it can link with an object/library compiled by a C compiler. The C compiler doesn't mangle symbol names since it doesn't support functionality such as function overloading where name mangling is used. And C++ always mangles symbol names and thus can't resolve C symbols without the extern "C" decoration. You don't notice this for lots of C libraries since their authors have written preprocessors into their headers that automatically decorate all C function prototypes as extern "C" when a C++ compiler is being used. But try this with, say, flex(1) C parsers and you'll see link errors (C lex.yy.h will not have such preprocessors).

This notion of bindings between C and C++ becomes even more blurred when you start playing with function pointers. If, for example, you're playing with qsort() in C++ (not that you would in reality), it's technically incorrect to pass a C++ function pointer for the comparison function argument. If you're using the same compiler suite, this is usually glossed over and silently handled (e.g. Visual Studio, GCC) and you get no error and the program still works. Technically the C++ function pointer is not a callable C function and you'd really need to decorate the prototype with extern "C" (and compilers will sometimes treat an extern "C" function pointer type as a distinct type to a C++ function pointer!). There could be a different call convention used by C functions as compared to C++ functions. And, if I remember correctly, you can't do this with static methods in a class even though their addresses would be valid C++ function pointers. The only way you can do this so as to not pollute the namespace is to create the extern "C" function in an anonymous namespace.

Learned about these unusual subtleties while playing with libevent2 in C++. You'll probably never encounter issues passing C++ function pointers to C functions that then invoke the function pointers. Just know that you're potentially venturing into undefined behavior by doing so.