Why are C++ "complex" functions not member functions?

Question

I was looking at the C++ library <complex>, and noticed that functions such as std::conj and std::norm are free functions i.e. static functions not placed inside the std::complex class. Why is this the case?

I would've thought that, from a C++ OOP design perspective, it would've made more sense to have e.g. complex<T> complex<T>::conj() and complex<T> complex<T>::norm() as methods so that I can call auto norm = z.norm() instead of auto norm = std::norm(z).

Am I missing something about how the standard library is designed which justifies why these functions are free?

Answer 1

Am I missing something about how the standard library is designed which justifies why these functions are free?

The C++ standard library does not exclusively follow the OO design paradigm.

Free functions, when combined with parameter overloading, play much nicer when you are writing templated code that should work with both class types and primitive types.

For example, suppose I have a list of values (either complex, as std::complex<float>, or real, as float) and I want to compare them on magnitude. Then I can write a comparison function like

template <class T>
bool magnitude_less(const T& lhs, const T& rhs)
{
  using std::abs;
  return abs(lhs) < abs(rhs);
}

Writing such a function would not be possible if abs for std::complex<T> would have been a member function based on OO design principles.

Answer 2

There is a school of though that prefers "non-member non-friend" functions, and justifies it in terms of improving code cohesion. I believe the original source for the idea is Effective C++ by Scott Meyers. The example in Bart's answer is a concrete demonstration of how this plays out in practice.

Answer 3

std::complex represents complex numbers, which is a mathematical concept. In mathematics it is customary to write f(x) instead of x.f(). So for more numerical or mathematical code, it is more natural to write norm(z) instead of z.norm(). (Also, there was and is lots of numerical code in C and Fortran, where the syntax goes norm(z).)

(This is in addition to the reasons stated in other answers.)

Answer 4

The basic argument here is that cohesion and reusability is improved if you don't create member functions that don't require access to private data. i.e. can be implemented efficiently using only member functions.

Personally, I think C++ took that philosophy a bit too far, but I also think most libraries take it a bit too far the other way.

For example, consider finding the complex number with the largest magnitude from a list of complex numbers. You can't make this a member function of Complex because it operates on a list. You can make max a member function of List, but it doesn't know how to compare complex numbers. So you have some sort of Ordering interface or type class. You can't just make Complex implement this interface, because of the ISP, but also because you might want to also be able to order a Complex by real component or imaginary component sometimes instead of magnitude.

So where do you put all the Ordering implementations for Complex? Now you have a place that's separate from the Complex class, but still "belongs" to the Complex class.

Most OO programmers don't find that separation strange, because they were syntactically forced into it. But they don't think twice about clumping things together when they aren't forced to separate them, even when there might be a different, more cohesive grouping.

Answer 5

For most users it would be nicer if C++ did the OOP thing(including giving methods to int, float..., but without making everything inherit from some MagicRootObject).

Unfortunately there is a strong dislike for member functions(Herb Sutter even had a GOTW where he bashes 100+ string member functions, as if millions of developers that use string have to implement them instead of use them).

For one example of this usability horror you could check out How to trim a std::string? At least in C++23 string will get a contains member function, only 25 years too late.

Additionally your example is trivial since function has 1 argument, but you can see errors that explode with useless error spam as soon as you use something more complex.

Sure this is technically possible even with member functions, but compiler has an easier time giving you nicer error message since one argument(object instance) is known.