Boost logo

Boost :

From: Ivan Matek (libbooze_at_[hidden])
Date: 2021-08-24 18:33:10


On Tue, Aug 24, 2021 at 6:01 PM Robert Ramey via Boost <
boost_at_[hidden]> wrote:

> I guess if it doesn't work, it's not valid. Certainly from what little
> user documentation there is - cpp reference, there's no information on
> this topic. My user case looks like:
>
> template<typename T>
> struct interval {
> T m_min;
> T m_ max;
> interval(const T & min, const T & max) :
> m_min(min),
> m_max(max)
> {}
> }
>
> template<typename T>
> constexpr interval<T> get_interval(const T & t) {
> return std::is_constant_evaluated()
> ? interval<T>(t, t); // we know the value of t at compile time
> so the range is effectively [t, t]
> : interval<T>(std::numeric_limits<T>::min(),
> std::numeric_limits<T>::min()); // otherwise we won't know the value
> until runtime so it could be in the range [...]
> ;
> }
>
> So I'm returning different values depending on whether we're compiling
> or execution. In fact, if we know the value of t at compile time, the
> runtime code will never be executed. So there would never be an
> ambiguity, but of course the compiler can't see that so maybe that's why
> the compiler is unhappy with this.
>
Still not 100% clear what bigger goal is, for me example code compiles
<https://www.godbolt.org/z/sbKGh53ec> when I make constructor constexpr.
I presume you want to use the returned interval to construct some types(for
example something like safe_signed_range ) and that is where the problems
may occur.
As far as I know this is impossible in C++, to have constexpr arguments,
unless you use them as template arguments, e.g. func<3>(), but if you have
func(3) there is no way to get that 3 during compile time.
So even if this new boost macro is added that will not help you since even
if compiler knows that 3 is 3 it will not let you to use it at compile time
due to C++ language rules <https://www.godbolt.org/z/hWPTGvPss>.
So I am not an expert, but I think it is indeed not possible to do what you
want.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk