Archive for the ‘cpp’ Category
Thunksgiving
Posted on: 31/10/2010
Quoting Wikipedia:
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++.
Endianness and you
Posted on: 30/09/2010
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-existant.
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.
Overloading macros
Posted on: 31/08/2010
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 last post, as we will briefly demonstrate (the idea has also been mentioned under the comment section in the aforementioned post).
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.
Futures: asynchronous invocation
Posted on: 31/05/2010
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.
Quines
Posted on: 16/04/2010
- In: tricks
- 5 Comments
A Quine is a computer program which prints a copy of its own source code as its only output.
Thus it is theoretically possible to compile such a program, run it, and then have its output compiled again to produce the initial program – in an infinite loop, forever.
- In: mechanisms
- 2 Comments
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.
cplusplus.co.il 
Recent comments