constexpr - C23 thoughts and opinions revisited

Liste des GroupesRevenir à cl c  
Sujet : constexpr - C23 thoughts and opinions revisited
De : thiago.adams (at) *nospam* gmail.com (Thiago Adams)
Groupes : comp.lang.c
Date : 16. Oct 2024, 12:54:58
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <veo9ii$288l8$1@dont-email.me>
References : 1
User-Agent : Mozilla Thunderbird
I reviewed my thoughts about C23 constexpr posted on "C23 thoughts and opinions".
My previous post:
-------------------------------------------------
On 25/05/2024 08:19, Thiago Adams wrote:
...

In my view , for this sample constexpr generates noise. It also can make the compilation slower, otherwise, why not everything constexpr by defaul?
I still didn't find a useful usage for constexpr that would compensate the mess created with const, constexpr. I already saw ( I don't have it now ) proposals to make const more like constexpr in C. In C++ const is already a constant expression!
The justification for C was VLA. They should consider VLA not VLA if it has a constant expression. In other words, better break this than create a mess.
#define makes the job of constexpr.
  
One more sample of NOISE of constexpr from the same real source.
int compare(const Node* a, const Node* b)
{
     return memcmp(a, b, sizeof(Node)) == 0;
}
bool IsValid(Node * pnid)
{
     static constexpr Node node = { 1, 2 };
     return compare(pnid, &node);
}
What is expectation passing the address of compile constant to a runtime function? This is pure noise!
Nothing happens, nothing is done at compile time.
https://godbolt.org/z/ecsMf4vaY
-------------------------------------------------
Before:
I used to think, why execute code at compile time when it always yields the same result? Wouldn't it be better to just leave the result pre-calculated, avoiding slower compilation times and unnecessary compiler complexity?
Also the noise.
Now:
I now see it as a generalization or extension of constant expression capabilities, making the compiler smarter. Some analyses I used to perform in a second pass during flow analysis are now done at the parser phase as part of constant expression evaluation.
For example:
const int i = 1;
// Error detected at the parser phase.
int a = 4 / (i - 1);
Generalizing for functions could make the compiler check the computation in compile time. I am thinking in term of safety. But I don't want to make the language more complex. Nothing changes. Just the compiler evaluation becomes generalized (instead of saying more complex).
My previous thoughts about the noise haven't changed. However, I think it’s interesting to have this implemented with const.

Date Sujet#  Auteur
16 Oct 24 * constexpr - C23 thoughts and opinions revisited2Thiago Adams
16 Oct 24 `- Re: constexpr - C23 thoughts and opinions revisited1Bonita Montero

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal