if ((dest bitor netmask) == bcdest and protocol == udp)

But in typical C++ fashion, they chose to specify it in a completely brain-dead way. The names don’t alias the operators they’re named for, but their actual punctuation representations. That means this is valid code:

Address parse(const std::string bitand repr);

The ability to do this doesn’t really help anyone, except lazy compiler vendors who want to implement the aliases as predefined macros. But it gives us all one more WTF, and another tool in our arsenal for writing obfuscated code.

I have a template class — let’s call it Foo. It used to have a couple of non-trivial constructors and assignment operators:

template <typename T>
class Foo
{
public:
    Foo(T* = 0);
    Foo(const Foo<T>&);
    ~Foo() throw();

    Foo<T>& operator=(T*);
    Foo<T>& operator=(const Foo<T>&);

    ...
};

This all works fine — user-defined constructors and assignment operators are used in all cases. But one day, I realise that I can simplify some code by making the constructors and assignment operators more general:

template <typename T>
class Foo
{
public:
    Foo(T* = 0);
    template <typename U>
    Foo(const Foo<U>&);
    ~Foo() throw();

    Foo<T>& operator=(T*);
    template <typename U>
    Foo<T>& operator=(const Foo<U>&);

    ...
};

Instead just being able to construct or assign from the same class, you should be able to construct or assign from any instantiation of the template. But this caused things to break all over the place. Can you see why? The compiler will now generate a copy constructor and assignment operator. To stop the compiler from generating them, you need not just a constructor/operator general enough to accept an instance of the same class, but a constructor/operator that takes an instance of exactly the same class. To make it work, I need to do this:

template <typename T>
class Foo
{
public:
    Foo(T* = 0);
    Foo(const Foo<T>&);
    template <typename U>
    Foo(const Foo<U>&);
    ~Foo() throw();

    Foo<T>& operator=(T*);
    Foo<T>& operator=(const Foo<T>&);
    template <typename U>
    Foo<T>& operator=(const Foo<U>&);

    ...
};

There’s another case where this can easily trip you up. Consider this:

class Fish
{
    ...
};

class Salmon : public Fish
{
public:
    Salmon(const Fish&);

    ...
};

Counter-intuitively, a generated copy constructor will be used to construct Salmon from other instances of Salmon derived classes; the user-defined constructor will only be used to construct Salmon from instances of Fish and other derived classes thereof.

The current counter-intuitive behaviour makes it too easy to end up with broken code. The issues could have been avoided in a number of ways:

• No generated copy constructors/assignment operators
• Suppress generated copy constructors/assignment operators in the presence of user-defined copy constructors/assignment that are general enough to accept an instance of the same type (or to think of it another way, give the generated copy constructor/assignment operator lower precedence than all user-defined constructors/assignment operators)
• Suppress generated copy constructors/assignment operators
  in the presence of any user-defined constructors/assignment operators

While I’m excited about some of the new features in C++0x, I can’t help but dread that some of them will be implemented in equally brain-dead ways. Move semantics is one that comes to mind immediately.

Fairly early on, people realised that the only things you really need for flow control are a way to make a comparison, and a way to conditionally jump to another point in the program based on the result of a comparison. On top of these primitives, you can build flow structures that are as complex as you like. If you look at the native machine code that computers run, you can see that this has really been taken to heart: most CPUs provide a way to store the result of a comparison and one or more conditional jump instructions. Early programming languages like BASIC and Fortran had flow control based entirely on these primitives, too. If you learned to program on an 8-bit personal computer, you’ll no doubt remember writing statements like “IF condition THEN GOTO line” all the time.

But in 1968, this form of flow control was about to get a major setback (at least in high-level languages), because Edsger Dijkstra had written what was to become a highly influential letter entitled “A Case Against the Goto Statement”. You probably don’t know it by this name, though, because it was published in CACM under the title “ Go To Statement Considered Harmful” (Niklaus Wirth, a CACM editor at the time, changed the title for publication). This letter criticised the goto statement and the form of flow control associated with it, instead advocating structured programming.

Most modern high-level programming languages are designed with structured programming in mind: simple statements can be grouped into compound statements (with begin and end delimiters in Pascal, or with curly braces in C or Java), and flow control is based around these compound statements. For example, and if statement can be used to conditionally skip over a compound statement. Essentially, compound statements are the basic building block from which you build your structured code. Poor goto has survived to varying degrees: it’s present but rarely used in C and Pascal, and is a reserved word with no function in Java, for example.

