Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thiago Adams <thiago.adams@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Fri, 29 Nov 2024 09:30:37 -0300
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <vicc5d$12kql$1@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <vi6sb1$148h7$1@paganini.bofh.team>
 <vi6uaj$3ve13$2@dont-email.me> <87plmfu2ub.fsf@nosuchdomain.example.com>
 <vi9jk4$gse4$1@dont-email.me> <87bjxzt7xq.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 29 Nov 2024 13:30:38 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d4f23f3e22a158530d6134251c073abe";
	logging-data="1135445"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Yb8CmNE58b+vDTVWdJIlJRr8f6nzSu3I="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MIG3i4ck2ZMPtKDMPbthagl0L0Y=
Content-Language: en-GB
In-Reply-To: <87bjxzt7xq.fsf@nosuchdomain.example.com>
Bytes: 3893

Em 11/28/2024 5:33 PM, Keith Thompson escreveu:
> If an object is const because of its definition, then that object is
> itself read-only, and anything that bypasses that (pointer casts, etc.)
> causes undefined behavior.

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



 >> For compile that computation what matters is the guarantee that the
 >> compiler knows the values (it knows because it always the same value
 >> of initialization) when using the object. (It does not depend on flow
 >> analysis)
 > There's no requirement for the compiler to "know" the value of a const
 > object.

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

Sorry if I am begin repetitive, but here is my motivation to say that 
const was already ready for that, no need to new keyword constexpr.

Consider this sample

void f(const int a)
{
   const int b = 1;

   switch (a){
      case a: break; // OPS
      case b: break; // should be OK
   }
}

The compiler does not know the value of 'a' even it is declared as 
constant object; on the other hand the compiler knows the value of 'b';

So, here is my point - In init-declarators. const and constexpr becomes 
similar.




Em 11/28/2024 5:33 PM, Keith Thompson escreveu:
 >> Sample why no-storage is useful
 >>
 >> void F()
 >> {
 >>     register const int i = 1;
 >>     //lets way we have lanbdas in C
 >>     f( []()
 >>       {
 >>           //safe to use i even in another thread, or even after 
exiting F
 >>           int k = i;
 >>       }
 >>     );
 >> }
 > Without "register", since i is const, its value will never change
 > (barring undefined behavior), so it should be safe to use anyway.
 > How is eliminating the storage for i useful?  You can just ignore
 > it, and the compiler may be able to optimize it away.


If lambdas were implemented in C, a decision has to be made about 
capture. Is it allowed or not?
Objects with no storage could be allowed to be captured because this 
will never imply in lifetime problems; for instance if the lambdas is 
called by another thread.

C23 also added constexpr in compound literal.

(constexpr struct X ){ }

I also don´t understand why not just use const for that.

I also allow static.

(static const struct X ){ }

I think in this case it makes sense.