Re: question about linker

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

Em 11/28/2024 5:33 PM, Keith Thompson escreveu:

If an object is const because of its definition, then that object is
itself read-only, and anything that bypasses that (pointer casts, etc.)
causes undefined behavior.

>
Yes. This is my point. When the object itself cannot change, I used
the name immutable. And "ready only" when we don´t know if the object
is immutable or not - like pointer to const object.
In any, case it is just a matter of definition. I think it is clear
for both of us. (I am not claiming these definitions are part of C
standard)
>

For compile that computation what matters is the guarantee that the
compiler knows the values (it knows because it always the same value
of initialization) when using the object. (It does not depend on flow
analysis)

There's no requirement for the compiler to "know" the value of a const
object.

>
When the expression is required to be constant expression like in
switch case, then the compiler must know the value.

True, but we weren't talking about constant expressions.  We were
talking about objects of const type.  Despite the obvious similarity of
the words "const" and "constant", they're really two different things.

And the name of an object (in the absence of constexpr) can't be a
constant expression.  Given `const int zero = 0;`, the name `zero` is
not a constant expression and cannot be used in a case label.  (There
are proposals to change that.)

Sorry if I am begin repetitive, but here is my motivation to say that
const was already ready for that, no need to new keyword constexpr.
>
Consider this sample
>
void f(const int a)
{
  const int b = 1;
>
  switch (a){
     case a: break; // OPS
     case b: break; // should be OK
  }
}
>
The compiler does not know the value of 'a' even it is declared as
constant object; on the other hand the compiler knows the value of
'b';
>
So, here is my point - In init-declarators. const and constexpr
becomes similar.

That has been proposed, but I personally oppose it, and the language (as
of C23) doesn't support it.  (C++ does.)

Given:

    const int b = initializer;

the expression `b` would be a constant expression if and only if the
initializer is a constant expression (optionally enclosed in {...}, I
suppose).  It's not always obvious whether an expression is constant or
not; you have to examine everything it refers to.  And if you intend b
to be a constant expression but accidentally write a non-constant
initializer, it's still a perfectly valid declaration of a read-only
object initialized with the result of evaluating a run-time expression;
the error won't be flagged until you try to use it.

Recall that `const int r = rand();` is still perfectly valid.

But given:

    constexpr int b = initializer;

you *know* that b can be used as a constant expression, and if the
initializer is not constant the compiler will flag it immediately.

This is already in C23.  Dropping constexpr is politically impossible at
this point.

[...]

C23 also added constexpr in compound literal.
>
(constexpr struct X ){ }
>
I also don´t understand why not just use const for that.

Because constexpr and const mean different things.

I also allow static.
>
(static const struct X ){ }
>
I think in this case it makes sense.

That's valid in C23.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */