Two more small utility libraries !

So it’s been a while since my last post, live has been a bit crazy for the last three months!

In the last weeks, I have been working on a couple more simple utility libraries simple_ogl and simple_plugin.
I have by looking at previous projects and identifying either things that I was copying from project to project (creating a modern context OpenGL ready window) or somethings which I have only used a couple of times but was was a huge gain which I would want to bring to new projects (creating plugins that can be hot-reloaded for quick code iteration).

The first utility is simple_ogl, it is a small header file that allows to easily create a modern OpenGL ready window. It has no external dependencies (unless you consider gl.h a dependency ) and can just be dropped into your project and be ready to use.

The second one is simple_plugin, another single header library that offers a quick way to implement a plugin system into your application. One of the feature of this system, and the main reason I wanted to make it reusable across projects is that it allows for hot-reloading of the plugins (which are dlls). So we can change some code in a plugin, recompile and see changed instantly as our main application is running. Here is an example of what I’m talking about and the main inspiration.

Like the last post about simple_log I wanted to write about something I had learned from this little project. After thinking about it, what stuck with me the most was the feeling of paralysis when confronted with some design decision for these two small libraries.

The decisions themselves don’t really matter that much, what I think is interesting is that at some point I understood what was keeping me from trucking on. I was trying to make them to general! I was thinking of too many use cases in order to either add something to it or figure out the API.

The breaking point came when I was figuring out how to structure the plugins in order for them to interact with a client application. I went online to read about how other people have done this before and eventually ended up liking this idea a lot! (Yes I like this blog a lot)

My poor man’s summary of the post :

  • The plugin header contains:
    • Name of the API that it offers (#define at the top).
    • An “API struct” which is a struct containing function pointers to the functionality the plugin provides. One reason for this is to make it easier to pass the API around, instead of multiple functions you have one struct.
    • Any other documentation is in the header as well.
  • The dll contains:
    • The implementation of the plugin’s functionality.
    • A load_xxx and unload_xxx function (where xxx is the name of the plugin) which the client application call into to load and unload the plugin.

 

So I decided to use the same ideas, to structure the plugins. That is when the paralysis struck! I thought I had to make it easier, more general. All I was doing was spending time afraid to commit to any one solution, because it was too specific.

Eventually I came back to the original idea that I liked and seemed to make sense. I’m not saying it was wasted time as it forced me to genuinely think about other solutions (and there are many more!).

What I am saying is that sometimes you just need to make a (informed) design decision and keep going. Keeping it focused and specific is better then trying to cater to every hypothetical use case, specially when you don’t really have any data about these cases.

So make a decision. It might even be the wrong decision, but that’s alright. You learn, iterate and next time around make a different more informed decision.

Slowly improving towards your goal.

 

 

Advertisements

Releasing simple_log

I have recently released a small utility library called simple_log !

simple_log is a simple to use logging utility written in C++. It is a single file header that implements logging utility functions (to file or console) that should be very easy to drop-in and start using in any pre-existing project. It currently only supports Windows applications.

simple_log came from me deciding to tidy up some logging code that I have been using in my own projects for some time now and making it available for anyone who might want to use it. The process of transforming code which I have been using only for my myself to code which might be used by others was interesting and I wanted to write a small post about some things that stuck with me.

A lot of these might be obvious to some, specially if you are a more experienced developer. But for less experienced people it might be interesting to read.

Let’s get started.

Continue reading “Releasing simple_log”