重载运算符 () 而不是 [] 用于索引

Question

An old code base I'm refactoring has a rather unorthodox way to access n dimensional vectors by overloading the () operator instead of the [] operator.

To illustrate, suppose Vec is a class that overloads both operators for indexing purpose of an internal list of doubles.

Vec v, w;
int index = 651;
double x = v(index);   // they index like this ..
double y = w[index];   // .. instead of like normally..

I can only think of one good reason why you would do this: The operator[] requires an argument of type size_t which may or may not be uint64 depending on the platform. On the other hand, the index type used in the code is mostly int , which would mean a lot of implicit/explicit type casting when indexing. The code is extremely indexing heavy, so I'm quite hesitant to change this.

Does this really makes any sense for todays modern compilers and 64bit platforms? I quickly whipped up a test on https://godbolt.org/ You can try it out here here

I was primarily concerned with the latest x64 gcc and Visual Studio compilers, but the difference is primarily when compiling in x86-64 gcc (11.2). Gcc adds a cdqe instruction for the () operator, which we know may be less efficient .

Hence I am a bit puzzled. Why would one make this choice?

Answer 1

One "problem" with [] is when you have multiple dimensions. With an array you can do arr[val1][val2] , and arr[val1] will give you an array you can index with [val2] . With a class type this isn't as simple. There is no [][] operator so the [val1] needs to return an object that [val2] can be applied to. This means you need to create another type and provide all the functionality you want. With () , you can do data(val1, val2) and no intermediate object is needed.

Answer 2

The operator[] requires an argument of type size_t

This is incorrect. operator[] can accept an operand of any type, including non-integral types. However, the limitation is that it must be a single argument. This may change in a future standard, but if your code is old, it is clearly affected.

Does this really makes any sense for todays modern compilers and 64bit platforms?

Using 32-bit indexes on a 64-bit platform may be beneficial, if you have to store a lot of indexes and don't need the extra range. Keeping your data condensed not only saves memory, but may also improve CPU cache hit rate and increase performance.