Use if constexpr macro instead of condition macro.

[awulkiew]

This PR replaces uses of BOOST_GEOMETRY_CONDITION with BOOST_GEOMETRY_CONSTEXPR if possible and it is not destructive to readability.

Unfortunately it as less straightforward than I thought it would be because with MSVC and level 4 warnings enabled "unreachable code" warning is generated of some code exists outside if constexpr block. In such case an additional else block has to be added to prevent the warning. This means there are more blocks and indentations.

Constexpr conditions has to be checked separately from regular conditions. This means that some of the code has to be repeated e.g. if it has to be executed for both compile-time or run-time condition. This also can add more blocks and indentations.

For the reasons above I left BOOST_GEOMETRY_CONDITION in formulas because code like this:

if (Foo == 0)
{
   return bar;
}
// update bar
if (Foo == 1)
{
   return bar;
}
// update bar
etc.

would force me to add else brackets. Unless we agreed to write if constexpr differently than "regular" ifs, with different brackets placement, indentations, etc. I can't think of any way that would look good.

So if you think that some of the changes look bad feel free to point it out so I'll revert it to BOOST_GEOMETRY_CONDITION.

[barendgehrels]

-> 2024

(it's about the next line, but you can ignore this comment)

[barendgehrels]

Can this (and similar) made CONSTEXPR as well? Apart from needing the else branch, but you did that elsewhere too
Scratch that, it was already in the description of the PR

[barendgehrels]

I'm OK with this change.

I made a remark about the copyright (sometimes 2023, sometimes 2024) but it's not important, and maybe you started it already last year.

[barendgehrels]

Thanks for the change

[awulkiew]

I made a remark about the copyright (sometimes 2023, sometimes 2024) but it's not important, and maybe you started it already last year.

Yes, I made the majority of changes last year and came back to it now. I was forced to resolve some conflicts so I updated the dates accordingly.

[vissarion]

this is also change the behavior e.g. the block

            tp.operations[0].operation = operation_intersection;
            tp.operations[1].operation = operation_blocked;
            *out++ = tp;
            //tp.operations[0].operation = operation_intersection;
            tp.operations[1].operation = operation_intersection;
            *out++ = tp;

was executed in all cases but now only in touch or append_colinnear_opposite cases.

Is this intentional?

[awulkiew]

If there is any change in behavior it was not intentional. But AFAIU there is no change here. We're talking about the block below at line 607(old) or 622(new) correct? In the old version it was executed:

if ( is_q_spike
  && ( BOOST_GEOMETRY_CONDITION(is_version_touches)
    || inters.d_info().arrival[1] == 1 ) )

now it's executed if output_spike is true and this is set in block:

if (is_q_spike)

and only

if BOOST_GEOMETRY_CONSTEXPR (is_version_touches)

or

else if (inters.d_info().arrival[1] == 1) // Version == append_collinear_opposite

For convenience here is the old version and the new version.

Or am I missing something?

[vissarion]

OK, I was looking only at the changes and thought you were fixing something. It is clear that you just rewrote it, and it is actually simpler this way. So, everything is fine here.

[vissarion]

LGTM, thanks!

[vissarion]

this is probably here by mistake.

[awulkiew]

yes, fixed