Date: Sun, 31 Aug 2025 17:39:29 +0200
On 30/08/2025 01:35, Levo D via Std-Proposals wrote:
> On Fri, Aug 29, 2025 at 11:52:54PM +0100, Jonathan Wakely wrote:
>> On Fri, 29 Aug 2025, 22:43 Levo D via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>>> The goal of my proposal is to have all bounds be checked at compile time.
>>> If I were including containers, the check would be for all containers (and
>>> arrays).
>>> I haven't seen "hardened preconditions," but glancing at P3471R0, it looks
>>> like it's a runtime check, which isn't my goal.
>>>
>>> There isn't anything I could add to that. It'd be helpful if that proposal
>>> went through, since
>>
>>
>> It is already part of C++26 and already available in shipping compilers.
>
> What can I look up for more info? Everything I seen says runtime.
It is normal for optimising compilers to do runtime checks at compile
time if the values are all known at compile time. This is basically
"constant propagation" optimisation - when the compiler sees "if (x <
y)" and it knows that the values of "x" and "y" are constants, it will
pre-calculate the condition to get "if (true)" or "if (false)". It will
then eliminate the condition and the not-taken branch.
This is more powerful than having things /require/ compile-time
evaluation, because sometimes compilers can simplify expressions even
when the parts are not all constants. Compilers can use range
information to evaluate conditionals even when exact values are not known.
Of course compilers are not omniscient, and their optimisations are not
omnipotent - but they do tend to get better over time. If the standards
make demands on this kind of thing, it can limit what you can write in
code, limit what compilers can do when targeting simpler and faster
compilation rather than greater runtime efficiency, and sometimes even
limit the optimisations available for runtime improvements.
I am not sure if this is the kind of thing Jonathan is alluding too, but
you should understand that just because something is specified as
"runtime", does not mean compilers can't handle it at compile time.
> On Fri, Aug 29, 2025 at 11:52:54PM +0100, Jonathan Wakely wrote:
>> On Fri, 29 Aug 2025, 22:43 Levo D via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>>> The goal of my proposal is to have all bounds be checked at compile time.
>>> If I were including containers, the check would be for all containers (and
>>> arrays).
>>> I haven't seen "hardened preconditions," but glancing at P3471R0, it looks
>>> like it's a runtime check, which isn't my goal.
>>>
>>> There isn't anything I could add to that. It'd be helpful if that proposal
>>> went through, since
>>
>>
>> It is already part of C++26 and already available in shipping compilers.
>
> What can I look up for more info? Everything I seen says runtime.
It is normal for optimising compilers to do runtime checks at compile
time if the values are all known at compile time. This is basically
"constant propagation" optimisation - when the compiler sees "if (x <
y)" and it knows that the values of "x" and "y" are constants, it will
pre-calculate the condition to get "if (true)" or "if (false)". It will
then eliminate the condition and the not-taken branch.
This is more powerful than having things /require/ compile-time
evaluation, because sometimes compilers can simplify expressions even
when the parts are not all constants. Compilers can use range
information to evaluate conditionals even when exact values are not known.
Of course compilers are not omniscient, and their optimisations are not
omnipotent - but they do tend to get better over time. If the standards
make demands on this kind of thing, it can limit what you can write in
code, limit what compilers can do when targeting simpler and faster
compilation rather than greater runtime efficiency, and sometimes even
limit the optimisations available for runtime improvements.
I am not sure if this is the kind of thing Jonathan is alluding too, but
you should understand that just because something is specified as
"runtime", does not mean compilers can't handle it at compile time.
Received on 2025-08-31 15:39:35