Add macro DUNE_CONSTEXPR_ASSERT

In C++11 and with not fully C++14 compliant compilers constexpr functions can only have a return statement. This prevents the use of assert() inside of constexpr functions. This macro can be used as a workaround like this:

  constexpr auto foo(int a, int b, x)
  {
    return CONSTEXPR_ASSERT(a<b), x;
  }

For NDEBUG there is no penalty. Otherwise there are two options:

• In a non-constexpr context an assert() will fail if the condition is not matched. The error message will be slightly different from a classic assertion.
• In a constexpr context the assert() branch will be ignored if the is condition is matched. Otherwise this will lead to a compile error (like static_assert) because the branch using assert() is not constexpr.

Added 1 commit:

• 10fc71b3 - Use DUNE_CONSTEXPR_ASSERT

Reassigned to @christi

Looks good. The syntax is bit counter-intuitive, but OK. One suggestion... wouldn't it be better to write something like

constexpr auto foo(int a, int b, x)
{
    RETURN_WITH_ASSERT(a<b, x);
}

The syntax you proposed was in fact my first try. However, the proposed one seemed more intuitive to me. A normal assert(c) mimics a function call. If this would really be true and if this function would be constexpr you could use

constexpr auto foo(int a, int b, x)
{
  return assert(a<b), x;
}

The proposed macro tries to hack around those shortcomings keeping the syntax. But with the proper macro name that you proposed, I like the other syntax equally well.

Is this for 2.5? Do you mind merging?

Mentioned in merge request !142 (merged)

I implemented the syntax proposed by @christi in !142 (merged) using a slightly different name for the macro. I'm undecided about the syntax, but I tend to prefer !142 (merged) over this one because its easier to explain. @christi,@gruenich: You are the only ones who showed interest in this, which one do you prefer?

I don't mind. In any case I would have to look up the syntax anyway and both seems logical.

You are the only ones who showed interest in this, which one do you prefer?

I believe that for average users the new version !142 (merged) is easier to grasp.

Then let's go with this one.

Status changed to closed

Superseded by !142 (merged)

Mentioned in commit 1410d4a9