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

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

A question about if constexpr

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

Contents

  A question about if constexpr Daniel <danielaparker@gmail.com> - 2019-11-27 05:45 -0800
    Re: A question about if constexpr "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-27 15:03 +0100
      Re: A question about if constexpr Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-11-29 16:33 +0000
        Re: A question about if constexpr Öö Tiib <ootiib@hot.ee> - 2019-11-29 16:52 -0800
          Re: A question about if constexpr David Brown <david.brown@hesbynett.no> - 2019-11-30 12:03 +0100
            Re: A question about if constexpr Öö Tiib <ootiib@hot.ee> - 2019-11-30 03:47 -0800
              Re: A question about if constexpr David Brown <david.brown@hesbynett.no> - 2019-11-30 15:08 +0100
    Re: A question about if constexpr Sam <sam@email-scan.com> - 2019-11-27 18:40 -0500
      Re: A question about if constexpr Öö Tiib <ootiib@hot.ee> - 2019-11-27 23:16 -0800
        Re: A question about if constexpr Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-11-29 16:35 +0000
          Re: A question about if constexpr Öö Tiib <ootiib@hot.ee> - 2019-11-29 16:41 -0800
      Re: A question about if constexpr David Brown <david.brown@hesbynett.no> - 2019-11-28 10:24 +0100
        Re: A question about if constexpr Bo Persson <bo@bo-persson.se> - 2019-11-28 11:58 +0100
          Re: A question about if constexpr David Brown <david.brown@hesbynett.no> - 2019-11-28 12:37 +0100
          Re: A question about if constexpr Robert Wessel <robertwessel2@yahoo.com> - 2019-11-28 14:04 -0600
            Re: A question about if constexpr David Brown <david.brown@hesbynett.no> - 2019-11-29 09:23 +0100
              Re: A question about if constexpr Robert Wessel <robertwessel2@yahoo.com> - 2019-11-29 14:42 -0600
        Re: A question about if constexpr Daniel <danielaparker@gmail.com> - 2019-11-28 21:09 -0800
          Re: A question about if constexpr "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-29 07:41 +0100
          Re: A question about if constexpr Öö Tiib <ootiib@hot.ee> - 2019-11-28 23:50 -0800
            Re: A question about if constexpr David Brown <david.brown@hesbynett.no> - 2019-11-29 09:38 +0100
              Re: A question about if constexpr Öö Tiib <ootiib@hot.ee> - 2019-11-29 17:15 -0800
                Re: A question about if constexpr Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-30 08:19 +0200
                  Re: A question about if constexpr Ned Latham <nedlatham@woden.valhalla.oz> - 2019-11-30 00:24 -0600
                    Re: A question about if constexpr Öö Tiib <ootiib@hot.ee> - 2019-11-30 02:13 -0800
                      Re: A question about if constexpr Ned Latham <nedlatham@woden.valhalla.oz> - 2019-11-30 04:56 -0600
                        Re: A question about if constexpr Öö Tiib <ootiib@hot.ee> - 2019-11-30 03:20 -0800
                          Re: A question about if constexpr Ned Latham <nedlatham@woden.valhalla.oz> - 2019-11-30 05:38 -0600
                            Re: A question about if constexpr Öö Tiib <ootiib@hot.ee> - 2019-11-30 04:57 -0800
                              Re: A question about if constexpr Ned Latham <nedlatham@woden.valhalla.oz> - 2019-11-30 09:46 -0600
                                Re: A question about if constexpr Öö Tiib <ootiib@hot.ee> - 2019-11-30 11:09 -0800
                                  Re: A question about if constexpr Ned Latham <nedlatham@woden.valhalla.oz> - 2019-11-30 20:03 -0600
                                    Re: A question about if constexpr Öö Tiib <ootiib@hot.ee> - 2019-11-30 23:43 -0800
                                      Re: A question about if constexpr Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-01 04:56 -0600
                                        Re: A question about if constexpr Christian Gollwitzer <auriocus@gmx.de> - 2019-12-01 18:33 +0100
                                          Re: A question about if constexpr Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-01 19:27 -0600
                                            Re: A question about if constexpr boltar@nowhere.co.uk - 2019-12-02 08:34 +0000
                                              Re: A question about if constexpr Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-02 04:21 -0600
                                          Re: A question about if constexpr boltar@nowhere.co.uk - 2019-12-02 08:33 +0000
                                          Re: A question about if constexpr Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-03 17:05 +0000
                                            Re: A question about if constexpr boltar@nowhere.co.uk - 2019-12-03 17:09 +0000
                                              Re: A question about if constexpr Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-03 18:03 +0000
                                                Re: A question about if constexpr boltar@nowhere.co.uk - 2019-12-04 16:49 +0000
                                                  Re: A question about if constexpr Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-04 18:36 +0000
                                                    Re: A question about if constexpr boltar@nowhere.co.uk - 2019-12-05 12:51 +0000
          Re: A question about if constexpr David Brown <david.brown@hesbynett.no> - 2019-11-29 09:30 +0100
        Re: A question about if constexpr Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-29 10:51 +0200
    Re: A question about if constexpr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 13:52 -0800
    Re: A question about if constexpr Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-01 14:42 +0100

