The grand 'goto' poll - Page 4
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com

View Poll Results: How often have you used 'goto' in the last 5 years?

Voters
111. You may not vote on this poll
  • I use goto regularly.

    3 2.70%
  • I use goto occasionally.

    8 7.21%
  • I've used goto VERY occasionally.

    34 30.63%
  • I've never used goto at all.

    66 59.46%
Page 4 of 9 FirstFirst 1234567 ... LastLast
Results 46 to 60 of 122

Thread: The grand 'goto' poll

  1. #46
    Join Date
    Nov 2003
    Location
    Vienna, Austria
    Posts
    212
    Excellent explanation Andreas.
    All the buzzt
    CornedBee

  2. #47
    Join Date
    May 1999
    Location
    Southern California
    Posts
    12,266
    Originally posted by j0nas
    Sam and others... Yes, maybe I did take many of the replies too seriously or didn't express myself well enough. I have problems with replies, in "open ended" questions, that sound like he or she is telling the pure truth. I'll try better next time.
    I know it can be difficult for others to know how serious I am or am not. Sometimes it is difficult for me to know. For what it is worth, I definitely know that it is unlikely that another person will change their mind if someone else insists that their way is the only way.

    I was trying to find a post somewhere in the first couple of pages to respond to on a couple of topics but I can't find what I was looking for. It is amazing that this has already grown to four pages.

    I agree that try/catch is not the ideal solution. I prefer to use return codes for determining an error condition. However one advantage of try/catch is that it is part of the standard, so the compiler and other programmers expect it to behave according to the standard.

    I can understand use of a goto for cleanup. Cleanup is a relatively inconvenient thing to deal with sometimes. Often we need to do something such as get an interface or open a file or allocate memory and we must do something else depending on what was done previously. If we get an error we must undo what has been done but only as much as has been done. There are many possible solutions and I am not describing all the details of using a goto for this but I do understand that a goto could be a convenient way to do the cleanup.
    "Signature":
    My web site is Simple Samples.
    C# Corner Editor

  3. #48
    Join Date
    Aug 2001
    Location
    Stockholm, Sweden
    Posts
    1,664
    Originally posted by Yves M
    Can you explain why you need goto in your case? It would be interesting to know.
    Sure.

    In C and the type of business I'm in, we often end up doing lots of sequential stuff: calling a function, if the function failed, goto cleanup. If you need to call, let's say, 8 other functions within a function, I rather use goto cleanup/fail than having 8 levels of indention. That's why I think goto:s make my C source code more readable, easier to maintain and therefore less buggy. If you also combine this with the good habit of always initializing local variables (at least pointers), you've created a very good foundation of a defensive programming style. My experience says that creating these simple "rules" of programming, helps less senior programmers to both maintain and add new functionality to existing code, without screwing up too much.

    And yes, you can do all this without using goto, but that will cost you with more code and/or less readable code.

    Occasionally, I've used another technique, the well-known do-while(0) method, instead of goto. That is fundamentally the same thing, but without using the goto keyword.

  4. #49
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,242
    Originally posted by Andreas Masur
    Well...this has become longer than expected...sorry for that...
    Not at all Andreas. It's now early morning (UK time) and you've certainly got my brain into gear - but it's much appreciated! I think the RAII technique you described is similar to the principle of smart pointers, which I use quite extensively - but I'd never heard the term RAII.
    Originally posted by Andreas Masur
    'catch' areas can be react on specific objects or all exceptions:
    Code:
    catch(...)                                     // Will react on every thrown exception object
    catch(const CError &refcException)             // Will only react on thrown 'CError' and derived objects
    For my money, this is the only weakness of try/catch logic. The option:-

    catch(const CError &refcException) // or whatever

    can only be relied upon in code that you wrote yourself. Too many times I've come across documentation stating that function X throws an 'int' - which it probably did at one time - except that the code got updated but the documentation didn't. In fact, I think there's at least one example of this in MFC although I can't remember what it is now.

    The upshot is that, when interfacing to someone else's code, it's usually better to play safe and stick with:-

    catch(...)

    because it catches any thrown exception.

    Thanks to everyone who pitched in on this. I can't speak for everyone else but I've found it enormously enlightening!

  5. #50
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,242
    Oh - one other question.....

    Where the thrown exception object is a pointer - e.g.
    Code:
    catch(some_exception_object * pException)
    is it always safe to assume that the object being pointed to will need to be deleted? - e.g.

    Code:
    catch(some_exception_object * pException)
    {
    . . .   // do whatever needs to be done
    delete (pException);   //  :confused:  - Would this always be the case?
    }

  6. #51
    Join Date
    May 2000
    Location
    KY, USA
    Posts
    18,652
    Originally posted by John E
    I think the RAII technique you described is similar to the principle of smart pointers, which I use quite extensively - but I'd never heard the term RAII.
    Yes, you are right...a smart pointer is following exactly this technique...

    Originally posted by John E
    For my money, this is the only weakness of try/catch logic. The option:-

    catch(const CError &refcException) // or whatever

    can only be relied upon in code that you wrote yourself. Too many times I've come across documentation stating that function X throws an 'int' - which it probably did at one time - except that the code got updated but the documentation didn't.
    That is of course one of the biggest problems. However, that is not only a problem while using exception handling. But that is exactly one of the drawbacks, however, usually you can enclose you entry routine with a general 'catch(...)' to prevent crashing and allow a successful closage of the application.

    The above description is even worse in regard to exception specifications. They are supposed to clearly indicate which type of exceptions will be thrown by a function. Nevertheless, this serves only documentary purposes since your above described problem counts here as well...
    Ciao, Andreas

    "Software is like sex, it's better when it's free." - Linus Torvalds


    Article(s): Allocators (STL) Function Objects (STL)

  7. #52
    Join Date
    May 2000
    Location
    KY, USA
    Posts
    18,652
    Originally posted by John E
    Oh - one other question.....

    Where the thrown exception object is a pointer - e.g.
    Code:
    catch(some_exception_object * pException)
    is it always safe to assume that the object being pointed to will need to be deleted? - e.g.

    Code:
    catch(some_exception_object * pException)
    {
    . . .   // do whatever needs to be done
    delete (pException);   //  :confused:  - Would this always be the case?
    }
    Yes...while throwing pointers around you usually have to delete them, nevertheless this kind of depends what the type of exception handling is supporting...
    Ciao, Andreas

    "Software is like sex, it's better when it's free." - Linus Torvalds


    Article(s): Allocators (STL) Function Objects (STL)

  8. #53
    Join Date
    Nov 2003
    Location
    Vienna, Austria
    Posts
    212
    Actually it depends on how you throw the exception. If you throw it with
    throw new CException("Error occurred!");
    then you need to delete it.

    If you throw it with
    // global
    CException globalException;

    throw &globalException;
    then you cannot and must not delete it.

    In general, it is not a good idea to throw pointers. Stick with throwing temp objects and catching references, exception classes should be small anyway.


    Oh, and in the MFC it's safe to assume you gotta delete the exception pointer.
    All the buzzt
    CornedBee

  9. #54
    Join Date
    May 2000
    Location
    KY, USA
    Posts
    18,652
    Originally posted by CornedBee
    Oh, and in the MFC it's safe to assume you gotta delete the exception pointer.
    Well...and failing in doing so in many examples...
    Ciao, Andreas

    "Software is like sex, it's better when it's free." - Linus Torvalds


    Article(s): Allocators (STL) Function Objects (STL)

  10. #55
    Join Date
    Nov 2001
    Location
    Beyond Juslibol
    Posts
    1,688
    I don't use a goto since the old times of BASIC.

    Haven't you ever read the famous article "GOTO statement considered harmful" by W. Dijkstra? (may 1968)

  11. #56
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,242
    I think Yves posted a link to it in another thread but although I followed the link, I couldn't find the goto comments !

    What did he say (in a nutshell!) ?

  12. #57
    Join Date
    May 1999
    Location
    Southern California
    Posts
    12,266
    Originally posted by Doctor Luz
    Haven't you ever read the famous article "GOTO statement considered harmful" by W. Dijkstra? (may 1968)
    Oh that sounds so familiar! I don't know if I read it but I know I have heard of that article. It was a part of the beginning of Structured Programming.

    Go To Statement Considered Harmful

    GoTo considered Harmfull

    considered harmful

    Perhaps someone can find the "‘Goto considered harmful’ considered harmful" article.
    "Signature":
    My web site is Simple Samples.
    C# Corner Editor

  13. #58
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,242
    I like the conclusion in that last link - that it took several decades before everybody realsed that in fact, both sides were wrong...!


  14. #59
    Join Date
    May 2000
    Location
    KY, USA
    Posts
    18,652
    Originally posted by John E
    I like the conclusion in that last link - that it took several decades before everybody realsed that in fact, both sides were wrong...!
    Well..sometimes it takes some time...
    Ciao, Andreas

    "Software is like sex, it's better when it's free." - Linus Torvalds


    Article(s): Allocators (STL) Function Objects (STL)

  15. #60
    Join Date
    Aug 2002
    Location
    Madrid
    Posts
    4,588
    Dijkstra's article
    In [2] Guiseppe Jacopini seems to have proved the (logical) superfluousness of the go to statement. The exercise to translate an arbitrary flow diagram more or less mechanically into a jumpless one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one. [1]
    This is good argument for the pro-goto people
    Get this small utility to do basic syntax highlighting in vBulletin forums (like Codeguru) easily.
    Supports C++ and VB out of the box, but can be configured for other languages.

Page 4 of 9 FirstFirst 1234567 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center