  |
元の批判記事を見るとわかるけれども、趣味グラマ視点の反論に便乗してるのだもの、どーせ使われることのない汎用性なんて考える必要無いじゃない。いえ、もしそういう保存の仕方が常態化してる個人ユーザが身近にいらっしゃっるのであれば、謝らなくちゃならないかもしれませんが。まず、分割が必要なほどの超巨大画像を処理する個人ユーザなんて極々少ない特殊事例だと思う。
一応、分割された画像の処理ってだけなら、先にメモリ上で複数画像のピクセルデータが連続になるように作ってやれば（つまり、メモリ上で画像を組み合わせて完成させてやれば）、呼出元の変更は最小限で済むし、読み込み自体も、単なる結合で済むので簡単だと思う。超巨大画像だとメモリが持たない気がするけれども。
オブジェクト指向が人間らしい書き方かには疑問の余地があるが、C言語とかでプログラミングしてると必然的に行き着く考え方だとは思う。 関数を作成できる言語ならカプセル化の必...
趣味グラマーのおいらに言わせりゃ、オブジェクト指向だなんだとかっこいい言葉を使っちゃいるけど、現状の実態は構造化のなれの果てのような気がする。 というかなんか酷い。こん...
それは単にオブジェクト指向がきちんと身についてないまま使って、収集がつかなくなっているだけに聞こえる。
横からゴメンね。 例えば、画像処理用のクラス（imgClass）があったとする。そのとき、 for (i = 0; i < width; ++i) { for (j = 0; j < height; ++j) { color = imgClass.getPixel(x, y); .... }} と ...
それってimgClassの実装が変わった場合、アクセサメソッド使っていない場合は全部書き直すことにならないか？ 例えば超巨大画像を効率よく保存するために、64x64のブロックに区切って保...
元の批判記事を見るとわかるけれども、趣味グラマ視点の反論に便乗してるのだもの、どーせ使われることのない汎用性なんて考える必要無いじゃない。いえ、もしそういう保存の仕方が...
gdgdっぽいけど反論しておくと、超巨大画像云々はあくまで例です。 メモリ連続云々は、ミップマップ構築等で横方向だけでなく縦方向のアクセスも行われるとき、巨大な画像だとメモリ...
たしかに趣味グラマには本格的なOOPは必要ないと感じます。 2万行くらいならなんとか全体把握できるし。 きちんとしたOOPが必要なのって、10万行以上のプログラムを、 10人以上で開発す...
レス元の増田だけど… 何をいわんとしているかがいまいち判らないのだけども、自分ひとりが使うわけではなくてもそうするのはむしろ当たり前に思える。 何度も呼ぶ必要の無い関数...
いや、例見る限りじゃ違うんじゃない？
保守する人のことも考えてあげてください。もちろん数年後の自分自身も含めてね。 一回作ったら終わりでもう二度と保守しないような使い捨てプログラムならそれでもいいかもしれま...
はて、精神衛生上というか後者の方がいいような気がするな。 はっ！ 俺もWinAPIのGetPixelで恐怖心を植えつけられてる派だからか！ 画像を反転コピーしようとして、あれはショックだっ...
それってコンパイラがインライン展開してくれれば問題ない気がする。 C言語で学んだ人って末尾再帰でも実行コストに恐怖してしまう人が多いような。
case文の羅列を醜いと感じるか、数行の関数/メソッドの羅列を醜いと感じるか、とか、 構造体やポインタ渡し、関数ポインタ等の好き嫌い、 あと、行動で分類するか対象で分類するか、...
6
