But what if we wanted to keep only the biggest N elements, and just have the queue dynamically throw away all other elements? I am sure you can imagine why such a behavior would be much desired: for instance, keeping the best N suggestions for a specific search term springs to mind. Unfortunately, the STL does not support such an adapter.

I believe the following assignment is a nice introductory interview question. Something to break the ice with, if you will:
Naturally, we’d want any solution to rely as heavily as possible on previously available code; How would you implement a bounded_priority_queue using only the given priority_queue from the STL?

At this point I would like to invite you, the readers, to take a moment and think of a solution for the provided specification. Keep in mind that the priority queue offered by the STL requires a Compare binary-function object (such as less) to be used for comparing the elements held within, and only supports a few relevant operations: push, pop and size.

The suggested solution is as follows:
Keeping a maximum heap of N elements, is exactly the same as holding a minimum heap and popping the minimal elements when the size is about to reach the limit (N) — asking for the maximal N elements is exactly the same as dropping the minimal elements until there are N elements left. We are able to convert a maximum heap to a minimum heap by altering the Compare function object mentioned above. More specifically, all we have to do is swap its two arguments.

I actually bumped into a need for such an implementation in my normal course of work. As Googling for an answer did not provide a solution, I thought posting one could be beneficial to others. Therefore, a nearly complete C++ solution is hereby provided:

#include <queue>
#include <stdexcept>
#include <algorithm>

template <class T,
          class Container = std::vector<T>,
          class Compare = std::less<typename Container::value_type>
         > class bounded_priority_queue {
    public:
        typedef T value_type;
        typedef std::size_t size_type;

        explicit bounded_priority_queue (const size_type& maxsize)
         : maxsize_(maxsize)
        {
            if (maxsize_ < 1)
                throw std::runtime_error("bpqueue maxsize<1");
        }

        void push (const value_type& val) {
            if (queue_.size() >= maxsize_)
                queue_.pop();
            queue_.push(val);
        }

        std::priority_queue<T, Compare, Container> pop_all () {
            std::priority_queue<T, Compare, Container> result;

            bounded_priority_queue tmp(*this);
            while (!tmp.queue_.empty()) {
                result.push(tmp.queue_.top());
                tmp.queue_.pop();
            }

            std::swap(this->queue_, tmp); // specialized ptr swap
            return result; // return value optimization
        }

    private:
        struct reversed_compare : Compare {
            // notice that all four versions are required
            // so that no new restrictions are created:
            // (you might even want mixed const params..)

            bool operator() (const T& l, const T &r) {
                return Compare::operator()(r, l);
            }

            bool operator() (const T& l, const T& r) const {
                return Compare::operator()(r, l);
            }

            bool operator() (T& l, T& r) {
                return Compare::operator()(r, l);
            }

            bool operator() (T& l, T& r) const {
                return Compare::operator()(r, l);
            }
        };

        std::priority_queue<T, Container, reversed_compare> queue_;
        size_type maxsize_; // not const to stay assignable
};

Note that the interface for such a class is tricky – there is no good way of defining the top() functionality, as a maximum heap (with the reversed comparison, mind you) will not let you access the minimal member. It will only give access to the maximal one.
The solution I have suggested here works around this issue by providing only a way for retrieving all elements altogether, through pop_all. I would greatly appreciate any feedback on this matter.

Another interesting property of the pop_all implementation offered here is that it provides a strong exception guarantee – in the case of an exception during the copying of the elements, it will leave the original queue untouched. This is also achieved through the invocation of the swap algorithm, which should have a (no-throw) pointer-swapping specialization for the underlying vector type.
This is a very important characteristic, and it comes with a cost of an extra copy operation.

One more issue worth taking note of is that the provided pop_all implementation supports return value optimization. But that is a topic for another post.

While I am generally pretty happy with what C++ has to offer, adopting some of the features offered by other mechanisms can come in handy sometimes. To be more specific, in this post we will mimic Java’s support for defining a common super-type for generic elements (i.e. List).

The task at hand is the implementation of a priority queue, which is essentially a heap. Sure enough, the priority queue will have a parametric (template) type T, which will have to be Comparable. Something along the lines of:

