Writing fairly straightforward C++ code, we usually make heavy use of the RAII concept. Therefore, we greatly rely on the simple (and basic) assumption that all appropriate destructors will be called. What happens if that is not the case?
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++.
The handler std::terminate() is called whenever the exception handling mechanism cannot find a suitable catch clause for a thrown exception (and in some other cases. For example, when an exception is thrown during the handling of another exception – see this GotW post about std::uncaught_exception). It is possible to define a custom handler by using std::set_terminate.
In this post we would like to create a terminate handler which will be able to catch the exception that led to its invocation, when there is one.
One of the containers introduced within TR1 (which is already widely available – both in gcc and Visual Studio) is a Tuple type, which is adopted from The Boost Tuple Library. Tuple types are very convenient at times; For example, it is possible to return multiple values from a function through a tuple, or write more intuitive and expressive code by utilizing tuples.
In this post we will examine the functionality offered by the new Tuple container, and have a go at profiling its performance. Actually, the results of said profiling were a small (pleasant) surprise to me.
If you ever try to define a public custom new-operator while keeping the corresponding delete-operator private, you’ll end up unable to compile any code that actually invokes the public operator new. The reasoning is quite interesting.
The RAII design pattern can be utilized to create simple and intuitive logging facilities, like the one we will present now. Through the useful macro LOG_FUNC, the proposed ScopeLogger will easily create function call graphs at run time, to allow easy debugging and tracking of program execution.
In this post I will introduce a common problem you are likely to bump into when inheriting from templated base classes.
C++ provides a mechanism that allows any function to declare exactly which exception types it may throw, and these declarations are actually enforced in runtime. We will review exactly how this mechanism works, and why it is usually left unused.
How would you like the next piece of code?
??=include <iostream> ??=define A "hey" int main () ??< char x??(??) = A; if (0 ??' 1) std::cout << x << std::endl; // what do you say about this code??/ std::cout << "amusing" << std::endl; ??>