Whether or not these insights apply to the actual halting problem is a next level review that must be done by a qualified computer scientist.
The code you have provided is a demonstration of something that has already been demonstrated mathematically. Doesn't matter how you phrase your posts that remains true.
Lets say you create a interpreter which changes the context in which the problem runs. For example it halts every single time a specific instruction is called. Certainly provable that it halts then. But that is a different problem than the one you posted.
So your choices are
1. Find your own problem and prove anything you want about it. You must fully define the problem space.
2. Find a way to invalidate the existing Turing proof using the context in which it was presented. You do not get to change that context - if you want to change the context then see item #1.
Note that step #1 even being fully correct will say nothing about the Turing proof.
Latest update: the bug is gone after I run cmd console, instead of the new Terminal console. Case closed. Thanks everybody for checking and testing.
I found a cout bug with Visual C++ 2022 on Windows 11. VC++ 2019 does not have this bug. When I try to debug, the problem goes away. I have produced a small repo that reproduces the issue. Please help me check so that I can report this bug to Microsoft. Thanks.
Mine also has a tabbed interface, so I have three tabs: cmd, PowerShell and Linux under WSL. It seems just as fast as anything else. I can only assume there is another interface that is the default in the 11 version. Unfortunately (or maybe not) my PC does not support Windows 11.
I am trying to play an mp3 file from a WinAPI/C++ application. I'm using 32-bit MinGW on Windows 10.
I found an example program which uses the MCI (winmm) interface to play the file; I found an example command-line program which implements this using mciSendString() calls...
I had some problems handling paths to the mp3 file, and *thought* I had fixed it by converting the paths to 8.3 short format... the command-line program plays the files just fine, but when I import exactly the same code into my WinAPI dialog-box application, although the MCI functions all return success, no sound plays...
Does anyone have any idea what is missing here?? Or does this library just not work from a Windows dialog app?
Well, all of the Windows-supported libraries present problems, especially if one is building using MinGW rather than Visual C++. Generally, they cannot be built at all without a massive amount of hacking the code bases to make them MinGW-compatible. No DirectShow apps will build, neither will the more-recent MS audio interface (don't recall the name at the moment).
However, I found a freeware library called zplay, which is easy to build, open source, and nice, compact code... it also has the ability to play other formats, such as flac... so I'll just go with that...