The word thunk has at least three related meanings in computing science. A “thunk” may be:
- A piece of code to perform a delayed computation (similar to a closure)
- A feature of some virtual function table implementations (similar to a wrapper function)
- A mapping of machine data from one system-specific form to another, usually for compatibility reasons
In all three senses, the word refers to a piece of low-level code, usually machine-generated, that implements some detail of a particular software system.
In this post (whose name looks like an unrelated typo) we shall observe the need for a thunk of the second kind, in C++.
Continue reading Thunksgiving
Programming is all about generalizations. We, as programmers, usually do not want to worry about all the small details; We will usually assume that there’s enough physical memory on the machine, we will knowingly use cross-platform libraries to make the operating system we’re running on irrelevant as well, and sometimes we will even resort to using programming languages that take these ideas to the extreme – like i.e. Java, which runs entirely on a virtual machine — making all above issues non-existent.
But there comes a time, especially in low-level programming languages (like C++ luckily is), when we simply cannot ignore certain low level details. One such example is the expected, architecture specific, Endianness.
Continue reading Endianness and you
The feature of function overloading can prove to be pretty useful: it allows us to define a few versions of the same function, which differ in argument types, or even in Arity (ignoring variadic functions for the moment). Unfortunately, the C\C++ pre-processor does not allow overloading macros in the same way; It treats such attempts as redefinitions.
While we do not really need to overload a macro in order to handle different argument types (since macros ignore type information), many times it would be desired to overload a macro such that each version is able to handle a different number of arguments. This goal can actually be achieved through invocation of the VA_NUM_ARGS macro mentioned in my previous post, as we will briefly demonstrate (the idea has also been mentioned under the comment section in the aforementioned post).
Continue reading Overloading macros
The C-Preprocessor is a very powerful mechanism, which offers many different features. One of these features is called Variadic macros: macros that accept a varying number of arguments. It is interesting to note at this point, that such Variadic macros, despite being part of the C99 Standard, are not part of the C++ Standard at the moment. However, a big number of C++ compilers support it nevertheless.
While allowing the definition of Variadic macros, there is no built-in (preprocessor) way of obtaining the actual number of arguments that is passed to a specific Variadic macro. In this post we shall provide a possible macro implementation for such a query.
Continue reading Variadic macro to count number of arguments
In the concurrent world, a Future object refers to an object whose actual value is to be computed in the future. You can think of it as a handle to an asynchronous invocation of a computation that yields a value.
Many so called concurrent programming languages support this idea as a native construct offered by the core language itself. Unfortunately, C++ does not. Well, at least not in the current standard; C++0x (or shall I say C++1x ?) is going to support std::future as part of the massive new C++0x thread library, which is based on boost::thread. In this post we will implement a simple, yet very powerful, such future object.
Continue reading Futures: asynchronous invocation