| Brian Wood <woodbrian77@gmail.com>: Mar 30 04:20PM -0700 On Monday, March 29, 2021 at 12:37:35 PM UTC-5, Richard wrote: > >"What Will Die Out Sooner C++ or C++ Programmers?" by Oleksandr Kaleniuk > IMO, this is just a flamey attention-seeking blog post, not a well > reasoned argument. Probably some parts of the language will die out, but I think both the language and those who use it properly have a bright future. Brian Ebenezer Enterprises - Come now, you who say, "Today or tomorrow we will go to this or that city, spend a year there, carry on business, and make a profit." You do not even know what will happen tomorrow! What is your life? You are a mist that appears for a little while and then vanishes. James 4:13,14 https://github.com/Ebenezer-group/onwards |
| olcott <NoOne@NoWhere.com>: Mar 30 09:20AM -0500 On 3/30/2021 12:28 AM, Kaz Kylheku wrote: > That is untrue. > What H^ specifies depends on the nature of H, because the bulk of H^ is > the sub-function H. http://www.liarparadox.org/Peter_Linz_HP(Pages_318-319).pdf Whenever H is a simulator then H^ <is> infinitely recursive never reaching the appended loop states whether or not the simulator always returns a value of true or false. This by itself proves that the famous: "do the opposite of whatever the halt decider decides" Now we construct a new Turing machine D with H as a subroutine. This new TM calls H to determine what M does when the input to M is its own description <M>. Once D has determined this information, it does the opposite. That is, it rejects if M accepts and accepts if M does not accept. (Sipser 1997:165) Never has had any effect on halting problem undecidability because no halt decider would ever return any value to H^. Sipser, Michael 1997. Introduction to the Theory of Computation. Boston: PWS Publishing Company (165-167) -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Kaz Kylheku <563-365-8930@kylheku.com>: Mar 30 03:03PM > Whenever H is a simulator then H^ <is> infinitely recursive never > reaching the appended loop states whether or not the simulator always > returns a value of true or false. H is not required to be a simulator. If H simply executes its input, we know that it fails to decide due to runaway recursion: the input calls the decider, which executes its input, which calls the decider. This is freshman-level obvious. The first materials I ever read about the halting problem spelled this out, for the dummies. > Never has had any effect on halting problem undecidability Not returning is completely, utterly relevant to undecidability. The undecidability of halting means that a decision function can only decide at most a subset of the possible cases, not all of them. Outside of the subset which it decides, it misbehaves in one of several ways: it either returns the wrong answer, or fails to halt, or else something else, like failing due to a division by zero or similar problem. Runaway recursion falls under "fails to halt"; it's a failed case. > because no halt decider would ever return any value to H^. Except in your program, where a "pure function" sometimes returns a value and sometimes doesn't, for the same pair of visible arguments! -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal |
| Richard Damon <Richard@Damon-Family.org>: Mar 29 09:51PM -0400 On 3/29/21 3:26 PM, Paavo Helde wrote: > If you think a copy ctor does not get used in your little experiment, > then how do you explain the output you saw? Or do you suggest the > compiler is buggy and destructs the same object twice? (Hint: it does not.) Another good thing to do when generating this sort of trace is include the 'this' pointer (i.e. the object address) and you would see that the two destruction are at different addresses. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment