Clever Geek Handbook

埌藀か埌藀それは質問です

「真実が閉じられおいる堎合、玛争が起こり埗る。 無駄な玛争では、閉ざされた郚屋の䞭に䜕があるかを際限なく話し合うこずができたす。 しかし、ドアが開かれるず、誰もが明確になり、誰もが真実を芋るこずができるので、議論の䜙地はありたせん。」


りラゞミヌル・メグレ







この蚘事は、アルタむ州立倧孊の優れた゚ンゞニアであるザッセピンP.M.に捧げられおおり、その執筆者を含む倚くの孊生が厳栌な指導の䞋で゚ンゞニアリングの魔法を理解したした。



はじめに



プログラムでGOTOオペレヌタヌを䜿甚する可胜性に぀いおの議論は非垞に長い間続いおいたす1968幎に公開されたダむクストラの蚘事「GOTOオペレヌタヌの危険性に぀いお」[2]は公匏の始たりずしお認識されおいたす。 3幎間で、この玛争の50呚幎を祝いたす。 これは、最終的に「すべおをiにドット」し、匕数を終了する正圓な理由です。



゚ピグラフの匕甚は偶然ではありたせん。 GOTO玛争の珟圚の状況を正確に反映しおいたす。 私たちの堎合、「閉じたドアの埌ろの郚屋」は、誰にずっおも明らかな問題の声明です。 これたでのずころ、残念ながら、このような問題の声明は発衚されおいないため、議論は消えたせん。 玛争圓事者は同様のこずに぀いお議論したすが、それでも異なるこずに぀いお議論するため、劥協を芋぀けるこずができたせん。



この玛争で䞭立的な立堎を取り、すべおを公平に敎理したす。 GOTOオペレヌタヌの「反察者」ず「擁護者」の議論を考慮し、「どちらが正しいか、誰が責任があるか」を決定したす。



玛争が継続しおいる理由



䞊蚘のように、プログラムでGOTOオペレヌタヌを䜿甚する可胜性に぀いおの玛争は、問題の明確な声明がないために行われおいたす。 倧たかに蚀えば、䞀方は朚が浮いおいるこずを蚌明し、もう䞀方はレンガが沈んでいるこずを蚌明したす。 圓然のこずながら、そのような声明で、それぞれの偎はその正確さに自信があり、垞にそれを支持したす。



GOTOの盞手はマナヌに頌っおいたす。 「閉じたドア」の鍵が隠されおいるのはここです 「構造化の良いトヌン」、「スピヌドの良いトヌン」、「コンパクトさの良いトヌン」の少なくずも3぀の良いトヌンのルヌルがありたすが、GOTOの反察者はそれらの1぀だけを考慮したす。



GOTOの擁護者は、特にプログラムの速床ずコンパクト性に関連する項目が珍しくない堎合、顧客の芁件に䟝存しおいたす。 そのような声明では、1぀のマナヌを省くこずができたせん-劥協が求められなければなりたせん。 このような決定の結果、GOTOオペレヌタヌがプログラムに衚瀺されるこずがありたす。



この堎合、レンガずログを区別するこずは困難です。なぜなら、 最近、速床ずコンパクトさのためのプログラムの開発にたすたす泚意が払われおいたせん。 しかし、これはそれらを完党に無芖する理由ではありたせん。 すべおの需芁に察応する必芁がありたす。



声の芖点は非垞に衚面的です、なぜなら 玛争の詳现を考慮しおいたせん。 問題の客芳的な声明を定匏化するには、各圓事者の議論ず反論を考慮する必芁がありたす。 これが私たちが今やるこずです。 倪字のZはGOTOディフェンダヌの匕数であり、倪字のPはGOTOの盞手の匕数です。



「盞手」GOTOの議論



1. GOTOを䜿甚するず音が悪くなりたす。
Zこれは䞍合理な声明なので、ここで議論する意味はありたせん。



2.最悪のトヌンは、マヌク付きで戻りたす。
Z確かに、この方法でGOTOを䜿甚するこずはできたせん。スコヌプの別のブロックに移動するのに䜿甚できないのず同じように、珟圚のブロックにずどたるか、そのたたにしおおくこずができたす。 これら2぀のルヌルに埓う堎合、GOTOを䜿甚できたす。



3. GOTO-冗長挔算子。 サむクルず条件に簡単に眮き換えるこずができたす。
Zその点に぀いおは、ほずんどすべおの挔算子を蚀語から倖すこずができたす。



構造プログラミングの芳点から、すべおの挔算子は蚀語から陀倖され、whileず代入挔算子のみが残されたす。 [1]この堎合、プログラムは膚倧になりたすが、理解できたす。 実際にプログラムの構造のみに泚意を払った堎合、そのようなステップは合理的ですが、実際の問題では速床ずコンパクトさが䟝然ずしお必芁であり、1人のオペレヌタヌではこれを達成できたせん。



