constexpr was created why?

[gdo...@gmail.com]

is this one of those things where the committee had nothing better to do? ok, maybe I haven't got to the point where I see the demand for such, but I will be open-minded and use it when I see an opportunity.

prevents ..., more intuitive ..., easier to type than ..., more expressive than ..., solves the problem of ..., well I'm sure I'll see all of that at some point.

[Mr Flibble]

Just because you are ignorant of the benefits of constexpr it doesn't
follow that there are none.

/Flibble

[gdo...@gmail.com]

fibble: what are they then. show everyone how smart you are.
list example, reasons, discussions, point of view.
I mean just show "me" how smart you are.

[Mr Flibble]

I don't have to show everyone how smart I am but perhaps you do: the
smart thing to do would be to read a book or two and/or a *decent*
online reference.

/Flibble

[Manfred]

On 7/20/2022 12:25 AM, gdo...@gmail.com wrote:
> is this one of those things where the committee had nothing better to do? ok, maybe I haven't got to the point where I see the demand for such, but I will be open-minded and use it when I see an opportunity.
>
> prevents ..., more intuitive ..., easier to type than ..., more expressive than ..., solves the problem of ..., well I'm sure I'll see all of that at some point.

Short answer: to facilitate compile time evaluation.

[Bonita Montero]

The problem with compile-time evaluation is that this might cost
a lot of CPU-time if the compiler does that at any place. So the
developer suggests the compiler where this might be appropriate.

[David Brown]

A useful reference for C++ is cppreference.com. This should be your
starting point for information about a C++ feature - it is technical and
precise, but more readable than the standards and it makes it clear how
things change between C++ standards :

<https://en.cppreference.com/w/cpp/language/constexpr>

Of course, that is just the technical details - it doesn't cover the
question of if, and why, people use constexpr.


Basically, a "constexpr" function is one which /can/ be evaluated at
compile time, to give a "core constant expression" result. And a
"constexpr" variable is one which is definitely known and fixed at
compile time.

Suppose you want some arrays whose sizes are square numbers - maybe you
want to put matrices in there. You can write :

int xs1[16];

You can also write :

int xs2[4 * 4];

Then you think a helper function is a good idea - perhaps you will
generalise things later :

int square(int x) { return x * x; }

int xs3[square(5)];

Suddenly, this won't compile - even though it is "obvious" that the size
of the array is fixed.

The answer is to make "square" a constexpr function:

constexpr int square(int x) { return x * x; }

The function body has not changed, but you have now said that /if/ the
values passed to it are "core constant expressions", so is the result of
the function. (You can still use it with variables, in which case it
acts like a normal run-time function.)

Now the declaration for "xs3" is fine, because "square(5)" is a
compile-time constant.


For a variable, if you make it "constexpr", then you are insisting that
the compiler figures out its initialisation at compile time, and you are
guaranteeing that no one can try to change its value (no cheating with
const_cast<> and the like).

So this makes "constexpr int n = 10;" useful in more contexts than
"const int n = 10;" would be. For example, where in C you might have had :

#define MAX_NO_OF_WHATSITS 100

you now have :

constexpr int max_no_of_whatsits = 100;


Probably the biggest difference comes with templates and more advanced
metaprogramming - constexpr lets you simplify the code a good deal, and
can be used in template parameters, "if constexpr" statements, concepts,
noexcept specifiers, etc.

You can also use constexpr variables and functions for pre-computing
tables or other values, for more efficient runtime code, for switch
labels, and various other places where you need a "real" constant.

[Mut...@dastardlyhq.com]

IME ever constexpr I've seen could have been evaluated by the developer
directly and just been a hard coded const/macro. Constexprs are generally a
solution looking for a problem.

[Juha Nieminen]

gdo...@gmail.com <gdo...@gmail.com> wrote:
> is this one of those things where the committee had nothing better to do? ok, maybe I haven't got to the point where I see the demand for such, but I will be open-minded and use it when I see an opportunity.
>
> prevents ..., more intuitive ..., easier to type than ..., more expressive than ..., solves the problem of ..., well I'm sure I'll see all of that at some point.

constexpr alleviates a serendipitous problem that manifested itself all the
way back in the early days of C++98 (perhaps even before).

You see, the template mechanism was originally designed to merely allow
writing generic classes and generic functions, where you just implement the
class or function once, but it can be used for any type (that's compatible
with the implementation): The compiler automatically generates a version
of the implementation where the types have been replaced. Thus it's much
easier to use the same code for multiple types (and the code is ostensibly
as optimized for that type as possible).

However, it was quite soon discovered that, serendipitously, the C++
template mechanism could be used for a limited form of compile-time
programming. The template mechanism almost forms a "language within
a language", where using its own peculiar syntax you can do all kinds
of calculations at compile time. The so-called "template metaprogramming"
paradigm was born.

It was soon developed into a surprisingly complex "sub-language" of C++.
You could have linked lists, with all typical list operations (appending,
splicing, splitting, traversing, etc.) and you could do all sorts of
calculations, all at compile time.

The problem? Because templates were never designed for this from
the ground up, the syntax is not optimal for this, and "template
metaprogramming" programs tend to be very obfuscated, complicated and
hard to understand. There's also the problem that what you can do with
them is very limited. They are also quite heavy for the compiler to
evaluate (and, in some cases, could require an enormous amount of RAM
because complex "template metaprograms" effectively result in
ginormously long type declarations that may take even megabytes of RAM.)

Thus a better solution was devised for C++11: constexpr.

constexpr allows using C++'s own "normal" syntax, rather than the
complicated template syntax, in order to do those same calculations
much easier. In addition, constexpr code is easier to read, supports
things that template metaprogramming doesn't (such as floating point
calculations), and is much more efficient for the compiler to evaluate
and (usually) requires significantly less RAM. Plus, the exact same code
can be also used at runtime in addition to compile time, so it's yet
again one thing where code repetition is avoided.

[David Brown]

Many things could be calculated by the developer and hardcoded into
software. But we usually don't do that, when the programming language
provides a way to handle it. When you use "sizeof" in a memcpy or
allocation function, it is not because the developer is incapable of
figuring out the size of the type. It is because using "sizeof" makes
code clearer, easier to change, maintain or re-use, easier to port, and
less likely to be wrong.

The same logic applies to other compile-time calculations. Let the
computer do what the computer is good at, leaving the programmer to do
what he/she is better at.

[Mut...@dastardlyhq.com]

sizeof() makes it clear what you are doing. A constexpr is code that someone
will have to understand and/or manually execute to find what the value it
produces is. I'm not sure adding code to create const values aids code clarity
in any way.

[Öö Tiib]

Without understanding what the functions in program do there are no difference
if these are constexpr or not . For example std::string::append is constexpr
since C++20. If you did understand what it did before then there are no difference
compiler may just do it compile time with constant arguments . If yo did not
understand what it did then that it is constexpr changes nothing.