The crusade against the goto statement has continued unabated. Most programming lecturers will advise against its use, or neglect to mention its existence. Programs that make use of it are referred to as “spaghetti code” because flow control can conceivable jump from any given point to any other given point. This can make code difficult to understand, debug or modify. However, in spite of this, I think Dijkstra’s message is being largely ignored.

You see, the beauty of structured code, and part of what makes it easy to understand (and consequently easy to debug and modify), is that code blocks only have a single entry point and a single exit point – program flow enters the block at the beginning, continues through it linearly, and leaves it at the end. All flow control statements operate on entire blocks – an if statement skips an entire block if the condition is not met. The goto statement obviously violates this principle, as program flow can be made to jump to an arbitrary point. And that’s why Dijkstra criticised it: because it causes program flow to deviate from the program’s structure. However, despite the ongoing crusade against goto, several other flow control structures that effectively do the same thing are being encouraged. These include loop control statements (continue and break), C-style return statements and exceptions. Let’s have a look at each of them.

First up, let’s think about loops. A loop will have some kind of condition that must be maintained in order for it to run, and a block of code that runs while the condition is maintained. Now this block, like any other block of code in a structured program, will have a natural entry point at the top and an exit point at the bottom. The loop itself has an exit point after the loop condition is evaluated. But when you add a continue statement, you’re adding another exit point to the loop body. You can no longer say that the loop body will be entered at the top and left at the bottom. In fact, continue may as well just be shorthand for doing a goto that jumps to the end of the loop body. A break statement is slightly worse: it’s like a goto that jumps to a point just outside the loop – it’s not only adding an additional exit point to the loop body, but adding an exit point to the loop itself!

C-style return statements are similar: they add exit points to functions (effectively a goto that jumps to the end of the function body). I do realise that there isn’t really much you can do about them, though – there isn’t any other way to return a value from a function. The best you can really do is to only ever place one return statement in a function, and to place it at the end of the body. (Pascal lets you return a value by assigning to the name of the function, so there’s no excuse there.)

Now neither of these are really any better or worse than goto statements. They’re just like shorthand goto statements where the destination is implied. If you use them, fair enough – just be aware of the consequences, and think twice before you criticise goto again, because your code is starting to look like spaghetti, too.

But exceptions are the worst of all. Exceptions are like a goto where you don’t know the destination! Think about it: throwing an exception could jump to somewhere in the same function, or somewhere up the call stack. You just don’t know where it will land (The only thing they can’t do that a goto can is to jump backwards within a code block.) Use of exceptions means you don’t know whether a function call will return, or jump somewhere else. Worst of all, in C++ simply unwinding an object could cause an exception to be thrown, which will most likely lead to a memory leak.

To deal with exceptions properly, you need to write ugly code. Languages like Java help you out a bit with finally blocks. But you still have to remember to wrap anything that needs cleaning up in a try block and to place the clean-up code in the corresponding finally block – the language can’t make you code properly. So now you’re code is littered with try…finally constructs.

Of course, the C++ way has to be the ugliest: RAII. If you need to clean something up, you need to make a small class with the thing that needs to be cleaned up in the constructor, and the clean-up code in the destructor, and remember to be very careful to ensure you won’t throw an exception from the destructor, because then you’re really screwed. Now create an instance of this class and make sure it’s unwound at the point where you need the clean-up to occur. Now your code is littered with these small classes that are only really there in case an exception is thrown. You also can’t see the program flow properly, because it will be jumping to all these little destructors. And you want to hope you don’t need to try stepping through it in a debugger, because that’s an absolute nightmare.

There’s one place that exceptions are even more evil, if that’s possible: Objective-C++. There is no proper way to deal with exceptions in Objective-C++ because C++ frames will not be properly unwound when an Objective-C exception is thrown. (Objective-C exceptions are generally only thrown in truly exceptional circumstances, so it isn’t such a big problem in practice, but that’s beside the point.)

So why don’t we bring back goto? We’re doing all the things that make it harmful – we’re just kidding ourselves by refusing to call it what it is.