[Discuss-gnuradio] gr-fec: why BOOST_CONSTEXPR_OR_CONST?

[Michael Dickens]

I have a MacPorts ticket requesting that I enable CTRLPORT, which
requires Thrift, which was recently updated to 0.10.0 in MacPorts -- so
I thought it worth a try again to see if it works.

Thrift requires C++11 for building, which means that "gnuradio
+ctrlport" will also require C++11. Easy enough, or so I thought, by
forcing CMake to use C++11 via using the right compiler and adding
"-DCMAKE_CXX_STANDARD=11" as a commandline argument.

This combination works well until it reaches gr-fec, which errors out
due to a BOOST_CONSTEXPR_OR_CONST declaration that's valid C++ when it
is "const" ... but the C++ code isn't valid for a "constexpr", which
requires that the variable value be defined in the declaration.

gr-fec/include/gnuradio/fec/polar_decoder_common.h:70
{{{
      private:
        static BOOST_CONSTEXPR_OR_CONST float D_LLR_FACTOR;
}}}

gr-fec/lib/polar_decoder_common.cc:37
{{{
      const float polar_decoder_common::D_LLR_FACTOR = -2.19722458f;
}}}

Looks like D_LLR_FACTOR was correctly defined to work with the
"constexpr" or "const" version of BOOST_CONSTEXPR_OR_CONST in <
https://github.com/gnuradio/gnuradio/commit/a1cf11937665392bcfa223a5095ff903eb44c69b
> by Jaroslav Škarvada, and then broken in <
https://github.com/gnuradio/gnuradio/commit/a981e6a18c4f28cc6058fef4167c01ad3dc7d58a
> by Josh Blum.

In my searching, the code above is the -only- place where a "constexpr"
is potentially used. Thus, can we please just get rid of it and use
"const" instead? Why the need for a constexpr here and no other place?

One can work around this issue by defining BOOST_NO_CXX11_CONSTEXPR, but
the code should be able to build without this workaround.

Thoughts? Comments? - MLD