From Newsgroup: comp.lang.c

I think constexpr keyword is unnecessary.
Anything you do with it could/should be done with const.

Even without const , one object like (struct point){.x=1, .y=0} is a
constant in my view.

So, for instance, no need for (constexpr struct point){.x=1, .y=0} here.

The VLA could have been the motivation for a new keyword, but I don’t
think it matters.

On the other hand, (static struct point){.x=1, .y=0} makes sense.

If constexpr were "no-storage" I think it would make sense but it is not.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 11.10.2024 um 14:25 schrieb Thiago Adams:

I think constexpr keyword is unnecessary.
Anything you do with it could/should be done with const.
Even without const , one object like (struct point){.x=1, .y=0} is a constant in my view.
So, for instance, no need for (constexpr struct point){.x=1, .y=0} here.
The VLA could have been the motivation for a new keyword, but I don’t think it matters.
On the other hand, (static struct point){.x=1, .y=0} makes sense.
If constexpr were "no-storage" I think it would make sense but it is not.

const doesn't replace constexpr. constexpr is when you want to
assure that the variable is compile-time generated. You can't
enforse this constraint with const.
But I find all these attempts to modernize C hopeless. C wants
to remain a minimalist language and is therefore light years
behind other languages. For me, C is intended to be used when
a more advanced lanugage is not available.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/11/2024 3:03 PM, Bonita Montero escreveu:

Am 11.10.2024 um 14:25 schrieb Thiago Adams:

I think constexpr keyword is unnecessary.
Anything you do with it could/should be done with const.
Even without const , one object like (struct point){.x=1, .y=0} is a
constant in my view.
So, for instance, no need for (constexpr struct point){.x=1, .y=0} here.
The VLA could have been the motivation for a new keyword, but I don’t
think it matters.
On the other hand, (static struct point){.x=1, .y=0} makes sense.
If constexpr were "no-storage" I think it would make sense but it is not.

const doesn't replace constexpr. constexpr is when you want to
assure that the variable is compile-time generated. You can't
enforse this constraint with const.

What I am saying is make const do that. No need for a new keyword.

But I find all these attempts to modernize C hopeless. C wants
to remain a minimalist language and is therefore light years
behind other languages. For me, C is intended to be used when
a more advanced lanugage is not available.

constant expression make sense in C. It is not new, it is very old.
The difference now is the extension and this will not make the language
more complicated but more coherent.





--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 11.10.2024 um 20:11 schrieb Thiago Adams:

constant expression make sense in C. It is not new, it is very old.

const has a definition and it allows non compile-time evaluated
variables.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/11/2024 4:17 PM, Bonita Montero escreveu:

Am 11.10.2024 um 20:11 schrieb Thiago Adams:

constant expression make sense in C. It is not new, it is very old.

const has a definition and it allows non compile-time evaluated
variables.

yes. but?

What I am suggesting again is remove the keyword constexpr. make const
do that.

Just to remember C++ was already like that before constexpr. In c++
const could be used as constant expressions.
What C++ could not ensure is that global variables would have a compile
time initialization.
In C all global variables are initialized in compile time.
For local variables like...

const int i = ... ;
the compiler must evaluate the initialization expression if it can be
computed in compile time then i is "constexpr" does not matter if it
have or not the constexpr keyword.



--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 11.10.2024 um 21:30 schrieb Thiago Adams:

Em 10/11/2024 4:17 PM, Bonita Montero escreveu:

Am 11.10.2024 um 20:11 schrieb Thiago Adams:

constant expression make sense in C. It is not new, it is very old.

const has a definition and it allows non compile-time evaluated
variables.

yes. but?

With constexpr you could enforce that the expression you assign is
compile-time evaluated. That's while constexpr would make sense.

What I am suggesting again is remove the keyword constexpr. make const
do that.

Just to remember C++ was already like that before constexpr. In c++
const could be used as constant expressions.
What C++ could not ensure is that global variables would have a compile
time initialization.
In C all global variables are initialized in compile time.
For local variables like...

const int i = ... ;
the compiler must evaluate the initialization expression if it can be computed in compile time then i is "constexpr" does not matter if it
have or not the constexpr keyword.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/12/2024 1:39 AM, Bonita Montero escreveu:

Am 11.10.2024 um 21:30 schrieb Thiago Adams:

Em 10/11/2024 4:17 PM, Bonita Montero escreveu:

Am 11.10.2024 um 20:11 schrieb Thiago Adams:

constant expression make sense in C. It is not new, it is very old.

const has a definition and it allows non compile-time evaluated
variables.

yes. but?

With constexpr you could enforce that the expression you assign is compile-time evaluated. That's while constexpr would make sense.

This is already the default in C for file scope variables and places
where constant expression are required like enums.

Let's see local variables, that may or may not have a compile time value.

For instance


int main(){
const int a = 1;
constexpr int i = a; //error
}

i must be initialized with a constant expressions.
What I am suggesting is

const int a = 1; // is a constant expression
const int i = a; // is a constant expression


Note that C++ is already like that


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 12.10.2024 um 15:23 schrieb Thiago Adams:

With constexpr you could enforce that the expression you assign is
compile-time evaluated. That's while constexpr would make sense.

This is already the default in C for file scope variables ...

They must be optimized away by the compiler and the linker, constexpr
not. And most compile time constants that are constexpr'd in C++ are
local variables. So constexpr makes sense at least for local variables.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 11/10/2024 13:25, Thiago Adams wrote:

I think constexpr keyword is unnecessary.
Anything you do with it could/should be done with const.

Even without const , one object like (struct point){.x=1, .y=0} is a constant in my view.

So, for instance, no need for (constexpr struct point){.x=1, .y=0} here.

The VLA could have been the motivation for a new keyword, but I don’t think it matters.

On the other hand, (static struct point){.x=1, .y=0} makes sense.

If constexpr were "no-storage" I think it would make sense but it is not.

