Liste des Groupes | Revenir à cl c |
Em 5/25/2024 8:05 AM, David Brown escreveu:
I don't share that opinion, but I understand it.>In my view , for this sample constexpr generates noise.
In C (not C++), defining an object as "constexpr" gives you two things compared to defining it as "const". One is that its value can be used when you need a constant expression according to the rules of the language (such as for the size of an array in a struct). The other is that it gives a compile-time error if its initialiser is not itself a constant expression - and that means an extra check and protection against some kinds of programmer errors, and extra information to people reading the code.
>
I don't expect it to make a difference in generated code from an optimising compiler, in comparison to objects declared with "const".
>
>
It also can make the compilation slower, otherwise, why not everything constexpr by defaul?That claim, on the other hand, is very strange. Making everything constexpr by default would be a massive change to the language that would break all but the most negligible of existing code. And I can think of no particular reason why constexpr would slow down compilation, at least to any measurable degree.
I still didn't find a useful usage for constexpr that would compensate the mess created with const, constexpr.I don't need a feature to "compensate" for anything to be useful. I don't need it to be perfect to be useful. There's a few things about constexpr in C23 that I think are poor decisions, unreasonable restrictions, or suboptimal integration with other language features (like static_assert) - such as the array limitations you've found. That will mean I can't use constexpr as much as I'd like, or as much as I do in C++. But even if there is just one situation where I think using constexpr is neater or clearer than using enum, #define, or some other technique, then I will use constexpr in that one situation. Why are you so insistent on throwing it out completely just because it doesn't do everything you might want?
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!No, it is not - but sometimes a const object with particular characteristics can be used in situations where you would otherwise need a constant expression. I mentioned earlier that I find this convenient in C++ - Keith said it was inconsistent, which is also true. I think that to a large extent, if C "const" had acquired the additional features of C++ "const" (excluding the different linkage for file-scope "const" objects, since that would be a breaking change) then it would have done everything C23 "constexpr" does today. I personally would have been fine with that as a solution. But I fully appreciate that it would have been inconsistent and perhaps hard to specify - you'd would have the situation that /some/ const objects could be used for things like static initialisers, while others could not.
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 is one way to make named items that can be used in constant expressions, yes. But if it can be done using #define or constexpr, I think constexpr is the neater choice. Opinions can vary - that's my opinion.
#define makes the job of constexpr.
Les messages affichés proviennent d'usenet.