Date: Mon, 25 Aug 2025 14:04:14 -0700
Now we completely agree on the meaning of constexpr. I just was
trying to explain that C++ users in general seem to need to be told it
doesn't do much.
"it forced clang to execute sort at runtime so there was no runtime
call to sort."
Do you have a link or something that proves that? You might know
something I don't. But that is the only thing we disagree over. My
testing indicated that clang will actually execute the entire sort
routine using its "constant folding" pass:
https://llvm.org/doxygen/ConstantFolding_8h.html
If you contrive the right test you can cause clang to stop constant
folding right in the middle of folding a function down to nothing. So
I could get clang to generate only the bottom half of a call to
insertion sort. After that the compiler just seems to declare
"whatever" and leave the rest of the sort call to the runtime.
On Mon, Aug 25, 2025 at 11:24 AM Ivan Matek <libbooze_at_[hidden]> wrote:
>
>
>
> On Mon, Aug 25, 2025 at 5:54 PM Adrian Johnston <adrian3_at_[hidden]> wrote:
>
>>
>> I am not suggesting the standard somehow defined constexpr to do
>> nothing at all. What I am saying is there is a distinction between
>> "it can be evaluated at compile time" and "the code generator will
>> more thoroughly evaluate it at compile time than any other code if it
>> doesn't have to." Can you show me an example of constexpr resulting in
>> better code generation at runtime (and not compile time?)
>
>
> That is not what constexpr is for when applied to function. constexpr does not mean: optimizer try to generate better codegen for this function.
> It means (for functions): this function can be called at compile time. Now that in itself may generate better code,
> as we saw with the sort example I provided, it forced clang to execute sort at runtime so there was no runtime call to sort.
> Not because std::sort is constexpr, but because variable was constexpr. Now obviously to initialize variable that required std::sort to be constexpr,
> what I am saying is that important part of constexpr is what I wrote before:
> when I see
> constexpr auto var = ...
>
> I know var is computed at compile time or compilation will fail.
>
>>
>>
>> Ok, but I have been writing C++ for 20 years and I still don't have
>> any idea what people are doing running all this code C++ at compile
>> time. I know of examples from numerical computing that are
>> compelling. My only use case failed horribly and silently. Yeah, sure
>> constexpr is better than template meta programming, but that wasn't a
>> problem we had all day long.
>
>
> If you problems do not require constexpr do not use constexpr.
> If you are not sure if your problems benefit from constexpr check out some respected open source libraries related to your problem and see
> if they use constexpr or google some blog articles/cppcon talks, e.g High Performance Message Dispatch - Luke Valenty
>
> But there is no requirement for you to use every feature of the language.
>
>
>
>
>
On Mon, Aug 25, 2025 at 11:24 AM Ivan Matek <libbooze_at_[hidden]> wrote:
>
>
>
> On Mon, Aug 25, 2025 at 5:54 PM Adrian Johnston <adrian3_at_[hidden]> wrote:
>
>>
>> I am not suggesting the standard somehow defined constexpr to do
>> nothing at all. What I am saying is there is a distinction between
>> "it can be evaluated at compile time" and "the code generator will
>> more thoroughly evaluate it at compile time than any other code if it
>> doesn't have to." Can you show me an example of constexpr resulting in
>> better code generation at runtime (and not compile time?)
>
>
> That is not what constexpr is for when applied to function. constexpr does not mean: optimizer try to generate better codegen for this function.
> It means (for functions): this function can be called at compile time. Now that in itself may generate better code,
> as we saw with the sort example I provided, it forced clang to execute sort at runtime so there was no runtime call to sort.
> Not because std::sort is constexpr, but because variable was constexpr. Now obviously to initialize variable that required std::sort to be constexpr,
> what I am saying is that important part of constexpr is what I wrote before:
> when I see
> constexpr auto var = ...
>
> I know var is computed at compile time or compilation will fail.
>
>>
>>
>> Ok, but I have been writing C++ for 20 years and I still don't have
>> any idea what people are doing running all this code C++ at compile
>> time. I know of examples from numerical computing that are
>> compelling. My only use case failed horribly and silently. Yeah, sure
>> constexpr is better than template meta programming, but that wasn't a
>> problem we had all day long.
>
>
> If you problems do not require constexpr do not use constexpr.
> If you are not sure if your problems benefit from constexpr check out some respected open source libraries related to your problem and see
> if they use constexpr or google some blog articles/cppcon talks, e.g High Performance Message Dispatch - Luke Valenty
>
> But there is no requirement for you to use every feature of the language.
>
>
>
>
>
trying to explain that C++ users in general seem to need to be told it
doesn't do much.
"it forced clang to execute sort at runtime so there was no runtime
call to sort."
Do you have a link or something that proves that? You might know
something I don't. But that is the only thing we disagree over. My
testing indicated that clang will actually execute the entire sort
routine using its "constant folding" pass:
https://llvm.org/doxygen/ConstantFolding_8h.html
If you contrive the right test you can cause clang to stop constant
folding right in the middle of folding a function down to nothing. So
I could get clang to generate only the bottom half of a call to
insertion sort. After that the compiler just seems to declare
"whatever" and leave the rest of the sort call to the runtime.
On Mon, Aug 25, 2025 at 11:24 AM Ivan Matek <libbooze_at_[hidden]> wrote:
>
>
>
> On Mon, Aug 25, 2025 at 5:54 PM Adrian Johnston <adrian3_at_[hidden]> wrote:
>
>>
>> I am not suggesting the standard somehow defined constexpr to do
>> nothing at all. What I am saying is there is a distinction between
>> "it can be evaluated at compile time" and "the code generator will
>> more thoroughly evaluate it at compile time than any other code if it
>> doesn't have to." Can you show me an example of constexpr resulting in
>> better code generation at runtime (and not compile time?)
>
>
> That is not what constexpr is for when applied to function. constexpr does not mean: optimizer try to generate better codegen for this function.
> It means (for functions): this function can be called at compile time. Now that in itself may generate better code,
> as we saw with the sort example I provided, it forced clang to execute sort at runtime so there was no runtime call to sort.
> Not because std::sort is constexpr, but because variable was constexpr. Now obviously to initialize variable that required std::sort to be constexpr,
> what I am saying is that important part of constexpr is what I wrote before:
> when I see
> constexpr auto var = ...
>
> I know var is computed at compile time or compilation will fail.
>
>>
>>
>> Ok, but I have been writing C++ for 20 years and I still don't have
>> any idea what people are doing running all this code C++ at compile
>> time. I know of examples from numerical computing that are
>> compelling. My only use case failed horribly and silently. Yeah, sure
>> constexpr is better than template meta programming, but that wasn't a
>> problem we had all day long.
>
>
> If you problems do not require constexpr do not use constexpr.
> If you are not sure if your problems benefit from constexpr check out some respected open source libraries related to your problem and see
> if they use constexpr or google some blog articles/cppcon talks, e.g High Performance Message Dispatch - Luke Valenty
>
> But there is no requirement for you to use every feature of the language.
>
>
>
>
>
On Mon, Aug 25, 2025 at 11:24 AM Ivan Matek <libbooze_at_[hidden]> wrote:
>
>
>
> On Mon, Aug 25, 2025 at 5:54 PM Adrian Johnston <adrian3_at_[hidden]> wrote:
>
>>
>> I am not suggesting the standard somehow defined constexpr to do
>> nothing at all. What I am saying is there is a distinction between
>> "it can be evaluated at compile time" and "the code generator will
>> more thoroughly evaluate it at compile time than any other code if it
>> doesn't have to." Can you show me an example of constexpr resulting in
>> better code generation at runtime (and not compile time?)
>
>
> That is not what constexpr is for when applied to function. constexpr does not mean: optimizer try to generate better codegen for this function.
> It means (for functions): this function can be called at compile time. Now that in itself may generate better code,
> as we saw with the sort example I provided, it forced clang to execute sort at runtime so there was no runtime call to sort.
> Not because std::sort is constexpr, but because variable was constexpr. Now obviously to initialize variable that required std::sort to be constexpr,
> what I am saying is that important part of constexpr is what I wrote before:
> when I see
> constexpr auto var = ...
>
> I know var is computed at compile time or compilation will fail.
>
>>
>>
>> Ok, but I have been writing C++ for 20 years and I still don't have
>> any idea what people are doing running all this code C++ at compile
>> time. I know of examples from numerical computing that are
>> compelling. My only use case failed horribly and silently. Yeah, sure
>> constexpr is better than template meta programming, but that wasn't a
>> problem we had all day long.
>
>
> If you problems do not require constexpr do not use constexpr.
> If you are not sure if your problems benefit from constexpr check out some respected open source libraries related to your problem and see
> if they use constexpr or google some blog articles/cppcon talks, e.g High Performance Message Dispatch - Luke Valenty
>
> But there is no requirement for you to use every feature of the language.
>
>
>
>
>
Received on 2025-08-25 21:04:28