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

List:       kde-devel
Subject:    Re: The no goto religion
From:       Harry Bock <hbock () providence ! edu>
Date:       2007-08-03 11:56:52
Message-ID: 46B31804.3090507 () providence ! edu
[Download RAW message or body]

James Richard Tyrer wrote:
> 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.
>
>   
I do have to respectfully disagree;  I do believe that core KDE 
developers try their best to make their code as efficient as possible 
while still being well-structured. I honestly do not believe that your 
code, as well-intentioned as it is, will make a significant improvement 
in overall application performance.  You really need hard data to back 
up your point.  If you want, I'd be more than happy to benchmark and 
profile applications that frequently use findMatchingIcon with both 
versions.

Shall we make it a bet? :)
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]