Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: "constexpr" everywhere?
35 views
Skip to first unread message
Message has been deleted
Bo Persson
May 3, 2015, 3:56:13 AM5/3/15
to
On 2015-05-03 00:14, Stefan Ram wrote:
> When Herb Sutter revised his definition of a class for
> complex numbers for C++11, he did not make the constructors
> constexpr, although it seems that this could have been
> possible and there were comments that suggested this to him.
>
> What do you think why he did not use »constexpr« at the
> beginning of the constructors and some member functions?
Perhaps he just didn't see any immediate use for compile time complex
arithmetic?
Bo Persson
> When Herb Sutter revised his definition of a class for
> complex numbers for C++11, he did not make the constructors
> constexpr, although it seems that this could have been
> possible and there were comments that suggested this to him.
>
> What do you think why he did not use »constexpr« at the
> beginning of the constructors and some member functions?
Perhaps he just didn't see any immediate use for compile time complex
arithmetic?
Bo Persson
Öö Tiib
May 3, 2015, 6:30:47 AM5/3/15
to
On Sunday, 3 May 2015 01:14:19 UTC+3, Stefan Ram wrote:
> When Herb Sutter revised his definition of a class for
> complex numbers for C++11, he did not make the constructors
> constexpr, although it seems that this could have been
> possible and there were comments that suggested this to him.
>
> What do you think why he did not use »constexpr« at the
> beginning of the constructors and some member functions?
> Could there be any drawback of using »constexpr«, when it
> When Herb Sutter revised his definition of a class for
> complex numbers for C++11, he did not make the constructors
> constexpr, although it seems that this could have been
> possible and there were comments that suggested this to him.
>
> What do you think why he did not use »constexpr« at the
> beginning of the constructors and some member functions?
> is possible?
Even the latest betas of Microsoft compilers do not support
'constexpr' too well. Herb Sutter is lead architect of Microsoft
C++ compilers so can not publish C++ code that puts those into
bad light.
> Should we use »constexpr« in front of every constructor
> or function where its possible?
>
> (Ok, it might become part of the public interface and then
> it might be difficult to change the interface later when,
> for some reason, the constructor or function cannot be
> implemented as constexpr any longer.)
We should use 'constexpr' functions and constructors where we
plan to use these for producing constant expressions. It is
pointless to use 'constexpr' just to detect if a constructor
or function matches with (quite loose in C++14) requirements
for those.
Message has been deleted
Öö Tiib
May 3, 2015, 9:10:20 AM5/3/15
to
On Sunday, 3 May 2015 14:59:27 UTC+3, Stefan Ram wrote:
> the compiler will choose to calculate it at compile time
> when feasible. This will never hurt (?) and sometimes speed
> up program execution, since some values do not have to be
> calculated at run time. So one should always use »constexpr«
> when possible. /Not/ because we can thus detect whether C++
> requirements are fulfilled, /but/ because we want the
> program to run as fast as possible!
'constexpr' does not make function to run compile time nor does lack
of it guarantee that it does not run compile time so your point is
moot.
Besides how you teach software development without knowing at all
what our work is about?
First we want the program that we make to do what it should do.
Second we want it to work as correctly as it is possible. Everything
else (like speed of its run and such) is of secondary importance
until those two goals have been met.
Unfortunately these primary goals are most hard to reach. What it
should do is often unknown (or more precisely imagined naively) even
to its authors and stakeholders and what it does follows the
requirements (even those naive interpretations) always incorrectly
or imprecisely at least in some corner cases. So we typically
gradually maintain it closer and closer to what it should actually
do as our knowledge grows.
Marking every function possible as 'constexpr' does not aid with
neither of two primary goals and it only distracts during
maintenance. Example: So we discover that we clearly need to add a
try-catch into some function but originally it was marked as
'constexpr'. Why? Maybe author used it somewhere to make constant
expressions. Remove it and rebuild. Half our later ... does not
seem to be the case. Maybe code makes constant expressions with it
under some other build options? Can't build all the configurations
out of blue so lets see all the 1000 calls of it. Hours later ...
no ... we may add try-catch. Author did put 'constexpr' there just
to waste our time.
> In the special case of »complex«, there is an additional
> reason: A complex number should behave as similar to a
> double as possible. Since »double« is a "literal type" we
> want complex to be a "literal type" too.
About why Herb Sutter designed 'complex' like he did I already
answered and you snipped it. Can't you avoid bringing back
discussions that you snipped? Here it goes again:
> Öö Tiib <oot...@hot.ee> writes:
> >We should use 'constexpr' functions and constructors where we
> >plan to use these for producing constant expressions. It is
> >pointless to use 'constexpr' just to detect if a constructor
> >or function matches with (quite loose in C++14) requirements
> >for those.
>
> When a function or constructor is declared with »constexpr«,
> >We should use 'constexpr' functions and constructors where we
> >plan to use these for producing constant expressions. It is
> >pointless to use 'constexpr' just to detect if a constructor
> >or function matches with (quite loose in C++14) requirements
> >for those.
>
> the compiler will choose to calculate it at compile time
> when feasible. This will never hurt (?) and sometimes speed
> up program execution, since some values do not have to be
> calculated at run time. So one should always use »constexpr«
> when possible. /Not/ because we can thus detect whether C++
> requirements are fulfilled, /but/ because we want the
> program to run as fast as possible!
'constexpr' does not make function to run compile time nor does lack
of it guarantee that it does not run compile time so your point is
moot.
Besides how you teach software development without knowing at all
what our work is about?
First we want the program that we make to do what it should do.
Second we want it to work as correctly as it is possible. Everything
else (like speed of its run and such) is of secondary importance
until those two goals have been met.
Unfortunately these primary goals are most hard to reach. What it
should do is often unknown (or more precisely imagined naively) even
to its authors and stakeholders and what it does follows the
requirements (even those naive interpretations) always incorrectly
or imprecisely at least in some corner cases. So we typically
gradually maintain it closer and closer to what it should actually
do as our knowledge grows.
Marking every function possible as 'constexpr' does not aid with
neither of two primary goals and it only distracts during
maintenance. Example: So we discover that we clearly need to add a
try-catch into some function but originally it was marked as
'constexpr'. Why? Maybe author used it somewhere to make constant
expressions. Remove it and rebuild. Half our later ... does not
seem to be the case. Maybe code makes constant expressions with it
under some other build options? Can't build all the configurations
out of blue so lets see all the 1000 calls of it. Hours later ...
no ... we may add try-catch. Author did put 'constexpr' there just
to waste our time.
> In the special case of »complex«, there is an additional
> reason: A complex number should behave as similar to a
> double as possible. Since »double« is a "literal type" we
> want complex to be a "literal type" too.
About why Herb Sutter designed 'complex' like he did I already
answered and you snipped it. Can't you avoid bringing back
discussions that you snipped? Here it goes again:
"Herb Sutter is lead architect of Microsoft C++ compilers so
he can not publish C++ code that puts those into bad light."
0 new messages