Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #85482 > unrolled thread

constexpr was created why?

Back to article view | Back to comp.lang.c++

Contents

  constexpr was created why? "gdo...@gmail.com" <gdotone@gmail.com> - 2022-07-19 15:25 -0700
    Re: constexpr was created why? Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-19 23:56 +0100
      Re: constexpr was created why? "gdo...@gmail.com" <gdotone@gmail.com> - 2022-07-19 17:18 -0700
        Re: constexpr was created why? Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-20 01:21 +0100
    Re: constexpr was created why? Manfred <noname@add.invalid> - 2022-07-20 03:06 +0200
      Re: constexpr was created why? Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-20 03:24 +0200
      Re: constexpr was created why? Muttley@dastardlyhq.com - 2022-07-20 08:23 +0000
        Re: constexpr was created why? David Brown <david.brown@hesbynett.no> - 2022-07-20 13:04 +0200
          Re: constexpr was created why? Muttley@dastardlyhq.com - 2022-07-20 15:12 +0000
            Re: constexpr was created why? Öö Tiib <ootiib@hot.ee> - 2022-07-20 21:00 -0700
    Re: constexpr was created why? David Brown <david.brown@hesbynett.no> - 2022-07-20 09:27 +0200
    Re: constexpr was created why? Juha Nieminen <nospam@thanks.invalid> - 2022-07-20 09:46 +0000

#85482 — constexpr was created why?

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.

[toc] | [next] | [standalone]

#85484

On Tue, 19 Jul 2022 15:25:09 -0700 (PDT)
"gdo...@gmail.com" <gdotone@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.

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

/Flibble

[toc] | [prev] | [next] | [standalone]

#85487

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.

[toc] | [prev] | [next] | [standalone]

#85488

On Tue, 19 Jul 2022 17:18:15 -0700 (PDT)
"gdo...@gmail.com" <gdotone@gmail.com> wrote:

> 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.

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

[toc] | [prev] | [next] | [standalone]

#85490

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.

[toc] | [prev] | [next] | [standalone]

#85492

Am 20.07.2022 um 03:06 schrieb 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.

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.

[toc] | [prev] | [next] | [standalone]

#85495

On Wed, 20 Jul 2022 03:06:18 +0200
Manfred <noname@add.invalid> wrote:
>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.

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.

[toc] | [prev] | [next] | [standalone]

#85499

On 20/07/2022 10:23, Muttley@dastardlyhq.com wrote:
> On Wed, 20 Jul 2022 03:06:18 +0200
> Manfred <noname@add.invalid> wrote:
>> 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.
> 
> 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.
> 

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.

[toc] | [prev] | [next] | [standalone]

#85502

On Wed, 20 Jul 2022 13:04:57 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 20/07/2022 10:23, Muttley@dastardlyhq.com wrote:
>> On Wed, 20 Jul 2022 03:06:18 +0200
>> Manfred <noname@add.invalid> wrote:
>>> 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.
>> 
>> 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.
>> 
>
>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.

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.

[toc] | [prev] | [next] | [standalone]

#85516

On Wednesday, 20 July 2022 at 18:12:59 UTC+3, Mut...@dastardlyhq.com wrote:
> On Wed, 20 Jul 2022 13:04:57 +0200 
> David Brown <david...@hesbynett.no> wrote: 
> >On 20/07/2022 10:23, Mut...@dastardlyhq.com wrote: 
> >> On Wed, 20 Jul 2022 03:06:18 +0200 
> >> Manfred <non...@add.invalid> wrote: 
> >>> 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. 
> >> 
> >> 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. 
> >> 
> > 
> >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.
> 
> 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.

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.

[toc] | [prev] | [next] | [standalone]

#85494

On 20/07/2022 00:25, 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.

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.

[toc] | [prev] | [next] | [standalone]

#85497

gdo...@gmail.com <gdotone@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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web