問題タブ [using-statement]

私は以前に関連する質問をしたことを知っています。私はちょうど別の考えを持っていました。

引数は次のとおりです。SqlDataReader drオブジェクトは接続オブジェクトやコマンドオブジェクトのような新しいオブジェクトではないため、cmd.ExecuteReader()メソッドを指す単なる参照であるため、リーダーを。内に配置する必要がありますかusing。（以前の投稿に基づいて、を使用するオブジェクトはIDisposableに入れる必要がありusing、からSQLDataReader継承する必要があることを理解しているIDisposableので、それを入れる必要があります。私の判断で正しいですか？）新しいオブジェクトの場合、コマンドへの参照ポインタであるオブジェクトを破棄する際に問題が発生しますか？

どうもありがとう

ActiveDirectoryと区別される名前を取得するディレクトリサービス関数で「usingステートメント」を正しく使用しているかどうかを教えてください。オブジェクトを正しく破棄して閉じたい。

コード：

WCF Web サービス メソッドを安全に呼び出す方法を知りたいです。これらの方法は両方とも許容可能/同等ですか? より良い方法はありますか？

最初の方法:

2 番目の方法:

クライアントが適切に閉じられ、処分されていることを確認したい。

ありがとう

今日、同僚の C# コードを閲覧していたところ、次のものが見つかりました。

usingオブジェクトの寿命の範囲を定義する中括弧のペアが続くステートメントを常に見てきました。コードを書いた私の同僚は、ステートメントの中括弧data1 usingは必要なく、コードはそれらが存在してdata2 usingステートメントをネストした場合と同じことを行うと言いました。では、中括弧を省略するとどうなるでしょうか。

usingキーワードを使用している場合でも、実装する必要がありますIDisposableか？

オブジェクトの処理が終了したら、usingディレクティブ、またはdisposeディレクティブのどちらが優れていますか？

一方、System.Net.Mailを処理しているときは、オブジェクトのDispose（）を実行して、漂遊ロックを解放する必要があると言われます。

一貫したガイダンスはありますか？特定のオブジェクトに対して、特定の状況で何がより適切であるかをどのように判断できますか？

には using ステートメントを使用しSqlConnectionます。プールへの接続を解放するだけの Dispose() の呼び出しを強制するため、パフォーマンスが向上します。

しかし、using で作成したオブジェクトは再定義できないことに気付きました。私はこのようにすることはできません:

using を置き換えて、次のようなことができるかどうか疑問に思っていました。

最後のブレースSqlConnectionの後はアクセスできません。}オブジェクトがスコープ外になるとすぐに Dispose() が呼び出されますか?

注: オブジェクト ライフタイム RAII を使用しない/ブロック スコープ RAII を使用する

追加の gc カテゴリ、短命のオブジェクト (gc カテゴリをやや頻繁にチェックする)、長命のオブジェクト (gc カテゴリをそれほど頻繁にチェックしない)、およびリソース オブジェクト (gc カテゴリを非常に頻繁にチェックする) を使用することは可能のようです。または、リソース オブジェクトの追加の参照カウント gc を使用することもできます。

using/with スタイルは、I/O のより機能的なスタイル (私が間違っていて、これが機能的なスタイルでない場合は許してください) を促進することで、いくつかの利点があるようです。オブジェクトベースの RAII の柔軟性 (簡単だから)。しかし、問題によっては、リソースの有効期間を追跡するのが難しい場合があります。

gc の複雑さと速度を回避する以外に、これが主流の言語で行われていない理由はありますか?それらの仕様では、一部のタイプのオブジェクト/またはすべてのオブジェクトの参照カウントが指定されておらず、人々が使用する他の実装には参照カウントがなく、それらの言語でのオブジェクトの有効期間 RAII の使用が制限されています。

PS:Perl に C++ タイプの RAII はありますか?

C# のステートメントに関しては(名前空間をインポートするディレクティブusingと混同しないでください)、中かっこが使用されていない場合、Visual Studio は後続の単一行コードをインデントしません。これは、この SO questionに示されているステートメントを使用した「ネスト」の典型です。using

usingステートメントの書式設定とは異なり、その後のステートメントがインデントされていないのは混乱を招きますif。

インデントしない理由はありますか、それとも単なる好みですか?

編集：

さらにテストを行った結果、VS の書式設定動作の一部について、私が間違っていたことが明らかになりました。using ステートメントを入力した場合:

...Enter キーを押すと、カーソルが に揃いますusing。次の行も using ステートメントである場合は、引き続き整列されます。そうでない場合、VS は完了時にインデントします。したがって、私の最初の例は、デフォルトのフォーマットをオーバーライドするか、それを行わない IDE を使用しない限り、実際には達成できないため、最初の質問はやや無効です。

それでも、複数のusingステートメントは技術的には 1 つのブロックとして扱うのが最善であることを知っておく価値があります。usingインデントの欠如は、ステートメントが中かっこのない連続したステートメントである場合にのみ適用されます。そして慣れてくると、あまり変わっていないように見えなくなります。

いつものように、これらのマイナーなプログラミングの詳細でさえも洞察と経験に答えてくれたすべての人に感謝します.

さまざまなスタイルガイドの関連セクションを読むことを含め、宣言の使用について私が行った調査のほとんどは、すべての#includesの後に表示される限り、C++ソースファイルで宣言の使用を使用するかどうかを示しています。決定はコーダーに任されました。私が読んだスタイルガイドでさえ、一貫性を保つためにそのような一般的な論争のどちらか一方に通常は当てはまりますが、この点に関してはかなり柔軟です。

私の質問は、この高度な柔軟性を考えると、一貫したスタイルを使用することはどれほど重要ですか？たとえば、著者が次のようなものを書いたとします。

std::vectorでは使用するがstd::coutまたはstd::endlでは使用しないという一貫性のないアプリケーションは、一般的に許容できると見なされますか、それとも規律がないと見なされますか？