template <typename T>
struct priority_queue {
    // ...
};

Keep in mind that we will have to do one of two things:

• Either clearly state in the documentation that the implementation of our priority_queue heavily relies on type T having implemented operator<,
• Or add another parametric (template) type F, to serve as a Comparator.

Both things may seem a little far from optimal. Have we gone with Java in the first place, all we would have had to do would have been something closely resembling the following:

class priority_queue<T extends Comparable>

As it turns out, the same effect (although with slightly different syntax) can actually be achieved even in C++, through utilization of two boost utilities: is_base_of and static_assert. A brief sketch is hereby presented:

struct Comparable {
    // required API..
};

template <typename T>
class priority_queue {
    // Ask compiler to enforce that T is a subtype of Comparable:
    BOOST_STATIC_ASSERT(boost::is_base_of<Comparable, T>::value);
};

A colleague of mine walked up to me some time ago and asked why isn’t such a mechanism included in C++’s core features. After putting some more thought into it, I have come to the conclusion that I would actually hate seeing such a built-in C++ feature – In my opinion, it will lead to an excessive number of not-general-enough base classes, which are only there to feed this mechanism. Moreover, it is very likely to lead to much more abuse of the multiple inheritance mechanism.

The C++0x standard draft presented a related feature named Concepts (and Concept-maps), which were recently dropped as well.

What do you think?

That’s what happened to me just the other day; I was using SWIG to wrap a C++ class to Python (by the way, SWIG is just plain awesome), and since exception specification causes wrapping of the exception classes as well, it’s a good idea to use that. So there I was, declaring my constructor to only throw instances of std::runtime_error.. Only to discover that one of my members (implemented elsewhere) could actually throw a const char*.

Luckily, I was familiar with the idea of catching exceptions raised within the initialization list, and that’s exactly what was needed to save the day. The required syntax is hereby presented:

struct myclass {
    myclass () throw(std::runtime_error)
        try
        : m_member("test") {
            // normal constructor code
        }
        catch (const char *err) {
            throw std::runtime_error(err);
        }

    private:
        someotherclass m_member;
};

There are of course some limitations on what you can do within the catch-block, the major one being that you must throw something; You cannot continue normal execution having failed initializing the object — if nothing is thrown when reaching the end of the catch-block, the caught exception is automatically re-thrown.

Extra details and more in-depth discussion of the mechanism can be found at GotW#66.

The word thunk has at least three related meanings in computing science. A “thunk” may be:

1. A piece of code to perform a delayed computation (similar to a closure)
2. A feature of some virtual function table implementations (similar to a wrapper function)
3. 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++.

Let us consider the following multiple inheritance hierarchy:

#include <iostream>

struct A {
    virtual A *clone () const {
        return new A();
    }

    int a;
};

struct B {
    virtual B *clone () const {
        return new B();
    }

    int b;
};

struct C : A, B {
    virtual C *clone () const {
        C *c = new C();
        std::cout << c << std::endl;
        return c;
    }

    int c;
};

int main () {
    B *b = new C();
    B *b_cloned = b->clone();
    std::cout << b_cloned << std::endl;
}

Please, do not let the length of the code snippet intimidate you. The illustrated test case is actually pretty simple; Three classes are defined — A, B, and C. C is derived from the unrelated other classes. All classes share a single virtual function which allows to clone() them, and a single member variable – just so they aren’t empty. The purpose of the two printouts will be made clear soon.

One nuance worth paying attention to is the fact that the clone() function is refined within C::clone() to yield a pointer-to-C instead of pointer-to-A/B. This is called Covariance. I could talk a lot more about Covariance, Contravariance, and C++’s lack of support for Contravariance in function parameters, but these topics will have to wait for a later post.

Let us recap what memory layout do A, B, and C have (on a 32bit machine):

A: [ Avptr | int(a) ] 8bytes
B: [ Bvptr | int(b) ] 8bytes
C: [ Cvptr | int(a) | BCvptr | int(b) | int(c) ] 20bytes


Needless to say that a cast from C* to A* requires no effort at all, while the virtual table pointer (vptr) of class B (notice that it is labeled BCvptr, which is intentionally different from Bvptr) is where it is to allow convenient casts of the form C* to B*. Therefore, it is not surprising to discover that the compiler will actually carry out much needed pointer adjustments in the following case:

