Olivier Langlois's blog

Mr. Sutter's books biggest strength to my opinion is that they bring together a bunch of original advanced C++ topics that you cannot find anywhere else. This book has its share of very original content but I feel like the ratio original content vs topics that you can find in other books is lower in this book than with the other books of the serie. The most interesting section in this book in my opinion is the one on exception safety and the less original section is the one on generic programming and STL as you can find much of the information contained in this section in other books such as Effective STL from Scott Meyer or C++ Template from David Vandervoorde and Nicolai M. Josuttis.

In item 24 of the book Effective STL, Scott Meyers explains to be careful about using the overloaded subscript operator (std::map::operator[]) when efficiency is important. The reason behind this advice being that when that operator is used to refer to an item that is not yet in the container, it will insert a new pair in the map by using the default constructor of the value part and then usually an assignation will be performed on the value reference returned by the operator. For non-trivial constructors and assignment operators, this can result to unnecessary overhead.

He then proceeds to present a function called efficientAddOrUpdate() that calls std::map::lower_bound() then performs some tests on the returned iterator to make sure that it is not equal to end() iterator and if the key pointed by the iterator is equivalent to the key used with lower_bound(). If the test is successful, then the value pointed by the iterator is updated or else std::map::insert() is called with the std::map::lower_bound() returned iterator as hint for the insertion point.

Few days ago, I had to recreate the efficientAddOrUpdate() function without my copy of Efficient STL book available and I have being struggling for a good half an hour to an hour trying to recall the implementation details or find them back by doing searches on the Internet. I have finally come to the following realization by giving up searching the Internet and looking at the <map> header file source code:

Scott Meyers efficientAddOrUpdate() function code is almost identical to the operator[] member source code function minus minor modifications

Here is the source code operator[]:

mapped_type& operator[](const key_type& _Keyval)
{   
    // find element matching _Keyval or
    // insert with default mapped
    iterator _Where = this->lower_bound(_Keyval);
    if (_Where == this->end() || 
        this->comp(_Keyval, this->_Key(_Where._Mynode())))
    _Where = this->insert(_Where,
            value_type(_Keyval, mapped_type()));
    return ((*_Where).second);
}

and efficientAddOrUpdate() code derived from it would be:

iterator efficientAddOrUpdate(map &m,
         const key_type& _Keyval,const val_type& _Val)
{
    iterator _Where = m.lower_bound(_Keyval);
    if (_Where == m.end() ||
        m.key_comp()(_Keyval, _Where->first)))
    {
        return m.insert(_Where,value_type(_Keyval, _Val));
    }
    else
    {
        _Where->second = _Val;
        return _Where;
    }
}

This book presents advices more or less in the same format than books from the Effective C++ serie. What is similar is that topics are divided in 47 small items of few pages each. The difference is that the author first ask questions to the readers or propose exercises and encourage the reader to put down the book and to take the time to think about the problem and then come back to read his answer. This format is more or less original as I have seen something similar in Tom Cargill's C++ Programming Style book.

I have read this book pretty fast which is a good sign of my interest in a book but in the same time this book did not leave me, at first, a strong impression that will make me remember this reading for a long time. It is hard for me to say exactly why but I think that it is because most items focus on very small details of C++. Some of these problems are very hard and probably is an indication that the book targeted audience is advanced C++ users which is not a bad thing by itself but I was not convinced that mastering these small details actually has a high impact on someone programming skills.

It took few months to let the wisdom contained in this book to sink in and I have found myself many times, in my day to day programming, confronted to problems where the material of this book helped to make wise design decisions. So now, I think that this book is very valuable for anyone that has mastered the C++ programming language and is ready to master tougher C++ issues.

Forward declaration is a technique that has at least 2 purposes:

• 1- Resolve circular dependency where class A refers to class B that refers to class A.
• 2- Reduce header file dependencies when header file A contains functions that takes pointers or references to classes defined in another header file.

For purpose #2, a TU (translation unit) that includes header file A but does not use the functions using the class defined in header file B and does not access that class, does not need to include header file B. That way if header file B ever change and forward declaration is used, this TU will not be recompiled. Taking systematically all the opportunities to reduce header file dependencies will not make a big difference on a project containing just a few TUs but it can save hours of compilation on big projects. Also, from experience, it is much easier to plan ahead and think about this aspect as the project grows than trying to remove the dependencies once they become a major problem for maintenance!

