Polymorphism in C++
C++ implements subtyping polymorphism in the form of
virtual functions, member functions that should be overridden on derived classes, in a way each class implements its own behavior for the function:
virtual void f() = 0;
virtual ~Interface() = default;
struct A : public Interface
void f() overrides
std::cout << "A!" << std::endl;
struct B : public Interface
void f() overrides
std::cout << "B!" << std::endl;
A couple of days ago I was studying at my university library when my colleague Miguel Madrid got up and started to traverse the library looking for programming books. It’s a game we usually play, to find out a good quality book in a place full of Java 2 SE manuals…
There are some gems on that library though. There’s a couple of copies of Alexandrescu’s “Modern C++ Design” (No longer that Modern, right?) and “C++ Template Metaprogramming”, the latter only borrowed by me in the last five years according to the registry. I always try to have a copy of both, it’s easy since there are only a few people doing C++ there, never reaching the “TMP mental asylum” I’m usually in.
But that day, Miguel reached me with a copy of “The Pragmatic Programmer”. “One of the most influential books in the history of software engineering” the cover says. I’m so scared of how software engineering examples look like…
As a C++ developer I love the Boost libraries. They are one of the highest quality and best suited C++ libraries in the world, with the spirit and design of being fully compatible with the standard library and its practices.
However, Boost is not easy to love. It’s shipped with tons of inter-dependencies, even circular dependencies, and that’s only for header-only libraries (thankfully 80% of Boost is header-only). For non header-only libs, it’s a true pain. You should compile those and then link against, being careful about what you are doing.
Even if setting up Boost manually could be a bit hard, when it works it’s a pleasure to develop with it.
At biicode we have been working hard to simplify the process, to make Boost available for any C++ programmer with just an include. But this is only the start, the project has been released as open source to allow everyone contribute and help.
I hope you like it.
A Tiny Metaprogramming Library episode 3:
Last time we introduced the mathematical concept of function as an entity that takes an input, generating an output. In that process, the function does not change any external state.
We also talked about metafunctions, a way to represent functions operating on C++ types using C++ templates.
After the theory, we followed with some conventions about the specific implementation of metafunctions in our tiny metaprogramming library. We decided that:
- Any type with a
type public member type is considered a metafunction, where
type represents the result of that metafunction.That means to take the result of a metafunction we should say
typename F::type in most of the situations. We introduced a simple tool
tml::eval to help a bit.
- Our metafunctions are templates, but these are constrained to take type parameters only.
In this post we will learn how to use boxing to pass value parameters as type parameters for our metafunctions. This is not something new but a way to understand what
std::integral_constant, one of the fundamentals of
<type_traits>, is and what can be used for.
I know I’m repeating this everytime I write a new article, but it’s one of the key points to make template metaprogramming feasible, which means: TMP is just a functional language. A language with a “Aghhhh, my eyes, please!!! Aaahhhhhg!!!” syntax, but still a functional language.
To start a C++ metaprogramming library the right way, we’d better have a clear idea of what a metafunction is, and how our library represents and manages a metafunction.
It seems people like template metaprogramming. After three successful blog posts about tmp – with 5k views on average each one – I’m sure people like and even want to understand that obscure corner of C++.
It’s not a funny way to play with the compiler only, template metaprogramming is a powerful tool for C++ developers and something that many of us must deal with everyday.
The problem: C and C++ compilation times
Biicode is a file-based dependencies manager for C and C++, focused on sharing and reusing source code, specifically, source (and header) files.
Biicode uses the CMake building system to configure and build blocks, its unit of source code sharing. The default way to develop blocks is to include the required sources and any required extra configuration for building such files on a
CMakeLists.txt file at the root of the block. Also biicode provides other files for specific config such as
So writting our own biicode block is a process with three simple steps:
- Get the sources and copy them on the block directory.
- Configure the
CMakeLists.txt file of the block for the specific build instructions for that sources.
- Upload the block to the biicode cloud via
bii publish command.
So far so good. This approach works pretty well and the biicode community is growing everyday thanks to it. Whats exactly the problem with this approach? Its simple: Some C and C++ sources are hard to compile and it takes time. A lot of time.
Today is the day! We host the C/C++ Madrid meetup
It’s finally here and full of interesting content. The C and C++ community gathers together to talk about metaprogramming.
On the shoulders of giants