トップページ⇒tech
854コメント333KB

オブジェクト指向は戦場では必要無し その3

■ このスレッドは過去ログ倉庫に格納されています
0001うつつつつNGNG
前スレがめでたく止まったようなので、その3
引き続きOO厨とアンチOO厨の血で知を笑う戦いきぼ。

その1 http://pc.2ch.net/test/read.cgi/tech/1011997945/
その2 http://pc.2ch.net/test/read.cgi/tech/1013266554/

0159デフォルトの名無しさんNGNG
>>158
話が逸れるけど、C++ で無名関数オブジェクトを定義できるようにするライブラリを
書いてる人がいるみたい。boost.org の ML で Review Request が出てた。

(Boost Lambda Library, 略称 BLL だそーだ)
0160デフォルトの名無しさんNGNG
>>153

同意。

OOの利点で語られることの殆どはOOをサポートしない環境でも
結構頻繁に使われるよね。

Netscapeなんて構造体のメンバにに関数ポインタを入れといて
メソッド的な使い方する方法を多用してたし、
これだって一種の多態だね。

別にOOの概念全部を必ず使わないとならないわでないのだから
そこは設計次第でしょ。

OOならできてOOでないとできないことなんて無いんだから・・・

0161デフォルトの名無しさんNGNG
やヴぇ・・・
ageちまった。

スマソ
0162デフォルトの名無しさんNGNG
>>160
> OOならできてOOでないとできないことなんて無いんだから・・・
まぁそうだが、OO で設計したら素直に OOPL 使え、とは思うけど。

インターフェースの多重継承なんかは、OOPL の力を借りないとやってられん
でしょ(関数呼び出しのたびに this 相当のポインタの offset を再計算、とか自
前でやってたら死ぬ)
0163160NGNG
>>162

確かに多重継承はOOPL使ったほうが合理的だと思う。
できる/できない
で語ったのはちと良くなかった

っていうか
Cで多重継承(と似たようなこと)をやるのが痛い
それこそOOのためにコードを書かされる
0164デフォルトの名無しさんNGNG
OOが便利に使えるところならOO使えばいいし、そのためには
(使えるなら)OOPL使えばいいよね。

でも、犬::鳴く、猫::鳴く 的な説明でOOを語る奴はやっぱうざいし。

打ち合わせのときなどに、「その設計はOO的じゃないですよ」なんて
言う奴って結構いないか?
0165デフォルトの名無しさんNGNG
>>164 色んな意見があるよね OOPLは便利に使うし使えるけどOOは嫌いとか

「その設計はOO的じゃないですよ」って言う奴はたいてい設計出来ない奴だから無視するのが吉
「こういう設計を提案します」って言う奴を信用しろ
0166デフォルトの名無しさんNGNG
結局オブジェクト指向ってプログラマがTechに走らないようにする縛りなんだな。
縛りの法則なんてプログラム出来なくたって覚えられる。
だがそんな状態の人が出来ることはせいぜい設計時のダメ出しぐらいで、
代替案なんてありゃしないから邪魔なだけなんだよな。
0167デフォルトの名無しさんNGNG
>>166
> 結局オブジェクト指向ってプログラマがTechに走らないようにする縛りなんだな。
そうなの?
0168デフォルトの名無しさんNGNG
この場合のTech=ひとりよがりのトリッキーな方法
0169デフォルトの名無しさんNGNG
>>168
それにしても、オブジェクト指向を導入すればトリッキーなコードがなくなるかと
言えば、全然関係ないと思うけど。とくに C++ なんかはキャスト使えばなんでも
アリアリだし、

 private なメンバにアクセスしたい
 → friend にしちゃえ (まだマシ)
 → 継承しちゃえ(ダメダメ)
 → #define private public (最悪)

とかあるわけだし。
0170デフォルトの名無しさんNGNG
その辺は XP の出番だろうな。
トリッキーなコードを書いたらペアプロでダメだしされるだろう。
0171糞NGNG
吉川英治 歴史時代文庫17
宮本 武蔵4

p48
無知はいつでも、有知よりも優越する。相手の知識を、テンと
して無視し去ってしまう場合に、無知が絶対につよい。生半可
な有知は誇る無知へ向かって、施すに術(すべ)がないという格
好になってしまう。
0172デフォルトの名無しさんNGNG
知らないふりをするのと、知らないのを比べたら
知らないほうがいいっていうことかな?

