XPost: comp.lang.c++

On 21/06/2024 22:41, olcott wrote:

On 6/17/2024 9:11 AM, Bonita Montero wrote:

Am 17.06.2024 um 05:47 schrieb olcott:

To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.

typedef void (*ptr)();
int H0(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   H0(DDD);
   return;
}

int main()
{
   H0(Infinite_Loop);
   H0(Infinite_Recursion);
   H0(DDD);
}

Every C programmer that knows what an x86 emulator is knows that when H0 >>> emulates the machine language of Infinite_Loop, Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate
normally.

When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.

*My POD24 diagnosis is reducing the time I have left to work on this*
Validation of POD24 as a robust early clinical end point of poor
survival in FL from 5225 patients on 13 clinical trials
https://pubmed.ncbi.nlm.nih.gov/34614146/

Everything correct, no further questions allowed.

Thanks for your help on this. The Liars on comp.theory are
even lying about what you actually said.

Pretty sure that Bonita was taking the piss.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c++

On 6/22/24 8:42 AM, olcott wrote:

On 6/22/2024 5:13 AM, Richard Harnden wrote:

On 21/06/2024 22:41, olcott wrote:

On 6/17/2024 9:11 AM, Bonita Montero wrote:

Am 17.06.2024 um 05:47 schrieb olcott:

To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.

typedef void (*ptr)();
int H0(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   H0(DDD);
   return;
}

int main()
{
   H0(Infinite_Loop);
   H0(Infinite_Recursion);
   H0(DDD);
}

Every C programmer that knows what an x86 emulator is knows that
when H0
emulates the machine language of Infinite_Loop, Infinite_Recursion,
and
DDD that it must abort these emulations so that itself can terminate >>>>> normally.

When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.

*My POD24 diagnosis is reducing the time I have left to work on this* >>>>> Validation of POD24 as a robust early clinical end point of poor
survival in FL from 5225 patients on 13 clinical trials
https://pubmed.ncbi.nlm.nih.gov/34614146/

Everything correct, no further questions allowed.

Thanks for your help on this. The Liars on comp.theory are
even lying about what you actually said.

Pretty sure that Bonita was taking the piss.

I would say that this would indicate that you are insufficiently
competent with the C programming language.

It seems you are the one that doesn't know the C programing language.
After all, you didn't know about the unordering of sub-expressions, or
that this can lead to undefined behavior.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c++

On 6/22/24 12:36 PM, olcott wrote:

On 6/22/2024 8:58 AM, Richard Damon wrote:

On 6/22/24 8:42 AM, olcott wrote:

On 6/22/2024 5:13 AM, Richard Harnden wrote:

On 21/06/2024 22:41, olcott wrote:

On 6/17/2024 9:11 AM, Bonita Montero wrote:

Am 17.06.2024 um 05:47 schrieb olcott:

To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.

typedef void (*ptr)();
int H0(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   H0(DDD);
   return;
}

int main()
{
   H0(Infinite_Loop);
   H0(Infinite_Recursion);
   H0(DDD);
}

Every C programmer that knows what an x86 emulator is knows that >>>>>>> when H0
emulates the machine language of Infinite_Loop,
Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate >>>>>>> normally.

When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non- >>>>>>> halting.

*My POD24 diagnosis is reducing the time I have left to work on
this*
Validation of POD24 as a robust early clinical end point of poor >>>>>>> survival in FL from 5225 patients on 13 clinical trials
https://pubmed.ncbi.nlm.nih.gov/34614146/

Everything correct, no further questions allowed.

Thanks for your help on this. The Liars on comp.theory are
even lying about what you actually said.

Pretty sure that Bonita was taking the piss.

I would say that this would indicate that you are insufficiently
competent with the C programming language.

It seems you are the one that doesn't know the C programing language.
After all, you didn't know about the unordering of sub-expressions, or
that this can lead to undefined behavior.

It seems pretty stupid to allow gaps in the semantics of C++ programs.
Simply specify that the order of evaluation is left to right unless:
(a) Otherwise specified such as operator precedence rules.
(b) Derives the same result as left to right ordering.

Nope. The problem is that such a rule breaks the fundamental design
decisions that the goal is to make it possible to create as efficient
machine code as possible.

If you need the left to right evaluation order, there are ways to write
the code to make that happen.

One of the fundamental design decisions in the language is that it
trusts the programmer to know the rules, and will strive for the fastest
code possible.

C++ made a special rule for the << operator because the gain for its use
as an output was high enough, and the cost as a normal shift operator
was rarely high (and normally hidden by the "as if" rule) so it was done
there.

There are too many cases for the more general arguement that causes
measurable speed differences.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c++

On 6/22/24 2:00 PM, Bonita Montero wrote:

Am 22.06.2024 um 19:20 schrieb Richard Damon:

C++ made a special rule for the << operator because the gain for its
use as an output was high enough, and the cost as a normal shift
operator was rarely high (and normally hidden by the "as if" rule) so
it was done there.

I guess C++ doesn't make a statement on that and the ordered behaviour
depens in the cascaded return of the stream-object.

My understanding is that the Standard made that a requirement so the
cascaded operands would be computed in the right order.

Prior to that, it was allowed to compute the order of the terms being
output in any order, as the call to operator <<(ostream& strm, T& value)
was allowd to compute value before resolving stream (as the value from
the previous operator <<, which caught enough people off guard.

That was considered useful enough, and where << is used as the shift
operator, the restriction is unlikely to cause a large impact, so they
did it for that special case.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c++

On 6/22/24 3:17 PM, Chris M. Thomasson wrote:

On 6/22/2024 10:58 AM, Bonita Montero wrote:

Am 22.06.2024 um 18:36 schrieb olcott:

It seems pretty stupid to allow gaps in the semantics of C++
programs. Simply specify that the order of evaluation is left to
right unless:
(a) Otherwise specified such as operator precedence rules.
(b) Derives the same result as left to right ordering.

Most UB is there to allow optimizations, also in this case.
I've got no problem with that.

Humm. Sounds reasonable. UB is there to be defined by a non-conforming compiler? ;^)

Doesn't need to be Non-Conforming to define the behavior of Undefined
Behavior!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c++

On 6/22/24 3:17 PM, Chris M. Thomasson wrote:

On 6/22/2024 10:58 AM, Bonita Montero wrote:

...

Most UB is there to allow optimizations, also in this case.
I've got no problem with that.

Humm. Sounds reasonable. UB is there to be defined by a non-conforming compiler? ;^)

By definition, non-conforming implementations can always do whatever
they like, regardless of whether the code has undefined behavior, merely unspecified behavior, or even standard-defined behavior.

UB is for the benefit of conforming implementations. It gives them
permission to handle code that has UB any way they want, without
sacrificing conformance.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c++

On 6/23/24 2:52 AM, Bonita Montero wrote:

Am 22.06.2024 um 20:50 schrieb Richard Damon:

Prior to that, it was allowed to compute the order of the terms being
output in any order, as the call to operator <<(ostream& strm, T&
value) was allowd to compute value before resolving stream (as the
value from the previous operator <<, which caught enough people off
guard.

With a left-associative operator the result of the left part has to be calculated before it can be used with the right part.

But the right part can be calculated before the left part is.

so in the call sequence: statement a+b+c where a,b, and c are
expressions of user defined types this becomes

operator+(operator+(a, b), c)

the expressions a, b and c can be evaluated in any order.

The change was that for operator<< the order of evalutation is DEFINED
to be a, then b, then c. That order was NOT provided for +.

Yes, the outer call can't be done before the inner call returns, but
unless there is a specific requirement in the Standard, no order of the sub-expressions is implied.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c++

On 22/06/2024 18:36, olcott wrote:

On 6/22/2024 8:58 AM, Richard Damon wrote:

On 6/22/24 8:42 AM, olcott wrote:

On 6/22/2024 5:13 AM, Richard Harnden wrote:

I would say that this would indicate that you are insufficiently
competent with the C programming language.

It seems you are the one that doesn't know the C programing language.
After all, you didn't know about the unordering of sub-expressions, or
that this can lead to undefined behavior.

It seems pretty stupid to allow gaps in the semantics of C++ programs.
Simply specify that the order of evaluation is left to right unless:
(a) Otherwise specified such as operator precedence rules.
(b) Derives the same result as left to right ordering.

The tighter you specify something, the less scope there is for
optimisations and generating more efficient code. It's a tradeoff. C
and C++, as languages aimed at (amongst other uses) generating efficient
code, have design decisions that give more flexibility to the compilers
rather than specifying the details of how implementations must work.

It is very simple to enforce the logical order of calculation of
subexpressions - use temporary variables. So the programmer has the
choice you are looking for, but needs to express it in a different way
from what you thought.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c++

On 23/06/2024 08:52, Bonita Montero wrote:

Am 22.06.2024 um 20:50 schrieb Richard Damon:

Prior to that, it was allowed to compute the order of the terms being
output in any order, as the call to operator <<(ostream& strm, T&
value) was allowd to compute value before resolving stream (as the
value from the previous operator <<, which caught enough people off
guard.

With a left-associative operator the result of the left part has to be calculated before it can be used with the right part.

Both the left part and the right part need to be evaluated before the
operator between them can be evaluated - but the two parts can be
evaluated in either order (or even interleaved in their evaluation). Associativity is irrelevant.


Before C++17 (which added the rules for sequencing for shifts, and made
a few other changes), if you had:

foo() << bar()

then the compiler could evaluate bar() then foo(), or foo() then bar().
It can still happily arrange them as it wants for "foo() + bar()".

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c++

On 22/06/2024 21:17, Chris M. Thomasson wrote:

On 6/22/2024 10:58 AM, Bonita Montero wrote:

Am 22.06.2024 um 18:36 schrieb olcott:

It seems pretty stupid to allow gaps in the semantics of C++
programs. Simply specify that the order of evaluation is left to
right unless:
(a) Otherwise specified such as operator precedence rules.
(b) Derives the same result as left to right ordering.

Most UB is there to allow optimizations, also in this case.
I've got no problem with that.

Humm. Sounds reasonable. UB is there to be defined by a non-conforming compiler? ;^)

No, UB is there so that /conforming/ compilers don't have to implement
any specific behaviour for it, and can optimise assuming that either it
doesn't happen, or that you don't care about the results if it does happen.

It is also useful for static analysis and debugging and tools like
sanitizers - since UB is typically the result of something you don't
want to happen in your code, like overflows, debugging tools can add
extra code to tell you of such events. If overflow behaviour had been
defined, it would be normal and expected behaviour, and debugging tools
can't freely change that.

Compilers - conforming or not - are always free to pick a definition for something that the standard says is undefined behaviour (either
explicitly, or by simply omitting a definition for the behaviour). If
they document this definition, you can view it as an extension and rely
on its use - if they don't document it, you rely on it at your own risk.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)