Re: constexpr keyword is unnecessary

Em 10/19/2024 6:24 PM, Keith Thompson escreveu:

David Brown <david.brown@hesbynett.no> writes:

On 19/10/2024 17:18, Thiago Adams wrote:

Em 10/18/2024 8:54 PM, Keith Thompson escreveu:

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

I think constexpr keyword is unnecessary.

>
Sure, most language features are strictly unnecessary.
>

Anything you do with it could/should be done with const.

>
No, absolutely not.
>

If not, do you have a sample where, using "const" as "constexpr",
would create problems?
The sample I know is VLA.
const int c = 2;
int a[c]; //a is VLA because c is not a constant expression.
But this is not enough to convince me because it is better not to be
a VLA here.
>

>
What practical difference would it make?  Can you think of any
difference between local variables "a" and "b" defined like this?
>
enum { n = 2 };
const int c = n;
int a[c];
int b[n];
>
Can you show any situation where you could use "a" and not "b", or
vice versa, or where the meaning would be different?  Can you show any
compiler that treats them differently in code generation (assuming a
compiler that supports enough of C99 to allow it)?
>
I know of no differences there.  That is enough to convince me that it
doesn't matter in the slightest whether it is technically a VLA or
not.

 VLAs are optional in C11 and later.  A conforming implementation that
doesn't support VLAs will accept `int b[n];` and reject `int a[c];`.
 `sizeof a` is not a constant expression, so it can't be used in a case
label or any other context that requires a constant expression.  (If
`const int c = n;` made c a constant expression, this would not apply.)
 Generated code for constructs that a compiler acccepts is likely to be
identical.  For a VLA type with a non-constant length, the compiler must
implicitly store the size somehow.  For a VLA type with a length that
the compiler can evaluate at compile time, the compiler is likely to
generate code equivalent to that for a non-VLA.
 

All positive changes from "not working" to "working", from "working in runtime" to "working at compile time."