短絡評価が悪いのはいつですか？

もう少し明確にするために、私はさまざまな言語で多くの時間を費やしたと述べます。しかし、これまでは常に使用するか、まったくサポートしていませんでした。

現在、VB.netを必要とするプロジェクトで作業を開始していますが、ANDとANDALSOの両方の面でVB.netを提供しているようです。最初のものは短絡せず、2番目のものは短絡します。

だから、これはなぜだろうかと思いますか？このように設定すると、モードを切り替えたいことが頻繁に発生することを暗示しているようです。しかし、短絡回路を使用することが悪いことになるような状況は考えられません。

私はこれがより多くのオプションのものに入る可能性があることを知っているので、これを他の場所に置く必要がある場合は、どこにいるか教えてください。

私は少なくとも公式の答えがあればいいのにと思っていますが、両方のオプションがあるのは、可能な場合は常にShort Circuitを行うよりも良い理由についてです。

論理式の一部の用語には、副作用がある場合があります。すべての副作用が指定された順序で発生することを保証することが必要な場合があり、スキップされないものがあり、論理を導くのは評価結果です。

if not (PushAirPlane(thrust) and TurnAirplane(vector)), SimulateCrash(severity)

それ以外の場合、以前の評価でfalseが返された場合、残りの用語を評価したくない場合があります。

if IsAirborne() and not (PushAirPlane(thrust) and TurnAirplane(vector)), SimulateCrash(severity)

2番目の例の短絡動作に依存するのは悪い形式であると主張する人もいますが、それはコーディングスタイルと信念体系になりつつあります。世界には、言語が提供するほぼすべての機能に依存する非常に優れたコードが数多くありますが、それはまさにその通りです。

VBのANDALSOは鮮明で、練習をより受け入れやすくする試みのようです。

JimmyJamesが彼の答えで指摘しているように、短絡評価に関して測定可能なパフォーマンスへの影響がある可能性があります。メカニズムを提供しない言語は、常に式のすべての用語を評価しますが、提供する言語は追加の分岐ステートメントを生成できます。どちらの場合も、各用語を評価するために必要な処理ステップの数と、コンパイラーおよびCPUアーキテクチャーに大きく依存します。通常、コードにボトルネックが測定され、それを軽減する方法を見つけるまで、そのようなことは気にしません。コードで短絡評価を許可するかどうかのルールは、コードを遅くし、早期に最適化することは時間の無駄になる可能性があるため、常に測定してから最適化することができます。

どうやら、あなたの質問は、短絡が一般的に良いか悪いかということではなく、VB.NETがそれを使用する場合と使用しない場合にオペレーターに提供する理由に関するものです。これを念頭に置いて、への答え

短絡評価はいつ悪いですか？

単に：後方互換性に違反する場合。

さて、VB.NETは古いVB6やVBAとの下位互換性はあまりないと言えますが、少なくとも言語の特定の部分は互換性があります。古いANDおよびORのセマンティクスを（短絡なしで）維持するというMicrosoftの決定により、古いVBプログラムをVB.NETに移植する際にエラーの大きなカテゴリが発生する可能性が低くなりました。

一方、VB.NETの言語設計者は、おそらく短絡は良いことだという意見を共有しました。正しく覚えていると、最初のVB.NETプレリリースバージョンはANDまたはOR演算子に短絡を提供していましたが、開発者のフィードバックは非常に悪く、VB.NET 1.0が登場する前にこの決定を取り下げたに違いありません。デザイナーが新しいキーワードの面でそれを実装することを決めたので、ANDALSOとORELSEの後方互換性と有用性とのトレードオフとして。

私見これは良い決断でした。過去10年間にいくつかの古いプログラムを移植する必要がありましたが、ANDおよび/またはOR（しゃれを目的とする）を含むすべての論理式に対して重い影響分析を行う必要がなかったため、そのタスクははるかに簡単で経済的になりました。一方、VB.NETで新しい論理式を記述する必要があるときはいつでも、演算子のデフォルトの選択は短絡形式です。これは、C、C ++、C＃などから慣れているものです。いくつかのイディオムをより簡潔な形式で記述します（ANDALSOでさらに4文字入力する必要がある場合でも）。

納得できない場合は、Joel SpolskyのMartian Headsetsに関する素晴らしい記事をお読みになることをお勧めします。これは、コンポーネントまたは言語またはステークのAPIが特定のサイズのユーザーベースに達した後、ソフトウェア開発の初期設計決定を簡単に取り消せない理由に関するものです。

短絡評価はいつ悪いのですか？

ブール値の全体的な結果の評価で実行されると予想される式の副作用に依存し始めるとすぐに、それらは悪くなります。

警告：これは少し難解です。ほとんどの場合、開発者は心配する必要はありません。しかし...実行時に分岐が発生するため、条件付き評価が原因でパフォーマンスが低下する可能性があります。非短絡操作は分岐せず、より予測可能です。

これがめったに問題にならない理由は、通常、コストが小さく、通常は2番目（または3番目など）の条件を評価するコストを上回るためです。これは、高性能が必要な場合に計算負荷の高いルーチンでのみ重要であり、それでも問題ではない可能性があります。

パスカルは、ANDとORが短絡評価を使用するかどうかを定義しませんでした。これにより、両方の世界で最悪の事態が発生します。

CおよびC ++にはビット単位の演算＆および|があります これは実際には非短絡操作を提供します。また、コンパイラーは、目に見える違いをもたらさない場合、好きな方法で評価することができます。