Page 1 of 3  [1] 2 3  Next page →

#70077 — A question about if constexpr

Consider

#include <string>
#include <iostream>

int main()
{
    constexpr int n = 1;
    constexpr int m = 10;
    std::string s = "abcd";

    if (n < m || s.empty())
    {
        std::cout << "ok\n";
    }
}

Is it reasonable that vs2019 produces a warning

warning C4127:  conditional expression is constant
consider using 'if constexpr' statement instead

g++ and clang do not, even with -Wall or -pedantic

The context is generated code where n = 1, ... 10, 11 ... 

Daniel

[toc] | [next] | [standalone]

#70078

On 27.11.2019 14:45, Daniel wrote:
> Consider
> 
> #include <string>
> #include <iostream>
> 
> int main()
> {
>      constexpr int n = 1;
>      constexpr int m = 10;
>      std::string s = "abcd";
> 
>      if (n < m || s.empty())
>      {
>          std::cout << "ok\n";
>      }
> }
> 
> Is it reasonable that vs2019 produces a warning
> 
> warning C4127:  conditional expression is constant
> consider using 'if constexpr' statement instead
> 
> g++ and clang do not, even with -Wall or -pedantic
> 
> The context is generated code where n = 1, ... 10, 11 ...

It's reasonable here because `n < m` is always true, which is known at 
compile time, and `||` has short-circuit evaluation, which means that 
the non-`constexpr` empty checking of the string is not considered.

If you switch the values of `n` and `m` then `if constexpr` can no 
longer be used, because then, though the result is also then knowable at 
compile time, it isn't /necessarily/ known at compile time. The compiler 
needs some smarts to understand that `s.empty()` must be `false` here.

That said, I find the Visual C++ warning about constant conditions to be 
generally unreasonable. For example, it pops up if you write `while(2+2 
== 4)` instead of the slightly more idiomatic `for(;;)`. Apparently it 
no longer does that for `while(true)`, but I just don't trust it, it's 
evidently tuned to ignore one special literal case, and that's it.


- Alf

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

#70149

On 27/11/2019 14:03, Alf P. Steinbach wrote:
> On 27.11.2019 14:45, Daniel wrote:
>> Consider
>>
>> #include <string>
>> #include <iostream>
>>
>> int main()
>> {
>>      constexpr int n = 1;
>>      constexpr int m = 10;
>>      std::string s = "abcd";
>>
>>      if (n < m || s.empty())
>>      {
>>          std::cout << "ok\n";
>>      }
>> }
>>
>> Is it reasonable that vs2019 produces a warning
>>
>> warning C4127:  conditional expression is constant
>> consider using 'if constexpr' statement instead
>>
>> g++ and clang do not, even with -Wall or -pedantic
>>
>> The context is generated code where n = 1, ... 10, 11 ...
> 
> It's reasonable here because `n < m` is always true, which is known at compile time, and `||` has short-circuit evaluation, which means that the non-`constexpr` empty checking of the string is not considered.
> 
> If you switch the values of `n` and `m` then `if constexpr` can no longer be used, because then, though the result is also then knowable at compile time, it isn't /necessarily/ known at compile time. The compiler needs some smarts to understand that `s.empty()` must be `false` here.
> 
> That said, I find the Visual C++ warning about constant conditions to be generally unreasonable. For example, it pops up if you write `while(2+2 == 4)` instead of the slightly more idiomatic `for(;;)`. Apparently it no longer does that for `while(true)`, but I just don't trust it, it's evidently tuned to ignore one special literal case, and that's it.

