• constexpr - C23 thoughts and opinions revisited

    From Thiago Adams@thiago.adams@gmail.com to comp.lang.c on Wed Oct 16 08:54:58 2024
    From Newsgroup: comp.lang.c


    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.


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Bonita Montero@Bonita.Montero@gmail.com to comp.lang.c on Wed Oct 16 14:25:59 2024
    From Newsgroup: comp.lang.c

    Am 16.10.2024 um 13:54 schrieb Thiago Adams:

    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.

    The code is easy to read, no matter if you make it constexpr
    or const. The language designers don't see the catastrophes
    you see with constexpr.

    --- Synchronet 3.20a-Linux NewsLink 1.114