関係ないけど、有知って言葉を辞書で調べたら
「有知無知三十里」って言葉が出てきた。
0173デフォルトの名無しさんNGNG
無知の知
ムチムチ (;´Д`)ハァハァ
0174デフォルトの名無しさんNGNG
>>172 >>173
無知はDQNと言っているらしい。
0175 NGNG
ああ、このような名スレがこんなに沈んでるなんて・・・。
sage誘導してるのがいるなー。
てことでage!
0176デフォルトの名無しさんNGNG
>>175
名スレと思うならほっとけYO
0177戦場では役に立たないと武蔵様も・・・NGNG
-------------------------------------------------------
が武蔵には、間髪のまに、処する方法が立っていた。
兵法によらず、すべての理は、それを理論するのは平常の事で、
実際にあたる場合は、いつも瞬間の決断を要するのであるから、
それは理論立てて考えてすることではない、ひとつの「勘」であった。
平常の理論は「勘」の繊維をなしてはいるが、その知性は緩慢であるから、
事実の急場には間に合わない知性であり、ために、敗れることが往々にある。
--------------------------------------------------------------
(吉川英治 宮元武蔵 吉川英治文庫 8巻96ページより引用)
0178デフォルトの名無しさんNGNG
ワケワカラソ
0179デフォルトの名無しさんNGNG
往々って辞書引くと「ときどき物事が起こるさま」って書いてあるね。
0180デフォルトの名無しさんNGNG
>>177の説明
理論だけでは戦場には役に立たない。
戦場には”勘”というのが重要。
その”勘”を養うには繊維となっている理論が重要であるが
それだけではまだ足りない。

つまり、戦場で勝つには”勘”を作っている理論とそれ以外(実践?)を
身に付けろってこと。

ちなみに、文章をよく読むと分かるが、平常の理論は事実の急場には間に
合わないと書いてあるが役に立たないとは書いてないので勘違いしないように。
0181デフォルトの名無しさんNGNG
負けたら即死な戦場では、「往々」は、一度でおしまいってことだ。
0182デフォルトの名無しさんNGNG
「本当の空とは知識や体験を経て達する迷いなき境地であり、空の心に善はあっても悪はない。
『知恵』と『道理』、そして人としての『道』があって初めて心は空となる…」宮本武蔵
0183デフォルトの名無しさんNGNG
え〜と、何やらありがたいような、
板違いなような、デムパなような…
0184デフォルトの名無しさんNGNG
なんだ、武蔵って兵法の理論書き残してるじゃん。
やっぱ理論の重要さを分かっているんだね。
さすが武蔵。
0185デフォルトの名無しさんNGNG
>>175
このスレは

悲惨な「 」を晒すスレ

なんだけど、本人はわかってないと見える (w

で、関数ポインタはどうなったのかね?
0186デフォルトの名無しさんNGNG
だいたい、「 」って、前スレで

ファイル分け >>>>>>> クラス

なんて、わけのわからない主張してたんだよな。
もともと直交している概念を比較してどうするよ。

思うに「 」って、根本的に「インスタンス」がわかってないんじゃないかな。

こいつは(恐ろしいことに)携帯Javaのプログラマだそうだが、こいつの書く
プログラムはstaticの塊なんじゃないかと想像してみる。
0187デフォルトの名無しさんNGNG
> こいつは(恐ろしいことに)携帯Javaのプログラマだそうだが
どうせ妄想でしょ(w
0188デフォルトの名無しさんNGNG
えーと、「 」が晒しあげられる経緯を読んでないんだが
>>186を見る限りとんでもないアフォだと見受けられる。
つーか、携帯ってi-modeだろ?
あれはOOなんて言ってたらメモリが足りないだろ。
8ビットマイコンのBASICプログラムみたいな感覚じゃないのか?
0189デフォルトの名無しさんNGNG
>>188
> あれはOOなんて言ってたらメモリが足りないだろ。
OO だと消費メモリが増えるという根拠は?
0190デフォルトの名無しさんNGNG
OOPLの仕組み知らんの?
0191デフォルトの名無しさんNGNG
なんでもかんでも一つのクラスに突っ込んじゃうほうがメモリ効率がいいとか、
変数はstaticにしといた方がメモりを食わないとか。
0192デフォルトの名無しさんNGNG
>>190
もちろん、代表的な Java VM に関する論文とか Inside the C++ Object Model
ぐらいは読んでますが。
0193デフォルトの名無しさんNGNG
>>192
それで?
0194デフォルトの名無しさんNGNG
>>193
繰り返しになるけど
> あれはOOなんて言ってたらメモリが足りないだろ
は根拠がない、もしくは何か勘違いしてると思ったので、根拠を聞いてみた。
0195デフォルトの名無しさんNGNG
根拠もなにも、10kだぜ?
俺は勘違いしてるか?
0196デフォルトの名無しさんNGNG
>>195
- メモリが足りない
- OO だからメモリが足りない

言ってることが別ってことでしょ。
0197デフォルトの名無しさんNGNG
>>196
下らんことでつっかかるな。
そんなん説明するのはめんどくさい。
0198デフォルトの名無しさんNGNG
下らんというか、このスレの趣旨ってそーゆーことじゃなかったのか? ま、俺は
何でもいいけど。
0199デフォルトの名無しさんNGNG
メモリが足りない= メモリが足りる為に最大限の努力をしなければいけない
そオブジェクト指向は基本的に、おぶ

つまり、途中で出た話のように OO言語を有効に使っていてもOOではないのと同じで
言語の機能は最大に利用しなければいけないけど、注目点は違うという事だ
0200デフォルトの名無しさんNGNG
>>199
日本語で書いてくれよ
0201199NGNG
あれ? 文字化けしてる?

まあそんな書き直すほどの事じゃないけど
 ようするに、
それよりも優先すべき事があるんだから
そっちをoriented 出来ないって単純な話だよ
0202デフォルトの名無しさんNGNG
>>201
> あれ? 文字化けしてる?
うん。

> そオブジェクト指向は基本的に、おぶ
> つまり、
こんな感じになってるので、何が「つまり」なのか謎。

> それよりも優先すべき事があるんだから
優先も何も、そもそも OO とメモリ使用効率が相反するのかって話じゃなかったの?
0203 NGNG
携帯Javaでクラスを作れないのはその世界では常識。
空のクラス1個宣言するだけで700バイト消費するんで使えません。

10K以内に納めるテクニック
http://www.atmarkit.co.jp/fmobile/rensai/doja07/doja07.html
プログラムの基本は「非オブジェクト指向」で
0204デフォルトの名無しさんNGNG
結局ちょっとしたプログラムにOOを適用する奴なんざぁ、
意味が無いことなんだよな。
0205デフォルトの名無しさんNGNG
>>204
なにから話がつながって「結局」なのか謎だが。

まぁ数千行程度の小規模なプログラムなら OO だろうが手続き型だろうが、設計
なんざしなくても作れるっつー気はするけど。
0206デフォルトの名無しさんNGNG
ハッキリ言って世界中の70%のプログラムにOOはイランと思う。
0207 NGNG
>>205
OOPLでは最初にちゃんと見通しを立てて設計しておかないと、
小規模でも行き詰まります。
0208デフォルトの名無しさんNGNG
>>207
OO じゃなくて OOPL なのか?
0209デフォルトの名無しさんNGNG
手続き型でも同じです。
0210 NGNG
手続き型なら部分変更で済む場合が多い。
0211デフォルトの名無しさんNGNG
OOなら部分変更で済む場合が多い。
0212デフォルトの名無しさんNGNG
>>207
俺、数千行どころか数万行でも最初に設計なしに作れるよ。 と言ったらどうする?

もちろんユーザから必要な帳簿のイメージのFAXは貰うけどさ
使うのは主にDelphiかVC++で、つまりはOOPLだけど
別にオブジェクト指向してるわけじゃない。
0213デフォルトの名無しさんNGNG
ハッキリ言って世界中のプログラムの70%にOOは必要だと思う
0214デフォルトの名無しさんNGNG
>>213
でも世の中のプログラマの70%は、一生OOを理解できない
脳みその持ち主だと思う。
0215デフォルトの名無しさんNGNG
それをプログラマとよんじゃぁいけない。
0216デフォルトの名無しさんNGNG
>>212 それは単に設計が早いだけと申し上げておきます
0217デフォルトの名無しさんNGNG
多態があればOOは必要ない
0218 NGNG
VC++は除外>>212
0219デフォルトの名無しさんNGNG
OOとか言っても実際、かりそめのクラス作ってるやつばっかりだと思う。
0220旅の始まりの人NGNG
クラスとして静的に定義しなければいけないものと、
パラメータとして実行時に動的に決めるものとの設計時の
切り分けがよく分かりません。後々後悔する事が多いっす。
完成してみたら、存在意義のない間抜けなクラスがあったり
無茶なパラメタライズがあったり。

どうやって設計段階で判断するんでしょうか?
0221デフォルトの名無しさんNGNG
同時進行だ
設計とコーティングは。
そしてリファクタリングを繰り返す。
そうしないと良いプログラムはできない
0222旅の始まりの人NGNG
リファクタリングですかー。

変更管理が面倒くさくないですか?
下位レイヤを変更したりすると、上位でそれ使ってるところを
みんな修正する羽目になるし。
0223とあるダメ社員NGNG
>>212

C言語ばかり使用していて、やっとOOの勉強を始めたばかりですので幼稚な
質問かもしれません。

|212 名前:デフォルトの名無しさん :02/02/28 23:32
|>>207
|俺、数千行どころか数万行でも最初に設計なしに作れるよ。 と言ったらどうする?
|もちろんユーザから必要な帳簿のイメージのFAXは貰うけどさ

まじめなお話で数千行(数万って…凄いなぁ)もあるプログラムを設計書も作成しな
いで、作れるというのは信じ難いです。
ま、白髪三千丈の類の冗談なんでしょうけど。

ちょうど220の人が書いているようにクラスを考えてみたりする必要もあるわけで
すよね、OOなら。
まして、合計で数千もの手続きを経なければならない機能を作り上げるのに、どうし
たら設計が手軽ですむのか、ちょっと教えて欲しいです。

個別のノウハウとか、そういうものを書いてみてください、といっている訳ではな
くて一般論で構わないので。

どうして、こういう物凄い発言が出来るのか知りたいのです。
0224デフォルトの名無しさんNGNG
>>222
その労力を極力軽減するのが OO だ。

ということらしいぞ。
0225デフォルトの名無しさんNGNG
>>223
212は1行もコード書いたことない妄想野郎だからさ
0226 NGNG
横レスだが、

DBからデータ拾ってきて表示して変更してセーブするだけで、
画面数がやたらに多いのだと軽く逝くけどね・・・。

0227旅の始まりの人NGNG
>>224
本当かなあ…後々静的定義と動的定義を交換するような修正は、
レイヤ間のインターフェイスを変えずに実装だけ変えて済ます
なんてことは不可能だと思うんだけど…
0228デフォルトの名無しさんNGNG
COBOL -> COBOOL

(・∀・)イイ!!
0229デフォルトの名無しさんNGNG
>>227
固定概念を取り払えよ
0230旅の始まりの人NGNG
>>226
そういうのは、1画面分の処理を通せば、後はコピペ(OOPなら実装継承?)
でちょいちょいと変更したのをいっぱい作っていけばいいだけですもんね。

私も、そういうのは設計なしで3万行というのを今書いてるところですよ。
コアだけちゃんと作れば、後は単調な作業が続くんですよねー。
0231たびの始まりの人NGNG
>>229
なにか目のさめるようなアイデアが書いてあるWebページとか本とか
知りませんか?
0232とあるダメ社員NGNG
>>230
うーん。どうにもよくわからないです。もうちょっと教えて欲しいです。

|そういうのは、1画面分の処理を通せば、後はコピペ(OOPなら実装継承?)
|でちょいちょいと変更したのをいっぱい作っていけばいいだけですもんね。
|私も、そういうのは設計なしで3万行というのを今書いてるところですよ。

あの、そういう作り方って、本当にやってらっしゃるのですか?。
似たような処理ばかりで、トータル3万行も?

継承したら、3万行にもなるわけないような気がするのですが、素人の考えなのでしょうか?
0233旅の始まりの人NGNG
>>232
インピーダンスミスマッチの吸収には、どうしても多量の
同じようなコード(あるいはパラメータ)が必要なんですよ…
RDBMSを扱うのは、もういやになりますねー。
0234デフォルトの名無しさんNGNG
>>233
俺もTemplateやら継承やら独自言語作ろうとして失敗した。
まあコードジェネレータ作るのが一番。
0235とあるダメ社員NGNG
>>233
それは、基本的に同じだけど違う部分を手直しする、という意味ですよね、きっと。
Cでやっても同じ事ですから、その部分についてはわかります。
でも、なぜそんなに大量に同じようでちょっと違うものを作り込まなければならな
いのかわからないのです。
0236旅の始まりの人NGNG
>>234
RDBMSをなるべく使わない、というのを最近考えるんですけどね。
OODBとか、キー値でハッシュテーブルにしたXMLテキストで永続化とか。
暇な時にトライ中です。
0237旅の始まりの人NGNG
>>235
GUIとRDBMSをつなげて100画面も作ると、そうなるんですよ。
0238デフォルトの名無しさんNGNG
RDBMSを扱うのに、コード生成するようなスクリプトを用意して
モデル記述の言語からすべて生成されるような仕組みにするのが、
よく使う逃げですね。

プログラマーの持つ最大にして唯一の能力は機械に仕事をやらせることで
す。
医者の不養生といいますが、プログラマーは、お客サンのためだけでなく、
自分のためにもめんどくさがりや精神をもっと発揮すべきなんですよね。

美学からいくと、生成したものは、Artではない気がする。そこの
プログラマーの心理的な抵抗がある気がする。
きっと、生成すらしなくてよいようなフレームワークがあるんだろうな。
なんだろう?
0239 NGNG
いやいや、御客の要望。見た目などで自動生成ではなかなか済まない。
(済まないと予想される)
例えば、同じアイテムなのに、
ある画面では「氏名」
ある画面では「あなたの名前」
ある画面では「姓」「名」だったり・・・。
0240デフォルトの名無しさんNGNG
俺より頭がいいやつは全員氏ね
0241旅の始まりの人NGNG
>>238
高速に動作する複雑な構造化問い合わせの機能が必要なければ、
RDBMSを使用しないというのは、かなり良い解決策だと思うん
ですよ。

検索のパターンだけ洗い出しておいて、RDBMSのスキーマ定義を
単純化して(可変長バイナリのカラムを用意する)、問い合わせ結果
をプログラム側で動的に解析するというのも、メモリとCPUパワー
に余裕があるなら、いける、かな?どうでしょう?
0242デフォルトの名無しさんNGNG
同一パタンならバルク転送しろよ
0243デフォルトの名無しさんNGNG
>>241
オブジェクトのストアとしてRDBMSを使っちゃえ、ということでせうか。

>>239
失礼しました。ほんとに使いごごちの良いアプリってモデル記述
言語をがんばってもそれが複雑になる一方というか、、、
モデルとビューとコントローラーは果たして分離できるのか。
それすら怪しい。。「オブジェクト」指向じゃだめなんでしょう。

なんかこう、多態で、可変で、そんな生き物みたいなもの、、
幽玄指向でいきましょう。
0244デフォルトの名無しさんNGNG
>>238 がいい事言った!

> 医者の不養生といいますが、プログラマーは、お客サンのためだけでなく、
> 自分のためにもめんどくさがりや精神をもっと発揮すべきなんですよね。

優れたプログラマは皆面倒くさがり屋である。
面倒くさがり屋であるが故に何でも自動化しようとし、プログラム技術が上達する。
しかし、面倒くさがり屋なので脳内設計が多く、上に立つ人間には向かない;->
0245デフォルトの名無しさんNGNG
>>244
↓ここのうけうりです。
See -> http://www.pragmaticprogrammer.com
邦訳は達人プログラマーね。
0246デフォルトの名無しさんNGNG
>>223
>まじめなお話で数千行(数万って…凄いなぁ)もあるプログラムを
>設計書も作成しないで、作れるというのは信じ難いです。
>ま、白髪三千丈の類の冗談なんでしょうけど。

俺、212じゃないけど、数千行程度なら「設計書」なんぞ書かなくても
楽勝で書けるよ。これぐらいなら当たり前じゃなかろうか。
別にコピペの塊じゃない。

C/C++なら、ヘッダファイルが十分「設計書」の役割を果たすと思う。
数千行程度のゴミプログラムで、それもひとりで書いてるんならね。

1関数で数千行書く奴もちょくちょくいるが(鬱 そういう話をしている
のでもない。
0247デフォルトの名無しさんNGNG
>>223
マジメに聞いてるようなんで マジメに答えましょう
好きな道具はDelphiです。
DelphiはOOPLですが設計にクラスわけなんてオブジェクト指向してる訳じゃないんで
別に最初に考えたりしません。 クラスは再利用したりしません。ただコンポーネントは
再利用出来ますが。
 まあ具体的な話の方がいいでしょう

慣れれば、会計処理なんて定型ですから必要な印刷物が判れば必要な入力画面もわかります
仕事貰ったら、印刷イメージ見ながら、どんどん入力画面作ります。画面作りながら SQLのCREATE文
書いてゆきます。  画面できたら客に使わせて入力させてゆきます。
それから印刷にかかりますが、印刷はお客さんにはコダワリが必ずあるので、貰ったイメージ通りに
作ればOKとはゆきません。
簡単なテキストスクリプトを作って現場で微調整できるように用意しておきます。
入力画面の要望聞きながら1ヶ月後には印刷部も出来上がります。
それで印刷させては客先で調整します。
 だいたいこれでコードは数千行です。

その後、色々細細と客の注文を聞いて便利機能を付け足します。
便利機能は手間がかかりますから、最初の状態から、だいたい2〜5倍のコードになります。
それは客の予算によってという事です
予算があれば最終的に数万行になるというだけです
0248246NGNG
だから数千から、MAX 1万行ぐらいの単位でモジュール分割して
(このモジュールはクラスではない。Javaならpackage相当)、
それを組み合わせて全体のプログラムを作るって感じかな。

「数千から、MAX 1万行ぐらいのモジュール」の外向けのインタフェースと、
それをどう組み合わせるかについては、さすがに文書化するけどさ。

0249デフォルトの名無しさんNGNG
まるでランボー(w

映画ではヒーローだけど
戦場ではちょと迷惑ね
0250デフォルトの名無しさんNGNG
>>246
数千行程度ならあたり前のゴミプログラムとか言ってるお前、
プログラム下手すぎだな。(ワラ
上手いコードほどコード量は少なくなるはずなんだが。
0251デフォルトの名無しさんNGNG
>>250
ちょっとしたスクリプト作れば簡単に数千行いくだろ
そうじゃないというなら見せて貰いたいもんだ。どうせ見せられないだろうがな(ワラ
0252デフォルトの名無しさんNGNG
普通にちょっとしたコントロール一つ書いても千行は必要だぞ
0253デフォルトの名無しさんNGNG
>>24の
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/lounge/file/1004530597_1/MyDraw.pas
このコードすごいな・・・コードものすごいというかさっぱり判らんけど走らせたら・・・
0254デフォルトの名無しさんNGNG
>>251>>252
そもそも何行かかるかなんて言語にもよるってのは置いといて、
そのちょっとしたスクリプトだかコントロールだかで
数千行かかってしまったという痴態をここで晒してみそ?
0255とあるダメ社員NGNG
>>246〜
どうもありがとうございます。

会計処理や事務処理分野は、私はよくわかっていませんので「定型的」と
言われてしまうと「そうなんですか」としか答えられませんが、「C/C++
なら、ヘッダファイルが十分「設計書」の役割を果たすと思う。」という
ような事が、本当にあり得るのか、わかりません。

246さんや247さんのやられている分野でも、試験の工程は必ず存在
しますよね。

設計書相当のものがなくて、どうして試験仕様が作れるのかという点と、
品質の確保をどのように行っていくのかがわかりません。

また、無理に再利用をしなくても良いとは思いますが、なんらかの修正
・機能追加を後日行わなければならなくなった時に、頼りになるのがソ
ースだけというのは、非常に効率が悪いと思いますが、OOの開発環境
では1万行にも及ぶプログラムでも大丈夫なのでしょうか?
0256John ◆0z.4Is5E NGNG
>ちょっとしたスクリプト作れば簡単に数千行いくだろ
Perlで数千行・・・悪夢
0257デフォルトの名無しさんNGNG
各自の“ちょっとした”の基準が統一されてないんだから、
話がかみ合わなくて当たり前。

2chでよく見る光景。
0258デフォルトの名無しさんNGNG
ちょっとしたスクリプトで数千行も書いてしまう馬鹿は
まずは構造化プログラミングから学習してください。
■ このスレッドは過去ログ倉庫に格納されています