On 12/4/25 13:06, Kamalesh Lakkampally via Std-Proposals wrote:
> Hello All,
>
> Today, in standard C++, the control-flow structure of a function is always /statically bounded/.
>
> Even if there are multiple possible branches, all possible successor functions are known at compile-time.
> For example:
>
> |function1 → function2 → function3 ↘ function4 |
>
> Here the compiler knows that |function2| can transfer control only to:
>
> * |function3|, or
>
> * |function4|.
>
> This is a fundamental assumption behind C++:
>
> *All possible control-flow destinations are statically known, even if the choice is dynamic.*

Let me disagree with that generality here. Certainly, calls through function
pointers or virtual functions have, in general, a statically-unknown target.

From the other sub-thread:

> for (auto&& task : task_list) {
> task();
> }

If you wish to optimize that case, assuming that a task itself doesn't know
its successor, then I'd suggest you do the research what can actually be
achieved on current CPUs, given the constraints you have, before you ask
the C++ committee for standardizing the unknown. Make yourself a few
(opaque) tasks, make a task_list, inspect the generated assembly instructions,
think about how the assembly could possibly improve, triple-check
the measurements about any performance gains, and document your findings.

My understanding is that current CPUs have quite some machinery in their
branch predictors to optimize call/return patterns, but given the
dynamic nature of your problem, I'm not seeing how you can avoid
the "call (or jmp) through function pointer" fundamental penalty.

Once you've done all that research, you still have to overcome the obstacle
of "bang for the buck": Is your super-special case worth the committee time
to standardize anything about it? Can you demonstrate your special case
isn't so special? Or that we need to invest very little?

Jens