Iterative approach? You mean as opposed to recursive?
Well, most programming is iterative, in that you walk through a set of values rather than taking an object and repeatedly applying a method to simplify until a base case is reached.
So you might iteratively walk through a collection by assigning numbers to each element in the collection (think: an array) and going in sequence through each element. (think: for loop)
Or you might recursively walk through that collection by removing one item, possibly doing something with that item, and passing the resulting set, less one member, back to the same function, which again removes one member and possibly does something with it, etc., until the set is empty.
Many people find recursion to be a difficult notion to get their heads around, but I've never run into anyone having confusion with the iterative approach.
Can you explain more about what you're looking for? Maybe I've misunderstood. At least one of us is confused, in any case. :)
hey i am talking about iterative planning technique for example if i take a simple c++ program how would i plan using iterative development as in this development it is divided into several iteration so how would i start with it
Okay, maybe you mean what I call the 4-R cycle: require, write, refactor, repeat.
Start with a program that does nothing. HelloWorld is a good starting place, because you have nothing invested in the code.
1) Require a new feature. This program would be much better if I added one simple thing. Say, it should prompt me for my name and accept a character string as input. (keep the features simple!)
2) Write that feature.
3) Refactor - well, not much to refactor yet.
4) Repeat: okay, now I want to prompt for first name, accept that, and then prompt for last name and get that as a separate string.
5) Write it.
6) Refactor: oh, look at this. I wrote two prompts and two inputs. Refactor to combine those into functions
void prompt(char *str) and
void accept(char *str) // str is destination of input string
You can include writing unit tests in the "write" phase, or in the "require" if you like. I'm going to remain agnostic on that one.
Read any of the plethora of books on agile/extreme/pragmatic methodologies for extremely detaile, not to say long-winded and cultish treatments of this subject.
(is "pragmatic" a methodology or just a brand? I can't tell)