Neat... I use(d) pre-decrement quite a lot (when walking an array (backwards when direction did not matter)... luckily I used just the while () ...; and not the do ... while() construct and never noticed an issue... ...and there is no issue with it... (the 'real' pre-pre-decrement...) - haha (I usually try NOT to enter a loop unconditionally... it is increased risk for an infinite loop (and it has messed with me). Of course, even with an upfront conditioned loop, an infiniteloop is possible, but much less because 'the break/exit thinking' is done upfront rather than an after thought. If I wanted to run the loop at least once, that would go also into the setup of the upfront condition... and thought. I'm though very aware of the fact that the do ... while() construct can be very useful (and is actually very Espruino-economic): it conveys already by its very architecture that the loop body is executed at least once where as with the upfront condition that fact is masked and only understood by wading the start values and the condition. @MaBe, saw your post the day before. Even though it is fixed now, i wanted to know if I was affected by it.
// predecrement.js
function predecTest() {
var i=5; // for example: ...=array.legth()
while(--i >= 0) console.log(i); // walk array
console.log("----(1)");
var j=4; // for example: ...=array.legth()-1
while (j >=0) {
console.log(j);
j--; }
console.log("----(2)");
var k=5; // for example: ...=array.legth()
while (k > 0) { k--; // walk array
console.log(k); }
console.log("----(2)");
var l=4; // for example: ...=array.legth()-1
do { console.log(l);
} while(--l >= 0); // walk array
console.log("----(4)");
}
function onInit() {
predecTest();
}
setTimeout(onInit,999);
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Neat... I use(d) pre-decrement quite a lot (when walking an array (backwards when direction did not matter)... luckily I used just the
while () ...;
and not thedo ... while()
construct and never noticed an issue... ...and there is no issue with it... (the 'real' pre-pre-decrement...) - haha (I usually try NOT to enter a loop unconditionally... it is increased risk for an infinite loop (and it has messed with me). Of course, even with an upfront conditioned loop, an infiniteloop is possible, but much less because 'the break/exit thinking' is done upfront rather than an after thought. If I wanted to run the loop at least once, that would go also into the setup of the upfront condition... and thought. I'm though very aware of the fact that thedo ... while()
construct can be very useful (and is actually very Espruino-economic): it conveys already by its very architecture that the loop body is executed at least once where as with the upfront condition that fact is masked and only understood by wading the start values and the condition. @MaBe, saw your post the day before. Even though it is fixed now, i wanted to know if I was affected by it.Output: