A question about if constexpr

[Daniel]

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

[Alf P. Steinbach]

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

[Sam]

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.

[Öö Tiib]

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.

[David Brown]

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.

[Bo Persson]

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

[David Brown]

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.

[Robert Wessel]

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

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.

[Tim Rentsch]

Daniel <daniel...@gmail.com> 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

Let me rephrase your question as a multiple choice:

"A compiler operating under default option settings
produces this warning message for the above program.
Would you be more likely to describe this choice as

(A) reasonable, or

(B) monumentally stupid?"

Asked like this, my answer would be (B).

There are, I am sure, a large number of related questions,
for which I expect I would give various answers depending
on the particular question.

[Daniel]

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

[Alf P. Steinbach]

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

[Öö Tiib]

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.

[David Brown]

On 28/11/2019 21:04, Robert Wessel wrote:
> On Thu, 28 Nov 2019 11:58:40 +0100, Bo Persson <b...@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".

[David Brown]

The part omitted by the false branch has to be able to compile, but
otherwise doesn't affect the code. For example:

const bool return_int = true;

auto foo(void) {
if constexpr(return_int) {
return 1;
} else {
return 1.0;
}
}

The return type of "foo" is determined by the "if constexpr". Without
the "constexpr", you would get an inconsistent deduction for the return
type.

Typically, you will see "if constexpr" in templates, I expect.

[David Brown]

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

One other point is that since the discarded part is discarded, any
identifiers it uses do not need to be defined or linked in with the code.

[Paavo Helde]

On 28.11.2019 11:24, David Brown wrote:
> 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".

An interesting example demonstrating the benefits of short string
optimization. If the constructor or destructor of an otherwise
effectively unused local object (as s above) call non-inlined functions,
the optimizer cannot (so easily) remove the whole instance. Indeed, the
following code produces ca 30 lines of assembly with gcc 9.2 and
-std=c++17 -O3, including calls to std::basic_string::_M_create and
operator delete:

#include <string>

int foo()
{
constexpr int n = 1;
constexpr int m = 10;

std::string s = "abcdabcdabcdabcd";

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

MSVC also has short string optimization, but it seems by some reason the
optimizer has not understood it can apply that for std::string s =
"abcd"; or std::string s("abcd"). Interestingly enough, if one writes
the string initialization as

std::string s("abcd", 4);

then also MSVC is able to optimize it away and produces:

int foo(void) PROC ; foo
mov eax, 1
ret 0
int foo(void) ENDP ; foo


So it appears this example is more about SSO and does not tell much
about constexpr.

[Mr Flibble]

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

[Mr Flibble]

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

[Robert Wessel]

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.

[Öö Tiib]

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

[Öö Tiib]

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.

[Öö Tiib]

I'm in doubt about that other point. I noticed it long time ago that
the implementations do not link useless functions. It was like 2004
or maybe 2007.

I did delete unused functions after refactoring and since there
was tens of such I used impossibility to set breakpoints in those
as heuristic that these are now unused.

However my program became ill-formed since I had erased one that
was optimized out but not because it wasn't called but because it
was called only in branch that was impossible to take.

So compilers did not need if constexpr back then for it ... why
these suddenly started to need it now?

[Paavo Helde]

You answered that yourself: constexpr is needed to make your ill-formed
program well-formed again.

[Ned Latham]

Paavo Helde wrote:

No. What would make his program well formed is the removal of that
"branch that [is] impossible to take".

(HTF doesd one *write* such a branch?)

[Öö Tiib]

+1 That did make it.

> (HTF doesd one *write* such a branch?)

It was the effect of evolution. About like that one developer wrote
a new feature, other fixed some issue in it and third implemented
an improvement. Details in if condition did change during the process
so it turned into always false. Neither those programmers nor reviewers
of their pull requests did notice that. Perhaps there was some mile-
stone pressing as it often is. Then it was released, real data arrived
(with what performance of it was weak) and that refactoring took place.

[Ned Latham]

嘱 Tiib wrote:
> Ned Latham wrote:
> > Paavo Helde wrote:
> > > 嘱 Tiib wrote:
> > > > David Brown wrote:
> > > > >
> > > > > One other point is that since the discarded part is discarded,
> > > > > any identifiers it uses do not need to be defined or linked in
> > > > > with the code.
> > > >
> > > > I'm in doubt about that other point. I noticed it long time ago that
> > > > the implementations do not link useless functions. It was like 2004
> > > > or maybe 2007.
> > > >
> > > > I did delete unused functions after refactoring and since there
> > > > was tens of such I used impossibility to set breakpoints in those
> > > > as heuristic that these are now unused.
> > > >
> > > > However my program became ill-formed since I had erased one that
> > > > was optimized out but not because it wasn't called but because it
> > > > was called only in branch that was impossible to take.
> > > >
> > > > So compilers did not need if constexpr back then for it ... why
> > > > these suddenly started to need it now?
> > >
> > > You answered that yourself: constexpr is needed to make your ill-formed
> > > program well-formed again.
> >
> > No. What would make his program well formed is the removal of that
> > "branch that [is] impossible to take".
>
> +1 That did make it.

Glad to help. You've erased the function it called as well?

> > (HTF does one *write* such a branch?)

>
> It was the effect of evolution. About like that one developer wrote
> a new feature, other fixed some issue in it and third implemented
> an improvement. Details in if condition did change during the process
> so it turned into always false. Neither those programmers nor reviewers
> of their pull requests did notice that. Perhaps there was some mile-
> stone pressing as it often is.

I've been there. The commercial environment is hostile to thoroughness.

> Then it was released, real data arrived
> (with what performance of it was weak) and that refactoring took place.

I have some difficulty with the mindset behind program development
these days; IDEs provide features that make routine programming
easier, but get in the way of the unorthodox approach; compilers
do the same; even operating systems can be a nuisance.

I cut my teeth on assembly-language programming on CP/M machines;
thoroughness is productive in that environment, and it translated
well for me into HLLs.

[David Brown]

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!

[Öö Tiib]

On Saturday, 30 November 2019 12:56:59 UTC+2, Ned Latham wrote:

> Öö Tiib wrote:
> > Ned Latham wrote:
> > > Paavo Helde wrote:

> > > > Öö Tiib wrote:
> > > > > David Brown wrote:
> > > > > >
> > > > > > One other point is that since the discarded part is discarded,
> > > > > > any identifiers it uses do not need to be defined or linked in
> > > > > > with the code.
> > > > >
> > > > > I'm in doubt about that other point. I noticed it long time ago that
> > > > > the implementations do not link useless functions. It was like 2004
> > > > > or maybe 2007.
> > > > >
> > > > > I did delete unused functions after refactoring and since there
> > > > > was tens of such I used impossibility to set breakpoints in those
> > > > > as heuristic that these are now unused.
> > > > >
> > > > > However my program became ill-formed since I had erased one that
> > > > > was optimized out but not because it wasn't called but because it
> > > > > was called only in branch that was impossible to take.
> > > > >
> > > > > So compilers did not need if constexpr back then for it ... why
> > > > > these suddenly started to need it now?
> > > >
> > > > You answered that yourself: constexpr is needed to make your ill-formed
> > > > program well-formed again.
> > >
> > > No. What would make his program well formed is the removal of that
> > > "branch that [is] impossible to take".
> >
> > +1 That did make it.
>
> Glad to help. You've erased the function it called as well?

That happened in previous step:
1) Compiler left it out from executable,
2) I erased it from code since break-point was impossible to set in it,
3) I erased the worthless branch that stopped to compile.