C c;
B *b = &c; // b != &c. Actually, b = &c+8.

Now, onwards to the interesting part; What happens when we write line #31 in the original code snippet (invocation of C::clone() which yields a pointer-to-C, from a B context)? And more importantly, what is actually going on under the hood?

The call b->clone() is invoked through the BCvptr. Due to the dynamic type of the object being C, we expect C::clone() to be called. But here’s the catch — a call to C::clone() yields a pointer (to a newly constructed C object) which points to the head of a C object, rather than to a B object! If C::clone() would be called normally, we would have a pointer-to-B which points on the wrong memory area, and that would just make us all unhappy.. So what dark magic is there, within BCvptr, that allows this code to work flawlessly?

Using the magical -fdump-class-hierarchy flag for g++, and the wondrous c++filt utility, we can obtain the actual structure of C’s virtual table:


Vtable for C
C::vtable for C: 6u entries
0 (int (*)(...))0
4 (int (*)(...))(& typeinfo for C)
8 C::clone
12 (int (*)(...))-0x00000000000000008
16 (int (*)(...))(& typeinfo for C)
20 C::covariant return thunk to C::clone() const


I will not go into much detail about the whole structure as it is enough information for one post, but I do believe that what’s important to us is pretty apparent here: at offset 8 there’s the normal invocation of C::clone within a Cvptr, while at offset 20 (which is exactly 12+8) there’s a call to a “covariant return thunk to C::clone”. As you have probably guessed by now, BCvptr is actually a pointer to offset 12 within Cvptr. Therefore, when making the aforementioned b->clone() call — a call is made to the function whose address resides at offset 8 from the current vptr; And since the current vptr is BCvptr, a call to the thunk is made.

Obviously, the compiler essentially implements this thunk as a simple wrapper around C::clone() combined with the required pointer adjustment to yield a proper pointer-to-B. Some of you may find this technique pretty similar to the notion of a Trampoline.

To wrap things up, it should come as no surprise to you, that both printouts produce addresses which differ by 8bytes — which is the exact required adjustment.

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.

Quoting Wikipedia:

Endianness is the ordering of individually addressable sub-units (words, bytes, or even bits) within a longer data word stored in external memory.

To be more specific, usually what concerns us is the byte ordering (since every byte is individually addressable in the common x86/IA32 architecture) within a bigger word, such as a 32bit integer (4bytes). There are essentially two “core” options:

• Little Endian — Little (less significant) byte first.
• Big Endian — Big (most significant) byte first.

Little Endian, in my opinion, is the less intuitive one. It means that if we are to store a 32bit integer of the Hexadecimal value 0×10203040 in memory address a, then the memory footprint would look like this: [40 30 20 10], where a[0]=40 a[1]=30 a[2]=20 a[3]=10.

Most PCs are of the x86 architecture. As such, you are very likely to bump into the Little Endian storage it employs. Here is a simple program illustrating the situation:

#include <iostream>

int main () {
    int integer = 0x10203040;
    char *ptr   = static_cast<char*>(static_cast<void*>(&integer));

    std::cout << "int:   " << std::hex << integer
        << std::endl;
    std::cout << "int[0]:" << std::hex << static_cast<int>(ptr[0])
        << std::endl;

    if (ptr[0] == (integer&0xff))
        std::cout << "little endian detected" << std::endl;
    else
        std::cout << "big endian detected" << std::endl;
}

As expected, on my Intel Pentium M, the output would be:

antrikot:~/work/sandbox> ./endianness-test
int: 10203040
int[0]:40
little endian detected

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).

Suppose we would like to create a macro which is to return the MAX of its arguments. Such feature is supported both by std::max and by the (in)famous MAX macro. The extra requirement we shall make here, other than insisting on a macro solution, is that the implementation should work for any positive number of arguments up to a certain limit, and as long as there’s at least one argument.

In this post we will provide a solution which computes the MAX of up to three arguments, but we will put an emphasis on providing a solution which is easy to scale to work with any number of arguments.