VC++ is correct to warn about while(2+2 == 4) and not for(;;) the later being the only acceptable why to do an endless loop (I don't agree that while(true) is just as good as it is syntactically less clean). The reason why VC++ is correct to warn about while(2+2 == 4) is that one of those 2's could be a typo and a variable was meant instead.

/Flibble

-- 
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

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

#70160

On Friday, 29 November 2019 18:33:53 UTC+2, Mr Flibble  wrote:
> 
> VC++ is correct to warn about while(2+2 == 4) and not for(;;) the later being the only acceptable why to do an endless loop (I don't agree that while(true) is just as good as it is syntactically less clean).

It was while(1) versus for(;;) last I saw anyone bothering to discuss 
those and these are still as apparently equivalent as these were back
then.

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

#70170

On 30/11/2019 01:52, Öö Tiib wrote:
> On Friday, 29 November 2019 18:33:53 UTC+2, Mr Flibble  wrote:
>>
>> VC++ is correct to warn about while(2+2 == 4) and not for(;;) the later being the only acceptable why to do an endless loop (I don't agree that while(true) is just as good as it is syntactically less clean).
> 
> It was while(1) versus for(;;) last I saw anyone bothering to discuss
> those and these are still as apparently equivalent as these were back
> then.
> 

I always use "while (true)" - and all my programs have that at least 
once, being small embedded systems.

I have never liked the look of "for (;;)" - and I fear that some email 
programs will turn it into a rather weird smiley!

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

#70173

On Saturday, 30 November 2019 13:04:07 UTC+2, David Brown  wrote:
> On 30/11/2019 01:52, Öö Tiib wrote:
> > On Friday, 29 November 2019 18:33:53 UTC+2, Mr Flibble  wrote:
> >>
> >> VC++ is correct to warn about while(2+2 == 4) and not for(;;) the later being the only acceptable why to do an endless loop (I don't agree that while(true) is just as good as it is syntactically less clean).
> > 
> > It was while(1) versus for(;;) last I saw anyone bothering to discuss
> > those and these are still as apparently equivalent as these were back
> > then.
> > 
> 
> I always use "while (true)" - and all my programs have that at least 
> once, being small embedded systems.

For me it is just style and it is not business of compiler to
regulate style. 
Especially annoying is the warning when someone had wrapped
function-like  macro's body into do { } while(false) and
then compiler starts to whine about while(false).
Until there are features available only in preprocessor we need
to use macros at places and so also safe idioms with those. 

> I have never liked the look of "for (;;)" - and I fear that some email 
> programs will turn it into a rather weird smiley!

Pasting to modern chats does it more likely than not. I just 
thought that in woodbrian's style of prefixing std with
:: we can get trigraph <:: in vector<string> that some eldery
compilers still support.

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

#70175

On 30/11/2019 12:47, Öö Tiib wrote:
> On Saturday, 30 November 2019 13:04:07 UTC+2, David Brown  wrote:
>> On 30/11/2019 01:52, Öö Tiib wrote:
>>> On Friday, 29 November 2019 18:33:53 UTC+2, Mr Flibble  wrote:
>>>>
>>>> VC++ is correct to warn about while(2+2 == 4) and not for(;;) the later being the only acceptable why to do an endless loop (I don't agree that while(true) is just as good as it is syntactically less clean).
>>>
>>> It was while(1) versus for(;;) last I saw anyone bothering to discuss
>>> those and these are still as apparently equivalent as these were back
>>> then.
>>>
>>
>> I always use "while (true)" - and all my programs have that at least
>> once, being small embedded systems.
> 
> For me it is just style and it is not business of compiler to
> regulate style.

Agreed.  Some prefer "while (true)", some prefer "for (;;)", and some 
prefer other variations.

Still, it is not unreasonable for a compiler to suppose that "while (2 + 
2 == 4)" is more likely to be a programmer mistake.  Sometimes the line 
between "unusual, inconsistent or lazy style" and "probable mistake" is 
not sharp, and a warning can be helpful - like a compiler warning on 
inconsistent indentation on nested if/else statements.


> Especially annoying is the warning when someone had wrapped
> function-like  macro's body into do { } while(false) and
> then compiler starts to whine about while(false).

That one would quickly get annoying.

> Until there are features available only in preprocessor we need
> to use macros at places and so also safe idioms with those.
> 
>> I have never liked the look of "for (;;)" - and I fear that some email
>> programs will turn it into a rather weird smiley!
> 
> Pasting to modern chats does it more likely than not. I just
> thought that in woodbrian's style of prefixing std with
> :: we can get trigraph <:: in vector<string> that some eldery
> compilers still support.
> 

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

#70079

[Multipart message — attachments visible in raw view] — view raw

Daniel writes:

> Consider
>
> #include <string>
> #include <iostream>
>
> int main()
> {
>     constexpr int n = 1;
>     constexpr int m = 10;
>     std::string s = "abcd";
>
>     if (n < m || s.empty())
>     {
>         std::cout << "ok\n";
>     }
> }
>
> Is it reasonable that vs2019 produces a warning
>
> warning C4127:  conditional expression is constant
> consider using 'if constexpr' statement instead

The compiler does not reject this code as ill-formed; and only issues a non- 
fatal diagnostic. This is entirely the compiler's prerogative.

Whether this or something else is "reasonable" is often a somewhat  
subjective matter. Someone might find it reasonable, this is a suggested  
optimization. Someone else may find this to be annoying. It is quite common  
to have constant expressions when doing template meta-programming, so the  
compiler's going to bark at you, now? That only servers as a discouragement  
from turning on the "treat all warning as fatal" prophylactic measures.  
That's the camp I'm in.

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

#70080

On Thursday, 28 November 2019 01:40:51 UTC+2, Sam  wrote:
> Daniel writes:
> 
> > Consider
> >
> > #include <string>
> > #include <iostream>
> >
> > int main()
> > {
> >     constexpr int n = 1;
> >     constexpr int m = 10;
> >     std::string s = "abcd";
> >
> >     if (n < m || s.empty())
> >     {
> >         std::cout << "ok\n";
> >     }
> > }
> >
> > Is it reasonable that vs2019 produces a warning
> >
> > warning C4127:  conditional expression is constant
> > consider using 'if constexpr' statement instead
> 
> The compiler does not reject this code as ill-formed; and only issues a non- 
> fatal diagnostic. This is entirely the compiler's prerogative.
> 
> Whether this or something else is "reasonable" is often a somewhat  
> subjective matter. Someone might find it reasonable, this is a suggested  
> optimization. Someone else may find this to be annoying. It is quite common  
> to have constant expressions when doing template meta-programming, so the  
> compiler's going to bark at you, now? That only servers as a discouragement  
> from turning on the "treat all warning as fatal" prophylactic measures.  
> That's the camp I'm in.

The subjectivity about warnings is easy to solve when programmer
works on code alone or is authority (everybody else are apprentices)
and there is just single tool/target that may warn.
Otherwise it is issue. 
 
A) Disable the warning globally? - It may be valuable hint in some 
   other situation.
B) Disable the warning locally? - Code can become ugly with pragmas,
   attributes and special comments.
C) Ignore the warning? - Build log can become scroll of false positives
   and some IDEs full of distracting orange <!> lines.
D) Refactor code in a way that it does not warn? - Refactoring has
   always chance to cause actual defects and some other tool may start
   to warn about some other aspect of result.

In bigger project it is worth communicating, reasoning, deciding
and even documenting what to do with it case by case.
On several cases consensus can be achieved in bigger community than
just single project. I presumed that OP asked it in hope of that.

For me if constexpr is relatively new performance optimization.
So in practice I would disable the warning globally on general
case and leave it on only in performance-analyzing builds but
revisit that decision after every release. What is reasonable
now may become backwards few years later.

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

#70150

On 28/11/2019 07:16, Öö Tiib wrote:
> On Thursday, 28 November 2019 01:40:51 UTC+2, Sam  wrote:
>> Daniel writes:
>>
>>> Consider
>>>
>>> #include <string>
>>> #include <iostream>
>>>
>>> int main()
>>> {
>>>      constexpr int n = 1;
>>>      constexpr int m = 10;
>>>      std::string s = "abcd";
>>>
>>>      if (n < m || s.empty())
>>>      {
>>>          std::cout << "ok\n";
>>>      }
>>> }
>>>
>>> Is it reasonable that vs2019 produces a warning
>>>
>>> warning C4127:  conditional expression is constant
>>> consider using 'if constexpr' statement instead
>>
>> The compiler does not reject this code as ill-formed; and only issues a non-
>> fatal diagnostic. This is entirely the compiler's prerogative.
>>
>> Whether this or something else is "reasonable" is often a somewhat
>> subjective matter. Someone might find it reasonable, this is a suggested
>> optimization. Someone else may find this to be annoying. It is quite common
>> to have constant expressions when doing template meta-programming, so the
>> compiler's going to bark at you, now? That only servers as a discouragement
>> from turning on the "treat all warning as fatal" prophylactic measures.
>> That's the camp I'm in.
> 
> The subjectivity about warnings is easy to solve when programmer
> works on code alone or is authority (everybody else are apprentices)
> and there is just single tool/target that may warn.
> Otherwise it is issue.
>   
> A) Disable the warning globally? - It may be valuable hint in some
>     other situation.
> B) Disable the warning locally? - Code can become ugly with pragmas,
>     attributes and special comments.
> C) Ignore the warning? - Build log can become scroll of false positives
>     and some IDEs full of distracting orange <!> lines.
> D) Refactor code in a way that it does not warn? - Refactoring has
>     always chance to cause actual defects and some other tool may start
>     to warn about some other aspect of result.
> 
> In bigger project it is worth communicating, reasoning, deciding
> and even documenting what to do with it case by case.
> On several cases consensus can be achieved in bigger community than
> just single project. I presumed that OP asked it in hope of that.
> 
> For me if constexpr is relatively new performance optimization.
> So in practice I would disable the warning globally on general
> case and leave it on only in performance-analyzing builds but
> revisit that decision after every release. What is reasonable
> now may become backwards few years later.

Utter tosh. if constexpr is far more than a "performance optimization"; it is especially useful in template code.

/Flibble

-- 
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

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

#70159

On Friday, 29 November 2019 18:35:35 UTC+2, Mr Flibble  wrote:
> On 28/11/2019 07:16, Öö Tiib wrote:
> > On Thursday, 28 November 2019 01:40:51 UTC+2, Sam  wrote:
> >> Daniel writes:
> >>
> >>> Consider
> >>>
> >>> #include <string>
> >>> #include <iostream>
> >>>
> >>> int main()
> >>> {
> >>>      constexpr int n = 1;
> >>>      constexpr int m = 10;
> >>>      std::string s = "abcd";
> >>>
> >>>      if (n < m || s.empty())
> >>>      {
> >>>          std::cout << "ok\n";
> >>>      }
> >>> }
> >>>
> >>> Is it reasonable that vs2019 produces a warning
> >>>
> >>> warning C4127:  conditional expression is constant
> >>> consider using 'if constexpr' statement instead
> >>
> >> The compiler does not reject this code as ill-formed; and only issues a non-
> >> fatal diagnostic. This is entirely the compiler's prerogative.
> >>
> >> Whether this or something else is "reasonable" is often a somewhat
> >> subjective matter. Someone might find it reasonable, this is a suggested
> >> optimization. Someone else may find this to be annoying. It is quite common
> >> to have constant expressions when doing template meta-programming, so the
> >> compiler's going to bark at you, now? That only servers as a discouragement
> >> from turning on the "treat all warning as fatal" prophylactic measures.
> >> That's the camp I'm in.
> > 
> > The subjectivity about warnings is easy to solve when programmer
> > works on code alone or is authority (everybody else are apprentices)
> > and there is just single tool/target that may warn.
> > Otherwise it is issue.
> >   
> > A) Disable the warning globally? - It may be valuable hint in some
> >     other situation.
> > B) Disable the warning locally? - Code can become ugly with pragmas,
> >     attributes and special comments.
> > C) Ignore the warning? - Build log can become scroll of false positives
> >     and some IDEs full of distracting orange <!> lines.
> > D) Refactor code in a way that it does not warn? - Refactoring has
> >     always chance to cause actual defects and some other tool may start
> >     to warn about some other aspect of result.
> > 
> > In bigger project it is worth communicating, reasoning, deciding
> > and even documenting what to do with it case by case.
> > On several cases consensus can be achieved in bigger community than
> > just single project. I presumed that OP asked it in hope of that.
> > 
> > For me if constexpr is relatively new performance optimization.
> > So in practice I would disable the warning globally on general
> > case and leave it on only in performance-analyzing builds but
> > revisit that decision after every release. What is reasonable
> > now may become backwards few years later.
> 
> Utter tosh. if constexpr is far more than a "performance optimization"; it is especially useful in template code.

