Operator overloading

2004-08-05T22:05:00Z

Continuing along the lines of the “say what you mean“ style of programming, let's look at a naming convention for certain types of functions which more accurately reflects what they mean. Last time, we saw a function for adding two 128 bit numbers:

int128 sum_of_128bit_numbers(int128 x,int128 y)
{
    int128 z;
    z.low = x.low + y.low;
    z.high = x.high + y.high;
    if (z.low < x.low)
        ++z.high;
    return z;
}

and some code which calls it:

    z = sum_of_128bit_numbers(x,y);

One way we can improve this is to write the function as an overloaded operator:

int128 operator+(int128 x,int128 y)
{
    int128 z;
    z.low = x.low + y.low;
    z.high = x.high + y.high;
    if (z.low < x.low)
        ++z.high;
    return z;
}

Then the syntax to call it is just:

    z = x + y;

which I'm sure you'll agree is much simpler, especially when you have lots of overloaded operators and a complex expression. Which would you rather read/write/review/maintain, this:

    z = x*x + y*y;

or this:

    z = sum_of_two_128_bit_numbers(product_of_two_128_bit_numbers(x,x),product_of_two_128_bit_numbers(y,y));

Programmers who are used to a programming language which doesn't offer operator overloads tend to be rather horrified at this concept the first time they see it (I know I was). They say things like “but this means I can't tell what even the simplest pieces of code really do just by looking at them”. I'd argue that this ability is overrated. Modern programming is all about abstraction. We don't need to know every single detail about what's going on in a particular line of code. We don't need to know the mechanics of how addition works to understand a line of code like:

    z = x + y;

We also don't need to know which registers the compiler decides to assign to which variables (if we did we'd be writing in assembly language, not C++). Nor do we need to know how numbers are represented in binary by the computer's hardware, nor the details of the logic gates and transistors used in the CPU's addition circuitry, nor the voltage levels in the processor nor any one of a million little details which all have to work out in order that we can add two numbers. All we need to know is the highest level concept - we're adding these two numbers. And that fact is best expressed by the statement:

    z = x + y;

Now, I do agree that it is possible to abuse that power and write code which is almost impossible to follow, for example by writing an “operator+” function that does something entirely different from addition. But you can write bad code in any language. You can do similarly evil things even in C:

int128 sum_of_128bit_numbers(int128 x,int128 y)
{
    int128 z;
    // Haha! We lied and will actually XOR the two numbers!
    z.low = x.low ^ y.low;
    z.high = x.high ^ y.high;
    return z;
}

The problem here is that the function doesn't do what it says, not that operator overloading is intrinsically evil. The name “operator+“ is just that - a name. It's a name which implies certain things about the semantics of the function in question, just like any good name should. It also allows callers of this code to employ certain syntactic sugar - they can write:

    z = x + y;

instead of:

    z = operator+(x,y);

(The latter is completely valid C++ code, by the way, though rarely more appropriate than the former).

There is one other argument against operator overloading - that is that it makes it more difficult to see the performance bottlenecks in a program. Maybe you have an “operator+” which adds large matrices together, and could potentially be quite slow if the matrices are large. You wouldn't necessarily expect a simple “x+y” expression to be slow, if you're used to programming in C where such expressions typically cause the compiler to emit only one or two machine language instructions.

The counter-argument is that we should not expect the names of functions to reflect how long they take to run (otherwise we'd be writing functions with names like “add_two_128bit_numbers_takes_about_20_cycles_to_run”) which would be a maintainance nightmare (imagine if every time you changed the implementation of a function you had to change the name of that function and every function that called it!). No, use the right tool for the job - visually inspecting a program isn't the right way to figure out where the performance bottlenecks are. Use a profiler instead.

std::cout << "Hello, World!" << std::endl;

2004-07-29T23:02:00Z

Hello! My name is Andrew Jenner and I'm a Software Design Engineer (SDE) in the Visual Studio Devices team. I work on IDE functionality for managed projects (though some of the components I have written are also used by the native project system).

However, for the most part this blog isn't going to be about programming for Smart Devices, programming for the .NET Compact Framework or even .NET programming in general. Instead I'm going to be writing about what I know best - C++ programming techniques, and general programming techniques that can be applied in most languages.

To start off, here's a programming principle that seems to me to be so fundamental that it is often forgotten: Say what you mean.

What do I mean by this? Well, let's start off with a simple example. Suppose you have some code like this:

#include <iostream>
#include <iomanip>

typedef long long int64;
typedef unsigned long long uint64;

struct int128
{
    int64 high;
    uint64 low;
};

int main()
{
    int128 x={10,20}, y={30,40}, z;

    z.low = x.low + y.low;
    z.high = x.high + y.high;
    if (z.low < x.low)
        ++z.high;

    std::cout << std::hex << std::setw(16) << std::setfill('0') << z.high;
    std::cout << std::setw(16) << std::setfill('0') << z.low << std::endl;
}

What does this code actually do? Well, it may not be obvious at first sight because it doesn't actually say what it does. But compare this slightly modified version:

#include <iostream>
#include <iomanip>

typedef long long int64;
typedef unsigned long long uint64;

struct int128
{
    int64 high;
    uint64 low;
};

int128 sum_of_128bit_numbers(int128 x,int128 y)
{
    int128 z;
    z.low = x.low + y.low;
    z.high = x.high + y.high;
    if (z.low < x.low)
        ++z.high;
    return z;
}

int main()
{
    int128 x={10,20}, y={30,40}, z;

    z = sum_of_128bit_numbers(x,y);

    std::cout << std::hex << std::setw(16) << std::setfill('0') << z.high;
    std::cout << std::setw(16) << std::setfill('0') << z.low << std::endl;
}

Now we can immediately see that this code implements addition of high precision integers. The simple act of naming the 4 mysterious lines of code (by putting them in a function with a descriptive name) has made the program much easier to understand (more so, I would argue, than an equivalent comment that just explains what those 4 lines of code do).

This change doesn't make any difference to the compiler (especially if it implements Named Return Value Optimization or chooses to inline the sum_of_128bit_numbers() function) but it greatly improves the readability of the program for humans. It's easy to write a program that a computer can understand (just change things until it compiles) but writing programs that are easy for people to understand is much more difficult. Since any non-trivial program will eventually need to be maintained, we should strive to make all our code as easy to read by humans as possible.

Andrew Jenner's WebLog

Operator overloading

std::cout << "Hello, World!" << std::endl;