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 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.
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; ??>
Iterating over a vector is a pretty simple task we get to do pretty often. It can be achieved in quite a few ways:
- Using normal random access (operator with index).
- Using std::iterator.
- Using std::for_each algorithm.
I set out to check the runtime differences between all these options, and the results turned out to be a little surprising (or not).