One approach, cleverly raised by a colleague of mine, suggests the following (example supporting up to three arguments):

#define MAX2(a, b) (((a)>(b)) ? (a) : (b))

#define MAX(a, ...) MAX_IMPL(a, __VA_ARGS__, a, a)
#define MAX_IMPL(a, b, c, ...) MAX2(a, MAX2(b, c))

This should clearly work for the MAX macro we are after, but certainly not for every function we would like to implement; For instance, if we were after a macro which can compute the average of its arguments, this approach would clearly not work.

The generic solution for macro overloading, and specifically for our case, is by employing the VA_NUM_ARGS construct with the following set of macros:

#define macro_dispatcher(func, ...) \
            macro_dispatcher_(func, VA_NUM_ARGS(__VA_ARGS__))
#define macro_dispatcher_(func, nargs) \
            macro_dispatcher__(func, nargs)
#define macro_dispatcher__(func, nargs) \
            func ## nargs

The macro_dispatcher mechanism actually implements, like its name suggests, a kind of a dispatch mechanism (which operates through calculating the number of arguments being passed to the macro) that is actually able to simulate an overloading mechanism. Thus, enabling the following implementation for our desired max macro:

#define max(...) macro_dispatcher(max, __VA_ARGS__)(__VA_ARGS__)

#define max1(a) a
#define max2(a, b) ((a)>(b)?(a):(b))
#define max3(a, b, c) max2(max2(a, b), c)
// ...

// to verify, run the preprocessor alone (g++ -E):
max(1, 2, 3);

In this scenario, the macro_dispatcher mechanism transforms the max(1, 2, 3) call to max3(1, 2, 3) invocation, which yields the desired result.

Needless to say, that the proposed technique can be utilized easily just about anywhere where macro overloading would be useful.

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.

Let us first present the solution (which has also been proposed before), and then we shall move on to discuss how it works and its limitations;

#define VA_NUM_ARGS(...) VA_NUM_ARGS_IMPL(__VA_ARGS__, 5,4,3,2,1)
#define VA_NUM_ARGS_IMPL(_1,_2,_3,_4,_5,N,...) N

// to verify, run the preprocessor alone (g++ -E):
VA_NUM_ARGS(x,y,z)

As with every Variadic macro, __VA_ARGS__ is replaced with the passed arguments, therefore making a little “shift” in the arguments following it. Thus, when we check the arguments being passed to VA_NUM_ARGS_IMPL, the aforementioned “shift” causes the sixth argument to hold the right – initial – number of arguments.

The given implementation imposes a couple of limitations:

• It will not work correctly for zero arguments. Some suggestions for an implementation capable of supporting this feature can be found in the comments section below.
• It supports only a limited number of arguments (up to 5, to be precise). The macro can be extended to support a maximal number of up to 63 arguments (in a way that is pretty obvious), which seems to push the upper bound for number of preprocessor macro arguments any way.

Can you propose a case where this would be useful? I am planning to share a number of ideas in future posts.

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.

As you could guess, our future object will create its own thread of execution in order to carry out the needed asynchronous computation. We shall exploit boost::thread for this task. A straightforward implementation is hereby presented:

#ifndef _FUTURE_HPP_
#define _FUTURE_HPP_

#include <boost/utility.hpp>
#include <boost/thread.hpp>
#include <tr1/functional>

namespace std { using namespace std::tr1; }

template <typename T>
class future : boost::noncopyable {
    public:
        future (const std::function<T ()> &func);
        operator T& ();
        bool ready () const;

    private:
        void compute ();

        volatile bool ready_, joined_;
        std::function<T ()> func_;
        boost::mutex mutex_;
        T result_;

        boost::thread thread_;
};

template <typename T>
future<T>::future (const std::function<T ()> &func)
 : ready_(false), joined_(false), func_(func),
   thread_(boost::bind(&future::compute, this))
{ }

template <typename T>
future<T>::operator T& () {
    if (!joined_) {
        // locking to prevent race conditions on join() which causes
        // undefined behavior if called more than once.
        // using double checked locking with all of its downsides.
        boost::mutex::scoped_lock lock(mutex_);
        if (!joined_) {
            thread_.join();
            joined_ = true;
        }
    }
    return result_;
}

