問題タブ [using]

VS2008には、Resharperと同様に、ディレクティブを使用してクリーンアップするための削除および並べ替え機能があることを知っています。コードが「クリーン」であり、将来存在しない可能性のある名前空間を参照する問題を取り除くこととは別に、使用ディレクティブの「クリーン」リストを維持することの利点は何ですか？

コードが少ない？コンパイル時間が速くなりますか？

私は using ステートメントを見ているだけです。私はそれが何をするかを常に知っていましたが、今までそれを使用しようとしなかったので、以下のコードを思いつきました:

これは機能しているようですが、SQLサーバーのダウンなどの予期しないエラーをキャッチするために、これをtry catchブロックで囲む必要があると私が知る限り、これには何かポイントがあります。何か不足していますか？

私が現在見ることができる限り、cmdを閉じて破棄するのを止めるだけですが、try catchがまだ必要であるため、コード行が増えます。

テンプレート基本クラスで「using」宣言を使用することは可能ですか? 私はそれがここにないことを読みましたが、それは技術的な理由によるものですか、それとも C++ 標準に反するものですか? gcc または他のコンパイラに適用されますか? それが不可能な場合、それはなぜですか?

コード例 (上記のリンクから):

SqlConnection が定義され、次に SqlCommand が定義されている多くの例が、両方とも Using ブロックに存在することを知っています。

私の質問: SqlCommand で直接接続を定義すると、コマンドが破棄されたときに接続が閉じますか?

私が次のものを持っていると想像してください：

ドキュメントによると、linqの実行は、foreachの行で発生する結果を実際に列挙するまで延期されます。ただし、usingステートメントは、MyFunct（）の呼び出しの最後にオブジェクトを確実に収集するように強制する必要があります。

ディスポーザが実行されたり、結果が実行されたりするのはいつですか？

私が考えることができるのは、遅延実行がコンパイル時に計算されることだけです。したがって、実際の呼び出しはコンパイラによってforeachの最初の行に移動され、usingが正しく実行されますが、foreach行まで実行されませんか？助けることができる教祖はそこにいますか？

編集：注：このコードは機能しますが、方法がわかりません。

少し読んだところ、コードでToList（）拡張メソッドを呼び出したことに気づきました。これはもちろん結果を列挙します。チェックされた回答の動作は、実際に回答された質問に対して完全に正しいものです。

ご迷惑をおかけして申し訳ありません。

私が持っているとしましょう

意味的には、「SomeFunctionalityFor6」は本質的にテンプレート引数6に固有の名前空間です。したがって、コードでは、実行する代わりに、テンプレートのこのインスタンスを使用します。

むしろ、実際の名前空間で「using」ステートメントを使用する機能が必要です。

これは、私が思うに、うまくいきません。Visual Studioは、usingステートメントの後に「namespace」キーワードで定義された名前空間が必要であると文句を言います。

とにかく私がやろうとしていることをすることはありますか？主に、静的メソッドを呼び出すたびに名前空間を完全に修飾したくありません。私はそのほとんどが単なる構文糖衣であることを知っていますが、私の意見では、コードをはるかに読みやすくすることができます。「class」キーワードを使用する代わりに、名前空間を直接テンプレート化する方法さえあるのだろうかと思います。

次のようなものを使用する場合:

conn.close(); を実行する必要がありますか? または、 using ステートメントにより、最後の呼び出しを実行できなくなりますか? using ブロック内のすべてを破棄しますか? たとえば、関係のない他のオブジェクトを呼び出した場合、それらも自動的に破棄されますか?

ありがとうございました。Microsoft のサイトでの使用について読んだ後、私は不明でした。メモリリークがないことを確認したい。

C++ では、「using」キーワードを慎重に使用することで、コードの可読性を大幅に改善できることがよくあります。次に例を示します。

になる

Pythonにも同様のものが存在しますか、それともすべてを完全に修飾する必要がありますか?

使用には落とし穴があり、範囲を適切に制限する必要があることを知っているという免責事項を追加します。

「使用中」ブロックを使用すべき (または使用すべきでない) 特定の例はありますか?

usingを実装するリソースを使用する標準的な方法であるため、ブロック内で WCF サービス クライアントをインスタンス化するのが好きIDisposableです。

ただし、この MSDN の記事で説明されているように、WCF クライアントをusingブロックでラップすると、クライアントが障害状態のままになるエラー (タイムアウトや通信の問題など) を隠すことができます。簡単にDispose()言うと、 が呼び出されると、クライアントのClose()メソッドが起動しますが、エラーが発生した状態であるため、エラーがスローされます。元の例外は、2 番目の例外によってマスクされます。良くない。

MSDN の記事で推奨されている回避策は、usingブロックの使用を完全に回避し、代わりにクライアントをインスタンス化して、次のように使用することです。

ブロックと比べると、usingそれは醜いと思います。また、クライアントが必要になるたびに大量のコードを記述する必要があります。

幸いなことに、(現在は廃止された) IServiceOriented ブログで、このような回避策をいくつか見つけました。次から始めます。

次に許可します：

usingそれも悪くないのですが、ブロックほど表現力がなく分かりやすいとは思いません。

私が現在使用しようとしている回避策は、blog.davidbarret.netで最初に読んだものです。基本的に、クライアントのDispose()メソッドはどこで使用してもオーバーライドします。何かのようなもの：

usingこれにより、フォルト状態の例外をマスクする危険なしに、ブロックを再び許可できるようです。

では、これらの回避策を使用して注意しなければならない問題は他にありますか? 誰かがより良いものを思いつきましたか？