Olivier Langlois's blog

I have read this book because it was recommended by Scott Meyer in his book More Effective C++: 35 New Ways to Improve Your Programs and Designs and he was saying that this book was showing what C++ looked like on LSD. This book certainly contains interesting ideas and it demonstrate that the author has an exceptional creativity as a C++ user but Mr. Coplien best quality is not teaching in my opinion. To me, the text is opaque and hard to understand when the author is using terms such as "orthodox canonical form".

I did not like this book because I found it hard to read. Some books are hard to read but worth reading because they teach you something. This one is hard to read and I could not make any sense with the book content. You should definitly avoid this book except if you want to find a cure for insomnia.

First prior to reading this book, I was finding the title unattractive. I did not know what statecharts were and what Quantum programming was. By reading this book, I have learn that statecharts were special finite state machines that could be built by deriving them from more general FSM similar to how OO classes inheritance works.

Quantum is the name of the presented framework in the book. The title is misleading because I though that Quantum programming was some weird new programming technique that I was not aware and did not care to learn. I think that it is important to find catchy names to market software but one negative point of the book, is that the author spend way too much pages to describe similarities between quantum physics and his framework to justify the name 'Quantum' for his framework. Programmers are not all quantum physics enthusiasts!

Concerning the book content, the author presents the C++ classes implementing the statecharts framework and a set of classes to make threads driven by statecharts collaborate together by communicating with message queues. It is an interesting reading and there are many places where you can learn good programming tricks by seeing the author code. However, I am not sure that I would want to use the framework because it is complex. Let me clarify what I mean. It is not the framework that is complex but implementing statecharts is complex. I believe that the author made his code as simple as possible to implement statecharts. Personally, I still have to work on a problem where a simple FSM will not be enough.

The best feature of the book is its presentation of a base class to implement FSMs and compares it with traditional table based FSMs and a OO FSM like the one presented in the Design Pattern book and it is highly convincing that his FSM implementation is superior to the other 2 in size, performance and ease of maintenance. Another interesting topic is the author method to emulate C++ in C. You cannot beat the real thing with an emulation but when you have to go write C and you are used to do OO programming, this method might become handy.

I would say that for the FSM pattern and the C++ in C methodology alone, even if it represents a small proportion of pages in the book, it justifies the purchase of this book.

In my opinion, one of the most twisted part of the C++ standard (I am sure that there is more than just one twisted aspect) it is the friend function declaration in a class when you add templates to the mix. Even compiler implementers are having a hard time to get it right. I had the following code that used to compile fine in VC++6:

template< typename T >
class X
{
    friend ostream &operator<<( ostream &, const X<T> & );
};

template< typename T >
ostream &operator( ostream &os, const X<T> &t )
{
    // Print out t
    return os;
}

but now with VC++2003, I received this error message:

unresolved external symbol ostream &operator<<( ostream &, const X<T> & )

That code snippet is non conforming to the standard and in order to make the compiler happy, I had to write:

template< typename T >
class X
{
    /*
     * The '<>' is needed to say that the friend is a
     * function template.
     */
    friend ostream &operator<< <>( ostream &,
                                   const X<T> & );
};

and for those who wonder, no I did not find the solution by myself. I had to look into my book C++ Templates. From section 8.4.1 (Friend Functions):

"An instance of a function template can be made a friend by making sure the name of the friend function is followed by angle brackets...If the name is not followed by angle brackets, there are two possibilities:

1. If the name isn't qualified (in other words, it doesn't contain a double colon), it never refers to a template instance...
2. If the name is qualified (it contains ::), the name refer to a previously declared function or function template. A matching function is preferred over a matching function template..."

So my example fits case #1 description so because of a bug into VC++6 (or maybe the standard was even not complete at the time of its release...), the compiler was erroneously accepting the friend statement as referring to a function template.

So this is the whole story. What I find sad is that the rule is not intuitive at all. There is no way I can reason it next time I am in the same situation. I will either remember the rule or I will have to check back in my C++ Template book. Herb Sutter has also written an item on that topic in his book C++ exceptional Style if you are interested in a different point of view on the topic but he pretty much comes to the conclusion that this is a tricky C++ standard aspect and that a lot of compilers have troubles accepting such statements.

The title is maybe misleading. It is not really a guide that will show you a procedure step by step 'how to do' to build secure systems as most engineering books do. It is rather a survey of the different security protocols used in various fields. Of course, you can learn from the success and errors described in the book and use this knowledge for developing a new system but you will have to connect the dots yourself.

The book is very dense in information and at first, its format was making it tedious for me to read. It did take around 3 chapters before I get accustomed to the format. Once, this aspect was out of the way, this book became amazingly interesting. It describes systems used in banking, by diplomats, military, for nuclear weapons, police, set-up box TV decoders smart cards and anti tampering devices in general, spies, biometric authentication, etc.. and focus on the security protocols used by these systems and then highlights the weaknesses of the systems and how people have figured out how to workaround these protocols.

The best quality of the book is that it will help you to better understand the mindset of a secure system designer and a system hacker.