for those of you purists that don't like break, continue and goto
-
i mean yeah. That's a little less clear to me though. I avoid do loops usually because the conditional can get confusing if you're used to regular for loops. It takes me a second to work out what's going on, like when exactly the condition exits. It's not big deal, it's just my preference. I think my code is clearer.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
It is simpler and I actually use pretty much exactly the same code when it is that simple. When you have more than a page of lines within that loop a sudden exit is not what I would do. And a sudden conditional exit with break or return might be even ok. Putting the i to the max and then exit in that manner is something I would never do.
-
It is simpler and I actually use pretty much exactly the same code when it is that simple. When you have more than a page of lines within that loop a sudden exit is not what I would do. And a sudden conditional exit with break or return might be even ok. Putting the i to the max and then exit in that manner is something I would never do.
well to each their own. probably it also has to do with my C++ background which influences a lot of my code. Not that C++ has different flow constructs, it's just that a) i learned these habits a long time ago and the industry changes b) C++ development is a different animal, and control flow is all over the place generally and for loops are used for almost everything except while(true) although some people go for(;;). It's not uncommon even to do stuff like
for(current=firstNode;null!=current;current=current.nextNode) if(current->key==key) break;to traverse a linked list for example.When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
yep. although there are cases where I'll modify i inside the loop for other reasons. Like if I have to add or remove items while enumerating (it happens with complicated algos)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
That makes sense, especially given the type of algorithms you deal with in parsers and data structures. In the course of developing several large, complex applications, I've learned that having pieces of code that must stay in sync logically or follow the same algorithm is a failure point. Refactoring can help if i makes sense to move things into a method, and then have each location invoke the method. The hard part there can be figuring out a name for the thing: "
CheckToSeeIfMessageNeededAtThreadExit" is ugly :-D.Software Zen:
delete this; -
That makes sense, especially given the type of algorithms you deal with in parsers and data structures. In the course of developing several large, complex applications, I've learned that having pieces of code that must stay in sync logically or follow the same algorithm is a failure point. Refactoring can help if i makes sense to move things into a method, and then have each location invoke the method. The hard part there can be figuring out a name for the thing: "
CheckToSeeIfMessageNeededAtThreadExit" is ugly :-D.Software Zen:
delete this;right. Extract Method is one of my favorite refactoring tools I don't use incredibly long names for private methods. I'll abbreviate something like the above to
_CheckMessageThread()Public members i usually go all out, and give it a really long name if it needs one.When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
why do this?
for(int i = 0;i
instead offor(int i = 0;i
hengh?? why you still use break?
:laugh:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
A purist should be worried about touching control variables. Hmmm.
Jordan
-
ugh, VB. I use goto in some of my code. Perfectly acceptable place to use GOTO - generated state machine code:
public static bool AcceptsByte(Grimoire.ParseContext pc)
{
pc.EnsureStarted();
if (-1 == pc.Current) return false;
if ((48 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
if ((49 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s2;
}
if ((50 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s4;
}
if ((51 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s3;
}
return false;
AcceptsByte_s1:
if (-1 == pc.Current) return true;
return -1 == pc.Advance();
AcceptsByte_s2:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s3;
}
return -1 == pc.Advance();
AcceptsByte_s3:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
return -1 == pc.Advance();
AcceptsByte_s4:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 52 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s3;
}
if ((53 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s5;
}
if ((54 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
return -1 == pc.Advance();
AcceptsByte_s5:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 52 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
return -1 == pc.Advance();
}but then I wouldn't write that code by hand. Too error prone.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Quote:
but then I wouldn't write that code by hand. Too error prone.
Isn't this exactly the point? All code gets compiled/interpreted/translated to jmps eventually. The goals of the written code should be correctness, understandability and simplicity. Leave the gotos and the clever techniques to the compiler.
-
throwwould be even more clear, definite and failure proof. (well I do see many kids using exactly that to 'not usegoto endlabel')Message Signature (Click to edit ->)
If finding the desired value is exceptional and unexpected and requiring special handling, then throwing an exception is appropriate. If it is the normal and desired case, exeactly what you expected: "Yeah, there it is!", then an exception is not the right mechanism.
-
why do this?
for(int i = 0;i
instead offor(int i = 0;i
hengh?? why you still use break?
:laugh:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Quote:
but then I wouldn't write that code by hand. Too error prone.
Isn't this exactly the point? All code gets compiled/interpreted/translated to jmps eventually. The goals of the written code should be correctness, understandability and simplicity. Leave the gotos and the clever techniques to the compiler.
You trust your compiler?? Wow!
-
Quote:
but then I wouldn't write that code by hand. Too error prone.
Isn't this exactly the point? All code gets compiled/interpreted/translated to jmps eventually. The goals of the written code should be correctness, understandability and simplicity. Leave the gotos and the clever techniques to the compiler.
I'll optimize when i need to. that doesn't always make the code readable.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I'll optimize when i need to. that doesn't always make the code readable.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
The reality is that with modern code, it's so far removed from the underlying machine language that gets executed that there's no point trying optimisations at the level of a break vs setting the iterator. Optimisations nowadays are at architectural levels - managing tight loops, using appropriate data structures, parallelisation, resource access.
-
The reality is that with modern code, it's so far removed from the underlying machine language that gets executed that there's no point trying optimisations at the level of a break vs setting the iterator. Optimisations nowadays are at architectural levels - managing tight loops, using appropriate data structures, parallelisation, resource access.
yes and no. it depends on whether you consider algorithmic optimizations to be architecture. For example, my first crack at LALR(1) table generation was taking 5 minutes to generate the tables for javascript. My second one cut that to a 5th of the time. The cost was code that was no longer "pure" and readable. It wasn't an architecture change. Unless you think it was. But I wouldn't agree, and I wrote it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
why do this?
for(int i = 0;i
instead offor(int i = 0;i
hengh?? why you still use break?
:laugh:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
why do this?
for(int i = 0;i
instead offor(int i = 0;i
hengh?? why you still use break?
:laugh:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Why not? What is the net value gain by the alternative you show?
-
Why not? What is the net value gain by the alternative you show?
there is none
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
why do this?
for(int i = 0;i
instead offor(int i = 0;i
hengh?? why you still use break?
:laugh:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
why do this?
for(int i = 0;i
instead offor(int i = 0;i
hengh?? why you still use break?
:laugh:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Purist? Baaah! Think of this in terms of far-Eastern philosophy, to wit, Yin/Yang[^]. Always the spot of yin in the yang portion, the spot of yang in the yin portion. Neither can exist without the other. So, continue to use break as they help you goto a better place.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
Those two code snippets don't do the same thing. The first doesn't change arr, the second does.
How does it do that? If it does, it is a bug
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
why do this?
for(int i = 0;i
instead offor(int i = 0;i
hengh?? why you still use break?
:laugh:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Because neither one of these loops does anything except waste time. Was there perhaps a reason you wanted to find out if
valueToFindwas inarr? If there was, the first loop is almost right,ipoints to the matching entry on loop exit. Only problem is,igoes out of scope on loop exit. Sigh. The second loop always hasi== arr.Lengthon loop exit, andistill goes out of scope -
Because neither one of these loops does anything except waste time. Was there perhaps a reason you wanted to find out if
valueToFindwas inarr? If there was, the first loop is almost right,ipoints to the matching entry on loop exit. Only problem is,igoes out of scope on loop exit. Sigh. The second loop always hasi== arr.Lengthon loop exit, andistill goes out of scopethe code to do something is supposed to go in the loop body. i omitted it for the example. sorry i wasn't more clear.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
