Hi!
I wanted to know how to have animated text, like displaying each letter at a different time.
Please can u telll me! :D
Printable View
Hi!
I wanted to know how to have animated text, like displaying each letter at a different time.
Please can u telll me! :D
Well, if you have the text saved in a string, you could do something like this:
It's simply a loop, displaying one character at a time.Code:string Text = "***ANIMATION***";
int Len = Text.size();
for ( int i=0; i<Len; i++ )
{
cout<< Text[i];
}
Thanks so much twomers!! :D :D
I was told you should really type
instead for good measure.Dont really know why but hey.Code:for ( int i=0; i !=Len; i++ )
I don't see how that is better for good measure as if there was some fault and it jumped about the value of int Len then it would keep going.
I think the != thing is needed for vectors and whatnot, but I don't really think it makes a difference. It yeilds the same effect, and what bumfluff said holds a lot of ground!
I know :)
It's not a requirement to do so. It's more an issue of good practice.
While probably open for debate, it is preferable to deal with the != operator instead of < or <= operators in for loop headers. This is so because generic algorithms for standard container types are much more picky in the choices we can make for operators. And loops are usually controlled with the != operator. As such, in an effort to maintain a single coding style across our program (and our programs), it is best one gets used to the != operator.
There is another reason... more debatable. And that is simply, it makes more sense to use != instead of < because it better captures the step nature of this type of loops.
Overall, it is a matter of preference. But do consider the shift to !=. It will pay later on.
The same for <= or < operators. Don't you think?Quote:
Originally Posted by bumfluff
Or couldn't you just use each when they are needed? I think for a 'for' loop, the '<' / '<'defines the acceptable scope for the loop better than the '!=' does ... if you know what I mean.
As I said, it is debatable... unless, you are using generic algorithms. On that case, you don't have a choice.
The underlying principle is thus consistency in our choices. This should always be our primary motivation.
Is's much safer I woud say. With < or <= it can never be out of bounds even if there is a mistake in the increment .Quote:
Originally Posted by Mario F.
Kurt
Really?Quote:
Originally Posted by ZuK
Do provide an example in which the choice of those operators would break in one instance and not on another.
Code:for ( int i=0; i<10; i++ )
{
i+= 12;
}
Code:for ( int i=0; i!=10; i++ )
{
i += 12
}
this will only write to buffer[0] and buffer[2];Quote:
Originally Posted by Mario F.
this will segfault for shureCode:char buffer[3];
for ( i = 0; i < sizeof(buffer); ++i ) {
buffer[i]=0;
++i ; by mistake;
}
KurtCode:char buffer[3];
for ( i = 0; i != sizeof(buffer); ++i ) {
buffer[i]=0;
++i ; by mistake;
}
That was funny :)
But I was expecting it...
You don't have a problem with the operator. You simply have a problem of bad code.
... I've just realized how off topic this is.
Not really. Off topic would be discussing why for is better than against.
As a side note, I do hope you realize the examples you provided are in fact yet another reason to choose !=. The bug inside the loop will be clearly visible once one runs the program. There's no telling what will happen on the other instance where one chooses < or <=.
The program may crash (which is good) or keep running and yield undefined results (which is very bad).
I agree, but you didn't specify that in your request for flaws with the '!=' ;) (nit picking and whatnot)
The only thing that I was thinking with my statement is that ifyour computer has some horrible glitch and then jumps over your limiting number in your for loop and that would mean that it would still be != and so would go into an infinite loop.
If such a thing happened then you, I, and the 16 megaton warhead launching engineer over there running your application, would want the program to crash. An infinit loop will do just that.
If you want to get the safest loop in the world, use the for_each algorithm. I'm sure they do this almost constantly in the nuclear weapons launching program.
Otherwise, for programs that we write, it is generally immaterial how we control for: Mario has merely proved that operator != is moderately safer in that it might crash the program, I'm more inclined to believe that this is undefined and the loop could run forever. > and < impose a ceiling which will stop the loop for sure.
No. More in the sense that it doesn't hide a bug in your code. It helps expose it. The "ceiling" provided by < or > operators may lead to undefined behavior if there was a bug and no checking being done after the loop ends. It has more potential to create an hard to find bug.Quote:
Mario has merely proved that operator != is moderately safer in that it might crash the program,
Me, being an engeneer ( luckily not working with warheads ), would prefer to keep the application running. I really hate it when I loose control of a process just because some possibly unimportant application crashes or locks the OS and I have to wait for a reboot. But I guess that is just a matter of perspective.Quote:
Originally Posted by Mario F.
Kurt
Really? You still wanted your application to keep running under undefined behavior?
Maybe perhaps if the loop ended with a 1 being sent to OrderLaunch(bool yesno)?
I think the argument is still semantic at best. It's... actually difficult for me to believe that you think != is going to help you find a seg-fault if you dereference memory that doesn't belong to your custom container class, or loop past the end of a c-string. Or why you think it's difficult to inspect your loop after it outputs the results X times more than it should.
Don't loop the launch instruction! Verify it via Alpha Niner OP 314159-A. Or use for_each. Geez. Nobody listens to me.
I am saying that as long an application runs there is still a chance for some corrective action. If it's dead no chance.
Kurt
Citizen,
I'm not advocating anything. I merely suggested that != might be a better approach to for loops. And I' sure I made it perfectly clear it is mostly a matter of taste. My opinion and that of those who defend this point of view is no more valid than anyone else's. Maybe if you stop, and slowly read the thread again you will see.
So please, don't step ahead of me in the line of "nobody is listening".
I believe it you read my post wrong.
> More in the sense that [not equal to] doesn't hide a bug in your code.
My previous reply was based on this statement, which clerly is no more true than what would happen if you used > or <. I did not say you were advocating anything, but what you are using to defend your point of view, and recommend that we switch from something natural is not making your point any stronger.
> You still wanted your application to keep running under undefined behavior?
Stopping a loop after i is not less than < 80 is defined. != would still be true, what happens?
My opinion is thus, and I will not repeat it.
We use != when it is necessary. If the loop condition will become an issue, for_each is good most of the time. Otherwise, as I've said, it's immaterial how to control for.
That was my bloody point from the beginning! Thanks for adding nothing to this thread.Quote:
My opinion is thus, and I will not repeat it.
We use != when it is necessary. If the loop condition will become an issue, for_each is good most of the time. Otherwise, as I've said, it's immaterial how to control for.
I am really not going to reply to this citizen. It's... no wordsQuote:
> You still wanted your application to keep running under undefined behavior?
Stopping a loop after i is not less than < 80 is defined. != would still be true, what happens?
> That was my bloody point from the beginning! Thanks for adding nothing to this thread.
No it wasn't, you need to reread your previous statements. The argument is based on semantics alone so you cannot defend your point of view with statements like "it does not hide a bug in your code," or that to use != for consistancy is good practice, when you yourself don't agree with it. In fact it is impossible to defend such a view with evidence.
This thread has ended peacefully.
Should have ended about two pages ago I think.
Yes. It should right at the point in which Citizen decided to jump in and transform an inocuous statement about a loop with a bug into a statement of principles.
Now what is the meaning of Life?
Could it be != 3
It couldn't be that easy to tell, but I could tell you that it's < Infinity.Quote:
Originally Posted by bumfluff
It might not be a number.
How about now?Quote:
Should have ended about two pages ago I think.