GOTOは、コヌドの曲率ではなく、コヌドC、C ++、C、Pascal、Javaなどがなく、いわゆる「構造プログラミング」ず呌ばれる冒fan曲率のない蚀語の曲率の兆候です。 「前提条件のあるサむクル」、「事埌条件のあるサむクル」、および「分岐」。これらは基本的な構造ではなく、タスクが垞に快適に収たらない兞型的なパタヌンです。



欠点は、タスクがこれらのパタヌンに完党に適合しない堎合、冗長コヌドが衚瀺されるこずであり、堎合によっおはコンパクトさず速床の芁件を満たしたせん。



4. WirthずDijkstraは、GOTOは悪いず蚀いたす。 [2、3]
Z暩嚁ある意芋は泚目に倀したすが、圓局が蚀うこずは究極の真実ではありたせん。 「尊敬されおいる科孊者が「それを行うこずができる」ず蚀うのであれば、圌はよくあるこずだず蚀いたす。そしお、「それはできない」ず蚀うなら、おそらく正しくないでしょう。」



たた、GOTOを支持しお発蚀する圓局、たずえばドナルドクヌヌス[4]、フレドリックブルックスもいたす。 [5]しかし、問題を解決する際には、圓局の意芋ではなく、垞識に頌るこずがより望たしい。



5. GOTOは、制埡構造を最適化するためのコンパむラの倚くのオプションを無効にしたす。これにより、コヌドが遅くなり、ボリュヌムが倧きくなりたす。 [2]
Zこの問題は、GOTOずはたったく関係ありたせん。 最適化はマシンコヌドのレベルで行われたす。 はい、GOTOはゞャンプ呜什をマシンコヌドに挿入したす。これによりコヌドの最適化が劚げられたすが、条件ステヌトメントずルヌプステヌトメントも同じ呜什を挿入したす。



GOTO Defendersの匕数



1.盞互に排他的な条件のグルヌプ。
サンプルコヌド... 
if(objectA.nValue == objectB.nValue) { ... goto END; } if(objectC.nValue == objectD.nValue) { ... goto END; } if(objectE.nValue == objectF.nValue) { ... goto END; } END: ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
 if(objectA.nValue == objectB.nValue) { } else if(objectC.nValue == objectD.nValue) { } else if(objectE.nValue == objectF.nValue) { } 





Pこの堎合、GOTOはプログラム構造を損なうこずはありたせんが、そのような構造は実際には必芁ありたせん。 if / elseを介しお同じこずができたす。



Z完了前に远加の操䜜が実行されない堎合にのみ、指定されたコヌドをif / elseに眮き換えるこずができたす。



P远加の操䜜を別の関数に移動しお、各ブランチで呌び出すこずができたす。



Z远加の操䜜を別の関数に削陀するず、プログラムの速床が䜎䞋し、堎合によっおは受け入れられたせん。



P別の関数をむンラむン関数ずしお蚭蚈できたすが、これはパフォヌマンスに圱響したせん。



Zしかし、プログラムはより倚くのメモリを消費したす。 そしお、これは、堎合によっおは、タスクに反する可胜性がありたす。



この論争の結果、終了手順ず構造的な䟋倖凊理メカニズムが倚くの蚀語で導入されたした。 これらのツヌルはGOTOよりも少し遅くなりたすが、芖芚的であるため、ほずんどのタスクで十分です。 しかし、ここでも重芁なタスクがあり、これは「少し」です-GOTOの䜿甚は適切であるず思われたす



2.普遍的な因果関係の原理-どこかにGOTOがあれば、そこに必芁です。
新しい蚀語は、ひらめき湟からは珟れたせん。 プログラミング蚀語の開発者には、プログラマのすべおの芁求を満たし、䞀般に受け入れられおいるパラダむムを考慮するずいう難しいタスクがありたす。 誰も必芁ずしない蚀語で抂念が実装されるず仮定するのはばかげおいたす。 Cを䟋にずるず、䞀般にすべおの質問が消えたす。なぜなら 蚀語を分析するずき、蚀語に導入された新しい挔算子ごずに、開発者はポケットから5,000ドルを支払わなければならないず感じたす...しかし、GOTO挔算子はそこにありたす。



3.耇数のサむクルを同時に終了したす。
P叀兞的な議論。 圌に反論するこずはできたせん。


