- C++相談室 part121 [無断転載禁止]©2ch.net
344 ：デフォルトの名無しさん[sage]：2015/12/22(火) 21:27:35.79 ID:07eSaah4 - >>337
あるわ
関数に分ける作業は、スパゲティー化した関数の事後の解析手段としては大いにアリ
ブロックにしただけだと、ブロック外で宣言された変数をブロック内で使い放題なので、本当に使っているのかどうか判然としない
グローバル変数を含まない関数に分けてみてはじめてコンパイラの力で「使われていない」ことが証明可能になる。
1000メンバの構造体に対する読み書きとか、
1000個のグローバル変数に対する読み書きとかやってる関数を考えたらﾜｶﾙ
実際に漏れはやった
|
- C++相談室 part121 [無断転載禁止]©2ch.net
349 ：デフォルトの名無しさん[sage]：2015/12/22(火) 21:42:49.94 ID:07eSaah4 - >>347
C++のラムダはよう知らんが、「キャプチャしていない」ことをコンパイラが証明してくれるかどうかに一抹の不安が…
ラムダは本質的に自由変数を束縛するブツなのでキャプチャが思わず自然にできてしまう気がして怖い…
あとgotoが無く構造的に複雑でもないのに読みづらいというケースは有り得る
void foo(<引数>) { Aブロック; Bブロック; Cブロック; Dブロック; Eブロック; }
というちょう長い関数が実はデータフロー的には
<引数>→A→B→E
<引数>→C→E
<引数>→D
でしかなかった、とかがそれ
|
- C++相談室 part121 [無断転載禁止]©2ch.net
350 ：デフォルトの名無しさん[sage]：2015/12/22(火) 21:48:19.23 ID:07eSaah4 - 上の例で、A, B, C, D, Eがいっぱいコードが詰め込まれたブロックで、1000メンバの構造体を好き勝手に読み書きしているだけに見えるコード、とか
見かけはガチのスパゲティーコードだが、関数に分けて行けばほぼ機械的な作業でブロック間のIN/OUTが明らかになる、
|
- C++相談室 part121 [無断転載禁止]©2ch.net
354 ：デフォルトの名無しさん[sage]：2015/12/22(火) 22:24:18.60 ID:07eSaah4 - >>353
>データ構造とアルゴリズムを議論せずにコード量を云々しても……
できる！
アルゴリズムの選択と、関係ないものをまぜこぜにしたコードの汚さは分けて議論できる
処置も然り
データ構造については一つの構造体が読みも書きもされる、という時点で黄色信号が点っていることがﾜｶﾙ
void foo(struct Foo& a)よりもvoid foo(const struct Bar& a, struct Baz& b);の方がなんぼかマシ
(*thisはどうなんじゃ、という反論が来たらもっと書く
1000メンバの構造体は、入れ子の構造体を数えたら1000個超えてた； という形でしばしばある
|
- C++相談室 part121 [無断転載禁止]©2ch.net
360 ：デフォルトの名無しさん[sage]：2015/12/22(火) 22:36:40.78 ID:07eSaah4 - >結局その1000個のメンバにアクセスし放題だから、複雑さは一緒だね
驚くべき決め付け力！
関数void foo(struct HugeStruct& x);を
関数void func_ABE(const struct SmallStruct1& x, struct SmallStruct2& y);と
関数void func_CE(const struct SmallStruct3& a, struct SmallStruct4& b);とか
に分ければ>>349なケースにおいて複雑さは減るし、データ構造は小さくなる
IN/OUTを明らかにする、とはこういうことを指向している
（無関係なものを排除するのはデフォ
|
- C++相談室 part121 [無断転載禁止]©2ch.net
362 ：デフォルトの名無しさん[sage]：2015/12/22(火) 22:41:12.85 ID:07eSaah4 - >>356
概ね同意だが、元がスパゲティーコードなのだとすると、
構造体の入れ子が意味的に正しい区切りかは解析してみないとﾜｶﾗﾝし、
構造体の入れ子の中にも、読まれるメンバと書かれるメンバが入り混じったフラットな部分（もっと分割できる）があるかもしれない
|