In this article, MSVC C++ ABI with default options is assumed unless stated otherwise. Some of the values assumed to be int may actually be long int or int32_t, but without access to an LP32 or LP64 target using the MSVC C++ ABI it’s impossible to confirm one way or the other. This description is mainly based on the behaviour of MSVC 19.29 for x86-64 and AArch64. The usual disclaimers about implementation-defined behaviour apply: depending on this behaviour produces code that is not portable, details may change at any time, and the accuracy is limited by my understanding.

Casting pointers to member functions

According to the C++ standard, pointers to base class member functions may be cast to pointers to pointers to derived class member functions with the same signature for non-virtual bases only. Casting member function pointers across virtual inheritance relationships is forbidden. This rule simplifies implementation of member function pointers by avoiding the need to obtain this pointer offsets to virtual bases from the virtual table at the time a pointer to a member function is called. (You can still call a pointer to a member function of a virtual base class by casting the object to a reference to an instance of the virtual base class. The virtual base class offset is obtained from the virtual table as part of the cast to the base class, not as part of the pointer to member function invocation.)

By way of example, assume the following declarations:

class a { };

class b : public a { };

class c : public virtual a { };

using afunc = void (a::*)(int);
using bfunc = void (b::*)(int);
using cfunc = void (c::*)(int);

In standard C++ it is legal to cast a value of type afunc to type bfunc because the class a is a non-virtual base of the class b. On the other hand, it is not legal to cast a value of type afunc to cfunc because the class a is a virtual base of the class c.

As an extension to the C++ standard, MSVC does allow casting a pointer to a base class member function to a pointer to a derived class member function for virtual base classes. With the declarations from the example above, MSVC allows casting a value of type afunc to cfunc. This is the cause of some of the complications in the implementation of pointers to member functions in the MSVC C++ ABI.

Pointer to member function representations

As an optimisation, there are four different pointer to member representations used in different situations. I call them “single inheritance”, “multiple inheritance”, “virtual inheritance” and “unknown inheritance”. There are options to change the way the compiler selects a member pointer representation, for example MSVC has /vmb, /vmg, vmm, /vms and /vmv command-line options and a #pragma pointers_to_members directive. Unless otherwise noted, the rules described here assume /vmb or #pragma pointers_to_members(best_case) is in effect.

Single inheritance

Pointers to member functions of classes with single inheritance are equivalent to this structure:

struct {
    uintptr_t   ptr;    // function pointer
};

This representation is the same size as a non-member function pointer. This makes it efficient to store, copy or pass as a function parameter, as it can usually fit in a single address register or general-purpose register.

This representation is used when either:

• The class definition is available, neither the class nor any of its direct or indirect base classes has any virtual base classes, neither the class nor any of its direct or indirect base classes has more than one base class, and neither the class nor any of its direct or indirect base classes declares any virtual member functions while deriving from a base class that has no virtual member functions.
• The class definition is not available and a forward declaration of the class with the __single_inheritance qualifier is available.

MSVC will use this representation for all pointers to member functions with the /vmg and /vms options or the #pragma pointers_to_members(full_generality, single_inheritance) directive in effect. In this situation, declaring a pointer to a member of a class with multiple direct base classes, a class with virtual base classes or a class with virtual member functions that derives from a class with no virtual member functions results in “error C2287: ‘c’: inheritance representation: ‘single_inheritance’ is less general than the required ‘multiple_inheritance’” where “c” is the name of the class.

This minimal representation can be used because two assumptions can be made:

• With non-virtual single inheritance, the base class (if any) always appears at the start of the class. A pointer to an instance of the class will not require adjustment when cast to or from a base class. Therefore, a pointer to a base class member function will not require this pointer adjustment when called.
• For virtual member functions, the compiler will generate an out-of-line stub that fetches the appropriate virtual table entry and jumps to it.