Utter jive, it was warning C4127 under discussion not usefulness of
if constexpr. What is the value warning C4127 "consider hinting me
that we can performance-optimize here."?

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

#70081

On 28/11/2019 00:40, Sam wrote:
> Daniel writes:
> 
>> Consider
>>
>> #include <string>
>> #include <iostream>
>>
>> int main()
>> {
>>     constexpr int n = 1;
>>     constexpr int m = 10;
>>     std::string s = "abcd";
>>
>>     if (n < m || s.empty())
>>     {
>>         std::cout << "ok\n";
>>     }
>> }
>>
>> Is it reasonable that vs2019 produces a warning
>>
>> warning C4127:  conditional expression is constant
>> consider using 'if constexpr' statement instead
> 
> The compiler does not reject this code as ill-formed; and only issues a
> non-fatal diagnostic. This is entirely the compiler's prerogative.
> 
> Whether this or something else is "reasonable" is often a somewhat
> subjective matter. Someone might find it reasonable, this is a suggested
> optimization.

It should not be a "suggested optimisation".  If the compiler is not
generating identical code for an "if constexpr" and an "if" where the
expression happens to be known at compile time (whether it is
technically a C++ constant or not), then the compiler is doing a poor
job at optimising.

I had a check at <https://godbolt.org> with the simpler test variation:


#include <string>

int foo()
{
    constexpr int n = 1;
    constexpr int m = 10;
    std::string s = "abcd";

    if (n < m || s.empty())
    {
        return 1;
    }
    return 0;
}

It turns out that MSVC (/O2 /Wall /std:c++17) generates a whole pile of
muck for that code.  It takes about 40 lines of assembly (excluding
string library functions) while it creates and deletes the string, adds
calls to "__security_check_cookie", whatever that is.  However, it
generates the same pile when "constexpr" is added.  (It also generates
an extraordinary quantity of warnings from its own headers here - is
that normal for MSVC, or is it an artefact of the godbolt.org setup or
my incomplete knowledge of MSVC command line parameters?)

gcc and clang, on the other hand generates a single "return 1;" result
whether you have "constexpr" or not.  And no warnings with "-Wall -Wextra".


> Someone else may find this to be annoying. It is quite
> common to have constant expressions when doing template
> meta-programming, so the compiler's going to bark at you, now? That only
> servers as a discouragement from turning on the "treat all warning as
> fatal" prophylactic measures. That's the camp I'm in.
> 

After seeing the almost endless list of warnings MSVC produced with that
test (again, let me stress this could be due to the way I used it) I can
understand that it would take a great deal of warning parameter tuning
before "treat all warnings as errors" could be considered with that
compiler.

gcc used to have a warning for when it eliminated dead code, which would
have triggered on code like this.  The warning was removed long ago,
since dead code is a natural result of optimisations (especially
inter-procedural optimisations and constant and range propagations), and
lead to large amounts of false positives.

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

#70082

On 2019-11-28 at 10:24, David Brown wrote:
> On 28/11/2019 00:40, Sam wrote:
>> Daniel writes:
>>
>>> Consider
>>>
>>> #include <string>
>>> #include <iostream>
>>>
>>> int main()
>>> {
>>>      constexpr int n = 1;
>>>      constexpr int m = 10;
>>>      std::string s = "abcd";
>>>
>>>      if (n < m || s.empty())
>>>      {
>>>          std::cout << "ok\n";
>>>      }
>>> }
>>>
>>> Is it reasonable that vs2019 produces a warning
>>>
>>> warning C4127:  conditional expression is constant
>>> consider using 'if constexpr' statement instead
>>
>> The compiler does not reject this code as ill-formed; and only issues a
>> non-fatal diagnostic. This is entirely the compiler's prerogative.
>>
>> Whether this or something else is "reasonable" is often a somewhat
>> subjective matter. Someone might find it reasonable, this is a suggested
>> optimization.
> 
> It should not be a "suggested optimisation".  If the compiler is not
> generating identical code for an "if constexpr" and an "if" where the
> expression happens to be known at compile time (whether it is
> technically a C++ constant or not), then the compiler is doing a poor
> job at optimising.
> 
> I had a check at <https://godbolt.org> with the simpler test variation:
> 
> 
> #include <string>
> 
> int foo()
> {
>      constexpr int n = 1;
>      constexpr int m = 10;
>      std::string s = "abcd";
> 
>      if (n < m || s.empty())
>      {
>          return 1;
>      }
>      return 0;
> }
> 
> It turns out that MSVC (/O2 /Wall /std:c++17) generates a whole pile of
> muck for that code.  It takes about 40 lines of assembly (excluding
> string library functions) while it creates and deletes the string, adds
> calls to "__security_check_cookie", whatever that is.  However, it
> generates the same pile when "constexpr" is added.  (It also generates
> an extraordinary quantity of warnings from its own headers here - is
> that normal for MSVC, or is it an artefact of the godbolt.org setup or
> my incomplete knowledge of MSVC command line parameters?)
> 
> gcc and clang, on the other hand generates a single "return 1;" result
> whether you have "constexpr" or not.  And no warnings with "-Wall -Wextra".
> 
> 

