Thread

1. BobbyTables2 · 1789744507 · focus · HN ↗

   TLDR: For almost 1/6 of a century, the C++ standards broke the simplest infinite loop and only just recently fixed it.

   Idiots!

   Don’t they really that people write real programs to solve real problems? This isn’t a theoretical academic exercise!

   1. bluGill · 1789745607 · focus · HN ↗

      You are an idiot if you write an infinite loop. An infinite loop is a waste of CPU cycles and energy when run.

      If it wasn't so hard to detect (the trivial cases are easy, but it gets hard quickly) I'd say the program should fail to compile.

      1. echoangle · 1789746186 · focus · HN ↗

         And how would you generate assembly to keep a microcontroller idle then?

         1. bluGill · 1789747159 · focus · HN ↗

            You call the CPU halt instruction.

            1. echoangle · 1789747504 · focus · HN ↗

               What if my CPU doesn't have that? I don't think Atmel Microcontrollers do for example.

               1. bluGill · 1789750837 · focus · HN ↗

                  Better CPU selection. Embedded almost always have power requirements and you need to put your CPU into a low power mode not a loop which is running fast. You can also design your hardware such that you can turn the power off completely in these cases (or perhaps reboot).

                  Now that I think of it, a different project (I worked just down the aisle, but I wasn't on it) solved a lot customer complaints by turning all the "while(1);" loops into blink an error code - which since it does IO is defined behavior. Which probably is the correct answer to your question - don't just spin doing nothing, spin in such a way that the user has a clue why nothing is working (and in turn you can find out and perhaps fix real world bugs)

                  1. dare944 · 1789753625 · focus · HN ↗

                     This is myopic. In many cases it takes time, and sometimes considerable programming effort, to enter and exit low power modes. So you don't do it willy-nilly; you do it when you believe the system has quiesced. That means, on a purely interrupt driven system that is not yet ready to sleep, the code may very well be spinning in an empty infinite loop somewhere.

                     There's no need to inform the "user" because there's nothing wrong with the system. Its simply waiting until the benefit of sleeping outweighs the cost of getting there.

                     1. bluGill · 1789760900 · focus · HN ↗

                        The context here is an infinite loop with no side effects. You have all the time needed to enter those states.

                        1. echoangle · 1789761762 · focus · HN ↗

                           Not necessarily, you could also want to make an infinite loop and wait for an interrupt without eanting to power down.
                        2. dare944 · 1789766428 · focus · HN ↗

                           It may take 100s of instructions to enter a deep sleep state, and 100s to 1000s more to exit it. If you anticipate having to service an event sooner than that, you don't enter sleep at all (especially since there's likely a point at which you're committed to sleep, and have to go all the way down in order to come right back out again). Instead, you hang around twiddling your thumbs until the event comes along.

                           Now if your processor has a halt/wait-for-interrupt instruction (most do but some don't) you can escape into assembly and use that. But it probably makes little to no difference to energy utilization, and of course its not portable. A nice while (true); would seem obvious, except that the C++ committee insisted that it wasn't.

                           Just one example of where the committee lost sight of the fact that it was defining an imperative programming language.

               2. AMDmi3 · 1789753799 · focus · HN ↗

                  AVRs have SLEEP instruction.

Unofficial Hacker News client; not affiliated with Y Combinator.