>
> > > (HTF does one *write* such a branch?)
> >
> > It was the effect of evolution. About like that one developer wrote
> > a new feature, other fixed some issue in it and third implemented
> > an improvement. Details in if condition did change during the process
> > so it turned into always false. Neither those programmers nor reviewers
> > of their pull requests did notice that. Perhaps there was some mile-
> > stone pressing as it often is.
>
> I've been there. The commercial environment is hostile to thoroughness.
>
> > Then it was released, real data arrived
> > (with what performance of it was weak) and that refactoring took place.
>
> I have some difficulty with the mindset behind program development
> these days; IDEs provide features that make routine programming
> easier, but get in the way of the unorthodox approach; compilers
> do the same; even operating systems can be a nuisance.
>
> I cut my teeth on assembly-language programming on CP/M machines;
> thoroughness is productive in that environment, and it translated
> well for me into HLLs.

Yes, it has gone harder since all tools have became easier to use
but also the targets are more complicated. It is tried to solve
by adding more programmers but synchronizing their effort is also
an effort. At the end everybody's vision of what is going on is
naive but things get somehow done.

[Ned Latham]

嘱 Tiib wrote:
> Ned Latham wrote:

----snip----

> > I have some difficulty with the mindset behind program development
> > these days; IDEs provide features that make routine programming
> > easier, but get in the way of the unorthodox approach; compilers
> > do the same; even operating systems can be a nuisance.
>

> Yes, it has gone harder since all tools have became easier to use
> but also the targets are more complicated. It is tried to solve
> by adding more programmers but synchronizing their effort is also
> an effort. At the end everybody's vision of what is going on is
> naive but things get somehow done.

That "somehow" bothers me. It's what started the over-complication
of the programming environment in the first place, IMO, and it
continues to influence development in all areas.

[Öö Tiib]

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.

[Öö Tiib]

On Saturday, 30 November 2019 13:39:12 UTC+2, Ned Latham wrote:

It has been going on for long time. Notice that the project was in
mid 2000's. Currently teams of teams of programmers of random skill
levels are doing any (even embedded) projects. It is more like norm.
So piles of such somehow made stuff is of what our economies consist
of.

But what can we do? Imagine that we organize some kind of "order of
masters" to fight with garbage and for virtue of master. Imagine
that we gain power and popularity. Then some monster (Google,
Microsoft, Amazon, SAP, Oracle, Apple or combo of such) will figure
out how to weaken it, buy it, fill with weasels and noobs and use it
for producing and marketing of even more garbage. ;)
It is hard to do something that is tricky to hack with power of
monsters. But maybe worth to try? :D

[David Brown]

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.

[Ned Latham]

嘱 Tiib wrote:
> Ned Latham wrote:

Funny you should mention that. I have a project XBNF, which is an
eXtended Backus Naur Formalism (like EBNF but extended a little
more), and a co-project xbnf, which is a machine reader for XBNF.

If you give xbnf the XBNF definition of the syntax of a programming
language and the XBNF definition of syntax errors in that language,
and matching error messages, it will check the syntax for you and
emit error messages. You can give it other XBNF definitions too;
matching program commands and High Level Language Productions (HLLP),
to emit the first stage of a compilation.

XBNF can also define the syntax matching HHLPs with Assembly Language
Productions, and OS Productions, and Machine Architecture Productions;
with all that xbnf becomes a full-flown compiler capable of running on
any machine it can be compiled for, and capable of compiling code in
any programming language whatever, for any OS whatever, and to run on
pretty much on any machine whatever.

Configuration (writing all those syntax files) will be a bitch without
a share setup, and as a compiler, it'll be pretty simple, but you'll
be able to define (say) C++ with or without things like constexpr as
suits you. We'll be free of the tyranny of the compiler-writers. It's
a hacker's wet dream.

And it's open source. Anyone who gets a copy is an obstacle to the
corporates that would sabotage it.

If I can get it done.

[Öö Tiib]

On Saturday, 30 November 2019 17:47:15 UTC+2, Ned Latham wrote:
> Öö Tiib wrote:
> >

