Olivier Langlois's blog

I have writen a new tutorial that presents an example on how to incorporate CFixeAlloc optimization into existing MFC software.

You can read it here and leave comments on it here.

I just published the second part of the serie on C programs refactoring in C++. Here is the introduction of this tutorial:

In the first part of the serie, I presented guidelines that needs to be followed when someone wish to use C++ from C programs. In an ideal world, the old C programs that you want to port to C++ should be rewritten completely. However in the real world, due to economical constraints, this is usually impossible and a more gradual approach must be adopted. During the transition period, to maximize the benefits of using C++ and to not end up with having a program consisting of just a bunch of C interfaces with C++ implementations, you can identify some patterns in the C program and refactor them appropriately. By having gone through the exercise myself, I am presenting the techniques that I have discovered and I will be discussing the benefits and the potential pitfalls of these refactoring patterns.

You can read the rest here.

I have written a new tutorial available on my website. Here is a small quote from the introduction that describes what it is about:

In this tutorial, I will introduce the simple guidelines and pitfalls to avoid when using C++ in C programs. The second part will continue by presenting higher level patterns to leverage the good software architecture patterns that C++ language facilities encourage into C programs.

You can read the rest here.

This is an acronym that means "substitution-failure-is-not-an-error" and it is used in the context of template functions overloading. When the compiler evaluates each overloaded template functions, it will not emit an error if by using the template parameter on one of the potential candidate function would generate an error. The compiler will just discard that function from the list of potential candidates. It is a powerful construction that allows metaprogramming as you can evaluate expressions at compile-time. Here is an example from the book C++ templates:

template<typename T>
class IsClassT {
  private:
    typedef char One;
    typedef struct { char a[2]; } Two;
    template<typename C> static One test(int C::*);
    // Will be chosen if T is anything except a class.
    template<typename C> static Two test(...);
  public:
    enum { Yes = sizeof(IsClassT<T>::template test<T>(0)) == 1 };
    enum { No = !Yes };
};

If T is a class, IsClassT<T>::Yes will be true because the first test() function will be chosen by the compiler. From the C++ templates book:

overload resolution prefers the conversion from zero to a null pointer constant over binding an argument to an ellipsis parameter (ellipsis parameters are the weakest kind of binding from an overload resolution perspective).

There is one subtle detail that is important enough to mention it. It is the usage of the template keyword at the Yes enumeration declaration. The reason behind the need for using the keyword is similar to why you sometime need to use the keyword typename.

It is because of template specialization, the compiler has no clue what the dependent name "test" is. Without explicit indication with the keyword template, it is interpreting "<" and ">" as "greater than" and "lower than" logical operators.

Maybe you were already using the principle without knowing its name but now next time you see SFINAE in a C++ forum, you will know what they are talking about.

This one has annoyed me for a while until I found the answer as pre STL stack classes used to have a pop() function that was popping the element and returning it to the user. I was finding it conveniant because everytime I wanted to access the top element, I also wanted to pop out the element of the stack so why STL containers is forcing its users to perform this common operation with 2 operations?

In 'The C++ Programming Language' book, Bjarne Stroustrup has this to say about pop_back:

Note that pop_back() does not return a value. It just pops, and if we want to know what was on the top of the stack before pop, we must look. This happens not to be my favorite style of stack, but it's arguably more efficient and it's the standard.

I wish that he took the time to explain his position about why it is more efficient for pop_back() to not return the element but I only understand why it was done like that by reading the book Exceptionnal C++ from Herb Sutter.

If you are using a STL container to store pointers, the performance argument disapear but if you store objects, all front() is returning is a reference to the top element and if pop_front() would return the top element, it would be by value and the copy constructor and the assignement operator would be involved. This is the performance argument that by having to call these 2 functions, it is adding overhead.

However, I suspect that this is not the main reason to have separated the 2 operations. Probably that the main reason is for exception safety garantee that the STL containers provide. Since, one requirement that STL impose on its users that contained objects destructors cannot throw exceptions, pop_front() can provide a no throw garantee. It could not if it had to return the top element because if the copy constructor or the assignment operator was throwing an exception, the element would be lost forever. In contrast, when an exception is thrown while assigning front() result, if you can cope with the exception, the element is not lost because it is still in the container.