There are some simple ways to improve bubble sort. The first is to move in two directions. The second is to first start comparing elements at a large distance than one and reduce the distance on how often element needed to be swapped.
I once used code duplication to implement a fourth type of dialog that looked somewhat similar to the others, that were sharing a lot of code, because I felt that although it looked much the same as the others, there was some fundamental difference. Took me about a day to implement. When some other engineer saw this, he spend the next three weeks trying to integrate all of them with some shared class. His work was not completely worthless, because he did find some small bug during all his efforts to avoid any possible code duplication. I already had predicted that it would take a lot effort, but I did not object, because I hoped that he would learn something from it and the next time think twice before always trying to avoid code duplication.
Many people have complained about the quality of TCC code. It sometimes feel the code id one big unittest including all nasty C edge cases. I found this out when developing an even tinnier C compiler to compile TCC 0.9.26.
I think that if you as 60+ person cannot bike without support your brain is probably also not fit enough anymore for the speed you are going to ride at. So, I advice older people not to use an e-bike. I am not going to use one. Maybe a trike is a safe option at speeds not exceeding 10km/h.
Are there also open-source solutions without dependency on server in the cloud and that depend on internet connection? I am looking for a total home solution where I can communicate with doorbel through laptop with headset.
Is comparing a signed integer with an unsigned integer UB? I resently wrote some code and compiled it with gcc to x86_64 (without optimization) that returned an incorrect answer.
This is one of the most frustrating things as being a software engineer: working on solutions that you feel that are not going to work. In some cases, I was the one saying that a particular solution was not going to work. It did not bring me any good.
Question: I once heard somebody talk about a micro-controller (with a minimal instruction set) where every register could be the program counter. It did not have jump or call instructions. You had 'emulate' those with the instruction (possibly conditionally) that changed the assignment of the program counter to one of the instructions. If I am not mistaken, it had eight registers. Does this ring a bell?
What about privacy? Maybe not everyone wants to share his information with every far relative that you might never have met or twenty years ago when your grandmother died and you already have become a grandparent as well.
I find this a bit disappointing. Why not publish it with the preprint. Now we have no way to establish the quality of the two solutions or whether it is even possible to improve one of the solutions. I wonder why the C variant could not implement a JSON parser without malloc and free, while the RUST variant could.
Really strange the the C JSON parser has to use malloc where the RUST version does not. As if it is not possible to write a JSON parser in C that does use malloc. I presume that the syntax of the commands that the device will accept is known, and than there is no reason why you have to build a DOM of the JSON before you can process it. Apparently, the RUST version can do it. I really begin to question the abilities of two teams if the one team failed to implement a JSON parser solution without using memory allocations.
I developed a similar language as an intermediate language for a C-compiler that I wrote. It uses reverse Polish notation instead of Polish notation [1], because it is easier to compile reverse Polish notation to machine code. I call the language Stack-C. See [2]. There are 32 bit and 64 bit compilers for x86 assembly and there is a memory safe interpreter for the language with a (rather limited) built-in debugger.