12 Apr
2005
12 Apr
'05
11:31 p.m.
Nate DeSimone wrote:
In general gotos are *REALLY* bad, there must be some
better way than
gotos to get this working, maybe it would be a good idea to put some
work into PSEH so that it is suitable for this purpose and save
yourself the trouble of doing it later.
There is nothing inherently wrong with goto, it's only bad when it makes
the code less readable. When used carefully, like in this case, it
creates code that is _more_ readable, not less, and that's clearly a
good thing. Also as I said before, the problem is not a lack of SEH, as
I believe that is now supported by gcc so we could use it, but rather
the problem is that virtually none of the NTAPI uses SEH. In order for
SEH to be beneficial, it's use has to be widespread.
Robert Köpferl wrote:
I can just ACK your post.
Not using goto is like a no-no. It was for the last 15y and will be
another. (?) The schools teach it. But one should allways think about
the "Trueth" wether it is ture or just "dontcare".
Using Exceptions and the resulting stack unwind etc. is not nice
concerning performance. However it leads to more secure and elegant
code. I for my part would rather insert some spare gotos. AND use auto
variables.
_______________________________________________
Just because schools teach it does not make it true. Half of what they
teach in school is wrong. As I said above, there is nothing inherently
bad about goto, it's just that it can easily be abused to create
spaghetti code, and new programmers often do just that. When used
carefully goto can be the lesser of two evils, as in this case. I think
it is clear that the code using goto is much cleaner and more
maintainable than the original code. If using goto improved the code,
then it has got to be a good thing.
C++ exception handling is the ideal way to handle this kind of thing,
but we're mostly using C and all the APIs are in C, so it is with C that
we must make our peace. Also blanket statements like C++ exception
handling adds too much overhead are very often quite wrong. Often C++
exceptions actually IMPROVE performance because they eliminate multiple
return value checks, duplicate code, and so on in favor of paying a very
small fee when entering and exiting non trivial functions. In the case
where an exception is not thrown, which is to say, the vast majority of
the time, the small overhead for pushing the exception handler onto the
exception stack is more than made up for by the overhead saved from not
having to constantly check a dozen different return parameters. In fact
if you have say, a loop, which calls 3 functions each iteration and
iterates 100 times, you are saving a ton of overhead by trading 300
return value checks for one exception handler push/pop.