> > But what can we do? Imagine that we organize some kind of "order of
> > masters" to fight with garbage and for virtue of master. Imagine
> > that we gain power and popularity. Then some monster (Google,
> > Microsoft, Amazon, SAP, Oracle, Apple or combo of such) will figure
> > out how to weaken it, buy it, fill with weasels and noobs and use it
> > for producing and marketing of even more garbage. ;)
> > It is hard to do something that is tricky to hack with power of
> > monsters. But maybe worth to try? :D
>
> Funny you should mention that. I have a project XBNF, which is an
> eXtended Backus Naur Formalism (like EBNF but extended a little
> more), and a co-project xbnf, which is a machine reader for XBNF.
>
> If you give xbnf the XBNF definition of the syntax of a programming
> language and the XBNF definition of syntax errors in that language,
> and matching error messages, it will check the syntax for you and
> emit error messages. You can give it other XBNF definitions too;
> matching program commands and High Level Language Productions (HLLP),
> to emit the first stage of a compilation.
>
> XBNF can also define the syntax matching HHLPs with Assembly Language
> Productions, and OS Productions, and Machine Architecture Productions;
> with all that xbnf becomes a full-flown compiler capable of running on
> any machine it can be compiled for, and capable of compiling code in
> any programming language whatever, for any OS whatever, and to run on
> pretty much on any machine whatever.

Sounds like you are also claiming doing what Mr Flibble is claiming doing.
Very interesting. If neither Mr Flibble nor you are just trolling then
may be you should try to cooperate or to compete or something like that.

> Configuration (writing all those syntax files) will be a bitch without
> a share setup, and as a compiler, it'll be pretty simple, but you'll
> be able to define (say) C++ with or without things like constexpr as
> suits you. We'll be free of the tyranny of the compiler-writers. It's
> a hacker's wet dream.

However to produce a translator of sophisticated modern programming
language (by programming or by configuring something) it will take
years of work of decent specialists.

> And it's open source. Anyone who gets a copy is an obstacle to the
> corporates that would sabotage it.
>
> If I can get it done.

Yeah ... and then there is "one ring" of Sauron open sourced. :D
I meant with "master" people who are willing to learn to be aware of
what they have produced into this world and also to learn capability
to carry the weight of responsibility for it. Since monsters
apparently don't care about it.

[Ned Latham]

嘱 Tiib wrote:
> Ned Latham wrote:

----snip----

>> xbnf becomes a full-flown compiler capable of running on
>> any machine it can be compiled for, and capable of compiling code in
>> any programming language whatever, for any OS whatever, and to run on
>> pretty much on any machine whatever.
>
> Sounds like you are also claiming doing what Mr Flibble is claiming doing.
> Very interesting. If neither Mr Flibble nor you are just trolling then
> may be you should try to cooperate or to compete or something like that.

Who is Mr Flibble?

----snip----

> However to produce a translator of sophisticated modern programming
> language (by programming or by configuring something) it will take
> years of work of decent specialists.

It'll all be in the configuration files; the first set will be for
Modula-C under linux on x86. After that, adding (say) C++ will require
one more file, adding (say) FreeBSD will require one more file, adding
(say) x86-64 will require one more file...

Only need to get one set right, then the community can take it over.

----snip----

[Öö Tiib]

On Sunday, 1 December 2019 04:03:42 UTC+2, Ned Latham wrote:

> Öö Tiib wrote:
> > Ned Latham wrote:
>
> ----snip----
>
> >> xbnf becomes a full-flown compiler capable of running on
> >> any machine it can be compiled for, and capable of compiling code in
> >> any programming language whatever, for any OS whatever, and to run on
> >> pretty much on any machine whatever.
> >
> > Sounds like you are also claiming doing what Mr Flibble is claiming doing.
> > Very interesting. If neither Mr Flibble nor you are just trolling then
> > may be you should try to cooperate or to compete or something like that.
>
> Who is Mr Flibble?

A regular here ... can do C++ OK ... not too nice discussion partner.
Claimed that he will make his scripting engine language agnostic.
https://neogfx.org/
https://neos.dev/
Actual name is Leigh Johnston.

[Ned Latham]

嘱 Tiib wrote:
> Ned Latham wrote:

----snip----

> > Who is Mr Flibble?
>
> A regular here ... can do C++ OK ... not too nice discussion partner.
> Claimed that he will make his scripting engine language agnostic.
> https://neogfx.org/

