  |
高負荷になるとカーネルコールから特殊なエラーが帰ってくるとか
単体じゃ出ない問題もあるし
人が違う、会社が違うっていうところから来る意識違いとか、結構テストしてもでるし。 結合のデバッグはなくならんよ。
あとは、引き継いで、数年後に違う人が改造するとかのときに、
あまりにも、STLガツガツだよ改造しにくい時があるんだよ。
数年後の改造って、当初の設計になかった追加機能だから、設計上できなくて結構改造ってときに
ベタベタに書いてあるか、STLガツガツに書いてあるかとか結構違ってくるしね。
メソッドが細かすぎるとコールスタックが深くなりすぎて、それはそれで追っかけにくいというのもある。
時間が経つと、書いた人がもういないとか、よくあるしね。
そういう時に、改造しやすくデバッグしやすく行儀よく書いてあるとすげー助かる。
最近は、年取ったのもあって、難しい部分は
std::copy(v.begin(), v.end(), std::ostream_iterator<string>(std::cout, "\n")); とか書くやつなんなの
それがSTLの本来の使い方。 変数宣言すると名前覚えたりするの面倒なんだよ。そっちの方が楽だし、OCamlやFSharpみたいな関数型言語に慣れたら一時変数が苦痛でしかない。
それは、使ったほうが分かりやすい例ではあるけど、わかんない人も多いかと思うよ。 それよりも、関数を引数にするアルゴリズム関連は 正直 やめてほしい。 長めの関数の中盤ぐら...
細かくメソッドに分けて単体テストを必ず書くようにするんじゃだめなの？
マルチスレッドのタイミング問題とか シグナルの問題とか 高負荷になるとカーネルコールから特殊なエラーが帰ってくるとか 単体じゃ出ない問題もあるし 人が違う、会社が違うって...
それは、巨大で100時間も連続で動かすようなプロジェクトにC++を取り上げるほうが間違っているとしか思えない。
JAVAで書いてもいいが、システムが巨大という意味にはJavaVMの移植とかLinuxのカーネルにパッチという意味まで含まれているので CだろうとC++だろうと使うことになるのは変わらんし 今時...
6
