- Advent of Code 2020 - Spoiler day 02 part B - 12 Updates
- Member operators - why the restriction? - 2 Updates
- What I'm doing wrong here ? - 5 Updates
- Both invocations of Confound_Halts() are decided consistently - 1 Update
- Happy Thanksgiving to all (logical necessity)(Over Ben's head) - 1 Update
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Dec 07 01:21AM On 06/12/2020 23:20, Alf P. Steinbach wrote: > auto main() -> int { return with_exceptions_displayed( cpp_main ); } > ------------------------------------------------------------------------ > - Alf (coding mode) Your use of "using" directives and your omission of "std::" in function bodies makes you code less readable IMO. /Flibble -- 😎 |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 07 07:26AM +0100 On 06.12.2020 13:29, Jorgen Grahn wrote: > Advent of Code > https://adventofcode.com/2020 Minimal support library: <url: https://github.com/alf-p-steinbach/kickstart/blob/master/source/examples/hello-world.md> I found that one way to screw up this exercise is to inadvertently save the data file as UTF-8 with BOM. :-o ------------------------------------------------------------------------ #include <algorithm> #include <fstream> #include <sstream> using std::max, std::ifstream; #include <kickstart/all.hpp> using namespace kickstart::all; auto read_map() -> vector<string> { vector<string> result; const auto& filename = "map-data.txt"; ifstream f( filename ); hopefully( not f.fail() ) or fail( ""s << "Failed to open '" << filename << "'." ); string line; while( getline( f, line ) ) { result.push_back( line ); } hopefully( f.eof() ) or fail( ""s << "Error reading file '" << filename << "'." ); return result; } struct Point{ int x; int y; }; void cpp_main() { const vector<string> map = read_map(); const int w = static_cast<int>( ssize( map.front() ) ); const int h = static_cast<int>( ssize( map ) ); Point current = {0, 0}; int count = 0; while( current.y < h ) { count += (map[current.y][current.x] == '#'); { //with auto& _ = current; _.x = (_.x + 3) % w; _.y += 1; } } out << count << endl; } auto main() -> int { return with_exceptions_displayed( cpp_main ); } ------------------------------------------------------------------------ - Alf (morning coding mode) |
Juha Nieminen <nospam@thanks.invalid>: Dec 07 07:49AM > using std::unordered_set; You wrote 27 characters in order to save writing 5 characters later. Seems like quite counter-productive. You write more code in order to make your code less legible. If I were reviewing your production code, I would never give this a pass. > #include <kickstart/all.hpp> > using namespace kickstart::all; // out, endl, fail, begin, end This whole program is invalid because it fails to compile. No matter how much you try to push your personal libraries, they will not catch on. Just stick to *standard* C++, which is all this newsgroup is about. |
Juha Nieminen <nospam@thanks.invalid>: Dec 07 07:55AM > _.x = (_.x + 3) % w; _.y += 1; > } > } It will perhaps never cease to amaze me your insistence in making your code less readable, harder to decipher, needlessly long, and needlessly requiring personal header files that nobody else gives a flying f about. |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 07 12:01PM +0100 On 07.12.2020 08:55, Juha Nieminen wrote: > It will perhaps never cease to amaze me your insistence in making your > code less readable, harder to decipher, needlessly long, and needlessly > requiring personal header files that nobody else gives a flying f about. If you don't understand that code then you're stupid. - Alf |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 07 12:05PM +0100 On 07.12.2020 08:49, Juha Nieminen wrote: > Seems like quite counter-productive. You write more code in order to make > your code less legible. > If I were reviewing your production code, I would never give this a pass. In any realistic setting I would review your code, not opposite. >> #include <kickstart/all.hpp> >> using namespace kickstart::all; // out, endl, fail, begin, end > This whole program is invalid because it fails to compile. For example, here you prove that you don't even master the basic tool usage. The code is perfectly fine, it compiles cleanly. > No matter how much you try to push your personal libraries, they will not > catch on. I wonder what's wrong with you with all that negativity and pushing your ideas of others' motivations. You are evidently not a good person. Why don't you take a hike. > Just stick to *standard* C++, which is all this newsgroup is about. This code is all standards-compliant C++17 code. You're an incompetent. - Alf |
spuddy@isnotyourbuddy.co.uk: Dec 07 11:31AM On Mon, 7 Dec 2020 12:01:04 +0100 >> code less readable, harder to decipher, needlessly long, and needlessly >> requiring personal header files that nobody else gives a flying f about. >If you don't understand that code then you're stupid. You're the typical know it all insecure programmer - you write unnecessarily complex code simply in order to show off then call people stupid if they have an issue with it. You have an attitude problem that would make you a nightmare to work with. |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 07 12:33PM +0100 > complex code simply in order to show off then call people stupid if they have > an issue with it. You have an attitude problem that would make you a nightmare > to work with. Juha Nieminen, you're an idiot. And perhaps very lonely, to try to troll this way. But definitely an idiot, and not a very nice person. - Alf |
spuddy@isnotyourbuddy.co.uk: Dec 07 11:34AM On Mon, 7 Dec 2020 12:05:21 +0100 >> your code less legible. >> If I were reviewing your production code, I would never give this a pass. >In any realistic setting I would review your code, not opposite. Have you been promoted out of harms way then? Did you company get sick of your unmaintainable convoluted obtuse code but couldn't fire you so promoted you to some meaningless management role instead? Any idiot can write convoluted code , it takes a good programmer to write code that does a good job AND is clear and easy to understand. I would suggest you have a think about that. |
spuddy@isnotyourbuddy.co.uk: Dec 07 11:53AM On Mon, 7 Dec 2020 12:33:03 +0100 >> to work with. >Juha Nieminen, you're an idiot. And perhaps very lonely, to try to troll >this way. But definitely an idiot, and not a very nice person. The fact that you think I'm a sock puppet says it all. Are you too stupid or just too arrogant to search what other groups I post to? I've been lurking on here for a while and used to post under a different name. |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 07 09:31PM +0100 On 06.12.2020 13:29, Jorgen Grahn wrote: > Advent of Code > https://adventofcode.com/2020 Minimal support library: <url: https://github.com/alf-p-steinbach/kickstart/blob/master/source/examples/hello-world.md> ------------------------------------------------------------------------ #include <fstream> #include <sstream> using std::ifstream; #include <kickstart/all.hpp> using namespace kickstart::all; auto read_map() -> vector<string> { vector<string> result; const auto& filename = "map-data.txt"; ifstream f( filename ); hopefully( not f.fail() ) or fail( ""s << "Failed to open '" << filename << "'." ); string line; while( getline( f, line ) ) { result.push_back( line ); } hopefully( f.eof() ) or fail( ""s << "Error reading file '" << filename << "'." ); return result; } struct Point { int x; int y; void operator+=( const Point& other ) { x += other.x; y += other.y; } }; void cpp_main() { const vector<string> map = read_map(); const int w = static_cast<int>( ssize( map.front() ) ); const int h = static_cast<int>( ssize( map ) ); int64_t product = 1; const Point deltas[] = {{1, 1}, {3, 1}, {5, 1}, {7, 1}, {1, 2}}; for( const Point delta: deltas ) { Point current = {0, 0}; int count = 0; while( current.y < h ) { count += (map[current.y][current.x] == '#'); { //with auto& _ = current; _ += delta; _.x %= w; } } product *= count; } out << product << endl; } auto main() -> int { return with_exceptions_displayed( cpp_main ); } ------------------------------------------------------------------------ - Alf (evening coding mode) |
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Dec 07 10:34PM On 07/12/2020 11:33, Alf P. Steinbach wrote: >> an issue with it. You have an attitude problem that would make you a nightmare >> to work with. > Juha Nieminen, you're an idiot. And perhaps very lonely, to try to troll this way. But definitely an idiot, and not a very nice person. Juha is correct, Alf, your code is hard to read. My biggest gripe is that you don't use "std::vector" but instead use "vector"; namespaces where invented to make code easier to grok so please stop trying to defeat their purpose. YOUR CODE IS HARD TO READ. /Flibble -- 😎 |
Vir Campestris <vir.campestris@invalid.invalid>: Dec 07 09:33PM On 04/12/2020 23:45, Öö Tiib wrote: >> behaviour varies depending on the class. > Can you post brief example of what you want to do and why > non-member operators can not help? struct A { std::string to_string(); }; struct XML { A a; std::ostream& operator<<(std::ostream& os, A const& datum) { os << "<A>" << a.to_string() << "</A>" ; } }; struct JSON { A a; std::ostream& operator<<(std::ostream& os, A const& datum) { os << "{\"A\":\"" << a.to_string() << "\"}" } }; Within the struct XML an A should be written in XML format; within JSON it should be written in JSON format. (The actual differences are more subtle, and there are 4 classes containing many different data types) With non-member operators they are shared. I have a workaround; declare the operators in a namespace, and add "using ns;" in each class. Andy |
"Öö Tiib" <ootiib@hot.ee>: Dec 07 02:29PM -0800 On Monday, 7 December 2020 at 23:34:09 UTC+2, Vir Campestris wrote: > }; > Within the struct XML an A should be written in XML format; within JSON > it should be written in JSON format. These accept argument "datum" but output member "a"? I assume typo. > containing many different data types) > With non-member operators they are shared. I have a workaround; declare > the operators in a namespace, and add "using ns;" in each class. Ok. Seems lucky case where you do not need member's names ... and class name is plenty. |
Bonita Montero <Bonita.Montero@gmail.com>: Dec 07 02:13AM +0100 > The std::shared_ptr is expensive and so if its features are > not needed then it is pointless waste of resources into > unneeded complexity. No, shared_ptr isn't expensive. But not all data-types inside the task-objects might be moveable. |
Bonita Montero <Bonita.Montero@gmail.com>: Dec 07 02:29PM +0100 > The std::shared_ptr is expensive and so if its features are > not needed then it is pointless waste of resources into > unneeded complexity. And even more: the parameters inside the packaged task might not have a move-constructor or move-assignment-operator ! |
"Öö Tiib" <ootiib@hot.ee>: Dec 07 06:50AM -0800 On Monday, 7 December 2020 at 15:29:27 UTC+2, Bonita Montero wrote: > > unneeded complexity. > And even more: the parameters inside the packaged task might > not have a move-constructor or move-assignment-operator ! No. The actual issue is likely that you use defective packaged_task of Visual Studio. They refuse to fix it: <https://developercommunity.visualstudio.com/content/problem/108672/unable-to-move-stdpackaged-task-into-any-stl-conta.html> But you just post nonsense instead of saying that like usual. |
spuddy@isnotyourbuddy.co.uk: Dec 07 03:36PM On Mon, 7 Dec 2020 06:50:27 -0800 (PST) >of Visual Studio. They refuse to fix it: ><https://developercommunity.visualstudio.com/content/problem/108672/unable-to-m >ove-stdpackaged-task-into-any-stl-conta.html> If that hideous line noise in stackoverflow is the answer then someone is asking the wrong question. Probably written by Alf or one of his diciples. |
Bonita Montero <Bonita.Montero@gmail.com>: Dec 07 04:38PM +0100 > <https://developercommunity.visualstudio.com/content/problem/108672/unable-to-move-stdpackaged-task-into-any-stl-conta.html> > But you just post nonsense instead of saying that > like usual. He is packaging the task incorrectly. |
olcott <NoOne@NoWhere.com>: Dec 06 11:14PM -0600 On 12/6/2020 7:56 PM, Ben Bacarisse wrote: > Confound_Halts(Confound_Halts) and its simulation > Simulate(Confound_Halts, Confound_Halts) halt. The sentence does not > apply. The Turing Machine equivalent to a global halt decider would simply be a UTM that has been adapted to become a halt decider. This adapted UTM would decide not-halting on all three of the TM equivalent to the following three computations. Halts(main()) is called thus deciding infinite recursion of all three of these computations: int main() { HERE: goto HERE; } This is a simplified version of the infinite recursion detector that I designed two years ago (Hopefully this one is not over Mike's head): This is my 2018-12-13 solution: Every time the same function is called a second time from the same machine address with no control flow instructions** in-between we can know that this is definitely infinite recursion. ** A simplification of the original criteria to make my proof easier to understand. int main() { Halts(Confound_Halts, Confound_Halts); } This one is provided with a full execution trace: int main() { Confound_Halts((u32)Confound_Halts); HALT; } _Confound_Halts() [000005e0](01) 55 push ebp [000005e1](02) 8bec mov ebp,esp [000005e3](03) 8b4508 mov eax,[ebp+08] [000005e6](01) 50 push eax [000005e7](03) 8b4d08 mov ecx,[ebp+08] [000005ea](01) 51 push ecx [000005eb](05) e880fdffff call 00000370 [000005f0](03) 83c408 add esp,+08 [000005f3](02) 85c0 test eax,eax [000005f5](02) 740b jz 00000602 [000005f7](05) ba01000000 mov edx,00000001 [000005fc](02) 85d2 test edx,edx [000005fe](02) 7402 jz 00000602 [00000600](02) ebf5 jmp 000005f7 [00000602](01) 5d pop ebp [00000603](01) c3 ret _main() [00000610](01) 55 push ebp [00000611](02) 8bec mov ebp,esp [00000613](05) 68e0050000 push 000005e0 [00000618](05) e8c3ffffff call 000005e0 [0000061d](03) 83c404 add esp,+04 [00000620](01) f4 hlt [00000621](01) 5d pop ebp [00000622](01) c3 ret Output_Debug_Trace() Trace_List.size(17) [00000610](01) EMU_Level(0) 55 push ebp [00000611](02) EMU_Level(0) 8bec mov ebp,esp [00000613](05) EMU_Level(0) 68e0050000 push 000005e0 [00000618](05) EMU_Level(0) e8c3ffffff call 000005e0 ----CALL [000005e0] [000005e0](01) EMU_Level(0) 55 push ebp [000005e1](02) EMU_Level(0) 8bec mov ebp,esp [000005e3](03) EMU_Level(0) 8b4508 mov eax,[ebp+08] [000005e6](01) EMU_Level(0) 50 push eax [000005e7](03) EMU_Level(0) 8b4d08 mov ecx,[ebp+08] [000005ea](01) EMU_Level(0) 51 push ecx [000005eb](05) EMU_Level(0) e880fdffff call 00000370 ----CALL [00000370] [000005e0](01) EMU_Level(1) 55 push ebp [000005e1](02) EMU_Level(1) 8bec mov ebp,esp [000005e3](03) EMU_Level(1) 8b4508 mov eax,[ebp+08] [000005e6](01) EMU_Level(1) 50 push eax [000005e7](03) EMU_Level(1) 8b4d08 mov ecx,[ebp+08] [000005ea](01) EMU_Level(1) 51 push ecx [000005eb](05) EMU_Level(1) e880fdffff call 00000370 ----CALL [00000370] The PRIOR Instruction Specifies Infinite Recursion: Simulation Stopped: -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
olcott <NoOne@NoWhere.com>: Dec 06 10:07PM -0600 On 12/6/2020 7:56 PM, Ben Bacarisse wrote: > Simulate(Confound_Halts, Confound_Halts) halt. The sentence does not > apply. > Would you like me to explain the ruse you are trying to pull off again? I proved that the simulation of Confound_Halts(u32 P) had to be halted on line 18 of the simulation. The infinite recursion is between lines 12 and 18 of the simulation's execution trace shown at the bottom. Either this is over your head or you are a liar. I have incorrectly called you a liar so many times that I am going with it is over your head. The assembly language must be too difficult for you. This is my 2018-12-13 solution: Every time the same function is called a second time from the same machine address with no control flow instructions** in-between we can know that this is definitely infinite recursion. ** A simplification of the original criteria to make my proof easier to understand. I completely recreated the whole simulation. Prior simulations may have been incorrect. Actual debug trace of Halts() deciding halting on main() void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); } int main() { Halts((u32)Confound_Halts, (u32)Confound_Halts); HALT; } _Confound_Halts() [000005e0](01) 55 push ebp [000005e1](02) 8bec mov ebp,esp [000005e3](03) 8b4508 mov eax,[ebp+08] [000005e6](01) 50 push eax [000005e7](03) 8b4d08 mov ecx,[ebp+08] [000005ea](01) 51 push ecx [000005eb](05) e880fdffff call 00000370 // CALL Halts() [000005f0](03) 83c408 add esp,+08 [000005f3](02) 85c0 test eax,eax [000005f5](02) 740b jz 00000602 [000005f7](05) ba01000000 mov edx,00000001 [000005fc](02) 85d2 test edx,edx [000005fe](02) 7402 jz 00000602 [00000600](02) ebf5 jmp 000005f7 [00000602](01) 5d pop ebp [00000603](01) c3 ret _main() [00000610](01) 55 push ebp [00000611](02) 8bec mov ebp,esp [00000613](05) 68e0050000 push 000005e0 [00000618](05) 68e0050000 push 000005e0 [0000061d](05) e84efdffff call 00000370 // CALL Halts() [00000622](03) 83c408 add esp,+08 [00000625](01) f4 hlt [00000626](01) 5d pop ebp [00000627](01) c3 ret Output_Debug_Trace() Trace_List.size(18) [00000610](01) EMU_Level(0) 55 push ebp [00000611](02) EMU_Level(0) 8bec mov ebp,esp [00000613](05) EMU_Level(0) 68e0050000 push 000005e0 [00000618](05) EMU_Level(0) 68e0050000 push 000005e0 [0000061d](05) EMU_Level(0) e84efdffff call 00000370 // CALL Halts() [000005e0](01) EMU_Level(1) 55 push ebp [000005e1](02) EMU_Level(1) 8bec mov ebp,esp [000005e3](03) EMU_Level(1) 8b4508 mov eax,[ebp+08] [000005e6](01) EMU_Level(1) 50 push eax [000005e7](03) EMU_Level(1) 8b4d08 mov ecx,[ebp+08] [000005ea](01) EMU_Level(1) 51 push ecx [000005eb](05) EMU_Level(1) e880fdffff call 00000370 // CALL Halts() [000005e0](01) EMU_Level(2) 55 push ebp [000005e1](02) EMU_Level(2) 8bec mov ebp,esp [000005e3](03) EMU_Level(2) 8b4508 mov eax,[ebp+08] [000005e6](01) EMU_Level(2) 50 push eax [000005e7](03) EMU_Level(2) 8b4d08 mov ecx,[ebp+08] [000005ea](01) EMU_Level(2) 51 push ecx [000005eb](05) EMU_Level(2) e880fdffff call 00000370 // CALL Halts() The PRIOR Instruction Specifies Infinite Recursion: Simulation Stopped: -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
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