API

> https://neos.dev/

Interesting. The combination of his language schema file and JIT looks
a little, but only a little, like the combination of XBNF and xbnf, imo:
neos relies on the API and on UTF-8 and .mix files... xbnf relies only
on the services of the OS (including the character set and the file
types) and on XBNF. All of the files are text files, easy for a program
to produce and amend, easy for a human to read and amend.

XBNF is no mere scripting language; it is a mathematical meta-language
capable of defining the syntax of any context-free grammar: VMs for
programming language, OS and the software model of the CPU. All simple
text.

I will have to make it into a community project somehow, but I don't
think there's a prospect of that until I get sufficient code and
syntax defined to show that it's workable.

> Actual name is Leigh Johnston.

I'll keep my eyes open. Thanks.

[Bonita Montero]

I think a warning here is stupid because any compiler will optimize away
the comparison anyway. A "if constexpr ( )" is just for aesthetics here.

[Christian Gollwitzer]

Am 01.12.19 um 11:56 schrieb Ned Latham:

> XBNF is no mere scripting language; it is a mathematical meta-language
> capable of defining the syntax of any

> context-free grammar:

here is your problem: C is not context free. It is usually dealt with
the "lexer hack" to use a parser for context-free grammar.

Also, parsing the syntax is only a minor step in most actual compilers.
The big pile of work is in the optimizer (which is in theory optional)
and the code generator, and another big pile is in the library. Pure C
without the library is good for nothing.

That's why most regulars in this group are rather sceptical of Flibble's
project. A more realistic approach would sit on top of LLVM, where years
of work have been done already.


Christian

[Ned Latham]

Christian Gollwitzer wrote:
> schrieb Ned Latham:
> >
> > XBNF is no mere scripting language; it is a mathematical meta-language
> > capable of defining the syntax of any context-free grammar:
>
> here is your problem:

There *is* no problem.

> C is not context free. It is usually dealt with
> the "lexer hack" to use a parser for context-free grammar.

I am not trying to write something for C. (Though if the project's a
success, someone will eventually write an XBNF syntax definition of
it.)

> Also, parsing the syntax is only a minor step in most actual compilers.

The point with XBNF is its flexibility and the fact that it *is* just a
meta-language. Syntaces can be written for every programming language,
every OS, every machine architecture and for every stage of a compilation.
In this system, the problems dealt with by the initial "lexer hack", are
dealt with by xbnf's use of symbol tables (somewhat like Clang, I guess).

> The big pile of work is in the optimizer (which is in theory optional)

That is low a priority.

> and the code generator,

That's just a matter of writing XBNF syntax and output files for the CPU
software model.

> and another big pile is in the library. Pure C
> without the library is good for nothing.

You're talking about the linker now, not the compiler.

> That's why most regulars in this group are rather sceptical of Flibble's
> project. A more realistic approach would sit on top of LLVM, where years
> of work have been done already.

Looks good.

But I'll continue with XBNF. If nothing else, it provides the open source
community with another alternative to the over-complication and versionitis
of present-day offerings, to the lack of access to machine idiosyncracies,
and to corporate rapacity.

[bol...@nowhere.co.uk]

On Sun, 1 Dec 2019 18:33:25 +0100
Christian Gollwitzer <auri...@gmx.de> wrote:
>Am 01.12.19 um 11:56 schrieb Ned Latham:
>> XBNF is no mere scripting language; it is a mathematical meta-language
>> capable of defining the syntax of any
>
>> context-free grammar:
>here is your problem: C is not context free. It is usually dealt with
>the "lexer hack" to use a parser for context-free grammar.
>
>Also, parsing the syntax is only a minor step in most actual compilers.
>The big pile of work is in the optimizer (which is in theory optional)
>and the code generator, and another big pile is in the library. Pure C
>without the library is good for nothing.

Depends if you can embed assembler in it or not. If not its basically useless,
if you can it becomes a posh assembler.

