semicolonSoftware, the Internet and you.

This article describes a problem with the default handling of exceptions in Microsoft’s Visual C++ compilers. The problem is caused by the compiler’s extension to the C++ exception handling mechanism. I then give a technique that properly exploits this extension, bringing it into line with normal C++ exception handling. This allows programs to deal with exceptions that are normally very difficult to handle, such as memory access violations.

This article was originally based on Visual C++ 6, and the same issues exist in the Visual Studio .NET C++ compiler. Finally, after at least six years, Microsoft fixed the fundamental problem in Visual C++ 2005. But to fully take advantage of this, it’s still necessary to implement an exception translation scheme like the one described in this article.

Win32 hardware exceptions

Under Visual C++, certain exceptional runtime conditions can be treated something like C++ exceptions. These exceptions are raised by the OS for events like memory access violations, division by zero, and so on. A (presumably) full list is in Microsoft’s MSDN Library under “EXCEPTION_RECORD”.

They are referred to in the documentation as “hardware exceptions”, “C exceptions”, “structured exceptions” and “C structured exceptions”. Actually, they are neither C-specific nor structured (at least compared to C++ exceptions). I refer to them as “Win32 hardware exceptions” or just “Win32 exceptions” because they are specific to the Win32 operating systems and hardware on which they run.

Visual C++ programs may be unstable by default

Visual C++ is a good compiler. But, like all compilers, it has some bad features. The default handling of Win32 exceptions in pre-2005 versions is one of them.

Continue reading “Visual C++ exception handling” →

Whenever you have a choice, you should use the C++ prefix increment and decrement operators (e.g. ++i) instead of the postfix versions (e.g. i++). This will make your code more efficient, clear and consistent. This advice applies (more or less) to most languages that have both prefix and postfix operators.

1. Efficiency

Code like this is quite common:

for (i = 0; i < count; i++)
    // stuff

But consider what’s going on. The expression i++ has a value, namely the value of i before the increment. i is incremented during evaluation of the expression, but the program must keep a copy of the un-incremented i to use as the value of the expression.

Continue reading “Prefer prefix operators over postfix” →

The C++ negation operator (!) can be hard to see in code listings, and this leads to bugs. Here are a few solutions to this perennial coding problem.

The C negation operator (!) is used by most C++ programmers also. The trouble with it is that it can be hard to see. For example, code like this Continue reading “Clarifying C++ negation” →

C++ specifies how compilers should deal with programs that misbehave. This article describes one of the effects of these rules: compilers may generate no code for the body of a misbehaved function, whether or not the function is ever called.

Consider this function

void furphy()
{
    std:::cerr << "furphy";
    int* p = 0;
    *p = 0; // dereferencing a null pointer causes undefined behaviour
}

What code will a compiler generate for the body of this function? In particular, may the compiler elide (generate an empty body for) the function?

The answer is that, according to the C++ standard, a compiler can generate any code at all, or none at all, for the body of this function. This is true even if the compiler can’t tell whether the function is ever called. It’s even true if there is no way at all to tell this.

Continue reading “Disappearing C++ functions” →