Date: Wed, 30 Apr 2025 10:00:07 -0700
On Wednesday, 30 April 2025 00:59:39 Pacific Daylight Time Tiago Freire via
Std-Proposals wrote:
> Maybe what it needs is some form of “shadow data” and a way to use it, stuff
> that the compiler knows when evaluating things at compile time but that
> doesn’t translate into a tangible thing at runtime. That is effectively
> what compilers must do in order to be able to handle addresses (not just
> function addresses) in a compile time context. How else could you reason
> comparing function addresses at compile time when there are no addresses.
You can compare variable addresses before there are addresses and you can
store them in such a way that they materialise with their true addresseses at
runtime. During constexpr valuation, compilers are already holding far more
information per variable than their actual value, especially so for pointers.
So this should be possible to implement for functions too, with no change to
the runtime.
Std-Proposals wrote:
> Maybe what it needs is some form of “shadow data” and a way to use it, stuff
> that the compiler knows when evaluating things at compile time but that
> doesn’t translate into a tangible thing at runtime. That is effectively
> what compilers must do in order to be able to handle addresses (not just
> function addresses) in a compile time context. How else could you reason
> comparing function addresses at compile time when there are no addresses.
You can compare variable addresses before there are addresses and you can
store them in such a way that they materialise with their true addresseses at
runtime. During constexpr valuation, compilers are already holding far more
information per variable than their actual value, especially so for pointers.
So this should be possible to implement for functions too, with no change to
the runtime.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2025-04-30 17:00:11