- - PR -
Disposeパターンのためのusing
1
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-05-31 23:33
こんにちわ、k-nakです。
参照している記事を読んでいて以下のページを思い出しました。 http://mag.autumn.org/Content.modf?id=20050506145337 「C++→Java→C#という進化形路は本当に正当か いまここで問う、プログラム言語のリソース管理論」 上記のページとあわせて考えていて思いついたことなのですが、結局のところリソース管理に有効なDisposeパターン実現には、「Disposableなオブジェクトをスコープに拘束する」機能さえ言語にあればいいわけです。 ところが現在のC#のusingでは、これに加えて「新たなスコープを作る」機能も抱き合わせ販売状態になっているために、微妙に使い勝手が悪くなってると思います。 となるとたとえば以下のような「オブジェクトをスコープに拘束する」だけの構文があればいいのでは、と思ったのですがこの考え方って何か問題ありそうでしょうか?
上記で問題があるとなると、現状のusingがスコープが作れるステートメントである理由があるはずなのですが、今までそういうのを見かけたことがありません。 このことについて何かご存知の方がいましたら、その理由について教えていただけないでしょうか? 以下、余談ですけど、C#の場合、以下のような記述ができます。(ここの会議室で知りました)
これってVB2005の場合、こうなるんですよね……。
これもこういう風にかけたらすっきりするなぁ、と。
| ||||||||||||||||
|
投稿日時: 2005-06-01 00:33
usingが「スコープが作れるステートメントである」というより、
usingが「スコープが無いと実現が難しいステートメントである」 のではないかなあ、という気がします。 つまり、コンパイラのフロー解析が難しくなりそうだな、と。 特にgotoとかswitch/case/breakが含まれる場合は面倒です。 monoのmcs(C#コンパイラ)はこの辺に面倒なバグが少なからずありました。 個人的には、スコープを自動的に推測するusingは確かに 魅力があるかもしれませんが、この辺の困難を代償にするほどの 価値は無いんじゃないかなあと思います。 | ||||||||||||||||
|
投稿日時: 2005-06-01 06:12
コードの可読性の点からいえば、using の明示的なスコープ記述が適切と思います。
C++/CLIでは不要になるようですが... http://msdn.microsoft.com/visualc/using/multimedia/oopsla/default.aspx _________________ IEEE-CSDP 2004-2007 |
1