Welcome to the third and concluding part of the series about dependency and package management in C++ projects in which I’m gonna mostly focus on solutions built into build systems themselves. If you haven’t already, I encourage you to have a quick read of the first and the second part.
In this part I’ll have a closer look on meson wraps, cmake’s FetchContent, bazel’s central registry and, a bit unconventionally, conda.
Recently, I’ve learned about constexpr virtual functions. The support for
which was added along with C++20. C++23 additionally allows for constexpr new (with some restrictions). There’s a great article about constexpr virtual on C++ stories blog, followed by another great post about constexpr new. I highly recommend reading Bartek’s posts.
Wanting to add this new feature to my tool belt I was wondering what would be
the best application for constexpr virtual and how would I use them in my code.
Introduction of concepts in c++20 brought along a new set of problems requiring
solving related to wrapper types (like e.g. std::optional, std::variant).
Specifically, special functions (like constructors, copy constructors, destructors etc) need to have the same type of traits as the type they are wrapping i.e. these have to be copyable if the underlying type is copyable, trivially copyable if the underlying types are trivially copyable, and trivially destructible if the underlying types are trivially destructible.
Sure, = default is great and convenient especially for destructors and other
special member functions but when declaring a class that’s meant to be a part
of a shared library’s interface I try to avoid using it and here’s my reasons
why.
= default or include inline definitions in class’s header file to avoid
vtable/symbols duplication across compilation targets that use the header.Let’s start with a simple abstract class declared in a header file (calc.hpp):
Welcome to the second part of the series about dependency and package management in C++ projects. This time I’m gonna focus on somewhat less popular solutions than the main three.
Let’s evaluate if any of these are worth the hassle.
Hunter caters towards CMake. The
way it works is really similar to meson’s wraps (with the only difference that
it’s not built into CMake). Usage is fairly simple. You have to export
HUNTER_ROOT to a location of choice. Hunter will use it to store its build
directories and obtained source code. There’s nothing that has to be installed.
It’s kind of “self bootstrapping”. You have to download HunterGate within your CMake project:
This post is a quick reminder to self regarding specifics of RPATH,
RUNPATH, LD_LIBRARY_PATH, LD_RUN_PATH and the lookup order.
RPATH, RUNPATH - are entries in the ELF header, baked into the binary allowing
the dynamic loader to lookup its shared dependencies.
RPATH/RUNPATH can be specified directly, using a linker option (-rpath):
g++ -Wl,-rpath=path/for/rpath
If missing in the command line, RPATH can be set using LD_RUN_PATH variable.
In this post I’m gonna do a short overview of package management and vendoring solutions for C++. This is a controversial topic. Still, there’s no official standardised package manager however, there’s a plethora of solutions (some more mature than others) which I think solve the problem well (at least as far as I’m concerned). I planned to publish the entire overview in a single post however, there’s a lot of material to cover and eventually I had to split it up into multiple parts.