Question

Assume the following toy class, and modern compilers (recent gcc for example).

template <typename T>
class SomeVec {
public:
  ...
  virtual T get(const int index) = 0;
}

The application involves a fair amount of number crunching based on values stored in SomeVec subclasses, T being a primitive type, say int. However, the practice of stl containers and boost::numeric::ublas::vector is to return stored values via (const) reference.

I wondered the performance differences this involve. In this question it is shown that array element access by value and vector element access by reference results in the same code, so I assume the compiler can in some cases optimize stuff away.

Now my questions are:

• (1) stl and ublas are templated, while my solution requires virtual methods. Does this hinder modern compilers’ ability to optimize code?

• (2) If the compiler could not optimize to return the const atomic reference as value, then do I assume it right that the virtual method call and the dereferencing cost approximately the same? Or is one significantly more expensive than the other?

Thanks!

Answer 1

The reason STL returns references is because templated code doesn’t have the luxury of knowing that returned objects are small. While an int is no problem, returning a large struct slows things down for no good reason. In the latter case it only makes sense to use references, and since a reasonable compiler can optimise the case of using primitive types you may as well use references throughout.

Note that your method virtual T get(const int index) differs in other ways to STL container methods. Most importantly, and related to the issue above, your method returns a copy of the indexed object: manipulating the result will not change the state of the object in your container.

Also, declaring the index argument as const does nothing, since you pass index in by value and so all you are doing is preventing yourself from changing index locally within implementation. If you were passing index in by reference that would be a different matter, but you should be wary of doing so.

Finally, are you really sure that your class needs to be dynamically polymorphic (i.e., have virtual methods)? The STL containers are intentionally designed not to be inherited (which is why they do not have virtual destructors). Containers are not meant to provide an interface for derived classes, rather they are there to facilitate an implementation. I would argue that the subclass examples you suggest could just as easily be implemented as wrapper classes around a templated container, favouring code reuse through composition over inheritance (something advocated by the Gang of Four, amongst others). Aside from being good practice, avoiding virtual methods saves having vtables and corresponding pointers in your objects, and requiring the extra vtable lookup in each call. If you don’t really need dynamic polymorphism, why take the cost (and possibly prevent compiler optimisations)?