It depends on what constexpr means. Does it mean an expression known at compile-time? (Or at load-time when the expression refers to addresses
of static memory locations that will not change during the program's run.)

Or does it mean the expression will not change after it's mean assigned?

For example:

const int i = rand();
i = rand(); // not (directly) allowed

Further, if the const/constexr is in a loop, or anywhere in a function
where it can be encountered a million times, can the expression be
different each time? Example:

while (1) {
const i = rand();
constexpr j = rand(); // if legal
}

C has a problem with named constants, which are variously implemented
with #define, enum and const, none of which do the whole job, although
enum comes closest.

So where does constexpr fit into all that?

This table refers to examples like '#define A 100', 'eval {B=200}', and
'const int C=300'; Y is the desirable answer in each case:

#define enum const
Scope rules N Y Y
Any type Y N Y
& is an error Y Y N
Value fixed Y Y N (can be changed via casts)
Array bounds Y Y N (statics/module scope)
Array bounds Y Y N to avoid VLAs
Case labels Y Y N
Context free N Y Y (to do with macro expansion)
Fixed eval time Y Y Y

The last one is to do with how long it takes the compiler to evaluate
the expression, which is normally negligible.

'const int C=X' depends on how long X takes at runtime.

But 'constexpr int C=X' can depend on how long X takes at compile-time.

What does the column for constexpr look like for the other attributes?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/12/2024 10:52 AM, Bonita Montero escreveu:

Am 12.10.2024 um 15:23 schrieb Thiago Adams:

With constexpr you could enforce that the expression you assign is
compile-time evaluated. That's while constexpr would make sense.

This is already the default in C for file scope variables ...

They must be optimized away by the compiler and the linker, constexpr
not. And most compile time constants that are constexpr'd in C++ are
local variables. So constexpr makes sense at least for local variables.

If you are afraid your constant is not constant expression put a static_assert. Then remove.
And this makes sense only in local scope.

(C++ is a TOTAL mess. const in C++ already could be used n constant expression)

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/12/2024 10:53 AM, Bart escreveu:

It depends on what constexpr means.

It means the initialization expression must be evaluated at compilation.
Also the declarator can be used in another expression as constant.

Sample
constexpr int a = 1;
constexpr int b = a+1;

But the expression is always something the compiler need to check if is constant or not.

So, what I suggest is if the init expression is a constant expression (something we know at compile time) then the declarator is real
constexpr (no need for a new keyword)

For instance:

const int a = 1;
const int b = a+1;


Even if not constant, the compiler can do at compile time.
for instance.
int a = 1+2;
So this has to be done anyway.
The only difference is that using 'a' cannot be used as constant in
another expression.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 12/10/2024 22:43, Thiago Adams wrote:

Em 10/12/2024 10:53 AM, Bart escreveu:

It depends on what constexpr means.

It means the initialization expression must be evaluated at compilation.
Also the declarator can be used in another expression as constant.

Sample
constexpr int a = 1;
constexpr int b = a+1;

But the expression is always something the compiler need to check if is constant or not.

So, what I suggest is if the init expression is a constant expression (something we know at compile time) then the declarator is real
constexpr (no need for a new keyword)

For instance:

const int a = 1;
const int b = a+1;

Even if not constant, the compiler can do at compile time.
for instance.
int a = 1+2;
So this has to be done anyway.
The only difference is that using 'a' cannot be used as constant in
another expression.

So it looks like const/constexpr do different things, for example:


const int a = rand(); // OK
constexpr int b = rand(); // error

How about this:

static int x;
const int* p = &x; // OK
constexpr int* q = &x; // ??

q's value isn't known at compile-time.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 12.10.2024 um 23:37 schrieb Thiago Adams:

If you are afraid your constant is not constant expression put a static_assert. Then remove.

This is unnecessary work if you have constexpr.

(C++ is a TOTAL mess. const in C++ already could be used n constant expression)

C++ is five to ten times less work for the same problem.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/13/2024 7:51 AM, Bonita Montero escreveu:

Am 12.10.2024 um 23:37 schrieb Thiago Adams:

If you are afraid your constant is not constant expression put a
static_assert. Then remove.

This is unnecessary work if you have constexpr.

I can say the same of putting constexpr.
And it makes everything more confusing.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/13/2024 6:52 AM, Bart escreveu:

On 12/10/2024 22:43, Thiago Adams wrote:

Em 10/12/2024 10:53 AM, Bart escreveu:

It depends on what constexpr means.

It means the initialization expression must be evaluated at compilation.
Also the declarator can be used in another expression as constant.

Sample
constexpr int a = 1;
constexpr int b = a+1;

But the expression is always something the compiler need to check if
is constant or not.

So, what I suggest is if the init expression is a constant expression
(something we know at compile time) then the declarator is real
constexpr (no need for a new keyword)

For instance:

const int a = 1;
const int b = a+1;


Even if not constant, the compiler can do at compile time.
for instance.
int a = 1+2;
So this has to be done anyway.
The only difference is that using 'a' cannot be used as constant in
another expression.

So it looks like const/constexpr do different things, for example:

  const int a = rand();              // OK
  constexpr int b = rand();          // error

Yes.
constexpr is like - "require the initializer to be a constant
expression." But the compiler will have to check it anyway.

What I am suggesting is:

If the compiler is going to check anyway, after check, if the
initializer is a constant expression, then transfer this property
"compile time" to the variable automatically. Then no need for a new
keyword.

One justification for the usage of constexpr could be , if constexpr is
not present then we can skip this compile time check. But most C
compiler will do optimization anyway.

How about this:

  static int x;
  const int* p = &x;                // OK
  constexpr int* q = &x;            // ??

q's value isn't known at compile-time.

Addresses can be only initialized with 0 in C.
constexpr int* q = 0; //ok



--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 13.10.2024 um 13:32 schrieb Thiago Adams:

Em 10/13/2024 7:51 AM, Bonita Montero escreveu:

Am 12.10.2024 um 23:37 schrieb Thiago Adams:

If you are afraid your constant is not constant expression put a
static_assert. Then remove.

This is unnecessary work if you have constexpr.

I can say the same of putting constexpr.
And it makes everything more confusing.

Absolutely not, it's easy to read.
With your minimalism mindset you cannot cope with modern demands.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 13.10.2024 um 13:37 schrieb Thiago Adams:

Yes.
constexpr is like - "require the initializer to be a constant
expression." But the compiler will have to check it anyway.

I cannot understand why you are so militantly against this
new language feature that can be understood in 10 seconds.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/13/2024 8:49 AM, Bonita Montero escreveu:

Am 13.10.2024 um 13:37 schrieb Thiago Adams:

Yes.
constexpr is like - "require the initializer to be a constant
expression." But the compiler will have to check it anyway.

I cannot understand why you are so militantly against this
new language feature that can be understood in 10 seconds.

I have seen code like this:

void func()
{
constexpr int c = 1;
f(c);
}

For some reason, people believe that adding constexpr will magically
improve optimization. In reality, it doesn't change anything compared to
const and often reflects a misunderstanding of how the compiler works.
As a result, I end up having to explain it. In this sense, constexpr is
viral and spreads confusion.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 13.10.2024 um 14:38 schrieb Thiago Adams:

Em 10/13/2024 8:49 AM, Bonita Montero escreveu:

Am 13.10.2024 um 13:37 schrieb Thiago Adams:

Yes.
constexpr is like - "require the initializer to be a constant
expression." But the compiler will have to check it anyway.

I cannot understand why you are so militantly against this
new language feature that can be understood in 10 seconds.

I have seen code like this:

void func()
{
   constexpr int c = 1;
   f(c);
}

For some reason, people believe that adding constexpr will magically
improve optimization. In reality, it doesn't change anything compared to const and often reflects a misunderstanding of how the compiler works.
As a result, I end up having to explain it. In this sense, constexpr is viral and spreads confusion.

constexpr doesn't hurt.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On Sun, 13 Oct 2024 09:38:04 -0300
Thiago Adams <thiago.adams@gmail.com> wrote:

Em 10/13/2024 8:49 AM, Bonita Montero escreveu:

Am 13.10.2024 um 13:37 schrieb Thiago Adams:

Yes.
constexpr is like - "require the initializer to be a constant
expression." But the compiler will have to check it anyway.

I cannot understand why you are so militantly against this
new language feature that can be understood in 10 seconds.

I have seen code like this:

void func()
{
constexpr int c = 1;
f(c);
}

For some reason, people believe that adding constexpr will magically
improve optimization. In reality, it doesn't change anything compared
to const and often reflects a misunderstanding of how the compiler
works. As a result, I end up having to explain it. In this sense,
constexpr is viral and spreads confusion.

I see constexpr primarily as a way to enable use of functions from
math.h in static initializers.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/13/2024 9:58 AM, Bonita Montero escreveu:

Am 13.10.2024 um 14:38 schrieb Thiago Adams:

Em 10/13/2024 8:49 AM, Bonita Montero escreveu:

Am 13.10.2024 um 13:37 schrieb Thiago Adams:

Yes.
constexpr is like - "require the initializer to be a constant
expression." But the compiler will have to check it anyway.

I cannot understand why you are so militantly against this
new language feature that can be understood in 10 seconds.

I have seen code like this:

void func()
{
    constexpr int c = 1;
    f(c);
}

For some reason, people believe that adding constexpr will magically
improve optimization. In reality, it doesn't change anything compared
to const and often reflects a misunderstanding of how the compiler
works. As a result, I end up having to explain it. In this sense,
constexpr is viral and spreads confusion.

constexpr doesn't hurt.

It spreads confusion, and makes code incompatible with previous versions
of C "for free".




--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/13/2024 10:06 AM, Michael S escreveu:

On Sun, 13 Oct 2024 09:38:04 -0300
Thiago Adams <thiago.adams@gmail.com> wrote:

Em 10/13/2024 8:49 AM, Bonita Montero escreveu:

Am 13.10.2024 um 13:37 schrieb Thiago Adams:

Yes.
constexpr is like - "require the initializer to be a constant
expression." But the compiler will have to check it anyway.

I cannot understand why you are so militantly against this
new language feature that can be understood in 10 seconds.

I have seen code like this:

void func()
{
constexpr int c = 1;
f(c);
}

For some reason, people believe that adding constexpr will magically
improve optimization. In reality, it doesn't change anything compared
to const and often reflects a misunderstanding of how the compiler
works. As a result, I end up having to explain it. In this sense,
constexpr is viral and spreads confusion.

I see constexpr primarily as a way to enable use of functions from
math.h in static initializers.

Maybe you are thinking in C++? C does not have compile time functions.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 13.10.2024 um 15:09 schrieb Thiago Adams:

Em 10/13/2024 9:58 AM, Bonita Montero escreveu:

Am 13.10.2024 um 14:38 schrieb Thiago Adams:

Em 10/13/2024 8:49 AM, Bonita Montero escreveu:

Am 13.10.2024 um 13:37 schrieb Thiago Adams:

Yes.
constexpr is like - "require the initializer to be a constant
expression." But the compiler will have to check it anyway.

I cannot understand why you are so militantly against this
new language feature that can be understood in 10 seconds.

I have seen code like this:

void func()
{
    constexpr int c = 1;
    f(c);
}

For some reason, people believe that adding constexpr will magically
improve optimization. In reality, it doesn't change anything compared
to const and often reflects a misunderstanding of how the compiler
works. As a result, I end up having to explain it. In this sense,
constexpr is viral and spreads confusion.

constexpr doesn't hurt.

It spreads confusion, ...

It can be understood in 10s.

... and makes code incompatible with previous versions of C "for free".

New improvements are always incompatible and there are mature C23
compilers.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On Sun, 13 Oct 2024 10:10:19 -0300
Thiago Adams <thiago.adams@gmail.com> wrote:

Em 10/13/2024 10:06 AM, Michael S escreveu:

On Sun, 13 Oct 2024 09:38:04 -0300
Thiago Adams <thiago.adams@gmail.com> wrote:

Em 10/13/2024 8:49 AM, Bonita Montero escreveu:

Am 13.10.2024 um 13:37 schrieb Thiago Adams:

Yes.
constexpr is like - "require the initializer to be a constant
expression." But the compiler will have to check it anyway.

I cannot understand why you are so militantly against this
new language feature that can be understood in 10 seconds.

I have seen code like this:

void func()
{
constexpr int c = 1;
f(c);
}

For some reason, people believe that adding constexpr will
magically improve optimization. In reality, it doesn't change
anything compared to const and often reflects a misunderstanding
of how the compiler works. As a result, I end up having to explain
it. In this sense, constexpr is viral and spreads confusion.

I see constexpr primarily as a way to enable use of functions from
math.h in static initializers.

Maybe you are thinking in C++? C does not have compile time functions.

I'd expect that in the next standard a wide subset of math functions
would be allowed in constexp.
In C++ they become constexpr in C++23. If no unexpected difficulties
shows up in C++ then C would be next.




--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 13.10.2024 15:14, Bonita Montero wrote:

Am 13.10.2024 um 15:09 schrieb Thiago Adams:

Em 10/13/2024 9:58 AM, Bonita Montero escreveu:

Am 13.10.2024 um 14:38 schrieb Thiago Adams:

Em 10/13/2024 8:49 AM, Bonita Montero escreveu:

constexpr doesn't hurt.

It spreads confusion, ...

It can be understood in 10s.

I doubt that. - If you need a technical term for some "internal"
requirement you typically need a lot of background information
that (usually?) is pointless to a programmer.

What do I (in my role as a solution programmer) gain from it?

In that role specifically, but also generally, I think that
everything that a programming language can do under the hood
should not be a (concept-)burden to the programmer.

(Note that I'm not arguing against it.)

... and makes code incompatible with previous versions of C "for free".

New improvements are always incompatible and there are mature C23
compilers.

What do I (in my role as a solution programmer) gain from it?
Is it "necessary" (as the topic formulates it)?

Is it reasonable to subsume it with the "const" keyword, as the
OP suggests. - I am honestly asking, and interested in whether
that makes sense or not. (Yet I haven't seen a clear answer, or
maybe I have missed it.)

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 13.10.2024 um 15:35 schrieb Janis Papanagnou:

On 13.10.2024 15:14, Bonita Montero wrote:

It can be understood in 10s.

I doubt that. - ...

LOL

What do I (in my role as a solution programmer) gain from it?

More expressive code.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/13/2024 10:29 AM, Michael S escreveu:

On Sun, 13 Oct 2024 10:10:19 -0300
Thiago Adams <thiago.adams@gmail.com> wrote:

Em 10/13/2024 10:06 AM, Michael S escreveu:

On Sun, 13 Oct 2024 09:38:04 -0300
Thiago Adams <thiago.adams@gmail.com> wrote:

Em 10/13/2024 8:49 AM, Bonita Montero escreveu:

Am 13.10.2024 um 13:37 schrieb Thiago Adams:

Yes.
constexpr is like - "require the initializer to be a constant
expression." But the compiler will have to check it anyway.

I cannot understand why you are so militantly against this
new language feature that can be understood in 10 seconds.

I have seen code like this:

void func()
{
constexpr int c = 1;
f(c);
}

For some reason, people believe that adding constexpr will
magically improve optimization. In reality, it doesn't change
anything compared to const and often reflects a misunderstanding
of how the compiler works. As a result, I end up having to explain
it. In this sense, constexpr is viral and spreads confusion.

I see constexpr primarily as a way to enable use of functions from
math.h in static initializers.

Maybe you are thinking in C++? C does not have compile time functions.

I'd expect that in the next standard a wide subset of math functions
would be allowed in constexp.
In C++ they become constexpr in C++23. If no unexpected difficulties
shows up in C++ then C would be next.

Let´s say we have

double i = sin(1);

adding constexpr

constexpr double i = sin(1);

makes sin(1) to be evaluated in compile time.

**BUT**, I may want to compute sin(1) even without making i const.

double i = sin(1);

This shows another incoherence.

The desire of pre compute the function in compile time should not be
dependent of the declarator being const.

So, in this case I would create a _Static_eval.

double i = _Static_eval(sin(1));

This feature is not competing with const creating two ways of doing
something. (like constexpr is doing)


This is a complement to the language to force compile time computation
in cases the expression is not required to be a constant expression.




--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 13.10.2024 15:47, Bonita Montero wrote:

Am 13.10.2024 um 15:35 schrieb Janis Papanagnou:

On 13.10.2024 15:14, Bonita Montero wrote:

It can be understood in 10s.

I doubt that. - ...

LOL

What do I (in my role as a solution programmer) gain from it?

More expressive code.

This is not the least convincing. Since you seem to express only a language/compiler-internal theme, not any application programmers'
demand.

Regarding "expressiveness" (on the programmer's level) the OP's
suggestion (to use "const") is fine already, and probably better
than introducing a new keyword thus (unnecessarily?) complicating
the matter. - That's why I (honestly) asked for a concrete gain,
to understand whether it's maybe necessary for reasons that are
not yet obvious (to me).

But I take your elusion concerning my question as a meta-answer
that there is no gain. So don't bother.

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 13.10.2024 um 16:33 schrieb Janis Papanagnou:

This is not the least convincing. Since you seem to express only a language/compiler-internal theme, not any application programmers'
demand.

I don't understand how people can argue so desperately against a
feature that is so simple and that makes the code more readable.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/13/2024 11:41 AM, Bonita Montero escreveu:

Am 13.10.2024 um 16:33 schrieb Janis Papanagnou:

This is not the least convincing. Since you seem to express only a
language/compiler-internal theme, not any application programmers'
demand.

I don't understand how people can argue so desperately against a
feature that is so simple and that makes the code more readable.

C programmers care about C simplicity.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 13.10.2024 16:41, Bonita Montero wrote:

Am 13.10.2024 um 16:33 schrieb Janis Papanagnou:

This is not the least convincing. Since you seem to express only a
language/compiler-internal theme, not any application programmers'
demand.

I don't understand how people can argue so desperately against a
feature that is so simple and that makes the code more readable.

I'm aware that you are obviously in battle-mode and thus completely
missed that I'm not "against a feature" but just try to understand
the rationale for that. - Again you evaded answering that question,
and I see my suspicion confirmed that there is no gain.

For me, writing int i = 0; and const int i = 0; is perfectly
readable, and (unnecessarily!) adding another keyword degrades
readability.

As a programmer I expect a compiler to be able to detect constant
expressions, I don't want to litter my program code with technical
constructs to individually tell - on a per-statement basis - the
compiler that a specific constant expression should be evaluated
during compile-time and not postponed to run-time. To support a
simple compiler I think it's okay to instruct him explicitly to
spend more effort pre-evaluating constant expressions, say be a
compiler option. But certainly not by spreading keywords across
the code thereby making the code _less readable_.

(And, as you can derive from what I wrote, I find '_Static_eval'
also not increasing readability.)

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 13.10.2024 um 16:52 schrieb Thiago Adams:

Em 10/13/2024 11:41 AM, Bonita Montero escreveu:

Am 13.10.2024 um 16:33 schrieb Janis Papanagnou:

This is not the least convincing. Since you seem to express only a
language/compiler-internal theme, not any application programmers'
demand.

I don't understand how people can argue so desperately against a
feature that is so simple and that makes the code more readable.

C programmers care about C simplicity.

Not at this level.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 13.10.2024 um 17:03 schrieb Janis Papanagnou:

For me, writing int i = 0; and const int i = 0; is perfectly
readable, and (unnecessarily!) adding another keyword degrades
readability.

The difference is that for local variable const can be overridden
since this const is only logical constness but not physical const-
ness. This minimalist mindset is simply no longer up to date and,
considering the simplicity of the feature, simply absurd.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 2024-10-11, Thiago Adams <thiago.adams@gmail.com> wrote:

What I am suggesting again is remove the keyword constexpr. make const
do that.

Just to remember C++ was already like that before constexpr. In c++
const could be used as constant expressions.

Really?

const int f(int x) { ... }

says that calls to f can be evaluated at compile time?
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/13/2024 1:39 PM, Kaz Kylheku escreveu:

On 2024-10-11, Thiago Adams <thiago.adams@gmail.com> wrote:

What I am suggesting again is remove the keyword constexpr. make const
do that.

Just to remember C++ was already like that before constexpr. In c++
const could be used as constant expressions.

Really?

const int f(int x) { ... }

says that calls to f can be evaluated at compile time?

I am comparing what C have so far. Only variables not functions.

Sample

const int s = 4;
int a[s];

This was always valid in C++.



--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 13.10.2024 um 19:39 schrieb Thiago Adams:

Em 10/13/2024 1:39 PM, Kaz Kylheku escreveu:

On 2024-10-11, Thiago Adams <thiago.adams@gmail.com> wrote:

What I am suggesting again is remove the keyword constexpr. make const
do that.

Just to remember C++ was already like that before constexpr. In c++
const could be used as constant expressions.

Really?

   const int f(int x) { ... }

says that calls to f can be evaluated at compile time?

I am comparing what C have so far. Only variables not functions.

Sample

const int s = 4;
int a[s];

This was always valid in C++.

For local variables the constness can be casted away in C++.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 2024-10-13, Thiago Adams <thiago.adams@gmail.com> wrote:

Em 10/13/2024 1:39 PM, Kaz Kylheku escreveu:

On 2024-10-11, Thiago Adams <thiago.adams@gmail.com> wrote:

What I am suggesting again is remove the keyword constexpr. make const
do that.

Just to remember C++ was already like that before constexpr. In c++
const could be used as constant expressions.

Really?

const int f(int x) { ... }

says that calls to f can be evaluated at compile time?

I am comparing what C have so far. Only variables not functions.

What C has so far is just lagging behind the C++ constexpr.

constexpr has to be consistent for variables and functions and
everything else.

Can you do it all with const, while retaining backward compatibility of programs that don't know anything about the new constexpr meaning
of const?

I am deeply skeptical.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/13/2024 3:21 PM, Kaz Kylheku escreveu:

On 2024-10-13, Thiago Adams <thiago.adams@gmail.com> wrote:

What I am suggesting again is remove the keyword constexpr. make const >>>> do that.

Related:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3333.htm


I believe clang is already extending const power in more scenarios.

https://godbolt.org/z/h1ha5jfPn

struct X{
int i;
};

int main()
{
const struct X x2 = (struct X){.i=1};
static_assert(x2.i == 1);
}


https://godbolt.org/z/EW797PjEq
struct X{
int i;
};

int main()
{
const int a[] = {1, 2};
const struct X x2 = (struct X){.i=a[0]};
static_assert(x2.i == 1);
}


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 10/13/2024 6:51 AM, Bonita Montero wrote:

Am 12.10.2024 um 23:37 schrieb Thiago Adams:

If you are afraid your constant is not constant expression put a
static_assert. Then remove.

This is unnecessary work if you have constexpr.

(C++ is a TOTAL mess. const in C++ already could be used n constant
expression)

C++ is five to ten times less work for the same problem.

How do you measure "work'?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 15.10.2024 um 05:30 schrieb DFS:

On 10/13/2024 6:51 AM, Bonita Montero wrote:

Am 12.10.2024 um 23:37 schrieb Thiago Adams:

If you are afraid your constant is not constant expression put a
static_assert. Then remove.

This is unnecessary work if you have constexpr.

(C++ is a TOTAL mess. const in C++ already could be used n constant
expression)

C++ is five to ten times less work for the same problem.

How do you measure "work'?

In lines of code. Imagine you would specialize a container like
unordered_map by hand in C. That would be days of work. In C++
it's one line of code and you get nearly optimal performance.
Or just think about what an emplace_back on a vector of strings
all does; if the capacity isn't sufficient a doubled vector is
allocated (libstdc++, libc++), all objects are moved there and
a new item is emplaced at the end. That's one line of code, but
in C that's a half day's work.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 15/10/2024 12:41, Bonita Montero wrote:

Am 15.10.2024 um 05:30 schrieb DFS:

On 10/13/2024 6:51 AM, Bonita Montero wrote:

Am 12.10.2024 um 23:37 schrieb Thiago Adams:

If you are afraid your constant is not constant expression put a
static_assert. Then remove.

This is unnecessary work if you have constexpr.

(C++ is a TOTAL mess. const in C++ already could be used n constant
expression)

C++ is five to ten times less work for the same problem.

How do you measure "work'?

In lines of code. Imagine you would specialize a container like
unordered_map by hand in C. That would be days of work. In C++
it's one line of code and you get nearly optimal performance.
Or just think about what an emplace_back on a vector of strings
all does; if the capacity isn't sufficient a doubled vector is
allocated (libstdc++, libc++), all objects are moved there and
a new item is emplaced at the end. That's one line of code, but
in C that's a half day's work.

Sure, because every time you start a new C app, you're starting from zero.

There are no existing libraries to use. No online examples to use as templates. There are no examples of hashtables or growable arrays that
you've implemented over decades of your own work to draw from.

There is NOTHING.

In reality it isn't like that.

Use of C++ does have the advantage when posting bits of code in on-line forums, since there are a much larger number of /standard/ libraries
that someone running your code will have access to in their
installation, if the code fragment happens to use them.

Posted C code using a non-standard library would be problematical.
That's probably why C code that use a hash-map, for example, may need to
come with its implementation so it may appear to have a higher line count.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 15/10/2024 10:01, Bart wrote:

On 15/10/2024 12:41, Bonita Montero wrote:

Am 15.10.2024 um 05:30 schrieb DFS:

On 10/13/2024 6:51 AM, Bonita Montero wrote:

Am 12.10.2024 um 23:37 schrieb Thiago Adams:

If you are afraid your constant is not constant expression put a
static_assert. Then remove.

This is unnecessary work if you have constexpr.

(C++ is a TOTAL mess. const in C++ already could be used n constant >>>>> expression)

C++ is five to ten times less work for the same problem.

How do you measure "work'?

In lines of code. Imagine you would specialize a container like
unordered_map by hand in C. That would be days of work. In C++
it's one line of code and you get nearly optimal performance.
Or just think about what an emplace_back on a vector of strings
all does; if the capacity isn't sufficient a doubled vector is
allocated (libstdc++, libc++), all objects are moved there and
a new item is emplaced at the end. That's one line of code, but
in C that's a half day's work.

Sure, because every time you start a new C app, you're starting from zero.

There are no existing libraries to use. No online examples to use as templates. There are no examples of hashtables or growable arrays that you've implemented over decades of your own work to draw from.

There is NOTHING.

In reality it isn't like that.

Use of C++ does have the advantage when posting bits of code in on-line forums, since there are a much larger number of /standard/ libraries
that someone running your code will have access to in their
installation, if the code fragment happens to use them.

Posted C code using a non-standard library would be problematical.
That's probably why C code that use a hash-map, for example, may need to come with its implementation so it may appear to have a higher line count.

I think C could be improved a lot with something like ChatGPT to create parametrized containers.

I was planing to create something (not as advanced of course) but
something I could just write "create a vector of int" "create map of
strings to int" , "create single linked list" etc.




--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 15.10.2024 um 15:11 schrieb Thiago Adams:

I think C could be improved a lot with something like ChatGPT to create parametrized containers.

Don't usse ChatGPT except for simple code snippets.
With 50 lines or above you get a lot of mistakes.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 2024-10-15, Bart <bc@freeuk.com> wrote:

Sure, because every time you start a new C app, you're starting from zero.

There are no existing libraries to use. No online examples to use as templates. There are no examples of hashtables or growable arrays that you've implemented over decades of your own work to draw from.

There is NOTHING.

In reality it isn't like that.

Use of C++ does have the advantage when posting bits of code in on-line forums, since there are a much larger number of /standard/ libraries
that someone running your code will have access to in their
installation, if the code fragment happens to use them.

C++ standard libraries are such shit that it's standard practice
for any organization to to have its own locally developed libraries.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 15.10.2024 um 22:31 schrieb Kaz Kylheku:

C++ standard libraries are such shit that it's standard practice
for any organization to to have its own locally developed libraries.

Can you give a code example and describe why C++ STL is bad with that ?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 15.10.2024 15:11, Thiago Adams wrote:

On 15/10/2024 10:01, Bart wrote:

On 15/10/2024 12:41, Bonita Montero wrote:

On 10/13/2024 6:51 AM, Bonita Montero wrote:

C++ is five to ten times less work for the same problem.

(I have no numbers, but agree in the general point you make.)

In lines of code. Imagine you would specialize a container like
unordered_map by hand in C. That would be days of work. In C++
it's one line of code and you get nearly optimal performance.
Or just think about what an emplace_back on a vector of strings
all does; if the capacity isn't sufficient a doubled vector is
allocated (libstdc++, libc++), all objects are moved there and
a new item is emplaced at the end. That's one line of code, but
in C that's a half day's work.

Sure, because every time you start a new C app, you're starting from
zero.

Sadly, considering the practical consequences, yes. (See below.)

(And irony isn't helpful, Bart.)

There are no existing libraries to use. No online examples to use as
templates. There are no examples of hashtables or growable arrays that
you've implemented over decades of your own work to draw from.

There are, a lot! - And since there's no standard everyone's writing
his/her own, or copies *any* hack from "anyone". - It appears to me
like seen with shareware and freeware tools; you can choose between
plenty of contributions, rarely one well designed and none portable.
Some alleviation of the issue is sometimes achieved by use of some "quasi-standard" libraries that have been established, but that is
neither guaranteed to be existing (in the first place) nor reliable
when used.[*]) And you can also have "fun" if you assemble different
source code packages where each is coming with it's own version of (non-standard) container functionality.

[...]

Posted C code using a non-standard library would be problematical.
That's probably why C code that use a hash-map, for example, may need
to come with its implementation so it may appear to have a higher line
count.

[...]

I was planing to create something (not as advanced of course) but
something I could just write "create a vector of int" "create map of
strings to int" , "create single linked list" etc.

That's what I meant.

I'd still think it's better to look for an (somewhat) "established"
library that appears to be sophisticatedly written and sufficiently
fulfills your (functional and non-functional) requirements. If we
have the source code available, IME, we often [have to] produce yet
another version branch by changing or adding stuff. Or we want (or
have to) write an adapter or abstraction layer.

Existing code alone, Bart, is not addressing the issue. (Even if you
don't have to write the first chunk of some code.) That's missing the
problems.

(The situation is probably to be valued a bit differently in personal
or isolated projects; this may be where you're coming from?)

Using a well-designed standard library is the way to go. - And less
work, as formulated above, for the same problem _in practice_. YMMV.

Janis

[*] Two decades ago, for example, I used (in a Java project context)
a well designed regexp library from a well-known "contributor". There
were a few to choose from. This one was simple to use (no overhead to
provide unnecessary "flexibility"). Two years later another one, a
complex one, became Java standard. - that example is from practical
experience, and don't think the basic question and inherent problems
and practical implications are different in other language contexts
that don't have a well-designed standard library available for all
the elementary things like data structures.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 15.10.2024 22:31, Kaz Kylheku wrote:

C++ standard libraries are such shit that it's standard practice
for any organization to to have its own locally developed libraries.

What's your problem with it? (I mean; given that you're just cussing.)

Personally I started coding C++ in professional contexts before STL
was available, let alone in a standardized way; each Unix context had
its own quirks using the first predecessors of the standard STL. It
was really overdue that it got available and standardized.

Concerning the library itself its concepts were outstanding. (Other
libraries in other languages often gave the impression of a loosely
mixed set of ad hoc elements.)

I can see a point that it may be considered difficult to find one's
way into understanding it, especially for folks who don't read the
docs and just try to use them unprepared.

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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.

Keep in mind that "const" doesn't mean "constant".

In C, "constant" means (roughly) evaluable at compile time. (And as a
noun, it refers to what many other languages call "literals".)

The "const" keyword means "read-only"; the object it applies to cannot
be modified after it's initialized. The fact that the spelling of
the "const" keyword is derived from the word "constant" has caused a
great deal of confusion. Spelling it as "readonly" rather than "const"
would have avoided most of that confusion.

As of C11, the "const" keyword *never* makes an identifer usable in a
context that requires a constant expression. Given the following:

const int foo = <initializer>;

foo is treated the same way whether the initializer is constant
(e.g., 42) or not (e.g., rand()).

It's unfortunate that C11 doesn't provide a convenient way to define an identifier as a constant expression of any arbitrary type. Adding
constexpr in C23 addresses that problem.

C++ made what was, in my opinion, an unfortunate decision. Given:

const int foo = 42;
const int bar = rand();

the name foo is a constant expression, but bar is not. This feature
(hack, IMHO) was added to C++ at a time that constexpr did not yet
exist.

So in C11, it's easy to explain what "const" means, but in C++ it's more difficult because of that special-case rule.

"const" and "constexpr" do very different things. Conflating those into
a single keyword is not helpful. It might make the language easier to
use in some cases, but it makes it harder to explain. Spelling "const"
as "readonly" would have been an improvement, but it's far too late to
do that.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 19.10.2024 um 01:54 schrieb Keith Thompson:

The "const" keyword means "read-only"; ...

A global const variable isn't even read-only, i.e. it's value is
assumed to be static and never changed. The compiler never reads
it but uses the constant which is assigned as an immediate value.
I.e. if your platform allows you to change-the value through
casting the updated value is never reflected in the other code.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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.



--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On Sat, 19 Oct 2024 12:18:04 -0300
Thiago Adams <thiago.adams@gmail.com> 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.

const int c = 2;
struct bar {
int a[c];
int b;
};


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 19/10/2024 17:03, David Brown wrote:

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.

I can give examples where a compiler won't work, or it will generate
different code, but you won't execpt it because you won't recognise the compiler, or will dismiss it, or will dismiss even gcc because
optimisations aren't used.

If it will always be gcc-O2 or higher, and it is an example just like
these (so inside a function), then probably it will generate the same code.

But that's a lot of 'if's.

Where the code is different, then gcc on Windows for example likes to
generate a call to __chkstack() (to incrementally increase the stack a
page at a time in case it skips a page for a large allocation).


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/19/2024 1:53 PM, Michael S escreveu:

On Sat, 19 Oct 2024 12:18:04 -0300
Thiago Adams <thiago.adams@gmail.com> 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.

const int c = 2;
struct bar {
int a[c];
int b;
};

Yes, but in this case, you're changing something that was previously an
error into something that now works.



--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/19/2024 1:03 PM, David Brown escreveu:

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?

I don't see any practical difference. In theory, the generated code
could be different, but I'm arguing that this doesn't really matter and, consequently, it's not a good reason to differentiate between const and constexpr.





--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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

Em 10/19/2024 1:03 PM, David Brown escreveu:

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?

I don't see any practical difference. In theory, the generated code
could be different, but I'm arguing that this doesn't really matter
and, consequently, it's not a good reason to differentiate between
const and constexpr.

My reasons for not wanting `const int c = 2;` to make c a constant
expression have nothing to do with any theoretical difference in
generated code.

My reason is that "const" and "constant" are two almost entirely
distinct concepts. Conflating them makes the language more confusing.
Making the name of a "const" object a constant expression adds no new capabilities beyone what we already have with "constexpr".

Though the C23 standard hasn't yet been officially released, it's too
late to make any substantive changes. C23 *will* have constexpr, and
*will not* treat const-qualified objects as constants.

If I want a name for a constant expression of type int, I can (in C23)
use "constexpr", which clearly expresses that intent. Using "const"
instead, in all versions of C up to and including C23, will result in compile-time errors.

Let's pretend that when "const" was introduced in C89, it was spelled "readonly", which more closely reflects its meaning. Would you suggest
that

readonly int n = 42;

should make n a constant expression?

What you propose would make n a constant expression if and only if its initializer is constant. In C23, n is a constant expression if and only
if n is defined with "constexpr". If you add "constexpr" to a
declaration whose initializer is not a constant expression, it will be rejected.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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

Em 10/19/2024 1:53 PM, Michael S escreveu:

On Sat, 19 Oct 2024 12:18:04 -0300
Thiago Adams <thiago.adams@gmail.com> 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.

const int c = 2;
struct bar {
int a[c];
int b;
};

Yes, but in this case, you're changing something that was previously
an error into something that now works.

Or you can change something that's an error into something that works in
C23 by typing "constexpr" rather than "const".
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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."



--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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

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

Em 10/19/2024 1:03 PM, David Brown escreveu:

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?

I don't see any practical difference. In theory, the generated code
could be different, but I'm arguing that this doesn't really matter
and, consequently, it's not a good reason to differentiate between
const and constexpr.

My reasons for not wanting `const int c = 2;` to make c a constant
expression have nothing to do with any theoretical difference in
generated code.

My reason is that "const" and "constant" are two almost entirely
distinct concepts. Conflating them makes the language more confusing.
Making the name of a "const" object a constant expression adds no new capabilities beyone what we already have with "constexpr".

I see some differences but not enough to justify a new keyword and I
think it also generates confusion. So it is a matter of choosing what
that of confusion we want.

For instance, in file scope,

const int a = 1;
constexpr int b =1;

In both cases, because it is file scope, a and b need to be initialized
with constant expressions. I don´t see anything more special in b
compared with a to make any distinction.

Though the C23 standard hasn't yet been officially released, it's too
late to make any substantive changes. C23 *will* have constexpr, and
*will not* treat const-qualified objects as constants.

clang is already doing that (Allowing constant variable be used in
compile time). But It may be removed it in the future.
and I understand constexpr is already inside the C23.

If I want a name for a constant expression of type int, I can (in C23)
use "constexpr", which clearly expresses that intent. Using "const"
instead, in all versions of C up to and including C23, will result in compile-time errors.

Let's pretend that when "const" was introduced in C89, it was spelled "readonly", which more closely reflects its meaning. Would you suggest
that

readonly int n = 42;

should make n a constant expression?

What you propose would make n a constant expression if and only if its initializer is constant.

Yes, one of my points is that compilers will have to check whether the initializer is a constant expression anyway. constexpr isn’t helping the compiler or telling it something it doesn’t already know. It’s just telling the compiler to do something it likely would do anyway, even for
local variables. So, the absence of constexpr is essentially telling the compiler to ignore something it already knows and preventing existing
code from being handled at compile time

Consider:

const int c = 2;
int a = 0;
a = 1/(c-2);


The division by zero (c-2) will not be handled at compile time. Changing to:

constexpr int c = 2;
int a = 0;
a = 1/(c-2);

it will catch this even without flow analysis.

So, again, I don´t see a reason for not doing the same analysis using
const or allowing const variables be used in constant expressions.

In C23, n is a constant expression if and only
if n is defined with "constexpr". If you add "constexpr" to a
declaration whose initializer is not a constant expression, it will be rejected.

It seems like an artificial limitation has been introduced instead of generalizing const.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/19/2024 6:48 PM, Keith Thompson escreveu:
Thiago Adams <thiago.adams@gmail.com> writes:
Let's pretend that when "const" was introduced in C89, it was spelled "readonly", which more closely reflects its meaning. Would you suggest
that

readonly int n = 42;

should make n a constant expression?

I used to find const confusing, as it sometimes meant 'read-only' and
other times 'immutable.'
Now, it seems less confusing to me. When const is used with variables
that can be initialized (init-declarator), it acts as 'immutable,'
meaning the storage is constant.
In other contexts, like function parameters, const means 'read-only'
because we don’t know if the storage is constant or not.

It’s also interesting to note that constexpr acts as a storage
qualifier. What the compiler needs to know when evaluating an expression
at compile time, without depending on flow analysis, is the guarantee
that the object is immutable. This makes it safe to use the value it has
at initialization when the initialization is also a compile time expression.

const used in variables that can be initialized gives the compiler the
same guarantees.








--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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

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

[...]

My reasons for not wanting `const int c = 2;` to make c a constant
expression have nothing to do with any theoretical difference in
generated code.

My reason is that "const" and "constant" are two almost entirely
distinct concepts. Conflating them makes the language more confusing.
Making the name of a "const" object a constant expression adds no new
capabilities beyone what we already have with "constexpr".

I see some differences but not enough to justify a new keyword and I
think it also generates confusion. So it is a matter of choosing what
that of confusion we want.

But the new keyword already exists, and will be part of the language for
years. Removing the constexpr keyword will not be possible, because
doing so would break existing code.

For instance, in file scope,

const int a = 1;
constexpr int b =1;

In both cases, because it is file scope, a and b need to be
initialized with constant expressions. I don´t see anything more
special in b compared with a to make any distinction.

As of C23, you're right. But what if a future C standard allows
non-constant initializers for file-scope object (as C++ already does)?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 19/10/2024 19:22, Bart wrote:

On 19/10/2024 17:03, David Brown wrote:

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.

I can give examples where a compiler won't work, or it will generate different code, but you won't execpt it because you won't recognise the compiler, or will dismiss it, or will dismiss even gcc because
optimisations aren't used.

I know there are compilers that don't support VLAs at all - that's fair
enough (and that's why I specifically mentioned it). We can expect that compilers that can't handle VLAs at all will not support C23 constexpr,
or any suggested C++ style extensions to the semantics of "const".

If you have an example of a compiler that /does/ support VLAs, but
generates different code for "a" and "b" above, then it would be
interesting to hear about it. I will put a lot more weight on its
relevance if it is a mainstream or established compiler (it is a big
advantage if it is on godbolt.org), and one that does at least some
level of optimisation. (For compilers that have no optimisation, or
where optimisation is disabled, code quality really doesn't matter
anyway.) Single user compilers, on the other hand, have little
relevance beyond that one user, and therefore do not matter much.

If it will always be gcc-O2 or higher, and it is an example just like
these (so inside a function), then probably it will generate the same code.

But that's a lot of 'if's.

Where the code is different, then gcc on Windows for example likes to generate a call to __chkstack() (to incrementally increase the stack a
page at a time in case it skips a page for a large allocation).

Not with -O1.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 19/10/2024 21:41, Thiago Adams wrote:

Em 10/19/2024 1:03 PM, David Brown escreveu:

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?

I don't see any practical difference. In theory, the generated code
could be different, but I'm arguing that this doesn't really matter and, consequently, it's not a good reason to differentiate between const and constexpr.

My point was that if there is no practical difference, then there is no
reason to object to the VLA.

You can't use this as a reason for arguing that it would have been
better for "const" in C to gain the features that are now in C23
"constexpr", because this use of "const" was already allowed in C99. So
the "const" vs "constexpr" discussion is an orthogonal issue - I was
asking specifically about your comment regarding your apparent dislike
of VLA's.




--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 19/10/2024 23:24, Keith Thompson wrote:

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];`.

Yes. That's why I said "a compiler that supports enough of C99 to allow
it". (I think it was a really bad idea to make VLAs optional in C11 - I
can't see any justification for it other than pressure from a big
compiler vendor that has long neglected implementation of C standards.)

`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.)

Ah, there you have a difference. Thanks.

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.

Yes, that's the point - and that's why I wonder why Thiago is happy with
an array with a constant expression size, but dislikes one with a
non-constant size that is known and fixed at compile time, just because
it is technically a VLA.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 20/10/2024 11:45, David Brown wrote:

On 19/10/2024 21:41, Thiago Adams wrote:

Em 10/19/2024 1:03 PM, David Brown escreveu:

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?

I don't see any practical difference. In theory, the generated code
could be different, but I'm arguing that this doesn't really matter
and, consequently, it's not a good reason to differentiate between
const and constexpr.

My point was that if there is no practical difference, then there is no reason to object to the VLA.

I've seen endless exampples where people inadvertently created VLAs, and
where they are likely to less efficient.

It might start off like this:

const int n = 10;
int A[n];

Then they change something so that n is not evaluated until runtime
(maybe it's defined in terms of a parameter). Now the compiler will
silently generate less efficient code for a VLA, without giving the user
a chance to use an alternative.

You can't use this as a reason for arguing that it would have been
better for "const" in C to gain the features that are now in C23 "constexpr", because this use of "const" was already allowed in C99.  So the "const" vs "constexpr" discussion is an orthogonal issue - I was
asking specifically about your comment regarding your apparent dislike
of VLA's.

The advantage of constexpr AIUI is that a non-constant initialiser for n
is not allowed.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 20/10/2024 13:23, Bart wrote:

On 20/10/2024 11:45, David Brown wrote:

On 19/10/2024 21:41, Thiago Adams wrote:

Em 10/19/2024 1:03 PM, David Brown escreveu:

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?

I don't see any practical difference. In theory, the generated code
could be different, but I'm arguing that this doesn't really matter
and, consequently, it's not a good reason to differentiate between
const and constexpr.

My point was that if there is no practical difference, then there is
no reason to object to the VLA.

I've seen endless exampples where people inadvertently created VLAs, and where they are likely to less efficient.

I can't say I have ever seem such as situation. But of course
experiences differ.

It might start off like this:

    const int n = 10;
    int A[n];

Then they change something so that n is not evaluated until runtime
(maybe it's defined in terms of a parameter). Now the compiler will
silently generate less efficient code for a VLA, without giving the user
a chance to use an alternative.

Yes, a VLA where the size is not known at compile time will be less
efficient than when the size is fixed. It might still be a lot more
efficient than alternatives, such as using malloc(). I think VLAs -
with run-time sizes - have their uses, but you should be aware of when
you use them.

You can't use this as a reason for arguing that it would have been
better for "const" in C to gain the features that are now in C23
"constexpr", because this use of "const" was already allowed in C99.
So the "const" vs "constexpr" discussion is an orthogonal issue - I
was asking specifically about your comment regarding your apparent
dislike of VLA's.

The advantage of constexpr AIUI is that a non-constant initialiser for n
is not allowed.

Yes, that is something I also see as an advantage.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On Sat, 19 Oct 2024 21:08:10 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

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

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

For instance, in file scope,

const int a = 1;
constexpr int b =1;

In both cases, because it is file scope, a and b need to be
initialized with constant expressions. I don´t see anything more
special in b compared with a to make any distinction.

As of C23, you're right. But what if a future C standard allows
non-constant initializers for file-scope object (as C++ already does)?

You mean, initializers by arbitrary user code running before main?
Hopefully, it would never happen. Too much against the virtue of C.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Em 10/20/2024 1:08 AM, Keith Thompson escreveu:

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

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

[...]

My reasons for not wanting `const int c = 2;` to make c a constant
expression have nothing to do with any theoretical difference in
generated code.

My reason is that "const" and "constant" are two almost entirely
distinct concepts. Conflating them makes the language more confusing.
Making the name of a "const" object a constant expression adds no new
capabilities beyone what we already have with "constexpr".

I see some differences but not enough to justify a new keyword and I
think it also generates confusion. So it is a matter of choosing what
that of confusion we want.

But the new keyword already exists, and will be part of the language for years. Removing the constexpr keyword will not be possible, because
doing so would break existing code.

Yes. But const can be improved and we can just ignore constexpr.

Just to show one extra difference from constexpr

we have an error here

//'constexpr' initializer not representable in type of object
constexpr unsigned char c= 1234;

with const it is a warning. But again I don't think is is enough to
justify constexpr.

For instance, in file scope,

const int a = 1;
constexpr int b =1;

In both cases, because it is file scope, a and b need to be
initialized with constant expressions. I don´t see anything more
special in b compared with a to make any distinction.

As of C23, you're right. But what if a future C standard allows
non-constant initializers for file-scope object (as C++ already does)?

Then it could have initialization order problem..and C does not have exceptions to report error in initialization..
What C could have is compile time functions.

const int i = f();

I think this situation can be automatic, the compiler will try to
evaluate f at compile time because there is no other alternative.



--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 20.10.2024 um 03:56 schrieb Thiago Adams:

I used to find const confusing, as it sometimes meant 'read-only' and
other times 'immutable.'
Now, it seems less confusing to me. When const is used with variables
that can be initialized (init-declarator), it acts as 'immutable,'
meaning the storage is constant.
In other contexts, like function parameters, const means 'read-only'
because we don’t know if the storage is constant or not.

I'm asking myself what should be confusing with constexpr.

It’s also interesting to note that constexpr acts as a storage
qualifier. What the compiler needs to know when evaluating an expression
at compile time, without depending on flow analysis, is the guarantee
that the object is immutable. This makes it safe to use the value it has
at initialization when the initialization is also a compile time
expression.

const used in variables that can be initialized gives the compiler the
same guarantees.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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

I know there are compilers that don't support VLAs at all - that's
fair enough (and that's why I specifically mentioned it). We can
expect that compilers that can't handle VLAs at all will not support
C23 constexpr, or any suggested C++ style extensions to the semantics
of "const".

Why would we expect that?

IIRC, Microsoft has decided not to support VLAs in its C compiler. If
they chose not to support constexpr, they could not claim C23 conformance.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 20/10/2024 20:28, Keith Thompson wrote:

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

I know there are compilers that don't support VLAs at all - that's
fair enough (and that's why I specifically mentioned it). We can
expect that compilers that can't handle VLAs at all will not support
C23 constexpr, or any suggested C++ style extensions to the semantics
of "const".

Why would we expect that?

IIRC, Microsoft has decided not to support VLAs in its C compiler. If
they chose not to support constexpr, they could not claim C23 conformance.

Indeed. From the working draft I have of C23, while VLAs are optional, constexpr is not as far as I can tell.

MS has a long history of being reluctant to be compliant with anything
past C89 - it took them ages to finally support C99, and after that,
they added strictly what was not optional from what I see.

More generally speaking, it looks like MS hasn't really cared about C
ever since the late 90's - early 2000's where they entirely focused on
C++. The Windows API is still C in itself for the most part, but it
doesn't require anything past C89 (again that I know of / remember).
Ditto for drivers.

So I don't think there is any internal incentive to keep up with C
standards, except for the strict minimum so that developers can't say
that MSVC is completely obsolete.

Regarding const vs constexpr, it looks like some people have a hard time understanding the concept of not breaking existing behavior, which has
been one of C's strong points and largely explains why it's still being
used today. And as I understand, one argument was that const should be constexpr in some contexts where it's considered "obvious" (but not in others). Context-dependent keywords are not a fantastic idea.

Now may people tend to conflate 'constants' with 'literals' in C. And
don't realize that a const-qualified variable is still a 'variable', not
a 'constant' in the usual sense in CS. I personally think constexpr is a welcome addition in C. The naming may be questionable, or not. Sure it
was borrowed from C++. From what I know, there has been a rule between
the C and the C++ standard committees for a while, that using different
naming and keywords for what's the same feature in the two languages
should be avoided. And I guess it makes sense.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 20/10/2024 20:28, Keith Thompson wrote:

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

I know there are compilers that don't support VLAs at all - that's
fair enough (and that's why I specifically mentioned it). We can
expect that compilers that can't handle VLAs at all will not support
C23 constexpr, or any suggested C++ style extensions to the semantics
of "const".

Why would we expect that?

IIRC, Microsoft has decided not to support VLAs in its C compiler. If
they chose not to support constexpr, they could not claim C23 conformance.

MS is in a somewhat different position than other C compiler vendors.
They decided - for various reasons - not to support C99 other than parts
that had direct correspondence with C++ features. Without having
followed any of the proceedings, I suspect the reason VLAs are optional
in C23 is because MS wants to avoid adding more than they have to before
being able to jump to (approximate) C23 conformance. "constexpr" will
be relatively easy for them, as they have it in C++ already.

(I don't know how recently updated the cppreference page on C23 compiler support is, but if it is accurate, MS has a long way to go before C23 conformance - if that is even their aim.)

Pretty much every other C compiler that aims for at least vague
conformance, AFAIK, has done so linearly through the standards versions.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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

MS is in a somewhat different position than other C compiler
vendors. They decided - for various reasons - not to support C99 other
than parts that had direct correspondence with C++ features. Without
having followed any of the proceedings, I suspect the reason VLAs are optional in C23 is because MS wants to avoid adding more than they
have to before being able to jump to (approximate) C23 conformance. "constexpr" will be relatively easy for them, as they have it in C++
already.

Yes, Microsoft pretty much skipped over C99, but if I recall correctly
their current C compiler has reasonably good support for C11.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 10/21/2024 1:47 PM, Keith Thompson wrote:

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

MS is in a somewhat different position than other C compiler
vendors. They decided - for various reasons - not to support C99 other
than parts that had direct correspondence with C++ features. Without
having followed any of the proceedings, I suspect the reason VLAs are
optional in C23 is because MS wants to avoid adding more than they
have to before being able to jump to (approximate) C23 conformance.
"constexpr" will be relatively easy for them, as they have it in C++
already.

Yes, Microsoft pretty much skipped over C99, but if I recall correctly
their current C compiler has reasonably good support for C11.

Last time I checked it did not have full support for C11 threads.

[...]

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 2024-10-21, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 10/21/2024 1:47 PM, Keith Thompson wrote:

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

MS is in a somewhat different position than other C compiler
vendors. They decided - for various reasons - not to support C99 other
than parts that had direct correspondence with C++ features. Without
having followed any of the proceedings, I suspect the reason VLAs are
optional in C23 is because MS wants to avoid adding more than they
have to before being able to jump to (approximate) C23 conformance.
"constexpr" will be relatively easy for them, as they have it in C++
already.

Yes, Microsoft pretty much skipped over C99, but if I recall correctly
their current C compiler has reasonably good support for C11.

Last time I checked it did not have full support for C11 threads.

It's a pointless wrapper for POSIX threads, which differ from Windows
threads.

There is no reason to use it. Wherever POSIX threads are not found,
you can just implement *that* or find an implementation, or a
a subset that is good enough for your needs.

POSIX threads are no more or less standard than ISO C threads.
It is a gratuitous duplication.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Am 20.10.2024 um 14:22 schrieb Thiago Adams:

//'constexpr' initializer not representable in type of object
constexpr unsigned char c= 1234;
with const it is a warning. ...

Good that we have constexpr now.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 22/10/2024 05:02, Bonita Montero wrote:

Am 20.10.2024 um 14:22 schrieb Thiago Adams:

//'constexpr' initializer not representable in type of object
constexpr unsigned char c= 1234;
with const it is a warning. ...

Good that we have constexpr now.

I think a more generic feature would be to have a standard way of
promoting selected warnings to errors. This would avoid stacking
features with small differences, such as treating constexpr as a special
case compared to other constant expressions in C.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 10/21/2024 7:43 PM, Kaz Kylheku wrote:

On 2024-10-21, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 10/21/2024 1:47 PM, Keith Thompson wrote:

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

MS is in a somewhat different position than other C compiler
vendors. They decided - for various reasons - not to support C99 other >>>> than parts that had direct correspondence with C++ features. Without
having followed any of the proceedings, I suspect the reason VLAs are
optional in C23 is because MS wants to avoid adding more than they
have to before being able to jump to (approximate) C23 conformance.
"constexpr" will be relatively easy for them, as they have it in C++
already.

Yes, Microsoft pretty much skipped over C99, but if I recall correctly
their current C compiler has reasonably good support for C11.

Last time I checked it did not have full support for C11 threads.

It's a pointless wrapper for POSIX threads, which differ from Windows threads.

There is no reason to use it. Wherever POSIX threads are not found,
you can just implement *that* or find an implementation, or a
a subset that is good enough for your needs.

POSIX threads are no more or less standard than ISO C threads.
It is a gratuitous duplication.

The only compiler that I found that has full support for C11 threads,
atomics and membars was PellesC. The last time I checked MSVC for full
support was around a year and a half ago.

http://www.smorgasbordet.com/pellesc

They had some issues with some atomics that I pointed out:

https://forum.pellesc.de/index.php?topic=7167.msg27217#msg27217

https://forum.pellesc.de/index.php?topic=7311.msg27764#msg27764
--- Synchronet 3.20a-Linux NewsLink 1.114