Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

FOR loop in C

Status
Not open for further replies.

eblc1388

Active Member
Hi,

What is the middle parameter suppose to do in the FOR loop definition in the following code? Usually it is the upper limit for the loop variable but this construct is a little different from others.

Code:
#include <io8515.h>
/* This seems to produce the right amount of delay for the LED to be
 * seen
 */
void Delay()

{
	unsigned char a, b;

for (a = 1; a; a++)                   // <<<<<<<<
		for (b = 1; b; b++)   //  <<<<<<<
			;
	}

void LED_On(int i)
	{
	PORTB = ~BIT(i);	/* low output to turn LED on */
	Delay();
	}
 
a FOR loop will terminate when the middle parameter evaluates to 'false'. but really, it's when it evaluates to zero. Usually you use a conditional statement like a<100, however the compiler is just as happy to terminate the loop when the value of 'a' is zero.

It should be exactly the same as 'for(a=1; a!=0; a++)', it's just the 'hacker' way to get it done while saving three keystrokes, but making people scratch their head over it, as you realized firsthand ;)

It's obfuscated code like that that makes some people dislike C... The programmer saves themselves a fraction of a second worth of effort, but can waste hours of the collective time of those who try to understand it later on. I wouldn't be surprised to hear from Nigel about this one :)
 
Last edited:
Thanks. That's explains it very clearly.

I don't think Nigel is disliking C in general, he just think that with PIC applications, using C is "too heavy weighted", consume a lot of program memory words and slow for simple tasks like flashing LEDs or sending IR codes.
 
Yes, it is the same as "a!=0", but this might work with C for microcontrollers, supposing that an 8 bit register overflows and re-starts from 0. Personally, I don't like that sintax and suggest to use "a<=255".
 
Pommie said:
That won't work on an eight bit variable as 0 is less than 255.
yep, you'd have a bit of an infinite loop on your hands there ;)

but 'for(a=0; a<255; a++)' would work, which is probably what they meant to say.
 
It just as evandude said: The conditional statement to break out the loop. At first glance I thought those loops would run forever but had to remind myself that this is a microcontroller. A and B will simply overflow from 255 to 0 and then force the loops to exit.

I wonder why and what would be wrong with using a decrementer like A-- and B-- that clearly makes more sence as opposed to this "ugly getting away from whats important" code as C is so infamously known for.
 
They would overflow on a PC as well, you would get the exact same results if you explicitly defined the size of A and B as an 8 bit byte. PC compilers though tend to use 16 or 32 bits for a byte because that's the native metric for the processors. It's not a quirk of the langauge it's a failure of the programmer to understand what langauge and system they're programming for. One of my favorite movie quotes goes "Asumption is the mother of all fuckups"
 
Pommie said:
That won't work on an eight bit variable as 0 is less than 255.

Mike you're right, sorry for the oversight!

I also tried to simulate the original code and the loops break, as I supposed. I don't expext the same program to have predictable results, when running on a PC.
 
Last edited:
Nigel Goodwin said:
You would be wrong, I do dislike C in general! :D

I shared your view until a few days ago. I used to code in assembly.

Last weekend I coded a LCD display routine in C for AVR, and it worked as normal.

To see how difficult it is to be if I now choose to use a PIC instead, I changed three #define lines for Port definition at the top of the code for PIC and bingo it compiled ok and works on PIC too.

I was happy. It saved me a lot of time as my code can be re-used on both AVR and PIC with very minor changes.

Isn't this is what "C" is all about?
 
eblc1388 said:
Isn't this is what "C" is all about?
all about? no. but portability is certainly up there. I've got libraries that I use on the PIC, msp430, AVR and Renesas M16. recompile is all it takes. 8 vs 16 bit is a little tricky, though.

on the point about obfuscation. There has been a long standing "obfuscated C contest" tradition amongst C programmers - more as a joke than anything else. I think it's pretty easy to write god-awfull code in any language. Bad programmers write bad code, no matter what the language.
 
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top