Over the years I've accumulated a lot (~100.000 lines) of C code in more than 60 Git repositories. They all work together in a consistent manner, are far from perfect but I'm happy enough with them, and they served me very well in several other projects. LibCapy is an attempt to gather them into one single library, to refactor them along the way based on what I've learnt since, and to define a new place where to keep on adding more code to them.
The library doesn't serve a well defined goal, nor attempt to solve a particular problem. It's more a collection of functions and data structures which I happened to have interest into at some point in the past. So, it's certainly a bit biased toward computer graphics and machine learning, but there are also completely unrelated things there, especially at the beginning when there'll be only basic and generic functions and structures. The library is available under the GNU General Public License on this page and you'll find examples of use here.
Sharing it online is of course a way to leave the opportunity to someone interested to use it or just look at it. It's also a way for me to document it, which I was already doing with the former repositories, in a different way. Here, each unit will have it's own page in the category LibCapy of this website. These pages, and this page, and this library will be continuously updated, that's a forever WIP pet-project.
About the name
Do you know what a capybara is ? It's the biggest rodent in the world, living in South America. I like capybara, cause they live a lasy, quiet, peaceful life, are masters of stoicism and best friends of all. Just like we all should be. Just like a good library should be. Hence, LibCapy, that's it. (the crappy play on word Capy → C-Api also fits me well, too...)
Principles
The principles I wish to follow in this project are as follow. Some of them because I believe they are good, some because I just want to experiment with them.
- Linux OS. I have nothing against others, I just doesn't have the machine to code and test on it. Exception for Windows, which only deserves to burn in Hell.
- GCC compiler. Again I have nothing against others, I'm just using what I have and what I know, and I would happily test other compilers if I had the time and opportunity.
- Standard C. I want to stick to the standard to ease an eventual reuse in a different environment. The probability of such a reuse is infinitely low, but I'm motivated anyway by the challenge of seeing what's possible to do within the limits defined by the standard.
- OOP. I'm not a fanatic, I use what works to get the job done. Object oriented programming is one way, and that's a way I'd particularly like to experiment with in this project, alongside a more traditional use of C. And if you don't believe me when I say that C is a suitable language for OOP, read this. Or maybe you'll believe others, like Axel-Tobias Schreiner.
- Accessible. The code in this library contains bits which are definitely not beginner level. From the eventual end-user perspective I intend anyway to make it accessible to even the one-liners who feel lost after few tens of lines of scripting language.
- Commented. Here I'm a fanatic, I agree. I'm just viscerally convinced that's the correct way to go. Human use natural language. Code is the language of the machine. I write in natural language, as I think, then I translate into code, and the natural language stays as the comments. Tomorrow I'll have forgotten what I've done today. Tomorrow I'll be happy to read detailed explanations in natural language to understand the code I wrote today.
- Documented. The code base at the origin of this library contains around 200 structure declarations and 2000 function definitions. Even if I'm the author of every single line of code in this code base, I can't recall most of it. Above few thousands lines and/or past few weeks after writing them there is no way a human can remind something so complex. No doc means death by oblivion.
- Tested. No code is bug-free, have a look here if you think the opposite. Shipping code without testing it is the best way to maximise their number and their impact. I've taken care to add unit tests and use valgrind in the repos at the origin of this library, and they've been invaluable friends all along. I intend to keep doing it in this project.
- Warnings treated as errors. Even Linus Torvalds thinks so. During development I think it's ok to set aside temporarily a warning message (but surely not to turn it off). I also think it isn't for released code and all warning should then be treated with the same importance as errors.
Download
The library is freely available under the GPL license and you can download it from this page.
Examples
Examples of how you can use it and what you can do with it are available here.