template <typename T>
bool future<T>::ready () const {
    return ready_;
}

template <typename T>
void future<T>::compute () {
    result_ = func_();
    ready_ = true;
}

#endif // _FUTURE_HPP_

Few points worth taking note of in this implementation are these:

• We have to use a mutex to prevent a race condition on the join() operation, which may cause undefined behavior if called more than once and is not thread safe.
• Double checked locking is problematic in many cases (I strongly suggest reading this article about “C++ and the Perils of Double-Checked Locking” by Alexandrescu and Meyers) but should be fine here.
• The use of std::tr1::function and boost::bind (also in tr1) greatly simplify the implementation and its interface.

It is also important to mention that the folks at boost provide a similar functionality as part of boost::thread, but the interface seems a little uncomfortable. At least to me.

Now, a utilization example is in order. How would you feel about Fibonacci numbers making another appearance?

#include <iostream>
#include <tr1/tuple>
#include <boost/bind.hpp>

#include "future.hpp"

namespace std { using namespace std::tr1; }

unsigned nth_fib (unsigned n, unsigned modulo) {
    unsigned prev=1, curr=1;
    for (unsigned c=2;c<n;++c)
        std::tie(prev, curr) =
            std::make_tuple(curr, (prev+curr) % modulo);
    return curr;
}

int main () {
    future<unsigned> fib1(boost::bind(nth_fib, 1000000, 4567)),
                     fib2(boost::bind(nth_fib, 3000000, 1234));

    while (!fib1.ready() || !fib2.ready()) {
        std::cout << "working.." << std::endl;
        boost::this_thread::sleep(boost::posix_time::seconds(1));
    }

    std::cout << "fib1: " << fib1 << " fib2: " << fib2 << std::endl;
}

Just a reminder: using Tuples is pretty efficient.

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.

Consider the following main function:

#include <stdexcept>

int main () {
    throw std::runtime_error("error!");
}

Now, let us create our own terminate handler, which we will call ‘our_terminate’. We will use a trick to configure it even before the main function gets to run, by invoking set_handler as part of a global constant initialization (be aware of the random initialization order of global objects):

#include <exception>

void our_terminate (void); // decleration

namespace {
    static const bool SET_TERMINATE =
        std::set_terminate(our_terminate);
}

At this point, we are left with the challenge of writing the actual terminate handler we’re after. As far as I know there is no portable solution. The solution we will present here works for GCC (verified on versions 3.* and 4.*). It does not seem to work on Microsoft’s Visual Studio (2008), so a different approach should be taken there. It is always possible to check where the compiler places the currently active exception, and just take it from there (thus providing a compiler specific workaround for every compiler). Feel free to comment on the matter.

Normally, an empty throw directive (‘throw;’) outside of a catch clause (‘throw;’ within a catch clause means a re-throw of the caught exception) would lead to the invocation of the terminate handler. The interesting thing however, is that under GCC, using such an empty throw statement within our custom terminate handler will cause a re-throw of the currently active exception (if there is one), making the following code behave as desired:

#include <iostream>

void our_terminate (void) { // try 1
    try { throw; }
    catch (const std::runtime_error &err) {
        std::cout << "caught a runtime_error. what(): " <<
            err.what() << std::endl;
    }
    catch (...) {
        std::cout << "unknown exception occurred." <<
            std::endl;
    }
}

That actually works, for the reasons specified above. But this solution is far from being complete; What if an empty throw directive led to the invocation of our custom terminate handler?

int main () {
    throw;
}

There is no active exception, so the empty throw statement is actually executed in an endless loop (by repeatedly re-invoking the terminate handler, until the stack is exhausted).

So we would like to invoke ‘throw;’ only once. A possible solution is this:

void our_terminate (void) { // try 2
    static bool tried_throw = false;

    try {
        if (!tried_throw++) throw;
        std::cout << "no active exception" << std::endl;
    }
    catch (const std::runtime_error &err) {
        std::cout << "caught a runtime_error. what(): " <<
            err.what() << std::endl;
    }
    catch (...) {
        std::cout << "unknown exception occurred." <<
            std::endl;
    }
}

