Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


aregee

Member Since 06 Oct 2009
Offline Last Active Nov 03 2014 04:10 AM

Posts I've Made

In Topic: GOTO, why are you adverse to using it

06 September 2014 - 06:17 PM

 

I will post a snippet from my parser which is one of the routines I needed goto the most...

 

[...]

 

I won't repeat what Álvaro said, but please...

 

Write sensible names.

 

Name 'dyn' and the likes more like 'isDynamic' (If that is even what you mean).  Then you can test like this, assuming it is actually a boolean:

if (isDynamic) { ... }

Instead of:

if (isDynamic == true) { ... }

Try to make your code as readable like a book that you can.

 

Always use brackets, even if your if, for, while, do..while, etc is having only one line.

 

'currentLineCount', or 'CurrentLineCount' is MUCH easier to read than 'CurLnCnt'.

 

What is 'IsPastEOS'?  'EOF' is so common, I guess most people would understand, but 'EOS'?  End of stream?  I would spell it out in either case.

 

I know that you have an assembler background, and labels like this were common back then.  I also think you actually was limited to 8 chars on certain assemblers too, and that didn't help.  It really feels like reading assembler code written in C.

 

And I will also point back to Álvaros comments again.


In Topic: GOTO, why are you adverse to using it

06 September 2014 - 03:43 PM

I think exceptions have no place other than in the case of a fatal, unrecoverable failure in a program.  When I was learning Java way back, I was encouraged to use exceptions as the default way of reporting and handling errors.  I always felt that was a bit clunky, and it made for code that was filled with blocks that I felt never belonged in the code at all.  I always favoured explicit error checking over exceptions.  Who thought it was a great idea to throw a NumberFormatException when you feed bogus data to convert a string to an integer in Java??  That pretty much sums it up...


In Topic: GOTO, why are you adverse to using it

06 September 2014 - 09:52 AM

[...]

 

The "cascade deallocation" model:

 

[...]

 

Or the honest-to-god goto model:

 

[...]

 

And if you are thinking why I didn't just move the cleanup bit into its own function, let me ask you this: why would I create an off-screen helper function with critical cleanup code that intrinsically needs to be kept in sync with the do_work() function, when I can just have it naturally at the bottom of the function all by replacing "cleanup(); return 0;" with "goto cleanup;". What concrete, practical advantage is there? None. It's a waste of space and programmer energy, and a prime example of cargo cult programming.

 

 

If you want to think about this in a real technical way, you should be able to draw a flow chart of your function. This should be done in advance, but who does that? The rules of a flow chart is: that you are having only one entry point, and only one exit point, and that absolutely no lines are crossing each other. No, you can't cheat and draw a flow chart that branches to the right side, and then to the left side to avoid a crossing on the right side. If you are ever using any of goto, break, continue or early returns, then you are breaking this flow.

 

 

That's an arbitrary blanket rule. Early returns are a good thing. Breaks and continues have their places. Goto has its place too when you need some kind of control flow that improves readability (like the error handling example) and no other language construct naturally lends itself to that (admittedly, that is rare even in languages like C, and basically nonexistent for higher level languages). And when I see this kind of rule being repeated blindly all I can think of is the programmer who, told not to use goto, wrapped up his error handling code in a dreadful do{}while(0); loop to obtain the same control flow without writing 'goto' and obfuscating his code in the process. And that is far worse than any amount of gotos (well, almost any amount).

 

I'm not saying goto is good. Here the use of goto for error handling is justifiable because goto naturally lends itself to a rather elegant, very low boilerplate resource cleanup implementation in C. Clearly jumping all over your code, to labels hundreds of lines away, is nothing short of insane. But simply outright banning goto because there is a paper called 'goto considered harmful' without even considering the possibility that maybe, just maybe, goto could be used in a controlled manner (it is a tool, and just like any other tool it can be abused; break and continue are also tools which can be abused) simply shows a lack of intellectual depth in my opinion.

 

 

The cascade model is just plain ugly.  The goto way is actually really elegant.  In those cases I would probably go for a function in the past to avoid goto, but your arguments have convinced me.  There are definitively reasons for goto in certain cases, and the function way is not good either.

 

Regarding the blanket rule, I am not at all preaching the "flow chart" model, since I am obviously not following those rules myself, just wanted to hear some arguments, and I got a lot of good ones.  I am a follower of clean and elegant code, and that is for me more important than any other strictly (and blindly) enforced idioms.  Hearing comments like this also eases my insecurities/discomforts when I am breaking out of learned/taught conventions to make things more readable/elegant too, but the goto one has really got stuck in me for some reason. 


In Topic: GOTO, why are you adverse to using it

06 September 2014 - 09:32 AM

 

Something as simple as moving member variables to a local variables before going into a loop that calls a function can greatly improve performance because the compiler may not know if the member variables are going to be modified by the function being called; thus the compiler has to reload them on every iteration. With local variables, the compiler can assume that (*).

 

(*) Massively copying everything to local variables won't help either; because this data won't fit into registers and will end up in the stack every time we enter that troublesome function and reload when we leave it; which is basically what the compiler would do with member variables, but worse.

In such cases one has to sit down and analyze the sources of aliasing and rewrite the routine in a way that they get minimized or contained to a particular place where it won't matter. Also one has to analyze the possibility of enabling the visibility of the routine to the compiler so the compiler can know what it is doing and what gets modified (but if it's a virtual function, the compiler can't do it even if it sees the function's body). LCGT can help too in this cases; but remember that even then, there are some assumptions the compiler still can't make.

 

 

Oh dear!  I happen to do the opposite on occasion, moving local variables to member variable in cases where I have tight loops and want to optimise a bit, and now you are telling me that?  Seems I have a lot of work learning my own compilers behaviours...


In Topic: GOTO, why are you adverse to using it

06 September 2014 - 07:35 AM

My typical use is goto ex; which is jump to the exit routine, everything is done, clean up and get out.

 

I just noticed this... If your use of goto is to return, why don't you just put an return in place of the goto?  Then the intention will be much clearer.  With goto to exit, you are just camouflaging the real intent.  You are adding one more level of "complexity" that is unnecessary.  You are still breaking the flow with return, but it is still cleaner than a goto in this case.  Besides, I am not so sure it is all that bad to break the flow in this manner.  The intent with a return statement is clear: I am done with this function.

 

If you want to think about this in a real technical way, you should be able to draw a flow chart of your function.  This should be done in advance, but who does that?  The rules of a flow chart is: that you are having only one entry point, and only one exit point, and that absolutely no lines are crossing each other.  No, you can't cheat and draw a flow chart that branches to the right side, and then to the left side to avoid a crossing on the right side.  If you are ever using any of goto, break, continue or early returns, then you are breaking this flow.

 

According to these rules, I can't claim that I am being correct myself, since I am using all but the goto one.  However, there really aren't many cases where goto will be needed.  I am repeating myself a little bit now, because I am curious what view other people have about break, continue and early returns, if they see goto as evil.  I sure do see goto as evil, but realise that break, continue, and early returns kind of falls in the same drawer, so that would theoretically make those too evil, even though they seem to be seen as more acceptable.

 

Edit:

 

 

 

If the alternative to the goto is using boolean variables to control flow, I'd rather take the goto. The enemy is unreadable code. Injudicious use of goto leads to unreadable code, but if you have a situation where goto is more readable than the alternatives, go for it.

On the other hand, I am feeling a bit guilty, because I write code like this all the time: 

    for (uint8_t channel = 0; channel < module->ChannelCount; channel++) {
        
  [...] //Edited out to reduce amount of "spam"

 


Why would you feel guilty about using language constructs in a completely idiomatic way, making the code more readable?

 

 

Álvaro snuck in and answered my question.  Regarding "If the alternative to the goto is using boolean variables to control flow, I'd rather take the goto." It is sure the dilemma I have when I am breaking out of multi level loops.  I think I actually used boolean values in the case I had to solve this, and I considered goto for the first time in my life.  I somehow felt dirty either way.  None of the solutions felt really clean.  I think I need to be cured of goto-phobia then.

 

And regarding the other case, I don't feel guilty over those language constructs, that is why I am using them. It is just that they are technically gotos too, just a bit cleaner since the intention is clearer.  I always want to get better at what I am doing, that is why other people's opinions matters, and for me discussions like this is brilliant.


PARTNERS