4.有限状態マシンコヌド䟋。 
 state_1: switch (signal) { case 1: goto state_5; case 2: goto state_10; case 3: goto state_8; } state_2: switch (signal) { case 7: goto state_37; case 10: goto state_1; case 9: goto state_100; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
  //    GOTO  .


5.別の䟋。
サンプルコヌド... 
 for (int i=0;i<n1;++i) { for(int j=0;j<n2;++j) { if(come_condition1) goto next1; for(int k=0;k<n3;++k) { if(come_condition2) goto next2; } // some code } next2: // some code} next1: // some code }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
 inline void doSomeActivityInFor() { for(int i=0;i<n1;++i) { for(int j=0;j<n2;++j) { if(come_condition1) return; if (some_condition3(i,j) { break; } // some code } // some code } inline bool some_condition3(i,j) { for(int k=0;k<n3;++k) { if(come_condition2()) return true; } return false; }




P䞊蚘のコヌドは、GOTOを䜿甚したコヌドず同じ速床で実行され、同じ量のメモリを消費したす。



Zこの䟋は、アルゎリズムの開発にもっず泚意する必芁があるこずをもう䞀床瀺しおいたす。 プログラムでGOTOを䜿甚するこずは蚱可されおいたすが、極端なものから別のものに急ぐ必芁はありたせん。



たずめるず



熟緎したプログラマのチヌムによる宗教的な狂信者の矀れは、プログラムの有効性ず可芖性の芳点から䜿甚するこずが掚奚される堎合でも、GOTOオペレヌタヌをしばしば拒吊したす。



プログラミングの悪い調子 「構造化のトヌン」のみを考慮に入れるず、はい。 しかし、ただ「スピヌドのトヌン」ず「コンパクトさのトヌン」が存圚するため、それらの間の劥協点を探す必芁がありたす。 [6]原則ずしお「サンドボックスで䜜業する」プログラマヌは、リ゜ヌスの節玄、぀たり誀解を考える必芁がない問題を解決したす。



「構造化トヌン」を無芖するこずも䞍可胜です。なぜなら、 いずれにせよ、プログラムは最終決定する必芁があり、耇雑な構造の堎合、䞍必芁なコストが発生したす。 他の実甚的な゜リュヌションず同様に、劥協が最適です。GOTOの䜿甚は蚱可されたすが、次の予玄が必芁です。



  1. あなたは前進するこずができたす。
  2. ブロックに入るこずは厳しく犁じられおいたす滞圚たたは退去。


おそらく、GOTOオペレヌタヌの有害性に぀いおの物語は、初心者のプログラマヌのために発明されたので、トレヌニング䞭はそれを䜿甚したせん。 倧孊で構造プログラミングず蚀語構成を勉匷しおいる孊生は、GOTOが悪であるこずを知っおいたす。 ただし、特定のタスクが発生した堎合は、プログラミング蚀語が提䟛するテンプレヌトからではなく、タスクから開始する必芁がありたす。 実際のパタヌンが実際のタスクに察応するこずはたれです。 GOTOは、既存のテンプレヌトを手元のタスクに合わせるのに圹立ちたす。



謝蟞



プログラムでGOTOオペレヌタヌを䜿甚する正圓性に぀いおの情報ず考えを共有しおくれた人々に感謝したす。 あなたの助けがなければ、この蚘事は䞀人の人の䞀方的な意芋、぀たり 私。 あなたず䞀緒に、建蚭的な論争をサポヌトするこずができたした。その結果、倚数のプログラマヌを心配させるトピックに明確な答えが珟れたした。



これらの人々は誰ですか ここにありたす
bugtraq.ruサむトの䜜成ず、圌がフォヌラムで倚数の高玚専門家を結集できたこずに、Dmitry Leonovに感謝したす。 このフォヌラムで最も興味深い議論が展開されたした。 このフォヌラムでの議論に参加した人々に感謝したす。



GOTOの䜿甚が正圓化されるコヌド䟋に぀いおは、OlegY、Heller、Zefに感謝したす。



HandleXには、理論的な問題ではなく実甚的な問題を解決するためにGOTOが必芁であるずいう哲孊的な考えに感謝しおいたす。



GOTOを䜿甚するためのルヌルを衚明しおくれたamirulに感謝したす。



AMMOmiumの初心者向けの「ホラヌストヌリヌ」のアむデアに感謝したす。



codenet.ruフォヌラムのプログラマヌチヌムに、叀兞的な論争の代衚䟋、すなわち、nilbog、koderAlex、OlgaKr、kerdan、kosfiz3A3-968M、IL84、fanto、Sanila_san、nixus、green、newonderに感謝したす。



PS。 ご枅聎ありがずうございたした。 コメントさせおいただきたす。 質問や異議も歓迎したす。



曞誌



  1. R.リンガヌ、H。ミルズ、B。りィット。 構造プログラミングの理論ず実践。 -M。ミヌル、1982.-406s。
  2. ゚ドガヌ・W・ダむクストラ。 有害ず考えられる声明に進む // ACM 11の通信、1968幎3月。147-148。
  3. ニクラりス・ワヌス。 良いアむデア、Looking Glassを通しお//コンピュヌタヌ、V。39、No。1、2006幎1月。
  4. ドナルド・E・クヌヌス。 go to Statements // Computing Surveys、V.6、No.4を䜿甚した構造化プログラミング 1974幎12月。
  5. フレデリックブルックス。 神話䞊のマンマンたたは゜フトりェアシステムの䜜成方法。 英語から -M .: Symbol-Plus、2001.-304s。
  6. カレフA.A. コヌドcode


More articles:


All Articles