You should probably blaim this on the settings for Godbolt.org

Running locally, and adding a main function containing return foo(), it 
results in

--- C:\Users\BoP\source\reference\quick_test.cpp 
-------------------------------
    return foo();
00007FF6BB091000  mov         eax,1
}
00007FF6BB091005  ret


On the other hand, Visual Studio reports that it is using the compiler 
options

//permissive- /GS- /Zc:rvalueCast /GL /W4 /Gy /Zc:wchar_t /Zi /Gm- /O2 
/Ob2 /Fd"x64\Release\vc142.pdb" /Zc:inline /fp:precise /D "_UNICODE" /D 
"UNICODE" /errorReport:prompt /GF /WX /Zc:forScope /GR /arch:AVX2 /Gd 
/Oy /Oi /MD /std:c++latest /FC /Fa"x64\Release\" /EHsc /nologo 
/Fo"x64\Release\" /Ot /Fp"x64\Release\quick_test_ms.pch" 
/diagnostics:column


Don't know exactly which one makes the difference.  :-)


    Bo Persson

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

#70083

On 28/11/2019 11:58, Bo Persson wrote:
> On 2019-11-28 at 10:24, David Brown wrote:
>> On 28/11/2019 00:40, Sam wrote:
>>> Daniel writes:
>>>
>>>> Consider
>>>>
>>>> #include <string>
>>>> #include <iostream>
>>>>
>>>> int main()
>>>> {
>>>>      constexpr int n = 1;
>>>>      constexpr int m = 10;
>>>>      std::string s = "abcd";
>>>>
>>>>      if (n < m || s.empty())
>>>>      {
>>>>          std::cout << "ok\n";
>>>>      }
>>>> }
>>>>
>>>> Is it reasonable that vs2019 produces a warning
>>>>
>>>> warning C4127:  conditional expression is constant
>>>> consider using 'if constexpr' statement instead
>>>
>>> The compiler does not reject this code as ill-formed; and only issues a
>>> non-fatal diagnostic. This is entirely the compiler's prerogative.
>>>
>>> Whether this or something else is "reasonable" is often a somewhat
>>> subjective matter. Someone might find it reasonable, this is a suggested
>>> optimization.
>>
>> It should not be a "suggested optimisation".  If the compiler is not
>> generating identical code for an "if constexpr" and an "if" where the
>> expression happens to be known at compile time (whether it is
>> technically a C++ constant or not), then the compiler is doing a poor
>> job at optimising.
>>
>> I had a check at <https://godbolt.org> with the simpler test variation:
>>
>>
>> #include <string>
>>
>> int foo()
>> {
>>      constexpr int n = 1;
>>      constexpr int m = 10;
>>      std::string s = "abcd";
>>
>>      if (n < m || s.empty())
>>      {
>>          return 1;
>>      }
>>      return 0;
>> }
>>
>> It turns out that MSVC (/O2 /Wall /std:c++17) generates a whole pile of
>> muck for that code.  It takes about 40 lines of assembly (excluding
>> string library functions) while it creates and deletes the string, adds
>> calls to "__security_check_cookie", whatever that is.  However, it
>> generates the same pile when "constexpr" is added.  (It also generates
>> an extraordinary quantity of warnings from its own headers here - is
>> that normal for MSVC, or is it an artefact of the godbolt.org setup or
>> my incomplete knowledge of MSVC command line parameters?)
>>
>> gcc and clang, on the other hand generates a single "return 1;" result
>> whether you have "constexpr" or not.  And no warnings with "-Wall
>> -Wextra".
>>
>>
> 
> You should probably blaim this on the settings for Godbolt.org
> 
> Running locally, and adding a main function containing return foo(), it
> results in
> 
> --- C:\Users\BoP\source\reference\quick_test.cpp
> -------------------------------
>    return foo();
> 00007FF6BB091000  mov         eax,1
> }
> 00007FF6BB091005  ret
> 
> 
> On the other hand, Visual Studio reports that it is using the compiler
> options
> 
> //permissive- /GS- /Zc:rvalueCast /GL /W4 /Gy /Zc:wchar_t /Zi /Gm- /O2
> /Ob2 /Fd"x64\Release\vc142.pdb" /Zc:inline /fp:precise /D "_UNICODE" /D
> "UNICODE" /errorReport:prompt /GF /WX /Zc:forScope /GR /arch:AVX2 /Gd
> /Oy /Oi /MD /std:c++latest /FC /Fa"x64\Release\" /EHsc /nologo
> /Fo"x64\Release\" /Ot /Fp"x64\Release\quick_test_ms.pch"
> /diagnostics:column
> 
> 
> Don't know exactly which one makes the difference.  :-)
> 

