[C++] constexpr qualifier in static const field getters

[vdidenko]

This is a follow up enhancement to the #195 issue.

I am tailoring the incoming message reaction, and it would be great to use a switch statement in the vein of the structurechart's comment. Similarly to @structurechart I ran into the constexpr requirement.

Would it be possible to discuss a solution similar to the sample commit vdidenko/simple-binary-encoding@fe16a8ce1f1e14916d3ebe363978549a26267d5c? It introduces public constexpr fields and uses them to maintain the getter function signatures.

I have only changed the fields I think I care about, but should I make the pull request similarly modifying all static const declarations touched by the original solution at a601c48?

[vdidenko]

Updated the sample commit reference in the issue with a version which builds without warnings and preserves getters' signatures.

[tmontgomery]

I don't think it is necessary to do all the static const declarations. I am a little leery of the MSVS compiler support on constexpr for this, but I believe it is better to go ahead. As long as the getter signatures are preserved, it should be OK for those currently using it.

[vdidenko]

If the code is OK as is, then I will make it into a PR by separating it from the nested namespaces issue (constexpr support is on the top of the nested namespaces branch by accident, there is no dependency).

[vdidenko]

After reviewing it, it will be easier to make this pull request after the nested namespaces work.

[vdidenko]

@tmontgomery, the PR #355 is posted for a review.

[vdidenko]

Solution to this issue is reasonably challenged in the PR discussion at #355 (comment).

[vdidenko]

@tmontgomery, when you refer to:

add the new statics when it is C++11 and can be constexprs

are you talking about the functions? I thought you did not want to touch their signature at all, or do you mean to have a second function?

[vdidenko]

@rigtorp, yes making current functions constexpr should work, but I was under impression that was not a welcome change at the time of the PR. If I am wrong then it is a simple fix indeed.

[rigtorp]

@tmontgomery @vdidenko I don't think changing const to constexpr if supported by the compiler would cause any issues at all, same ABI etc.

[vdidenko]

I will get the patch out tomorrow - I am late now out of the door. It will be more reliable to be on the same page with a patch in front of us. OK?

[tmontgomery]

@vdidenko no worries. Sorry. What I meant was it might be cleaner to make the static constexpr be dependent on C++11 being used and not even being there if not. Along the lines of:

#if __cplusplus >= 201103L
static constexpr std::uint16_t SbeBlockLength{(std::uint16_t)47};
#endif
static const std::uint16_t sbeBlockLength(void)
{
    return 47;
}
#endif

Edit: that would be backwards compatible with previous codecs.

[rigtorp]

@tmontgomery i think it's better not to add any member variables

This should suffice:

static SBE_CONST_KIND std::uint16_t sbeBlockLength(void)
{
  return 47;
}

With SBE_CONST_KIND defined as currently: const for < c++11 and constexpr for >= C++11.