7

I have a basic (mathematical) vector class, which in my opinion benefits from C++'s operator overloading. Vector-scalar operations are defined as self-modifying functions in the class itself,

class Vec3i {
  Vec3i& operator+=(int const n) {
    for (int i = 0; i < 3; ++i) {
      _data[i] += n;
    }
  }
  std::array<int, 3> _data;
};

and as non-modifying free functions. For these I can see two options when it comes to passing in the vector.

// By value, meaning an implicit copy.
Vec3i operator+(Vec3i lhs, int const rhs) {
  return (lhs += rhs);
}

// By const reference, copying manually.
Vec3i operator+(Vec3i const& lhs, int const rhs) {
  auto result = lhs;
  return (result += rhs);
}

Are there good reasons to prefer one variant over the other? I prefer having the const parameter (const-ing everything that will never be modified), but the by-value variant is nicely concise. Or should I simply start to read by-value as implicitly const?

  • Passing non-retained input arguments as const reference is very idiomatic in C++. If you don't like that style, it would be necessary to overcome that personal taste because it's used by everyone else who write in C++. One must also learn its limitations - what it actually guarantees and what it doesn't. – rwong Dec 16 '14 at 2:02
  • 2
    @rwong: using "const reference" for function parameters in C++ is not more or less idiomatic than just passing parameters by value. It is typically (but not exclusively) used for passing "big" objects to avoid unnecessary copying, but in the example above, a copy is made in both cases. – Doc Brown Dec 16 '14 at 9:00
5

In older C++ (pre C++11), there is no significant difference between your two implementations of operator+. Either the copy constructor gets called when you invoke the operator or when you make the explicit copy inside the operator.
In this case, it is more of a personal preference/coding guideline issue which one to choose.

With the introduction of move constructors in C++11, the pass-by-value case has gained an advantage, because that allows the parameter to be constructed using either the copy constructor or the move constructor, depending on what the operator is being invoked with.
For your Vec3i class, the difference is not that big, but if you have classes that maintain dynamically allocated resources, the proper use of move constructors can significantly reduce the amount of memory that your application needs.

  • Thanks! I'll accept this answer as it is the most detailed, and mentions the difference between C++ and C++11. In this case moving does not require any special syntax on the side of the caller, it only depends on what kind of *value is used there, right? – Kolja Dec 16 '14 at 10:00
  • 1
    @Kolja: That is right. If operator+ is used on an r-value (e.g. the result of a preceding +, - or * operator), then the compiler will automatically try to move. – Bart van Ingen Schenau Dec 16 '14 at 10:41
2

This is probably a bit opinionated, but if I see two equivalent alternatives in code, I typically prefer the one with less "noise". In your case, the difference of the second alternative to the first is only in additional "noise" - technical code which does not improve the readability in any way. That is why I would prefer the first variant.

or should I simply start to read by-value as implicitly const

You should read functions with "by value" arguments as side-effect free, if that is what you meant.

  • Yes, I meant "side-effect free". What the by-value approach is missing for me is some easily readable sign in the signature that says "your stuff won't be messed with here". I only ever looked at const that way, but that is probably because I was only ever taught to pass everything bigger than basic types by reference. – Kolja Dec 16 '14 at 10:07
  • @Kolja: IMHO you should not need an explicit sign for "no side effects here" - writing such functions should be the standard. A sign makes IMHO only sense for parameters for which you expect side effects. But actually C++ misses a good sign for these parameters either. – Doc Brown Dec 16 '14 at 10:55
0

I would go for the take by value approach.

Maybe in this case it does not matter as the Vec3i is cheap to copy, but in general, this would allow the lhs value to be constructed from rvalue with a move constructor, thus removing any copying of objects.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.