On 19/09/2025 17:29, Thiago Macieira via Std-Discussion wrote:
> On Thursday, 18 September 2025 21:09:47 Pacific Daylight Time Yongwei Wu wrote:
>>> Yes, they do. ALL the time, especially in template code but anything that
>>> is not nailed down and may have some generality too. For example,
>>> anything that may depend on a configuration-time feature check. Given we
>>> have the __cpp macros describing the availability of features, this
>>> applies to the C++ Standard too.
>>
>> Arguable, especially if -O0 demonstrates completely different
>> behaviour. I would normally use #if or if constexpr to ensure
>> something is really eliminated, even if optimization is completely
>> turned off.
>
> Who said anything about different behaviour?
>
> The compiler is allowed to remove dead code *because* it's dead and therefore
> not observable. The Standard defines what is observable precisely for this
> reason.
>
> Timing is not observable. Obviously, timing in debug mode builds is VERY
> different from timing in release builds. If timing were observable, then no
> optimisations would be allowed.
>

As a bit of an aside, there is a variant of C called "XC" that is made
by XMOS, specifically for their microcontrollers. It includes timing
constraints as part of the language (along with some other features such
as CSP-style message passing and hardware thread support), intimately
tied to the details of the XMOS devices. It is not something that could
work in a generic programming language for arbitrary devices - it works
because the tools know /exactly/ how long specific instructions take.
Timing constraints are proven by a simulator/checker program, somewhat
akin to Rust's "borrow checker" for checking borrow semantics outside of
the compiler. So it is certainly possible to having aspects of timing
as observable in a programming language, but there are significant
limitations to how it could be done - it is not going to be suitable for
C++.