Re: C23 thoughts and opinions

Em 5/25/2024 8:05 AM, David Brown escreveu:

On 25/05/2024 02:27, Thiago Adams wrote:

Em 5/24/2024 5:19 PM, Keith Thompson escreveu:

Thiago Adams <thiago.adams@gmail.com> writes:

On 24/05/2024 16:45, Keith Thompson wrote:

Thiago Adams <thiago.adams@gmail.com> writes:

On 23/05/2024 18:49, Keith Thompson wrote:

error: 'constexpr' pointer initializer is not null
5 |     constexpr char * s[] = {"a", "b"};
>
>
Then we were asking why constexpr was used in that case.

Why not?

>
When I see a constexpr I ask if the compiler is able to compute
everything at compile time. If not immediately it is a bad usage in my
view.

I don't understand.  Do you object because it's not *immediately
obvious* that everthing can be computed at compile time?  If so, why
should it have to be?

>
My understanding is that constexpr is a tip for the compiler. Does not
ensure anything. Unless you use where constant expression is required.
So I don't like to see constexpr  where I know it is not a constant
expression.

>
Your understanding is incorrect.  "constexpr" is not a mere hint.

I think I can explain I little better
>
Let´s consider we have a compile time array of integers and a loop.
>
https://godbolt.org/z/e8cM1KGWT
>
#include <stdio.h>
#include <stdlib.h>
int main() {
     constexpr int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
     for (int i = 0 ; i < sizeof(a)/sizeof(a[0]); i++)
     {
         printf("%d", a[i]);
     }
}
>
What the programmer expected using a constant array in a loop?
The loop is in runtime, unless the compiler expanded the loop into 8 calls using constant expressions. But this is not the case.
This was the usage of constexpr I saw but with literal strings.
So, the array a is not used as constant even if it has constexpr.
>

 The array /is/ constant.  It never changes.  The compiler can use that. I would expect the array to be fixed in the code section of the binary, along with any other read-only data in the program, rather than put on the stack.
 In this particular case, the constexpr makes little difference because the compiler knows everything about what happens to the array "a", since its address does not "escape" from the current translation unit.  The compiler will generate the same code regardless of whether the array is declared "constexpr int", "const int", or plain "int".  (But it can check for accidental modification better with "const" or "constexpr" in case the programmer made a mistake.)
 I am not entirely sure of the specifications for printf, but the compiler may even be able to turn this into:
 int main() {
     printf("12345678");
}
 It is /certainly/ allowed to turn it into :
 int main() {
     for (int i = 1; i < 9; i++) {
         printf("%d", i);
     }
}
 In C (not C++), defining an object as "constexpr" gives you two things compared to defining it as "const".  One is that its value can be used when you need a constant expression according to the rules of the language (such as for the size of an array in a struct).  The other is that it gives a compile-time error if its initialiser is not itself a constant expression - and that means an extra check and protection against some kinds of programmer errors, and extra information to people reading the code.
 I don't expect it to make a difference in generated code from an optimising compiler, in comparison to objects declared with "const".
 

In my view , for this sample constexpr generates noise. It also can make the compilation slower, otherwise, why not everything constexpr by defaul?
I still didn't find a useful usage for constexpr that would compensate the mess created with const, constexpr. I already saw ( I don't have it now ) proposals to make const more like constexpr in C. In C++ const is already a constant expression!
The justification for C was VLA. They should consider VLA not VLA if it has a constant expression. In other words, better break this than create a mess.
#define makes the job of constexpr.