[bol...@nowhere.co.uk]

On Sun, 01 Dec 2019 19:27:21 -0600
Ned Latham <nedl...@woden.valhalla.oz> wrote:
>But I'll continue with XBNF. If nothing else, it provides the open source
>community with another alternative to the over-complication and versionitis
>of present-day offerings, to the lack of access to machine idiosyncracies,
>and to corporate rapacity.

Newflash - no one cares. As long as the compiler compiles their code and does
a reasonable optimisation job thats all that matters to them. Whether "cc"
calls gcc, clang or something else is irrelevant unless they're trying to use
some bleeding edge features.

[Ned Latham]

boltar wrote:

> Ned Latham wrote:
> >
> > But I'll continue with XBNF. If nothing else, it provides the open
> > source community with another alternative to the over-complication
> > and versionitis of present-day offerings, to the lack of access to
> > machine idiosyncracies, and to corporate rapacity.

I should have said "xbnf"; XBNF itself is done, and is and advance in
that area. It will continue regardless.

It's xbnf that will provide the alternative.

> Newflash - no one cares. As long as the compiler compiles their code
> and does a reasonable optimisation job thats all that matters to them.
> Whether "cc" calls gcc, clang or something else is irrelevant unless
> they're trying to use some bleeding edge features.

You're missing the point. Compilers and languages both are becoming
more and more affected by versionitis, and the resultant compatibility
issues. This puts version control in the programmer's hands.

[Mr Flibble]

On 01/12/2019 17:33, Christian Gollwitzer wrote:
> Am 01.12.19 um 11:56 schrieb Ned Latham:
>> XBNF is no mere scripting language; it is a mathematical meta-language
>> capable of defining the syntax of any
>
>> context-free grammar:
> here is your problem: C is not context free. It is usually dealt with the "lexer hack" to use a parser for context-free grammar.

neos can compile code for languages which aren't definable using a context free grammar; neos also deals with BOTH the syntax AND the semantics of a language.

> Also, parsing the syntax is only a minor step in most actual compilers. The big pile of work is in the optimizer (which is in theory optional) and the code generator, and another big pile is in the library. Pure C without the library is good for nothing.
>
> That's why most regulars in this group are rather sceptical of Flibble's project. A more realistic approach would sit on top of LLVM, where years of work have been done already.

Try speaking for yourself and not for others unless you own some kind of fucking crystal ball.

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

[bol...@nowhere.co.uk]

On Tue, 3 Dec 2019 17:05:03 +0000
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>On 01/12/2019 17:33, Christian Gollwitzer wrote:
>> Am 01.12.19 um 11:56 schrieb Ned Latham:
>>> XBNF is no mere scripting language; it is a mathematical meta-language
>>> capable of defining the syntax of any
>>
>>> context-free grammar:
>> here is your problem: C is not context free. It is usually dealt with the
>"lexer hack" to use a parser for context-free grammar.
>
>neos can compile code for languages which aren't definable using a context
>free grammar; neos also deals with BOTH the syntax AND the semantics of a
>language.
>
>> Also, parsing the syntax is only a minor step in most actual compilers. The
>big pile of work is in the optimizer (which is in theory optional) and the
>code generator, and another big pile is in the library. Pure C without the
>library is good for nothing.
>>
>> That's why most regulars in this group are rather sceptical of Flibble's
>project. A more realistic approach would sit on top of LLVM, where years of
>work have been done already.
>
>Try speaking for yourself and not for others unless you own some kind of
>fucking crystal ball.

I'll speak for me - I'm sure your project is fun and important for you, but no
one else gives a rats arse.

[Mr Flibble]

You just contradicted yourself, dear.

[bol...@nowhere.co.uk]

On Tue, 3 Dec 2019 18:03:41 +0000

No, its my accurate opinion that no one else gives a damn.

[Mr Flibble]

That is not just speaking for yourself, dear.

[bol...@nowhere.co.uk]

On Wed, 4 Dec 2019 18:36:05 +0000

Never mind. Btw, you need to work on your patronisation skills.