[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: The no goto religion
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2007-08-03 5:01:11
Message-ID: 46B2B697.7050702 () acm ! org
[Download RAW message or body]

Harry Bock wrote:
> James Richard Tyrer wrote:
>> Richard Moore wrote:
>>   
>>> On 7/29/07, Kevin Krammer <kevin.krammer@gmx.at> wrote:
>>>     
>>>> You could also just return the moment you found a match.
>>>>       
>>> Yes, I've never in 10 years found a case where I'd want goto in C++.
>>>     
>> The question here is not if it is possible to avoid a "goto" but rather 
>> how much extra code is used to avoid using one -- meaning that using the 
>> "goto" is sometimes the most efficient solution.
>>   
> He never said he was explicitly avoiding them.  He said he has never 
> really found the need to use one.
>> Read Frank Rubin's letter to Communications (of the ACM) for examples 
>> and Donald Knuth's paper: "Structured Programing with _goto_ 
>> Statements". -- don't just take my word for it.
>>
>>   
> Trust us, we understand your stance on goto.  We know what it can save, 
> when it is helpful, when it isn't necessary, when it is too much, etc.  
> (even if some didn't, you've certainly made it clear) What you don't 
> understand is that we all have varying coding styles and preferences, 
> and most could really care less.  Just because you insist that goto is 
> the most efficient solution doesn't mean that everyone must follow your 
> advice and use it whenever you see fit, even though they understand it 
> very well (as this rather lengthy and fruitless thread has shown) and 
> even if their way is (very slightly) less efficient.
> 
> If a programmer prefers multiple function exit points or repetitive 
> code, I wouldn't worry about it too much.  If you think it's evil to do 
> so, great, don't write it that way.  Use goto, use inline assembler 
> directives to insert whatever variation of the jump instruction is most 
> efficient, whatever.  But you can't convince everyone here that _they_ 
> should do it whenever that situation arises, regardless of how many 
> cycles you gain or Donald Knuth articles you reference.

It is nice to know that you understand what I am saying.  But, then you 
say things that indicate that you don't. Kunth's paper suggests, and he 
has hard numbers that using overly structured code can result in a 
serious performance hit.  Like my bicycle, not AJS's.

This performance hit isn't that important in code that is only executed 
once in a while because although it slows that code down significantly, 
it doesn't make much difference in total performance.  However, with 
code, not what I used as an example but rather the similar code: 
"findMatchingIcon" which is the inner structure of the icon lookup code 
and it is executed a lot.  If this takes a 25% performance hit, that 
makes a large difference in the icon lookup performance.

But, if you are saying that KDE coders don't care about efficient coding 
and the performance of the software, then I will simply have to accept 
what you say.

-- 
JRT
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]