The empty throw will not be attempted the second time around, making this solution work as expected – even for the case where there is no pending exception.

In case the terminate handler is likely to be invoked more than once in your own environment, I would recommend resetting the ‘tried_throw’ flag back to false after printing the proper message.

Here are a couple of examples: What if you wanted to take the address of an object, which had implemented an entirely different semantic for the ampersand (&) operator? Or what if somebody decided to overload the comma operator in some strange manner?

As you could have guessed, there are solutions for such scenarios.

The comma operator (operator,)

Suppose there’s some sequence object, which you would want to advance and then print:

#include <iostream>

template <typename T>
void print_seq (const T &seq) {
    seq.reset();
    for (unsigned i=0;i<seq.size();seq.advance(), ++i)
        std::cout << i << " " << seq.curr() << std::endl;
}

Everything looks peachy until now, right? Well, not exactly;

struct sequence {
        sequence &reset   ()       { return *this; }
        sequence &advance ()       { return *this; }
        size_t    size    () const { return 0;     }
        unsigned  curr    () const { return 0;     }
    private:
        void operator, (unsigned)  {  /* none. */  }
};

int main () {
    // this will complain about comma operator being private!
    sequence seq;
    print_seq(seq);
}

What we’ve witnessed just now is that writing generic functions (or libraries), like our templated ‘print_seq’ function, can be a little tricky when the unexpected strikes. Luckily, there’s a solution: we are able to invoke the ‘void()’ token to keep user-defined overloaded comma operators from running. Here’s how we should re-write the function:

template <typename T>
void print_seq (T &seq) {
    seq.reset();
    for (unsigned i=0;i<seq.size();seq.advance(), void(), ++i)
        std::cout << i << " " << seq.curr() << std::endl;
}

Using ‘void()’ we make sure that only the default comma operator gets to execute, instead of any user defined ones (in case there are any).

Now we shall discuss another operator which can be overloaded in many unexpected ways;

The ampersand operator (operator&), also known as ‘address of’

Assume the task at hand is to write a generic improvement of an equality test, such that it would first check if both operands are the same object (by comparing their addresses) and only then invoke operator== for the actual comparison:

template <typename T>
bool equal (const T &lh, const T &rh) {
    return &lh == &rh || lh == rh;
}

C++’s short-circuit evaluation mechanism guarantees that if the first comparison is successful, the second one (which is usually more expensive) will not be invoked.

Being familiar with the first example in this post, your spider senses must be going off at this point. You should be asking yourself: “What if T has an overloaded user-defined version of operator&?”. Indeed, let me illustrate such a case:

template <typename T>
struct vector_element {
    unsigned operator& () const { return idx_; }
    // .. rest of implementation ..
};

The ‘vector_element’ class represents an element of a vector. As such, its operator& simply returns its index in the vector. So if we have two such vectors, and we attempt to compare two of their elements using the proposed ‘equal’ function, the result is going to be wrong. For example:

std::vector<vector_element<unsigned> > v1, v2;
// ...
if (equal(v1[5], v2[5]))
    std::cout << "Always true, regardless of value." << std::endl;

So how could we avoid this situation, you ask?

Well, the folks at boost have implemented a boost::addressof() utility function, which I strongly suggest you use in case of need. For the sake of completeness, here’s how we would implement such a functionality ourselves:

template <class T>
inline T* addressof (T &val) {
    return reinterpret_cast<T*>(
        &const_cast<char&>(reinterpret_cast<const char&>(val)));
}

A couple of key points are worth noting here:

• The const cast is useful since it saves us from the need of providing another overload for the const T& case.
• This implementation is well defined and portable since we’re reinterpret-casting from T to A, and then vice versa. (A being a char type here, but we could have used a local class, or something else, just as easily).

The boost implementation has some extra minor tweaks, but is essentially the same.

With this implementation, we would be able to provide a correct version of the ‘equal’ functionality we were so eager to achieve:

template <typename T>
bool equal (const T &lh, const T &rh) {
    return addressof(lh) == addressof(rh) || lh == rh;
}

I hope that this post illustrates just how careful we must be when implementing very generic solutions, and that it is quite possible to overcome just about any obstacle – as long as we can foresee it.