The reason why forward declarations work is because the compiler does not need to know the size of a class to generate code that handles pointer or reference to that type. A pointer or a reference always have the same size no matter the type.

Now that I have convinced you of the benefits of using forward declarations in header files, once you start using them, you might stumble on minor difficulties. How to forward declare a class inside a namespace? I have checked into the C++ bible 'The C++ Programming Language' from Bjarne Stroustrup and it remains quiet on the subject.

Fortunately, the answer is simple. Since namespace are open, all you have to do is:

namespace A
{
// Forward declaration
class B;
};

For nested classes, you can do it too but at the condition that it is done inside the outer class full declaration.

class B
{
  // Forward declaration
  class C;
};

is ok but

class B;
class B::C;

is not. If this is something that you need, you either have to give up the forward declaration of B or move out class C out of B.

I had high expectations about the fruit of the association of 2 authors that I appreciate but the result did not meet these expectations. Basically this book provides 101 rules or guidelines that you can get for free by looking at the table of content. Each of these rules is then followed by a very short explanation (1 or 2 pages usually). In my opinion, most of them are common wisdom that you can get from other sources. This is it. That is all you will get from this book. For that reason, I recommend to skip this one except if a convenient and compact collection of common knowledge is something that you are looking for.

It is not perfect. One complain is that the first part is too easy and is aimed for total beginners and then there is the second part where a lot of material is presented too fast. I wished that the book spent less time with very basic (pun intended) VBA stuff but takes more time to make the transition to more advanced topics smoother.

Other than that, the book contains a lot of code that can easily be reused such as in my C++ tutorial that shows how to automate Outlook from a C++ program.

I have been disappointed by this book. I wanted it mostly to learn how to program Outlook. When I started reading it, I have realized that only a small portion of it was dedicated to Outlook.

Perhaps that I am harsh against the book value because I am not part of the intended readers but I guess that even readers interested to programming Exchange would not find much value of this book. I am saying so because the book is huge close to a thousand pages but it sounds like a cut and paste of the Exchange programmer user manual. When I purchase a book like this one, I expect it to be a complement to the product documentation, to give a better insight of how and why a given software works like it does. This book does not deliver up to these expectations.

The best Outlook programming book that I have found is: Microsoft Outlook Programming, Jumpstart for Administrators, Developers, and Power Users. Skip this one.

You have to know that its target audience is beginner C++ programmers. I am somehow experienced with C++ programming and by looking at the excellent reviews this book got, I had high expectations when I purchased it. I have been disappointed to only have found maybe 2 small advices that I did not know. Reading over 250 pages for a so small reward has been disappointing. If you consider yourself good in C++, my advice is that you should skip this one.

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.

The content of this book slightly overlap the content of the author previous book (Secrets and Lies: Digital Security in a Networked World) but presents the material with a different angle. An angle with the perspective of a security expert that witness security measures taken by governments in reaction of the 9/11 terrorism attack and wants people to understand the absurdity of some of these measures.

It is not technical at all and does not necessitate any particular background to understand and enjoy. The author explains clearly how to make a risk assessment of something that you want to make more secure and then evaluate the cost of the security measures. Only when you have that data, you can evaluate if the added security is worth it.

These explanations are backed up with concrete examples such as evaluating the risk to make purchase with a credit card over the internet. Other examples include the absurdity of securing a lunch in a company refrigerator because the potential loss if having a lunch stolen does not justify securing it. The author also explains that even with technologies that looks very accurate such as facial recognition with an error rate of, let’s say, 0.0001 % are totally ineffective when they have to control a huge number of persons like a stadium crowd because even with this accuracy, they would create an unmanageable amount of false positive alerts.

The author also elaborate about why you should question the motivation of a security provider when it is a third party and link this with how people fears can be exploited to introduce invasive, excessively expensive and inefficient security measures. I think that the goal of the author was to make people more critics about security questions and my opinion is that his goal has been successfully achieved.

This book is not very technical but it is very interesting to read and is very good to convey the basic principles of security. This book will teach you why security is more important than ever with the advent of computers and internetworking. It will present you potential attackers, their motivations and their resources. It shows how to add security to a system by doing some analysis of how the system could be attacked. After reading this book, you will have a better understanding of what it means to make a digital system secure.