- P(P) halts because H(P,P) correctly determines that its input never halt [ exception to the rule ] - 13 Updates
- A plea... - 3 Updates
- "C: Everyone's favourite programming language isn't a programming language" - 1 Update
- Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ? - 1 Update
- Halting problem proofs refuted on the basis of software engineering - 5 Updates
- Is std::move() a misleading misnomer? - 2 Updates
| olcott <NoOne@NoWhere.com>: Jul 16 06:52PM -0500 On 7/16/2022 6:14 PM, Richard Damon wrote: > the loop. > THe problem is you use bad logic, like that faulty rule (2), to convince > yourself of something that isn't true. It is the case that the correctly simulated input (I see that Mike corrected you on this) would never terminate normally by reaching its "return" statement, thus is correctly determined to be non-halting. >> another exception to the rule of conventional understandings. > BUT, for your simulation to be "correct" its behavior must match what > the program actually does. Because you know these things on the basis of dogma rather than reasoning you will never get this. If enough people of high enough authority proclaimed that all white cats are black dogs many people would simply accept that as true. > call, to be "correct" needs to be compatible with that. > H's analysis that this H will not return says that H is either using > incorrect logic, that it is a incorrect simulator, or that H isn't These are provably correct yet beyond your capacity to verify. > abort its simulation, THIS H never gets stuck in infinite recursion, so > it doesn't matter what happens to the "other H" that isn't actually > present. *It is already provable that it definitely has another exception* The provably correct simulation of the input to H(P,P) have provably correct different behavior that the provably correct behavior of the direct execution of P(P). The no one here has the technical understanding of the x86 language (except possibly Mike) to verify this is zero evidence what-so-ever that I am incorrect. > means the behavior of the input is halting. > ALL the H's can abort the simulation because ALL the H's need to be the > SAME ALGORIGTHM and compute the same function. All H's can abort the simulation, yet the only the outermost H sees the abort criteria first and when it aborts its simulation none of the inner H's see anything at all because they are never invoked. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Mr Dribble <none@none.net>: Jul 16 05:15PM -0700 On 7/16/2022 8:10 AM, olcott wrote: > This conclusively proves that H(P,P) correctly simulates its input and Post it 154,517 more times you retarded mouthload of Bolivian donkey testicles. |
| Richard Damon <Richard@Damon-Family.org>: Jul 16 08:34PM -0400 On 7/16/22 7:52 PM, olcott wrote: > It is the case that the correctly simulated input (I see that Mike > corrected you on this) would never terminate normally by reaching its > "return" statement, thus is correctly determined to be non-halting. Nope. you even posted the trace of this. If H(P,P) returns 0, as you claim it does to main, it will do the same to P(P) and that makes P(P) Halt. Since P(P) Halts, a correct simulation of the input to H will also halt since the input to H(P,P) IS the representation of P(P) and if you want to claim otherwise, you have just declaired that P isn't writen right. Yes, there IS a case of a design for H where the correctly simulated input never terminates, and that is the case when H NEVER aborts its simulation, and thus H(P,P) never returns to main and thus fails to be a Decider. Which H are you claiming, the one that gives the wrong answer or the one that fails to be a decider? > reasoning you will never get this. If enough people of high enough > authority proclaimed that all white cats are black dogs many people > would simply accept that as true. And because you are ignorant of what you talk about because you don't know what anything means, you will never understand what yoy are writing about. I don't take these facts as "dogma", but becuase they ARE the definition. H(M,x) must accept if M(x) halts, and renect if M(x) never halts. By construction, P(P) will halt if H(P,P) rejects (returns 0), (and loop forever if H(P,P) accepts) so H(P,P) rejecting is NEVER a correct answer. What is the error in that arguement. Not how do you show something else, what it the error. Remember, if two contradictory statements can both be proved true, the logic system is inconsistent. Thus you "proving" something contrary to some other statement without showing the actual logical error in it just shows tha tyou are using a inconsisten logic system. >> H's analysis that this H will not return says that H is either using >> incorrect logic, that it is a incorrect simulator, or that H isn't > These are provably correct yet beyond your capacity to verify. To "prove" something contrary to another prove without disproving the original just proves that you logic system is inconsistent. Since you system includes "rules" beyond the generally accepted theries, all you have done it prove that you have added some inconsistent rule. > The provably correct simulation of the input to H(P,P) have provably > correct different behavior that the provably correct behavior of the > direct execution of P(P). WHAT EXCEPTIONS. THERE ARE NONE. Your "provable correct simulation" has had logical errors pointed out that you have not corrected. You are just proving you incabablility to perform correct logic. > The no one here has the technical understanding of the x86 language > (except possibly Mike) to verify this is zero evidence what-so-ever that > I am incorrect. No, there is much evidence, you are just ignoring it, proving your stupidity. I would actually challange you to a duel of technical knowledge, but I have a policy of not fighting an unarmed foe. > All H's can abort the simulation, yet the only the outermost H sees the > abort criteria first and when it aborts its simulation none of the inner > H's see anything at all because they are never invoked. You still don't understand do you. I think you are just to stupid to see anything that doesn't match your erroneous believes. There are TWO different "outermost" H's in view, one from the call to main, and one in the test program where main calls P(P) which calls H. Both of those should show that H(P,P) returns 0, and the second shows that when this happens to the actual machine, P(P) Halts. Since the DEFINITION of a correct simuation is one that matches that actual machine, the correct simulation of the input to H(P,P) by a real correct and complete simulator will also Halt. The fact that H thinks it doesn't just proves that H is wrong. As I said, it can be wrong serveral ways. 1) It can use incorrect logic, like your incorrect rule (3), to reach a bad conclusion of its input. 2) It can be that H does an incorrect emulation of its input, this is related to 1) as your emulator thinks that H(P,P) never returns, when we have previous show that, as long as H is a pure function, that H(P,P) will always return 0. 3) It could be that H just isn't a pure function and not qualified to be a decider. Since we don't have the code for H, we can't tell, but we KNOW that case 1 is at least partly true based on your claims, since you DO quote the incorrect rule. |
| olcott <NoOne@NoWhere.com>: Jul 16 07:40PM -0500 On 7/16/2022 7:34 PM, Richard Damon wrote: >> corrected you on this) would never terminate normally by reaching its >> "return" statement, thus is correctly determined to be non-halting. > Nope. you even posted the trace of this. So you don't give a rat's ass about verified facts. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Richard Damon <Richard@Damon-Family.org>: Jul 16 09:07PM -0400 On 7/16/22 8:40 PM, olcott wrote: >> Nope. you even posted the trace of this. > So you don't give a rat's ass about verified facts. A care about ACTUALLY verified facts, not your garbage. As I said, YOU have posted a trace of P(P) being simulated by a correct simulator that traced it to its final return, which actually DOES prove that P(P) is halting when H(P,P) returns 0. (Admittedly, the impossible progra was called H_Hat at the time, but it was the same program). Since you have NEVER pointed out an actual flaw in most of the rebuttals, YOU are the one shown to not care about facts. It is absolutely established that P(P) will Halt if H(P,P) returns 0. It is true BY DEFINITION, that the behavior of the input to H(P,P) must be the behavior of P(P) since that is what P uses to ask about P(P). You "proof" that it must be something different actually just proves that your H and P don't match the requirements and thus your proof is worthless. YOU don't know what truth is, you think you do, but you are mistaken. You prove this every time you ignore an error pointed out in your logic and your failure to correct them. You have been given many opertunities to provide evidence for your claims, but you refuse, but instead show your "intelgence" by just repeating your disproven claims again. It seems you think that by just repeating your lie often enough, some people might begin to believe it. In the not to distant future, based on what you have been saying, you are going to have a meeting with the Truth, and from what I see, you are going to be sorely disapointed. As you have said, those that live a life filled with lies are condemned to distruction, so that will be your fate. (Maybe you don't actually believe that, but that just shows more of your lying). There IS a truth, and it doesn't matter what people think, the Truth IS the Truth. Spending decades trying to prove something that isn't true isn't the way to find the real Truth. |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 10:28AM +0100 On Sat, 16 Jul 2022 19:32:53 +0200 > and Olcott are going round in circles, writing nothing new. Mr. > Flibble is even worse, bringing his own equally (but differently) > flawed ideas into the mix. How am I even worse? If you think my ideas are flawed then kindly point out those flaws rather than just indulge in wand waving. /Flibble |
| Skep Dick <skepdick22@gmail.com>: Jul 17 03:28AM -0700 On Sunday, 17 July 2022 at 11:28:20 UTC+2, Mr Flibble wrote: > if you think my ideas are flawed then kindly point > out those flaws rather than just indulge in wand waving. You respond to constructive/corrective feedback in identical fashion to Olcott. You are making the exact same errors as Olcott (tripping over the syntactic sugar of your chosen programming language - while ignorant of the semantics) I'd venture a wild guess Olcott is your Troll alter ego. |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 11:32AM +0100 On Sun, 17 Jul 2022 03:28:35 -0700 (PDT) > to Olcott. You are making the exact same errors as Olcott (tripping > over the syntactic sugar of your chosen programming language - while > ignorant of the semantics) I am not tripping over any syntactic sugar, the problem there is that you have no clue about how exceptions work and how returning from a function and throwing an exception from a function are quite differently semantically (i.e. nothing to do with syntax). If I am making the same errors as Olcott then kindly point out one of those errors. > I'd venture a wild guess Olcott is your Troll alter ego. Derp. /Flibble |
| Skep Dick <skepdick22@gmail.com>: Jul 17 03:40AM -0700 On Sunday, 17 July 2022 at 12:32:39 UTC+2, Mr Flibble wrote: > you have no clue about how exceptions work and how returning from a > function and throwing an exception from a function are quite > differently semantically (i.e. nothing to do with syntax). I have pretty good idea how information works. Which is precisely why I pointed out to you that these two functions are semantically equivalent. void f(x){ if(x==1) throw yes(); else throw no(); } bool f(x==1){ if(magic-you-can't-explain) return true; else return false; } > If I am making the same errors as Olcott then kindly point out one of > those errors. OK. I am pointing out (in this very exchange) that you are confusing syntax for semantics. |
| Skep Dick <skepdick22@gmail.com>: Jul 17 03:46AM -0700 On Sunday, 17 July 2022 at 12:32:39 UTC+2, Mr Flibble wrote: > you have no clue about how exceptions work and how returning from a > function and throwing an exception from a function are quite > differently semantically (i.e. nothing to do with syntax). Meh... I copy-pasted the wrong snippet... Looking from the lens of effect systems (google for algebraic effect handlers) These two functions are semantically equivalent - they provide one bit of information. void halt(x){ if(magic-you-can't-explain) throw yes(); else throw no(); } bool halt(x){ if(magic-you-can't-explain) return true; else return false; } |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 11:59AM +0100 On Sun, 17 Jul 2022 03:40:29 -0700 (PDT) > > of those errors. > OK. I am pointing out (in this very exchange) that you are confusing > syntax for semantics. No, YOU are confusing syntax with semantics: returning from a function and throwing an exception from a function are quite different semantically. /Flibble |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 12:04PM +0100 On Sun, 17 Jul 2022 03:46:40 -0700 (PDT) > else > return false; > } They are obviously not equivalent as throwing an exception and returning a value from a function are quite different semantically. Also, function does NOT have to have void return type to be able to throw an exception so such a function has two possible behaviours: 1) return a value to its caller 2) throw an exception to either be caught by a try/catch or cause abnormal program termination If you think (1) and (2) are semantically equivalent then you really are clueless as far as computer science is concerned. /Flibble |
| Skep Dick <skepdick22@gmail.com>: Jul 17 04:17AM -0700 On Sunday, 17 July 2022 at 13:04:37 UTC+2, Mr Flibble wrote: > abnormal program termination > If you think (1) and (2) are semantically equivalent then you really > are clueless as far as computer science is concerned. A function which maps all of its inputs to one of two possible return values; and a function which maps all of its inputs to one of two possible exceptions are semantically equivalent. They answer one yes/no question. Whether the answer is signalled via return value; or via an exception is just implementation detail. This is how information works. Bye, Olcott. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jul 17 03:24AM +0100 Please don't respond to Peter Olcott's posts here. His threads have taken over comp.theory, but there is no reason that comp.lang c (or comp.lang.c++) should suffer the same fate. These two groups have had many interesting threads over the years, but they will die if they fill up with junk. If you want to reply to him, just pick any of the thousands of posts in comp.theory and he'll be as happy to insult you and call you ignorant there as he is here. I've not made this a head post because I don't want to single anyone out. Everyone who'd got something out of comp.lang.c should care about its curation... -- Ben. |
| olcott <NoOne@NoWhere.com>: Jul 16 09:32PM -0500 On 7/16/2022 9:24 PM, Ben Bacarisse wrote: > I've not made this a head post because I don't want to single anyone > out. Everyone who'd got something out of comp.lang.c should care about > its curation... As soon as I get closure (very close now) I won't need to post on USENET at all. The current version of my work can only be properly reviewed by software engineers. The computer science issues are being addressed through emails to computer scientists. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Skep Dick <skepdick22@gmail.com>: Jul 17 03:35AM -0700 On Sunday, 17 July 2022 at 04:32:43 UTC+2, olcott wrote: > As soon as I get closure (very close now) I won't need to post on USENET Your closure-seeking loop seems to be stuck in an infinite loop. If your halting decider actually worked you would've terminated your closure-seeking loop by now. Irony has a certain flavour... |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 17 08:18AM +0200 Am 12.07.2022 um 14:48 schrieb olcott: > The big picture is that H(P,P) correctly determines that its input would > never terminate normally and H(P,P) does handle the above "impossible" > case. Seeing the big picture here means that it is pointless to deal with this topic so fruitlessly for years. |
| olcott <NoOne@NoWhere.com>: Jul 16 10:11PM -0500 On 7/16/2022 10:54 AM, Mike Terry wrote: > PO's simulation is correct at the individual instruction level. > His H steps the simulation forward a number of steps, and each > of those steps exactly matches the P(P) calculation steps. We can see from the x86 execution trace of the simulated P that the behavior of this simulated P exactly matches its x86 source-code, line-by-line. What we can also see from this same execution trace is that when H calls H(P,P) the simulated P remains stuck calling H(P,P) to simulate itself again thus forever preventing this simulated P from ever terminating normally by reaching its C:"return" or x86:"ret" instruction. *H(P,P) correctly determines that its input never halts* typedef void (*ptr)(); int H(ptr p, ptr i); // simulating halt decider void P(ptr x) { int Halt_Status = H(x, x); if (Halt_Status) HERE: goto HERE; return; } int main() { Output("Input_Halts = ", H(P, P)); } _P() [000013c6](01) 55 push ebp // Save Base Pointer register onto the stack [000013c7](02) 8bec mov ebp,esp // Load Base Pointer with Stack Pointer [000013c9](01) 51 push ecx // Save the value of ecx on the stack [000013ca](03) 8b4508 mov eax,[ebp+08] // Load eax with argument to P [000013cd](01) 50 push eax // push 2nd argument to H onto the stack [000013ce](03) 8b4d08 mov ecx,[ebp+08] // Load ecx with with argument to P [000013d1](01) 51 push ecx // push 1st argument to H onto the stack [000013d2](05) e82ffdffff call 00001106 // push return address on the stack; call simulated H [000013d7](03) 83c408 add esp,+08 // remove call arguments from stack [000013da](03) 8945fc mov [ebp-04],eax // load Halt_Status with return value from H [000013dd](04) 837dfc00 cmp dword [ebp-04],+00 // compare Halt_Status to 0 [000013e1](02) 7402 jz 000013e5 // if Halt_Status == 0 goto 000013e5 [000013e3](02) ebfe jmp 000013e3 // goto 13e3 [000013e5](02) 8be5 mov esp,ebp // Load Stack Pointer with Base Pointer [000013e7](01) 5d pop ebp // Restore Base Pointer value from stack [000013e8](01) c3 ret // return to caller Size in bytes:(0035) [000013e8] _main() [000013f6](01) 55 push ebp // Save Base Pointer register onto the stack [000013f7](02) 8bec mov ebp,esp // Load Base Pointer with Stack Pointer [000013f9](05) 68c6130000 push 000013c6 // Push P (2nd argument to H) onto the stack [000013fe](05) 68c6130000 push 000013c6 // Push P (1nd argument to H) onto the stack [00001403](05) e8fefcffff call 00001106 // push return address onto the stack and call executed H [00001408](03) 83c408 add esp,+08 // remove call arguments from stack frame [0000140b](01) 50 push eax // Push return value from H onto the stack [0000140c](05) 6837050000 push 00000537 // Push address of "Input_Halts = " onto the stack [00001411](05) e870f1ffff call 00000586 // call Output with its pushed arguments. [00001416](03) 83c408 add esp,+08 // remove call arguments from stack frame [00001419](02) 33c0 xor eax,eax // set eax to 0 [0000141b](01) 5d pop ebp // Restore Base Pointer register from stack [0000141c](01) c3 ret // return to 0 operating system Size in bytes:(0039) [0000141c] machine stack stack machine assembly address address data code language ======== ======== ======== ========= ============= [000013f6][0010235f][00000000] 55 push ebp [000013f7][0010235f][00000000] 8bec mov ebp,esp [000013f9][0010235b][000013c6] 68c6130000 push 000013c6 // Push P (2nd argument to H) onto the stack [000013fe][00102357][000013c6] 68c6130000 push 000013c6 // Push P (1nd argument to H) onto the stack [00001403][00102353][00001408] e8fefcffff call 00001106 // push return address; call executed H H: Begin Simulation Execution Trace Stored at:11240b Address_of_H:1106 [000013c6][001123f7][001123fb] 55 push ebp [000013c7][001123f7][001123fb] 8bec mov ebp,esp [000013c9][001123f3][001023c7] 51 push ecx // Save the value of ecx on the stack [000013ca][001123f3][001023c7] 8b4508 mov eax,[ebp+08] // Load eax with argument to P [000013cd][001123ef][000013c6] 50 push eax // push 2nd argument to H onto the stack [000013ce][001123ef][000013c6] 8b4d08 mov ecx,[ebp+08] // Load ecx with with argument to P [000013d1][001123eb][000013c6] 51 push ecx // push 1st argument to H onto the stack [000013d2][001123e7][000013d7] e82ffdffff call 00001106 // push return address; call simulated H H: Infinitely Recursive Simulation Detected Simulation Stopped [00001408][0010235f][00000000] 83c408 add esp,+08 [0000140b][0010235b][00000000] 50 push eax // Push return value from H onto the stack [0000140c][00102357][00000537] 6837050000 push 00000537 // Push address of "Input_Halts = " onto stack [00001411][00102357][00000537] e870f1ffff call 00000586 // call Output with its pushed arguments Input_Halts = 0 [00001416][0010235f][00000000] 83c408 add esp,+08 [00001419][0010235f][00000000] 33c0 xor eax,eax // set eax to 0 [0000141b][00102363][00000018] 5d pop ebp [0000141c][00102367][00000000] c3 ret // return to 0 operating system Number of Instructions Executed(987) == 15 Pages -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| olcott <NoOne@NoWhere.com>: Jul 16 08:23PM -0500 On 7/16/2022 7:38 PM, Richard Damon wrote: >> *possibly ever terminate normally by reaching its "return" instruction* > Which just doesn't matter as Halting is defined based on the actual > machine and not a simulation. Then the whole idea of a UTM would be totally bogus. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Richard Damon <Richard@Damon-Family.org>: Jul 16 09:49PM -0400 On 7/16/22 9:19 PM, olcott wrote: >> Which just doesn't matter as Halting is defined based on the actual >> machine and not a simulation. > Then the whole idea of a UTM would be totally bogus. Why? Just because Halting is defined by the actual machine, why does that make a UTM bogus? Note, since a UTM, BY DEFINITION, generates the equivalent output as the machine it is simuating, you can use valid logic between them, so if UTM(M,x) Halts, then you can use the definition of a UTM to say that this means that M(x) will halt too. That doesn't change the fact that Halting is DEFINED by the machine, it just says you don't base things on what the UTM said, you base it on what the UTM proves the machine will say. Big Note, that equivalence ONLY holds for something that IS a UTM, and not something based on a UTM that might chose to stop it processing, then you need to find logic rules that deal with that case. This is why halting isn't based on the results of the simulaiton by the Halting decider, since BY DEFINITION, a halting decider must answer in finite time, a simulation by a Halt Decider can NEVER, by itself, prove non-halting. It might provide evidence based on valid rules to let you prove non-halting, but that deduction will be able to be tested by running the actual machine (or simulation by an actual UTM which by definition gives the same answer). There is no wouldn't halt unless the halt decider aborted, as since the halt decider WILL abort in that case, there never was the case that the halt decider didn't abort, since that isn't the machine we are looking at. |
| olcott <NoOne@NoWhere.com>: Jul 16 09:08PM -0500 On 7/16/2022 8:49 PM, Richard Damon wrote: >> Then the whole idea of a UTM would be totally bogus. > Why? Just because Halting is defined by the actual machine, why does > that make a UTM bogus? If the correct simulation of a machine description does not specify the actual underlying computation then the concept of a UTM fails to remain coherent. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Richard Damon <Richard@Damon-Family.org>: Jul 16 10:17PM -0400 On 7/16/22 10:08 PM, olcott wrote: > If the correct simulation of a machine description does not specify the > actual underlying computation then the concept of a UTM fails to remain > coherent. The issue is what you have been running into, defining what "correct simulation" means. The definition of Halting says it is the behavior of the actual machine that matters, and "correct simulation" means that simulation matched that behavior, so can be also used. This is your fundamental problem, you keep on trying to claim that the input to H(P,P) doesn't actually match the machine it is supposed to be the description of, all that means is that your simulation isn't correct. By making the DEFINITION the actual machine, games like that become impossible, as the machine IS the machine. Remeber: By design P(P) WILL Halt if H(P,P) rejects, therefore since the definition of a correct halt decider is that H is will accept halting inputs, H gave the wrong answer and is not a correct halt decider. That is just simple DEFINITIONS. We don't need to worry if your rules that you try to use to prove that H is corrct are right or not, the defined test is run the machine. Since P(P) halts when H(P,P) returns 0, H was just wrong. |
| olcott <NoOne@NoWhere.com>: Jul 16 09:38PM -0500 On 7/16/2022 9:17 PM, Richard Damon wrote: >> remain coherent. > The issue is what you have been running into, defining what "correct > simulation" means. Mike already correctly addressed this in his reply to Paul N: On 7/16/2022 10:54 AM, Mike Terry wrote: -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 16 04:31PM -0700 On 7/15/2022 5:02 AM, Juha Nieminen wrote: > and 'v2' has been logically implemented) that 'v1' will contain what > 'v2' contained before this statement. > But what will 'v2' contain? For some reason, I thought of a move from v2 to v1 leaves v2 in an undefined zombie state where accessing v2 is undefined behavior because its now "dead"? |
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Jul 16 06:32PM -0700 On Sunday, 17 July 2022 at 00:31:23 UTC+1, Chris M. Thomasson wrote: > For some reason, I thought of a move from v2 to v1 leaves v2 in an > undefined zombie state where accessing v2 is undefined behavior because > its now "dead"? That's more or less right. v2 has to be put into a valid state. So the destructor must work. Also, it can be assigned to, and I believe that the assignment operator must work. But it can be and commonly is in a null state. However that shouldn't be treated as guaranteed. An employee class might contain no employees, it might contain one employee, or it might contain the full list of employees (the move assignment was in fact implemented as a copy) or it might contain v1's list of employees (the move assignment was implemented as a pointer swap). It not really a case of UB. It's about the implied contract the move assignment operator makes. |
| 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