Jason Lenthe on Sat, 29 Jul 2000 13:43:06 -0400 (EDT) |
I once had the misfortune of having to customize a program with more than 200 gotos in. I discovered that it is really easy to break code that is not your own and has a lot of gotos in it. Some people have pointed out that gotos can make code more efficient. While this may be true in some cases, in other cases gotos could also inhibit the optimizing complier from doing things like unrolling loops and such, thereby making the code less efficient than it might be. One other interesting thing is that break and continue are really just specific kinds of gotos, and so anything that applies to goto should probably apply to break and continue as well. My philosophy is that you should focus on making your algorithm as efficient as possible, then write smart code that is easy to maintain, and let the optimizer worry about reducing the number of machine intructions executed. Jason --- "Daniel K. Spicer" <spicer@linuxmania.com> wrote: > Does anyone have a reason why goto should not be > used in C code ?? > > I like to use it for error handling, but a couple > managers where I work > have this idea that the goto keyword should never be > used, although they > can't offer any reason why. I have heard before that > it's not good > practice, but I've never heard a valid reason why. > Can anyone shed some > light ? > > ______________________________________________________________________ > Philadelphia Linux Users Group - > http://www.phillylinux.org > Announcements - > http://lists.phillylinux.org/mail/listinfo/plug-announce > General Discussion - > http://lists.phillylinux.org/mail/listinfo/plug > __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ ______________________________________________________________________ Philadelphia Linux Users Group - http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mail/listinfo/plug-announce General Discussion - http://lists.phillylinux.org/mail/listinfo/plug
|
|