sterretje:
You will have to initialise the static int pixel with 80; by default it's initialised with 0. So the first time it will run from 0..121.
Looks like it did the job.. Thanks 
pixel = ++pixel%41;
Jiggy-Ninja:
I had to look up one of those statements to make sure it didn't have undefined sequencing. I don't even think most people on this forum would even be able to spot that as a potential issue.
It is undefined isn't it?
Hmm, maybe not under C++11. Still, that statement is a mess.
RayLivingston:
It's not the static context that's confusing. It's using a static interator in a for loop. i first used c in about 1981, and spent many years writing code, and almost 20 years managing teams of programmers writing c and c++ code. In all that time I never once saw the iterator in a for loop declared as static like that.
Me neither.
AndyKe:
You could say i got confused when i went back to this thread this early morning xD I see now, that a for loop is a bad design solving my problem.
And yes, You're all right about my lack of experience. Im an absolute newbie xD So the conclusion would be never to use a "for loop" for my specific task.This would do the job then..?
static unsigned long _timer = millis();
static int pixel;
...
if ((millis() - _timer) >= 100)
{
_timer = millis();
myGLCD.drawPixel(pixel, 206);
if (++pixel > 121)
pixel = 80;
}
You shouldn't use a for loop for sequencing. The loop() function is already looping for you, so you don't have to make another loop inside it. What for loops are mostly for is if you have a bunch of things you want to do the same operation on, like using pinMode or analogRead on a few pins at the same time.
Snippets are frowned upon, especially for someone new like you that won't know a lot of the subtle details. It's recommended to post a full sketch. If pixel and _timer are declared as global variables, they don't need to be declared static. It won't hurt them to be static since it's unlikely that you will be externally linking them (or even know what "external linkage" is), but it's also not necessary. If they are declared in the loop function, then yes they need to be static.
static is one of the more confusing C++ keywords to get a grasp of, since the meaning changes depending on whether it's used on a global-scope variable, block-scope variable, or class member.
I defined pixel as part of the for loop. Bad coding, I know.
for(static unsigned long _timer, pixel;.....
This uses math to count up from 0 to one less than x it stores it in the variable to prevent issues during rollover foo will never be x because the same number decided by itself has a remainder of zero starting the counter over.
++ operator before foo increments foo first, then we get the remainder after division by x and save it back in foo.
foo = ++foo%x;
I've seen this used elsewhere in others code but I admit it is confusing to new programmers. I'm not sure if this is good coding practice or not. I have not tested this for size advantages either.
Z
zhomeslice:
I've seen this used elsewhere in others code but I admit it is confusing to new programmers. I'm not sure if this is good coding practice or not. I have not tested this for size advantages either.
Z
Good coding practice is to write code that is clear and simple. Sadly, many programmers seem to believe "it was hard to write, so it should be hard to understand". If you must write complex expressions, use parentheses to make the evaluation order obvious, so others don't have to get out their c reference manuals to figure out what order the compiler will use. "Clever" code will almost always lead to "clever" bugs that can be extremely hard to find. Sadly, c/c++ is rife for such abuse. And, it makes it much more difficult for others to understand, much less modify, the code later on. It will likely make it harder for the original author to understand a few months, or years, down the road. There are times when the code must be complex, for the sake of speed, or size, or some other factor. But those occasions are exceedingly rare with fast, modern processors. The VAST majority of the time, clear, simple code will take less time to write, FAR less time to debug, and will be more reliable in the long term.
Regards,
Ray L.
You see, even Nick is unsure.
For the record, it is only OK if you are using one of the Arduino versions that uses the C++11 standard. I'm not sure when the change happened, but I think the last couple versions (1.7.X and 1.8.X) have used C++11.
And even then, it's only OK because it's the prefix increment operator. Change it to postfix, and it's undefined.
RayLivingston:
Good coding practice is to write code that is clear and simple. Sadly, many programmers seem to believe "it was hard to write, so it should be hard to understand". If you must write complex expressions, use parentheses to make the evaluation order obvious, so others don't have to get out their c reference manuals to figure out what order the compiler will use. "Clever" code will almost always lead to "clever" bugs that can be extremely hard to find. Sadly, c/c++ is rife for such abuse. And, it makes it much more difficult for others to understand, much less modify, the code later on. It will likely make it harder for the original author to understand a few months, or years, down the road. There are times when the code must be complex, for the sake of speed, or size, or some other factor. But those occasions are exceedingly rare with fast, modern processors. The VAST majority of the time, clear, simple code will take less time to write, FAR less time to debug, and will be more reliable in the long term.Regards,
Ray L.
It's just like when people use big, complex words to try and sound smart but don't know what those words actually mean and end up looking really stupid.
Jiggy-Ninja:
It's just like when people use big, complex words to try and sound smart but don't know what those words actually mean and end up looking really stupid.
Agreed! I find this thread quite jocose. Witnessing the castigation of @zhomeslice’s coruscating perspicacity over the more antediluvian rubric contemplated is, well, captivating.
BulldogLowell:
Agreed! I find this thread quite jocose. Witnessing the castigation of @zhomeslice’s coruscating perspicacity over the more antediluvian rubric contemplated is, well, captivating.
Lol, I had fun too @BulldogLowell
Z
P.S. I only had to look up most of the words 
BulldogLowell:
Agreed! I find this thread quite jocose. Witnessing the castigation of @zhomeslice’s coruscating perspicacity over the more antediluvian rubric contemplated is, well, captivating.
++karma for working "antediluvian" in there.
"So God made the vault and separated the stack under the vault from the heap above it. And it was so."
Jiggy-Ninja:
It's just like when people use big, complex words to try and sound smart but don't know what those words actually mean and end up looking really stupid.
Yup. One thing I learned from many years of engineering management - one brilliant, but undisciplined, engineer can cause more damage than a whole building full of average, but disciplined engineers. They try to be "clever", and impress people, and think the rules don't apply to them. A recipe for disaster. One project, a large VLSI design project, was years behind schedule, because a small team of brilliant engineers were given free-rein to do what they wanted. Their design was massively complex, and took years to debug. Individual bugs would often take literally months of simulations and testing to find root cause.
Simple is good. Complexity kills.
Regards,
Ray L.
And I suppose "throw it in the trash and start over" wasn't an option, under the "we have to throw good money after bad otherwise the bad money will be wasted!" rule of business management.
Jiggy-Ninja:
And I suppose "throw it in the trash and start over" wasn't an option, under the "we have to throw good money after bad otherwise the bad money will be wasted!" rule of business management.
Thank goodness we are just enjoying some time typing on a forum and not engineering rockets.
While it's all fun and games to criticize stupid questions, sometimes we need to understand that even though it's possible to do it one way, it's not always the best way to do it. The most important part is why this shouldn't be done.
Consider the first function every Arduino programmer learns "delay()" for example. Arduino need a simpler way to handle blink without delay just like they have with min() and max().
I see at any one time several first timer posts related to blocking delay() every day. And the reply posts get brutal at times. Most of the example code uses this because blink without delay is not simple and so we are in a never ending while loop.
Z
Jiggy-Ninja:
And I suppose "throw it in the trash and start over" wasn't an option, under the "we have to throw good money after bad otherwise the bad money will be wasted!" rule of business management.
That project was three years in the making when I joined the company. My first week, I read the spec, and told my boss it was a train-wreck in the making. But, I was the "new guy", what did I know. That was Jan. 2001, and the project was supposed to ship in Fall '02. I left the company in April '05, and the product finally shipped in '06.
Amazing how many times that has happened in my career. Another company I joined, a start-up, had a product they'd spent 3.5 years and $35M developing, that was going into production "in a few months". I was hired to lead the "next-generation" development. Of course, I started by studying the existing design. My second week on the job, I told the CEO not only was the first product not going into production that year, it was not going into production ever, because it simply did not work! But they did have a great demo! I offered the CEO a plan that would get them a product, albeit with more money, and time, required to re-do many things. To his credit, he took me seriously, had me take my concerns straight to the BoD. They thought I was a "pessimist", and dismissed by concerns. I joined the company in January, and left in July. They finally figured out I was right, but it was far too late. Literally on Xmas Eve that same year, everyone got pink slips, and they closed up shop for good. The whole fiasco was the result of one "brilliant but undisciplined" engineer who ran the whole show. The amazing thing was, all the engineers knew it was a train-wreck, but nobody would speak up, because the company culture was one of unbridled optimism, facts be damned.
Regards,
Ray L.