It is possible to invoke a member pointer using this representation without access to the class definition. Performance for calling this representation is similar to calling a non-member function pointer for non-virtual member functions. For virtual member functions, there is an additional fetch and indirect branch. However, there are no conditional branches involved, which avoids performance penalties on deeply pipelined and/or highly parallel processors.

Multiple inheritance

Pointers to member functions of classes with multiple inheritance are equivalent to this structure:

struct {
    uintptr_t   ptr;    // function pointer
    int         adj;    // this pointer displacement in bytes
};

Note that on typical architectures, pointers and pointer-sized integers have natural alignment and int is no larger than a pointer, so the overall size is twice the size of a pointer. On typical LLP64 targets (including Windows on x86-64 and AArch64), the structure has four padding bytes for a total size of sixteen bytes.

This representation is used when either:

• The class definition is available, neither the class nor any of its direct or indirect base classes has any virtual base classes, and the class or one of its direct or indirect base classes has at least two base classes.
• The class definition is available, neither the class nor any of its direct or indirect base classes has any virtual base classes, and the class or one of its direct or indirect base classes declares at least one virtual member function while deriving from a base class that has no virtual member functions.
• The class definition is not available and a forward declaration of the class with the __multiple_inheritance qualifier is available.

MSVC will use this representation for all pointers to member functions with the /vmg and /vmm options or the #pragma pointers_to_members(full_generality, multiple_inheritance) directive in effect. In this situation, declaring a pointer to a member of a class with at least one direct or indirect virtual base class results in “error C2287: ‘c’: inheritance representation: ‘multiple_inheritance’ is less general than the required ‘virtual_inheritance’” where “c” is the name of the class.

The this pointer displacement is necessary for the purpose of casting a pointer to a non-virtual base class member function to a pointer to a derived class member function with the same signature. The offset of the base class within the derived class is calculated when the pointer is cast, and applied (added to the this pointer) when it is invoked.

It is possible to invoke a member pointer using this representation without access to the class definition. This representation has twice the space cost of the single inheritance representation, but minimal additional performance cost to invoke – just one additional integer fetch and addition.

Virtual inheritance

Pointers to member functions of classes with virtual inheritance are equivalent to this structure:

struct {
    uintptr_t   ptr;    // function pointer
    int         adj;    // this pointer displacement in bytes
    int         vindex; // byte offset to base class offset in virtual table
};

Note that in the LLP64 data model, the two int members fit into the size of a pointer, so this representation has the same size as the multiple inheritance representation on typical LLP64 targets (including Windows on x86-64 and AArch64).

This representation is used when either:

• The class definition is available, and either the class or at least one of its direct or indirect base classes has at least one virtual base class.
• The class definition is not available and a forward declaration of the class with the __virtual_inheritance qualifier is available.

There is no combination of options or directives that will cause MSVC to use this representation for all pointers to member functions.

The virtual table index is necessary for the purpose of casting a pointer to a member function of a virtual base class to a pointer to a derived class member function with the same signature. The virtual table for the derived class contains offsets to all virtual base classes. The location of the offset to the virtual base class in the virtual table is populated when the pointer is cast; the offset is fetched from the instance’s virtual table and applied when the pointer is invoked, in addition to applying the this pointer displacement stored in the member function pointer directly.

It is not possible to invoke this representation of a pointer to a member function without access to the class definition – attempting to do so results in “error C2027: use of undefined type ‘c’” where “c” is the name of the class that was forward declared with the __virtual_inheritance qualifier. This requirement comes from a combination of two factors:

• Structure layout rules mean that the virtual table pointer is not necessarily at the location the this pointer points to. (The virtual table pointer may not be at the location the this pointer points to in some situations where the first base class has no virtual member functions or virtual bases, but a virtual table pointer is inherited from another base class. It’s very rare to actually encounter such a case in practice.)
• Invoking this representation requires access to the virtual table pointer, and hence knowledge of the offset to the virtual table pointer from the location the this pointer points to. This requires the base classes to be known.

The offset to the virtual base class and the this pointer displacement must be interpreted relative to the location of the virtual table pointer, which is not necessarily the location the this pointer points to. In pseudocode, the sequence for invoking this representation looks like this:

vptr = this[vadj]
this += vadj + vptr[vindex] + adj
CALL ptr

The offset to the virtual base class found in the virtual table will always be zero if the pointer does not represent a pointer to a member function of a virtual base class. In standard-conforming code, this will always be the case, as casting across virtual inheritance relationships is not permitted.

Compared to the multiple inheritance representation, this representation requires two additional fetches (the virtual table pointer and offset to the base class), at least two additional integer additions (the offset into the virtual table and the offset to the base class), and possibly a third addition of a constant (the offset to the virtual table pointer from the location the this pointer points to). On most architectures, some of these additions are implicit in addressing modes for the fetches. This representation still avoids the need for conditional branches: because the class is known to have a virtual table and the location of the virtual table pointer within the object is known, the offset to the virtual base can be fetched and added unconditionally even if it will be zero in most cases.

Unknown inheritance

Pointers to member functions of classes with unknown inheritance are equivalent to this structure:

struct {
    uintptr_t   ptr;    // function pointer
    int         adj;    // this pointer displacement in bytes
    int         vadj;   // offset to vptr or undefined
    int         vindex; // byte offset to base class offset in vtable or zero
};

Note that on typical LLP64 targets (including Windows on x86-64 and AArch64), the structure has four padding bytes for a total size of twenty-four bytes.

This representation is used when the class definition is not available, and the forward declaration of the class has no __single_inheritance, __multiple_inheritance or __virtual_inheritance qualifier.

MSVC will use this representation for all pointers to member functions with the /vmg and /vmv options, the /vmg option without the /vms or /vmm options, or the #pragma pointers_to_members(full_generality, virtual_inheritance) directive in effect.

If the virtual table index is non-zero, the offset to the virtual table pointer is added to the this pointer, and the offset to the base class is obtained from the virtual table and added to the this pointer. After this, the this pointer displacement is added to the (possibly already adjusted) this pointer. In pseudocode, the sequence for invoking this representation looks like this:

IF 0 != vindex:
    vptr = this[vadj]
    this += vadj + vptr[vindex]
ENDIF
this += adj
CALL ptr

It is possible to invoke this representation of a pointer to a member function without access to the class definition. Invoking this representation of a pointer to a member function requires a conditional branch and the associated performance penalties on deeply pipelined and/or highly parallel processors. This is necessary because without the class definition, it is not possible to know whether the class has a virtual table at all, and hence it may not possible to provide an offset to a zero value in the virtual table when an offset to a virtual base class is not required.

Comparison to Itanium C++ ABI

The Itanium C++ ABI is currently one of the most popular C++ ABIs, despite the market failure of the Itanium CPU architecture. The Itanium C++ ABI has been widely adopted on UNIX-like systems and by Open Source/Free Software development tools. Exact details vary by architecture, but conceptually the Itanium C++ ABI always represents pointers to member functions as a tuple containing three values:

• A union containing a function pointer or virtual table index
• A displacement to apply to the this pointer
• A flag to discriminate between a function pointer or a virtual table index

Disadvantages compared to the MSVC C++ ABI include:

• No provision for obtaining an offset to a virtual base class, so casting pointers to members of virtual base classes to pointers to members of derived classes cannot be supported
• Pointers to member functions are always larger than non-member function pointers, even in the simplest cases
• A conditional branch is required to invoke any kind of member function pointer in order to handle either a function pointer or a virtual table index

Advantages over the MSVC C++ ABI include:

• All member function pointers types are the same size and can be invoked in the same way
• Layout rules mean the virtual table pointer will always be at the location the this pointer points to if present, so there is no need to account for the offset to the virtual table pointer
• If a pointer to a virtual member function is to be called repeatedly, it is simple to resolve the function address and avoid repeated virtual table fetches and additional indirect branches

Calling conventions