OK.  As I said, I don't know the command line switches for MSVC - I just
used the ones I knew for optimisation, warnings and standard version.

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

#70088

On Thu, 28 Nov 2019 11:58:40 +0100, Bo Persson <bo@bo-persson.se>
wrote:

>On 2019-11-28 at 10:24, David Brown wrote:
>> On 28/11/2019 00:40, Sam wrote:
>>> Daniel writes:
>>>
>>>> Consider
>>>>
>>>> #include <string>
>>>> #include <iostream>
>>>>
>>>> int main()
>>>> {
>>>>      constexpr int n = 1;
>>>>      constexpr int m = 10;
>>>>      std::string s = "abcd";
>>>>
>>>>      if (n < m || s.empty())
>>>>      {
>>>>          std::cout << "ok\n";
>>>>      }
>>>> }
>>>>
>>>> Is it reasonable that vs2019 produces a warning
>>>>
>>>> warning C4127:  conditional expression is constant
>>>> consider using 'if constexpr' statement instead
>>>
>>> The compiler does not reject this code as ill-formed; and only issues a
>>> non-fatal diagnostic. This is entirely the compiler's prerogative.
>>>
>>> Whether this or something else is "reasonable" is often a somewhat
>>> subjective matter. Someone might find it reasonable, this is a suggested
>>> optimization.
>> 
>> It should not be a "suggested optimisation".  If the compiler is not
>> generating identical code for an "if constexpr" and an "if" where the
>> expression happens to be known at compile time (whether it is
>> technically a C++ constant or not), then the compiler is doing a poor
>> job at optimising.
>> 
>> I had a check at <https://godbolt.org> with the simpler test variation:
>> 
>> 
>> #include <string>
>> 
>> int foo()
>> {
>>      constexpr int n = 1;
>>      constexpr int m = 10;
>>      std::string s = "abcd";
>> 
>>      if (n < m || s.empty())
>>      {
>>          return 1;
>>      }
>>      return 0;
>> }
>> 
>> It turns out that MSVC (/O2 /Wall /std:c++17) generates a whole pile of
>> muck for that code.  It takes about 40 lines of assembly (excluding
>> string library functions) while it creates and deletes the string, adds
>> calls to "__security_check_cookie", whatever that is.  However, it
>> generates the same pile when "constexpr" is added.  (It also generates
>> an extraordinary quantity of warnings from its own headers here - is
>> that normal for MSVC, or is it an artefact of the godbolt.org setup or
>> my incomplete knowledge of MSVC command line parameters?)
>> 
>> gcc and clang, on the other hand generates a single "return 1;" result
>> whether you have "constexpr" or not.  And no warnings with "-Wall -Wextra".
>> 
>> 
>
>You should probably blaim this on the settings for Godbolt.org
>
>Running locally, and adding a main function containing return foo(), it 
>results in
>
>--- C:\Users\BoP\source\reference\quick_test.cpp 
>-------------------------------
>    return foo();
>00007FF6BB091000  mov         eax,1
>}
>00007FF6BB091005  ret


I've noticed the same effect a number of times - MSVC has, for quite a
while, tends to generate somewhat naive code for the basic function in
some cases, while going to town on optimization for inlined versions.
Not always, just sometimes, I've never quite figured out why - I've
usually assumed better parameter aliasing resolution for the inlined
version, although that would hardly apply to this example.


>On the other hand, Visual Studio reports that it is using the compiler 
>options
>
>//permissive- /GS- /Zc:rvalueCast /GL /W4 /Gy /Zc:wchar_t /Zi /Gm- /O2 
>/Ob2 /Fd"x64\Release\vc142.pdb" /Zc:inline /fp:precise /D "_UNICODE" /D 
>"UNICODE" /errorReport:prompt /GF /WX /Zc:forScope /GR /arch:AVX2 /Gd 
>/Oy /Oi /MD /std:c++latest /FC /Fa"x64\Release\" /EHsc /nologo 
>/Fo"x64\Release\" /Ot /Fp"x64\Release\quick_test_ms.pch" 
>/diagnostics:column
>
>
>Don't know exactly which one makes the difference.  :-)


Almost certainly /W4 instead of /Wall.  The latter is pretty unusable.

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

#70141

