09/11/18 08:12:42
>>899
なるほど
ちまちましたコードレベルの最適化はほんとに意味なくなってきてるんだなぁ
勉強になった
901:デフォルトの名無しさん
09/11/18 08:41:55
>>898
日本語が理解できない人だったんですね。
これは失礼しました。
902:デフォルトの名無しさん
09/11/18 08:48:42
>>886
＞StringFormatもargs指定ミスはコンパイル時に発見されないので +でつないでます。
なんでやねん。テストコード書けばテストできる範囲でしょ。
＞2重forで300回近くループするのでfor内部で変数宣言は好ましくないのでは？
実行時最適化が行われる.NET Frameworkの世界でそんな議論しても無意味だよ。
そして、むしろvar構文自体より（便利なものは積極的に使うべきだと思うが）ローカルインスタンスの明示的な初期化(=null;)のほうが問題。
C#ではすべての変数はデフォルト値で初期化されることが保証されているので
object obj=null;
などという初期化は無意味。それどころか変数が使われなくなると初期化なしだとワーニング出してくれるけど
初期化してると出してくれなくなったりするので余計に悪化している。
903:デフォルトの名無しさん
09/11/18 09:14:39
>>893
Javaの皮を被ったDelphiだから
904:デフォルトの名無しさん
09/11/18 09:18:19
varはなんか、なんかちょっと多様したら不味いことがおきるんじゃないかって気がしてならない
具体的に何が起きるのかはわからんけど
dynamicもしかり・・・
905:デフォルトの名無しさん
09/11/18 09:19:59
メソッド名がCamelCaseなのはMSの旧来の伝統
>>904
むしろvar使ったら読みづらくなるようなスコープの長い変数を作るのが悪い
906:デフォルトの名無しさん
09/11/18 09:21:56
>>902
> object obj=null;
> などという初期化は無意味。
可読性的には意味がある
>それどころか変数が使われなくなると初期化なしだとワーニング出してくれるけど
> 初期化してると出してくれなくなったりするので余計に悪化している。
ダウト
907:デフォルトの名無しさん
09/11/18 09:23:41
object obj;
object obj = null;
どう可読性に違いが
908:905
09/11/18 09:25:02
すまんPascalCaseだった
フィールドを既定値(default(type)の値)で初期化するとFxCopで警告出るよ
909:デフォルトの名無しさん
09/11/18 09:29:30
FxCop日本語版は有料なのか・・・
910:デフォルトの名無しさん
09/11/18 09:33:25
URLﾘﾝｸ(msdn.microsoft.com)
これだな
パフォーマンスは今のコンパイラでは関係ないが冗長だからやめろということらしい
FxCopはコメントのルールだけ外しとけば日本語ソースでも普通に使える
911:デフォルトの名無しさん
09/11/18 09:35:13
ローカル変数の確保は内部的にはメソッドスコープだよ。
そんなのを気にしながらBitmapをループ内で作るって…
912:デフォルトの名無しさん
09/11/18 09:39:02
世の中富豪的っていうかこまけえ最適化はコンパイラがやってやんぜ!!な方向に
確実に進化してるんだなぁ
913:デフォルトの名無しさん
09/11/18 09:39:09
>>907
皆が皆C#だけやってると思うなよ？
914:デフォルトの名無しさん
09/11/18 09:39:59
nullの方がヌルヌルして入りやすい
915:デフォルトの名無しさん
09/11/18 09:42:13
ローカル変数はデフォルト値で初期化されるって、されないよ。
だから必ずどこかで代入してから参照する必要があり、でないとエラーになる。
もちろん宣言と同時に代入するのでなくとも、どこかで入れればいいが、
宣言で代入するのが普通は分かりやすいけどな（というかできるだけ最初に代入する必要がある場所で宣言する）。
初期化が保証されてるのはフィールドだ。
916:デフォルトの名無しさん
09/11/18 09:45:37
＞＞ 2重forで300回近くループするのでfor内部で変数宣言は好ましくないのでは？
＞実行時最適化が行われる.NET Frameworkの世界でそんな議論しても無意味だよ。
実行時最適化関係ないよ。
ILの時点でローカル変数はメソッドスコープで確保される。
917:デフォルトの名無しさん
09/11/18 09:51:52
実際ループ内でしか使わない変数ならループ内で宣言してくれた方が
コード読む時も余計なこと考えなくてすむしメソッド化する時とかも便利だしなぁ。
#メソッド化すると呼び出しコスト↑と結局毎回確保になっちゃうけど
918:デフォルトの名無しさん
09/11/18 10:00:03
まあちっちゃなメソッドならインライン展開されるけどな。
とはいってもかなり小さい場合だけだったとは思うけど。
919:デフォルトの名無しさん
09/11/18 10:11:41
>>915
URLﾘﾝｸ(msdn.microsoft.com)(VS.71).aspx
これか、なるほど
俺ずっと勘違いしてたわ。
920:デフォルトの名無しさん
09/11/18 10:16:40
最終的にILになれば同じつうならあとは好みの問題だろう・・・
ギリギリの極限まで速度を追い求めない限り
些細な速度UPを得るよりも可読・メンテ性を維持したい
というのが俺の持論
もちろん事務系とかの話でFA系の処理とかになれば必要なところは可読性捨ててでも速度UPとるけど
921:デフォルトの名無しさん
09/11/18 10:18:50
みんながどのコードを前提に話してるのか見えないんだが・・・
ループ内で宣言したくないのって言うと、
よっぽどでかいインスタンスを毎回newして捨てるとか
そいういう場合？
922:デフォルトの名無しさん
09/11/18 10:49:08
変数のスコープを最小限にするのは宗教でもなんでもなく常識だろ
宣言だけループ外に置いて、わざわざミスが起こる確率を増加させる必要はない
あと、理由もなくローカル変数を規定値などに初期化するのも良くない
たとえば、未初期化の変数を参照するとコンパイルエラーになるので即座に分かるが、
無駄に初期化していると問題の発覚が遅れ、デバッグに要する時間も増える
923:デフォルトの名無しさん
09/11/18 12:28:52
>>922
処理上で意味のある値で初期化するんであって
常に null で初期化すると勘違いしてるから
そういう的外れな反論が飛び出すんだろう
924:デフォルトの名無しさん
09/11/18 12:45:14
インスタンス化の削減も微妙だけどな。
もちろんサイズがでかかったりインスタンス化が重いもので
かつ再利用できるものならループ内でのインスタンス化を削減するのもいいが、
何でもかんでも削減すりゃいいってもんじゃない。
よっぽどタイトなループなら別だが。
個人的には、よく言われるStringBuilderの再利用なんかも微妙だと思ってる。
平均的にはある程度効果はあるが、常識のようにやるべきこととは思えない。
925:デフォルトの名無しさん
09/11/18 12:46:59
「理由もなく」初期化すんなよってことであって
意味あって null で初期化すんのはべつにかまわんと思うけどな。
926:デフォルトの名無しさん
09/11/18 12:48:26
>>924
そういうのは最適化部分を狭いメソッド内に押し込めればOKってルールでやってるなあ。
927:デフォルトの名無しさん
09/11/18 12:50:40
なぜなら、StringBuilderのToStringは内部バッファをそのまま流用してString化するから。
その後StringBuilderに変更を加えた時点でバッファは複製される。
当たり前だけど結局メモリの再確保は起こるわけで、
StringBuilderを新たにインスタンス化するのと大差があるわけではない。
928:デフォルトの名無しさん
09/11/18 12:56:54
そんな細かいこと考えるよりもっとロジック工夫して高速化しろよ
929:デフォルトの名無しさん
09/11/18 12:57:56
だれに言ってんだよ
930:デフォルトの名無しさん
09/11/18 13:00:19
今日もお前ら絶好調だな
931:デフォルトの名無しさん
09/11/18 13:04:50
もっと褒めて
932:デフォルトの名無しさん
09/11/18 13:22:08
結局そういうのもバッドノウハウになってくんだろな
933:デフォルトの名無しさん
09/11/18 13:27:34
>>906
スマンカッタ。確かにフィールド、ローカル変数共に初期化してても他で使ってなかったらワーニング出るな。
初期化してないときとワーニングの内容は変わるけど。
＞可読性的には意味がある
意味がないことが多い。922の言うように未初期化参照のコンパイルエラーを出させるほうが素直なコード。
初期化コード自体がif文で分岐してるとかなら初期値を与えることはあるが、それは例外的な措置だよね。
>>923,925
844のBitmap、Graphicsインスタンスのnull初期化は不要だよな？
934:デフォルトの名無しさん
09/11/18 13:32:32
まあ初期化なくす前に明らかに宣言位置を変える方向だが。
宣言位置が適切なら、多くの場合その場で初期化が自然になるからね。
もちろん意味のない初期化はするべきではないけど、
上記を守れば基本的にそういうのはなくなるはず。
935:デフォルトの名無しさん
09/11/18 13:54:00
>>933
>844のBitmap、Graphicsインスタンスのnull初期化は不要だよな？
不要だがあったからといって悪い訳じゃない
936:デフォルトの名無しさん
09/11/18 14:05:32
チームの規約にしたがうレベル
戦ってまで守らなきゃいけない一線ではないわな
どっちにしても
937:デフォルトの名無しさん
09/11/18 14:14:32
>>935
>Bitmap、Graphicsインスタンスのnull初期化は不要だよな？
インスタンスのnull初期化じゃなくて変数(ry
938:デフォルトの名無しさん
09/11/18 15:48:55
formAからｆｏｒｍ.showでformBを開いた後、不要になったformBを×ボタンで閉じます。
この時、formBのリソースは全て開放されますよね？。
939:デフォルトの名無しさん
09/11/18 15:52:19
ガベージコレクションの対象にならないと開放されないよ。
940:デフォルトの名無しさん
09/11/18 15:57:44
そのｆｏｒｍという変数を保持している間は解放されないかな
941:デフォルトの名無しさん
09/11/18 16:17:16
規定のインスタンスを使用している場合はアプリ終了まで保持されるというような話を聞いた。
（でもこれってたしかVB.NETの話だったような。C#では規定のインスタンスってあるんかな？)
942:938
09/11/18 16:27:33
そうなるとFormClosingでちゃんと処理してから終了させた方が良さそうですね
ありがとうございます
943:デフォルトの名無しさん
09/11/18 16:32:41
>>942
いあ、そういふ意味ではないんだが。
Form_Closingイベントとメモリ開放は別話。
944:デフォルトの名無しさん
09/11/18 16:43:17
>>942
モーダルダイアログならFormAで次のようにFormBを表示し
using(Form formB = new FormB())
{
formB.ShowDialog(this);
}
formBフォームの中で使ってるリソースはFormBのDisposeをオーバーライドして行う