The proliferation of incompatible calling conventions for 32-bit i386 or i686 targets is well-known. For member functions, explicit arguments are pushed onto the stack in right-to-left order, the this pointer is passed in register ECX, and the called function removes the arguments from the stack on return. However, it is widely assumed that on x86-64, member functions are equivalent to non-member functions with the this pointer as an implicit first parameter. This is not true. The MSVC C++ ABI for Windows uses a subtly different calling convention for member functions on both x86-64 and AArch64.

This is not a comprehensive discussion of Windows calling conventions on x86-64 and AArch64. It’s intended to be just detailed enough to highlight the differences between non-member functions and member functions.

Non-member functions

Both x86-64 and AArch64 pass parameters and return results in registers. However, only scalar types (integers, floating point types, pointers and enumerated types), references, and small aggregate structures and unions (trivially constructible, destructible, copyable and assignable) may be returned in registers. In cases where the return type may not be returned in a regsiter, the caller allocates space for the return value (typically on the stack) and passes a pointer to the area for the return value as an implicit parameter.

On x86-64, register RCX is usually used for the first integer or pointer argument. However, if the return type cannot be returned in a register, the pointer to the area for the return value is passed in register RCX and explicit parameters are shifted by one position:

On AArch64, registers X0 to X7 are used for integer or pointer arguments. If the return type cannot be returned in a register, the pointer to the area for the return value is passed in register X8, which would otherwise be a volatile register with no special significance. Explicit parameters do not need to be shifted:

Member functions

There are three key differences in the calling convention for member functions:

• The this pointer is passed as an implicit first parameter.
• Structure and union type values are never returned in registers.
• The pointer to the return value area for structure and member types is passed as an implicit second parameter after the this pointer.

Note that for scalar types that may not be returned in registers, the pointer to the result area is passed in the same way it would be for a non-member function. An example of a type returned this way is a pointer to a member function of a class with unknown inheritance: it is a pointer, and hence a scalar type, but with a size of twenty-four bytes it is too large to return in registers.

For x86-64, these are the three possible situations on entry to a member function – note that when a scalar value cannot be returned in a register, the this pointer is shifted by one position:

For AArch64, these are the three possible situations on entry to a member function – note that the this pointer is always in X0:

Why the difference?

The different calling convention for member functions on x86-64 has been in place since MSVC added support for the architecture. AArch64 seems to follow x86-64 by analogy.

Initially I thought the different calling convention for member functions was to ensure the this pointer would always be in the same register for convenience. That was before I realised there are situations where this is not the case, and there are different rules for which types may be returned in registers.

I can only speculate as to what the reasoning behind the decision to use a different calling convention was. It may simplify interoperability with some other language, or it may simplify COM implementation in some way.

The problems for delegates

Unless you’re writing assembly language code or a compiler that generates it (or debugging a low-level issue), the real motivation for getting into the gory details of member function pointer implementations almost always comes back to the desire to implement fast delegates. Invoking pointers to member functions can be slower than invoking pointers to non-member functions, and mitigating that is a common goal.

The MSVC ABI presents three major problems for the purpose of implementing fast delegates without limiting developers:

• It is not practical to distinguish between the multiple inheritance and virtual inheritance representations of pointers to member functions in a template on LLP64 platforms. It’s simple to distinguish between the single inheritance, multiple inheritance and unknown inheritance representations using the result of the sizeof operator. However, the multiple inheritance and virtual inheritance representations have the same size on LLP64 platforms due to alignment and padding requirements. There’s no standard type trait for determining whether a class has at least one direct or indirect virtual base, and as far as I know there’s no MSVC extension for doing so either.
• There’s no standard way to obtain the location of the virtual table pointer within an object. In certain situations, the virtual table pointer will not be at the location the this pointer points to. There’s no standard way to obtain the offset to the virtual table pointer, and as far as I know there’s no MSVC extension for obtaining it, either. This makes it impossible to safely support the virtual inheritance representation even on platforms where it can be detected reliably.
• The subtle difference in calling conventions for non-member and member functions means that it is not possible to convert a pointer to a member function to an equivalent pointer to a non-member function if it returns a structure or union value that is not trivially default constructible and destructible. There is no equivalent non-member function signature that will cause the result value to be constructed in the correct location. For trivially constructible and destructible types, the area for the return value can be treated as a reference parameter following the this pointer. Using this approach requires a temporary variable that the compiler might not elide, and if your delegate implementation supports non-member functions as well as member functions, a conditional branch is required to select the correct equivalent non-member function signature before the call. This causes a performance penalty for all calls, working against the original goals of designing a fast delegate type.

