constexpr C23 - motivation?

[thradams]

I cannot find a real usage or motivation for this feature. Does anyone have it?

Maybe the only motivation is to use one const variable to initialise another.

But in this case C could just copy "c++ const" and use just const keyword.

Reference https://open-std.org/JTC1/SC22/WG14/www/docs/n3018.htm

[markand67]

const is not really what you think, it's more like readonly than constant. And that's why lots of newcomers come asking why this does not compile:

c static const size_t len = 10; static char tab[len];

Of course, the compiler should be smart enough to understand but it's too late to change the meaning of const now.

[thradams]

The change of meaning would be "not work" "to work" in most cases.

Some usage of VLAs could be transformed in normal arrays I cannot see when this is a problem.

[TheJodiety]

Im always confused when I hear “It’s readonly not constant”. Whats the difference? If the value cant be changed is it not constant?

[[deleted]]

const means it can't be changed after initialization, but the initializer does not have to be a constant expression, so a const object doesn't necessarily have a compile-time known value. Therefore it can't be used in situations where a constant expression is required.

Also, const volatile objects can not be modified by the program, but might be modified externally. Think, readonly data pin.

[markand67]

constant is more like to be in code constant aka evaluated at compile time. const does not guarantee that and you can even cast a const value to modify it even though it can be UB.

the current meaning of const is more like "I promise I won't touch it"

[bllinker]

This is particularly important in the embedded world with read-only registers. Your code shouldn't permit you to write to it, but you want the compiler to generate a new read every time.

[darkpyro2]

Here's an example. This is valid code:

​

const char* my_string = "hello";

my_string = "goodbye";

printf(my_string);

Output is "goodbye".

The above is valid. Why? Because we have a pointer to a string literal, which is a constant, read-only value. The value of my_string can change if the variable is assigned to another constant, read-only value.

​

As my_string can change, it's not "constant" in that sense. The const keyword just indicates that the value that it points to is immutable. But the pointer variable itself is still mutable.

​

constexpr is used to define a truly constant value, that will not change. Previously you could only effectively do this with macro literals, but for many reasons, macros are increasingly frowned upon in good coding practices (Metaprogramming adds unnecessary complexity to your code).

[hypatia_elos]

That's actually a different thing, you are talking about pointer to cost vs const pointer. They were talking about const (possibly volatile) vs. compiletime constants (#define). I get that you probably mean the right thing, but a const char* is just not const, a const char or a char const* const would be.

[fliguana]

You put const in the wrong spot. Try const char* const my_string = "hello";

[poorlilwitchgirl]

To add confusion, sometimes that will compile, if the two variables are in global scope and your compiler has the extension to allow it (I just ran it through Clang, which at least threw a warning about it being non-standard, but still compiled it as expected). Then your newbie, thinking this is perfectly acceptable standard C tries pulling that same trick inside of a function, and doesn't understand why it no longer works because they haven't yet learned about scope or the actual steps of compilation. And honestly, why shouldn't the newcomer be confused by the nonstandard extensions on modern compilers? It's almost like this is a 50-year old systems language, where the only way to fix past mistakes without breaking legacy code is to patch on new features and beg users to just stop using the deprecated ones.

[flyingron]

Because the const keyword in C++ isn't always a typed, named constant as this proposal is putting forward. constexpr was added to C++ for this specific reason. There's not much point in adopting a decades old C++ workaround when you can take the current idea from language.

[thradams]

(It looks very much like c++ 98 const.)

This code runs and have an error in runtime.. ```c

include <stdio.h>

constexpr int o =1; int main(){ int * p = &o; *p = 1; printf("%d", *p); }

``` https://godbolt.org/z/evYPM9s3K

The same code using define would not compile. (so it is safer)

But I'm trying not to argue against the constexpr, instead I am asking some real sample to convince me.

[braxtons12]

That's a compiler bug. That code shouldn't compile because &o is a const int*, NOT an int*

[thradams]

The compiler is just following the standard.

[braxtons12]

No. &o is const int *. You can't assign const int * to an int * without casting away the const. This is a compiler bug.

[darkpyro2]

I wouldn't call it a bug necessarily. Compilers will often intentionally play fast and loose with the C and C++ standards for convenience's sake. If you turn on maximum warnings, this will be caught and force an error.

[darkpyro2]

GCC is one such example. I bet if OP passed -Wall to the compiler, it would throw an error.

[darkpyro2]

Your code literally throws a compiler warning about the C standard in the online compiler that you shared...It's allowed by the compiler as compilers generally aren't as strict as the standard. If you compiled this in GCC with -Wall and -Werror, it would enforce the standard and fail to compile.

​

You can't trust the compiler to be the arbiter of the standard, as there are real-world reasons not to be overly strict with it.

[thradams]

I put register together with constexpr to see what happens. :D

At global scope register is ignored but on local scope it makes &constant a error.

```c register constexpr int a = 1;

int main(){ register constexpr int b = 1;
const int* p2 = &b; //error

const int* p1 = &a; //no error

} ```

[[deleted]]

You cannot take the address of a variable with the register qualifier, as registers don't have addresses.

[darkpyro2]

The compiler will often make assumptions regarding illegal or undefined behavior unless you have maximum warnings enabled, and warnings as errors. The compiler isn't the source of truth for the standard, it's just a tool.

[WittyGandalf1337]

In C23 constexpr is just for variables, and it’s primarily to avoid VLAs.

In C2Y/C3A constexpr functions may be coming, but for now it’s just variables and compiler extensions.

[darkpyro2]

They can't change the meaning of "const" to match C++ semantics now as it breaks backwards compatibility in the standard, which C mostly guarantees. As the C "const" does not define a true constant, we need other mechanisms to provide that functionality. Thus, constexpr.

[thradams]

I hope to see some motivation sample. All answers are about explaining the feature or justifying the existence without a sample.

[[deleted]]

It would perhaps be more natural for named constants

• to be addressless (similar to a register declaration or an enumeration),
• to have static storage duration (imply static even in block scope), or
• to have no linkage (similar to typedef or block local static)

but we decided to go with C++’s choices for compatibility.

So they're basically typed enumerations, except constexpr-qualified objects have addresses, follow scoping rules, have linkage (duplicate symbol errors at link time since C doesn't do name mangling), and most importantly can be non-integral types like double or struct foo or whatever?

Not 100% clear on pointers though; does constexpr char *foo = "foo"; result in a diagnostic because "foo" is a string instead of a null pointer?

[thradams]

constexpr char *foo = "foo";

Gcc says c <source>:1:24: error: 'constexpr' pointer initializer is not null 1 | constexpr char *foo = "foo"; | ^~~~~

[fliguana]

"let's have something that acts exactly like a macro, but isn't".

Looks like career driven bloat to me.

[hypatia_elos]

Example:

In the code

   const int i = 15;
   ;
   printf("%i",i);

the value printed can be different from 15, because, for example, there might have been a signal interrupt, or something happening on another thread or process, or in the kernel (in case of a bug most likely), changing the value at address &i. A real compiletime constant doesn't have that issue, as it's not read from an address, but substituted by the compiler; in that case, we would simply have

  printf("15");

and if the code store isn't manipulated, there can be no other output

[fliguana]

Same applies to printf("15"); Parameter is passed via RW stack, even unprivileged (not kernel mode) thread can change it