On 28/11/2019 21:04, Robert Wessel wrote:
> On Thu, 28 Nov 2019 11:58:40 +0100, Bo Persson <bo@bo-persson.se>
> wrote:
<snip>
> 
> I've noticed the same effect a number of times - MSVC has, for quite a
> while, tends to generate somewhat naive code for the basic function in
> some cases, while going to town on optimization for inlined versions.
> Not always, just sometimes, I've never quite figured out why - I've
> usually assumed better parameter aliasing resolution for the inlined
> version, although that would hardly apply to this example.
> 
> 
>> On the other hand, Visual Studio reports that it is using the compiler 
>> options
>>
>> //permissive- /GS- /Zc:rvalueCast /GL /W4 /Gy /Zc:wchar_t /Zi /Gm- /O2 
>> /Ob2 /Fd"x64\Release\vc142.pdb" /Zc:inline /fp:precise /D "_UNICODE" /D 
>> "UNICODE" /errorReport:prompt /GF /WX /Zc:forScope /GR /arch:AVX2 /Gd 
>> /Oy /Oi /MD /std:c++latest /FC /Fa"x64\Release\" /EHsc /nologo 
>> /Fo"x64\Release\" /Ot /Fp"x64\Release\quick_test_ms.pch" 
>> /diagnostics:column
>>
>>
>> Don't know exactly which one makes the difference.  :-)
> 
> 
> Almost certainly /W4 instead of /Wall.  The latter is pretty unusable.
> 

I am unlikely to remember all the switches given by Bo (though I will
remember that any oddities I see in MSVC may be alleviated by switches).
 But I will definitely try to remember /W4 instead of /Wall.  I guess
MSVC takes "/Wall" more literally than gcc "-Wall".

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

#70155

On Fri, 29 Nov 2019 09:23:27 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>On 28/11/2019 21:04, Robert Wessel wrote:
>> On Thu, 28 Nov 2019 11:58:40 +0100, Bo Persson <bo@bo-persson.se>
>> wrote:
><snip>
>> 
>> I've noticed the same effect a number of times - MSVC has, for quite a
>> while, tends to generate somewhat naive code for the basic function in
>> some cases, while going to town on optimization for inlined versions.
>> Not always, just sometimes, I've never quite figured out why - I've
>> usually assumed better parameter aliasing resolution for the inlined
>> version, although that would hardly apply to this example.
>> 
>> 
>>> On the other hand, Visual Studio reports that it is using the compiler 
>>> options
>>>
>>> //permissive- /GS- /Zc:rvalueCast /GL /W4 /Gy /Zc:wchar_t /Zi /Gm- /O2 
>>> /Ob2 /Fd"x64\Release\vc142.pdb" /Zc:inline /fp:precise /D "_UNICODE" /D 
>>> "UNICODE" /errorReport:prompt /GF /WX /Zc:forScope /GR /arch:AVX2 /Gd 
>>> /Oy /Oi /MD /std:c++latest /FC /Fa"x64\Release\" /EHsc /nologo 
>>> /Fo"x64\Release\" /Ot /Fp"x64\Release\quick_test_ms.pch" 
>>> /diagnostics:column
>>>
>>>
>>> Don't know exactly which one makes the difference.  :-)
>> 
>> 
>> Almost certainly /W4 instead of /Wall.  The latter is pretty unusable.
>> 
>
>I am unlikely to remember all the switches given by Bo (though I will
>remember that any oddities I see in MSVC may be alleviated by switches).
> But I will definitely try to remember /W4 instead of /Wall.  I guess
>MSVC takes "/Wall" more literally than gcc "-Wall".


That's about true.  /Wall is actually pretty much *everything* in
MSVC.  /W4 is pretty much everything rational in most cases, more like
what you get with GCC's -Wall plus most of -Wextra.

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

#70105

On Thursday, November 28, 2019 at 4:25:03 AM UTC-5, David Brown wrote:
> 
> If the compiler is not
> generating identical code for an "if constexpr" and an "if" where the
> expression happens to be known at compile time (whether it is
> technically a C++ constant or not), then the compiler is doing a poor
> job at optimising.
> 
Which raises the question, what is the point of the constexpr if statement anyway? 

Daniel

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

#70106

On 29.11.2019 06:09, Daniel wrote:
> On Thursday, November 28, 2019 at 4:25:03 AM UTC-5, David Brown wrote:
>>
>> If the compiler is not
>> generating identical code for an "if constexpr" and an "if" where the
>> expression happens to be known at compile time (whether it is
>> technically a C++ constant or not), then the compiler is doing a poor
>> job at optimising.
>>
> Which raises the question, what is the point of the constexpr if statement anyway?

Two main points:

* It communicates to a human reader that the expression is evaluated at 
compile time, guaranteed.
* In a function template the path not taken in a given instantiation, 
can contain code that wouldn't compile in that instantiation.

Maybe more, but it's late in the day for me.

- Alf

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

#70139

On Friday, 29 November 2019 07:09:19 UTC+2, Daniel  wrote:
> On Thursday, November 28, 2019 at 4:25:03 AM UTC-5, David Brown wrote:
> > 
> > If the compiler is not
> > generating identical code for an "if constexpr" and an "if" where the
> > expression happens to be known at compile time (whether it is
> > technically a C++ constant or not), then the compiler is doing a poor
> > job at optimising.
> > 
> Which raises the question, what is the point of the constexpr if statement anyway? 

In template code it is like super #if but outside of templates it is
basically only for to tell to readers, maintainers and compiler that
the condition is supposed to be constant expression by original logic
and something is perhaps gone bad when it is not anymore.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web