In practice, many developers just naïvely assume the virtual table pointer can be found at the location the this pointer points to, even though this isn’t guaranteed by the layout rules. It’s possible to work around the differing calling conventions by instantiating an adapter function when binding a delegate to a member function that returns a structure or union by value, but there are real-world delegate implementations that don’t do this. There are also real-world delegate implementations that ignore the differences between the multiple inheritance and virtual inheritance representations of member function pointers.

How do they get away with it?

So how do delegate implementations that don’t account for these seemingly insurmountable issues work at all? Well it actually turns out that situations that trigger the issues don’t come up as frequently as you might expect. Even if you aren’t being careful to avoid the problematic code, a combination of several factors means you may not ever encounter the issues:

Virtual inheritance is used sparingly

Several of the issues only come up when virtual inheritance is involved. Virtual inheritance is one of the less-frequently used C++ features. It has a space penalty, it adds indirection to base class member accesses, and it complicates base class construction. It’s only used when it’s really necessary. You may never need to write a class with any virtual bases, and even if you do, you may not need to use it with delegates. If you don’t use classes with virtual bases, you won’t get a situation where you need to find the virtual table pointer and fetch a value from the virtual table in order to invoke a pointer to a member function.

Classes where the this pointer doesn’t point to the virtual table pointer are rare

To make this happen, you need specific conditions involving a class with multiple base classes where the first non-empty base class has no virtual member functions and no direct or indirect virtual base classes, but the class inherits a virtual table pointer from another base class. It’s very rare to write a class that meets the requirements and has at least one virtual base class by coincidence. For example in many real-world cases, classes inherit a virtual destructor or a virtual base class via their first base class. This means assuming the virtual table pointer can be found at the location the this pointer points to rarely causes issues in practice.

Casting pointers to member functions across virtual inheritance relationships is non-standard

The offset to the virtual base class obtained from the virtual table when invoking a pointer to a member function will only be non-zero if the pointer represents a pointer to a function member of a virtual base class that has been cast to a pointer to a member of a derived class. Since this is not permitted by the C++ standard, it will never happen in portable code. Conveniently, this extension to the standard cannot be supported with the Itanium C++ ABI, so any code that uses it will fail to compile in many configurations (e.g. MinGW GCC on Windows x86-64, pretty much any Linux configuration, or macOS). The extension is unlikely to be useful in conjunction with delegates because the instance can be cast to a reference of the virtual base class when setting the delegate rather than casting the member function pointer. This means a situation where the offset to the virtual base class must be obtained from the virtual table when invoking a pointer to a member function is impossible in most portable code, and highly unlikely in code only built with the MSVC C++ ABI, especially considering the sparing use of virtual inheritance.

Functions return scalars more frequently than structures

The majority of functions return void or some kind of scalar value. Functions returning references (especially const references) are quite common, too. The different calling convention for member functions doesn’t affect functions that return void, scalars or references. Simply not using delegates with member functions that return structures or unions can be used as a workaround to avoid having to deal with the different calling convention used for member functions. You can also use a trait to prevent a delegate from being instantiated for pointers to member functions returning structure and union types.

These factors combine to allow code to work most of the time when various implementation difficulties are ignored.

Updates

• Updated on 6 June 2023 to correctly cover the case where a class declares at least one virtual member function while deriving from a single base class with no member functions (thanks to ykiko for pointing out this error).

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.