Skip to content

Function parameters

Hannes Hauswedell edited this page Jan 25, 2017 · 4 revisions

In parameters shall be const &

In-Parameters (those that come with a value that may not be modified) shall be passed as T const & except if they are POD, in which case you may use T const.

There is one exception!

If you need to copy an in-parameter inside your function, instead do this in the parameter construction so you don't needlessly copy temporaries:

This always involves a copy:

void (T const & in)
{
  T myCopy{in};
  myCopy.foo = 7;
  // ...
}

This otoh might use the move-constructor of T to prevent a copy:

void (T in)
{
  in.foo = 3;
  // ...
}

In-out parameters shall be &

In-Out-Parameters (those that come with a value which will be modified) shall be passed as T &.

Out parameters shall be return values

This is a big difference to SeqAn2!

SeqAn2:

void foobar(T & out1, T2 & out2, T3 & inOut, T4 const & in, TTag const & /**/)
{
  // ...
}

// ...

T out;
T2 out2;
foobar(out, out2, ...);

SeqAn3:

auto foobar(T3 & inOut, T4 const & in, TTag const & /**/)
{
  T out1;
  T2 out2;

  // ...

  return { out1, out2 };
}

// ...

T out;
T2 out2;
std::tie(out, out2) = foobar( ...); // move assignment

// ... OR via structured bindings:
auto [out, out2] = foobar( ...);    // (N)RVO

This is now possible because we have "named return value optimization" (NRVO) or "guaranteed copy elision" of return values with C++17.

Ordering

The parameter order in function definitions should be

  1. in-out
  2. in
  3. in (tags and pure type parameters)

e.g.

auto foobar(T3 & inOut, T4 const & in, TTag const & /**/)

Every function shall guarantee and be documented in regard to

Thread-Safety

  1. not thread-safe or unknown
  2. re-entrant (safe if called with different parameters)
  3. thread-safe (always safe)

Every function starts with 1., but should at least guarantee 2.

Clone this wiki locally