Re: C23 thoughts and opinions

On 23/05/2024 23:49, Keith Thompson wrote:

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

On 23/05/2024 10:11, David Brown wrote:

On 23/05/2024 14:38, Thiago Adams wrote:

[...]

I already see bad usages of constexpr in C++ code. It was used in
cases where we know for sure that is NOT compile time. This just
make review harder "why did someone put this here?" conclusion was
it was totally unnecessary and ignored by the compiler. The
programmer was trying to add something extra, like "magic" hoping
for something that would never happen.
>

IME poor or confusing uses of "constexpr" are for functions, not
objects, and C23 does not support "constexpr" for functions.

>
The sample C++ was something like
>
constexpr char * s[] = {"a", "b"};
     for (int i = 0; i < sizeof(s); i++)
     {
         //using s[i]
     }
>
I checked in C, it is an error.

 Apparently C23 has stricter rules for constexpr than C++ does.  I can
imagine those rules being relaxed in future editions of the C standard.
 

 From the proposal for "constexpr" in C23, <https://open-std.org/JTC1/SC22/WG14/www/docs/n3018.htm>, it says:
"""
There are some restrictions on the type of an object that can be declared with constexpr storage duration. There is a limited number of constructs that are not allowed:
pointer types:
     allowing these to use non-trivial addresses would delay the deduction of the concrete value from translation to link-time. For most of the use cases, such a feature can already be coded by using a static and const qualified pointer object, we don’t need constexpr for that. Therefore we only allow pointer types if the initializer value is null.
"""
I'm not sure (and haven't looked at all the discussions involved, so I could be completely wrong), but I think there is concern that constexpr pointers, other than null pointers, might need more features in the linker than C currently requires.  C++ already has more demands of linkers to handle things like inline variables and statics in templates.