File Descriptor Two

In part 1, we looked at how application developers can create a universal Vector2 type that converts to and from different library types. This approach works great when you control the application code, but what if you’re a library author? How can you design your Vector2 type to be automatically compatible with other libraries without knowing which ones your users might combine with yours? The Library Author’s Challenge As a library author, you can’t hard-code conversion operators for every possible Vector2 type that exists. You don’t know which other libraries your users will combine with yours, and adding dependencies just for type compatibility would be unreasonable. What you need is a way to make your Vector2 type generically compatible with any other Vector2-like type that has the same structure. ...

The Interoperability Problem When using multiple libraries in your project, a quite frequent source of annoyance is trying to share their fundamental types, such as a two dimensional vector, quaternion, euler angle, etc. In each library, you can find various names for exactly the same concept. Consider a hypothetical game development scenario: you could be using Box2D for physics (which has b2Vec2), raylib for graphics (which has Vector2). Despite that two types represent exactly the same thing, they cannot be used interchangeably. This forces you to copy one object into another, every time you wish to pass data and convert between them. Since these conversions are needed quite frequently, constantly operating on copies can become a source of bugs, along with being generally unergonomic. What if we could make our own type to rule them all? ...

Cross compilation is a common task during development, but different compilers and programming languages handle it in their own ways, and I wanted to write about the various flavors of trade-offs and design decisions that you will find across different tooling. I feel like I have absorbed a lot of information about how cross compilation works across different targets, tools and languages, so I figured it was time to condense my knowledge into a blog post. This is not a tutorial, but it still contains practically applicable knowledge. I don’t claim to get every detail correct, merely explaining how things work to my understanding. ...

When executing various Makefiles with w64devkit, you can occasionally run across a Windows program with a Makefile written for cmd.exe. Often the only thing broken about them is the conventional clean target, which uses del.exe and will only work under cmd.exe. make clean del *.o /s sh: del: not found make: *** [Makefile:734: clean] Error 127 Confusingly, even if you then open cmd.exe and run make clean from there, you still get the same error! ...