Jacek's Blog
Software Engineering Consultant
Homogenuous data in purely functional programs is typically managed in lists. Items can be appended or prepended to lists, different lists can be concatenated. Lists can be filtered, transformed, mapped, reduced, etc. Having all this nice stuff as a template meta library is quite an enabler for complex compile time meta programs.
C++ template meta programs are at first really hard to read. This is because the template mechanism accidentally became turing complete, although it was invented to enable for type-agnostic programming of generic algorithms. However, now the world knows that the C++ template part of the language is turing complete, people started writing full programs in it, and it enhances the power and flexibility of libraries quite a lot. This article aims to explain some very basic things one needs to know about the C++ template meta programming language, in order to be able to do things with it, or even understand foreign programs.
In both C and C++, it is not a sane idea to hold a reference (or a pointer in C) to a temporarily created object, as the reference is quickly dangling as soon as the assignment is done. But actually, C++ provides an interesting feature, where the life time of a temporary object can be extended to the life time of the reference which points to it.
What does actually happen, if an exception is thrown somewhere in the middle of a C++ program, but there is no try-catch clause which handles it? The program gets terminated. That is fine in general, but what happens to all objects which need to be properly destructed?
In order to use polymorphy, virtual functions are the way to go in C++. They are nice and easy to use. However, polymorphy is not always needed at actual runtime. If it is only used to separate generic from specific functionality in order to have a common interface and avoid code duplication, the cost of having indirection introduced by vtables might not be desired. This article shows how to use the CRTP in order to get the compile time advantages of polymorphy, without using virtual methods.
Some objects have different interfaces for doing the same thing in a different way. One could either check if two objects are equal, or if both are not different. Or one could ask if some container is empty, or if it has zero size. Classes should sometimes provide multiple kinds to express the same thing to let the user decide which way to express something is more readable in a specific context. But that does not mean, that the class developer has to express everything multiple times. This article explains how CRTP can help out and remove potential duplicate code lines.
When using C-style libraries, dealing with resources which need to be constructed and destructed again, the code doing the construction/allocation and destruction/release often ends up being ugly and repetitive, because one can’t easily stick with the RAII principle. Especially when a whole set of resources is allocated, and the case that some allocation inbetween fails, all already allocated resources need to be correctly released again. When wrapping such code in C++, it is possible to tidy such code paths up by using automatic destructor calls.
SFINAE type traits are very mighty, because they can check a lot of properties of types in a non-intrusive way. Unfortunately, they are extremely bloaty to implement. The single interesting expression within an SFINAE type trait is surrounded by lots of boiler plate code, which is ugly to read and repetitive. This article shows a nice one-liner approach to define new SFINAE type traits.
I happen to use the SDL library when i need to display graphics on the screen, but want to do it simpler than with OpenGL.
SDL is easy to use and portable, but it is a C-style library.
Because of that C nature, the library does not really help the user to write elegant, modern code.
Acquiring and Releasing SDL resources often ends up in ugly old school resource management.
It is not hard to fix that, and this article shows how useful shared_ptr from the STL is in such cases.
The approach is easily extendable to other kinds of resources, too.
The __FILE__ macro expands to the current source file name at compile time.
It is not really useful if the source file paths which the build system uses, are very long, as this would bloat log output with long path names.
It would be useful to have a shortened version, which only contains the file name without the whole path.
This article describes how to implement a __SHORT_FILE__ macro, that does not add any run time overhead.