what is a value?

what we can already see:

• equality is less restrictive than identity
  → identical objects are always equal
  → equal objects are not necessarily identical
• equality does not necessarily depend on an objects underlying physical representation
  → e.g. equality can be defined between instances of
       different types
• things are quite simple when dealing with unique values
  → e.g. numbers, strings, dates

is it even correct to get x by reference? NO!

scale(v, v[0])

passing x by reference introduced a hidden dependency,
causing a side-effect in our example

in general with using references we are referring to remote objects,
making the code more complicated, because it prohibits local reasoning

that's where we go much easier with values!

⇓

void scale(std::vector &v, double x)
{
  for (size_t i = 0; i != v.size(); ++i)
    v[i] /= x;
}

why do we so often tend to use references,
even if semantically there is no need to?

because references were always known
to be more efficient

→ c++ devs are used to optimize their code manually
→ sometimes on the cost of code simplicity

the interesting point is:

• with using a reference we declared identity, where we only needed equivalence!

• for the compiler this means our declaration is more restrictive! it has less freedom to optimize

with value semantics we get better code
and take advantage of automatic optimization

"tell the compiler that you are interested in values rather than objects, and the compiler chooses the best tool to implement your intentions"
^{(Andrzej Krzemieński)}

copy elision: When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects.
^{(§12.8.31, ISO C++11 Standard)}

→ copies and moves are made “in principle”, the compiler is allowed to optimize them away

→ regarding the as-if rule, copy/move have predefined semantics

copy/move construction should only be implemented explicitly for:

• RAII classes to encapsulate resources
• implementing optimizations

otherwise the compiler generated ones should be just fine (they simply copy all members on copy and move all members on move)

to be discussed design-wise: prefer rule of zero, rule of five defaults or
defaulted c/d-tors with assign by value?

but!

• make sure your type supports value semantics!
  → make first steps with std types

in general a type's public interface should ensure this:

if (a == b)
{
  op1(a); op1(b); assert(a == b);
  op2(a); op2(b); assert(a == b);
  op3(a); op3(b); assert(a == b);
  op4(a); op4(b); assert(a == b);
}

given two std::vector's differing only in their capacity()

are they equivalent?

..let's have a look at some simpler examples first..

class rational_t {
public:
  int num() const;
  int denom() const;

private:
  ...
};

bool operator==(const rational_t &lhs, const rational_t &rhs)
{
  long long ext_fraction1 = (long long)lhs.num() * rhs.denom();
  long long ext_fraction2 = (long long)rhs.num() * lhs.denom();

  return ext_fraction1 == ext_fraction2;
}

→ asking for salient attributes can be misleading

→   std::vector::capacity() is there for technical reasons only:

• a modified vector could have its capacity always set to its size
• it would just reallocate on every push and pop, but this is an implementation detail
• its observable behavior could not be distinguished from the original vector

→   std::vector::capacity() is an optimization:

• optimizations may be used to overcome drawbacks that arise from certain physical representations
• optimizations must not affect an objects logical state
• an objects logical state must not depend on optimizations

in other words: when a and b are vectors with different capacities,
we still expect the same behavior!

if (a == b)
{
  op1(a); op1(b); assert(a == b);
  op2(a); op2(b); assert(a == b);
  op3(a); op3(b); assert(a == b);
  op4(a); op4(b); assert(a == b);
}

• Shifing polymorphism from type to use allows for greater reuse and fewer dependencies
• Using regular semantics for the common basis operations, copy, assignment, and move helps to reduce shared objects
• Regular types promote interoperability of sofware components, increases productivity as well as quality, security, and performance
• There is no necessary performance penalty to using regular semantics, and ofen times there are performance benefts from a decreased use of the heap