C++ Bloopers - references to temporary objects

Breaking encapsulation of classes to expose internal state, is always a source for potential errors.

STL had to do this to allow communication with C's lower level strings and arrays. And here's how you can mess things up when using std::string.

Building custom iterators

Once one realizes that STL algorithms open the doors for expression, readability, maintenance and reusability, he wants to have it for the classes he creates.

Of course, you shouldn't expose the internals of your class, so you need a way to offer exploration of your object's data, without exposing implementation details, like the underlying data structures:

The quick-and-dirty way is to  provide algorithms for your class.

class Polygon {
        vector<Point> vertices;
    public:
        template <class Func>
        Func for_each_vertex ( Func f );  // access by vertex

        template <class Func>
        Func for_each_edge ( Func f );  // access by edge
};

However, this gives you limited expression. You soon have to write versions for find(), find_if(), copy(), copy_if(), transform(), count_if(), all_of(), any_of(), none_of(), and you end up replicating part of STL algorithms for each class, for each access type (by vertex, by edge).

Read this article, to see how you can implement this interface:

class Polygon {
        vector<Point> vertices;
    public:
        vertex_iterator begin_vertex();

        vertex_iterator end_vertex();

        edge_iterator begin_edge();

        edge_iterator end_edge();

};

inline, static, extern functions and namespaces

How safe do you think it is to write this piece of code in your .cpp file ?

file.cpp
struct Point {
    double *px;
    double *py;

    Point (double x, double y) {
        px = new double(x);
        py = new double(y);
    }
    ~Point() {
        delete x;
        delete y;
    }

    // other members ...
};

Read more why this is the most dangerous piece of code you can write in your .cpp, and it is more likely to be spotted after releasing the project...

The law of least surprise

Extreme programming argues that documentation is not needed, since code is the best description of what the program does. In order for this to be true, code has to be readable. Very readable.

It is important to be able to tell what is the direction of data in every line you read. In the following case, which variable is the source and which is the destination ?

    Array *names;
    struct Detail details;
    ...
    set_name_details (names, &details);

Here is a simple rule to make the caller code clearer...

The Roll - Unroll Pattern

The pattern that is most predominant in programming is:

• Setup some state
• Do some work
• Clean up

Manual housekeeping of this repetitive task requires too much care and energy, from the programmer’s side. Repetitive tasks sounds like a work that should be automated, rather than maintained manually.
Read how you can create an elegant piece of code, while reducing the maintenance load.

Algorithms should read like pseudocode

When an algorithm is described like pseudo-code, there is hardly ever any mention about the underlying data-structures. No statement is made on whether a list, a dynamic array, or a binary tree should be used.
With C++, it is possible to code in such a way.