How and why I built my C++ library
About me
I'm a computer science graduate with a lot of experience writing C and C++. As I was pursuing my degree in computer science I was employed as a working student at EMH metering GmbH & Co. KG where I wrote a lot of C++ software to interface with our digital electricity meters.
The problem I wanted to solve
During my time as a working student I was mostly stuck using C++14, but wanted to be able to use many of the C++17 standard library features with older compilers. Additionally, I found myself reimplementing similar code in multiple projects.
What is My own C++ library?
I built my own C++ library, called "philslib" (available at https://github.com/CppPhil/philslib).
Originally, the library started out as a collection of backports of C++17 standard library facilities to C++14. Over time the library grew and I added backports of C++20 standard library facilities and other functionality I previously found myself reimplementing multiple times. Besides standard library backports the library contains some interesting components, including a class template for the monitor concept, allowing thread safe access to an object, a class template for concurrent objects with the same interface which is similar to the active object pattern from other languages and unlike the monitor doesn't block. The library also features then-continuations similar to those from the ISO C++ concurrency TS, enabling continuations of std::futures (Javascript developers will be familiar with this concept). Additionally, a thread pool and a thread safe queue are also available. The library contains a "cheshire cat" class template which is a variant of the Pimpl (pointer to implementation) pattern, which unlike the Pimpl pattern doesn't require dynamic memory allocation. I've also written my own string_view which unlike the C++ standard library one is designed to work with null-terminated strings.
Tech stack
I've used C++ to implement my library. The code is C++14 compatible and only requires at least g++ 5.4.1 on GNU/Linux. The build system is CMake which allows building the unit tests and consuming the library as a client also using CMake. The library is a header only library, so using CMake as a client is not required.
The process of building My own C++ library
I got the idea of building my own C++ library back in 2016. I continuously added new features over the years as I followed the developments of the ISO C++ standardization committee and the developments of their technical specifications for C++. I also kept adding utilities that I found myself rewriting multiple times in different projects during my time as a working student.
Challenges I faced
As this was my first serious use of CMake I found myself quite confused with the amount of (mostly outdated) information on CMake. I had originally intended the library to be compiled and linked into a static library (or a dynamic / shared library if the user so chooses), but migrated to a header only library to make consuming it easier. Built times will suffer from a header only approach, but this way a user can integrate the library into their project no matter what environment they use, without building or linking the library first. Most of the code is generic template code regardless, so the majority of the library would always end up being header only.
Key learnings
I learnt a lot about CMake and modern CMake in particular. I wish I would've read a good book on CMake back when I got started. I've since become a lot for familiar with CMake.
I've also learned about some advanced C++ memory handling features such as placement new, aligned_storage, and C++17's std::launder.
Tips and advice
My advice is to get started and just do it. Learn about your tools and how to use them effectively. Use test-driven development from the very beginning and keep refactoring and fixing bugs throughout.
Final thoughts and next steps
In conclusion writing my C++ library was a good learning experience. I will continue maintaining the library but am open for new projects.
