トップページ⇒tech
981コメント292KB

ゲームプログラムなら俺に聞け30

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2014/01/05(日) 23:59:32.56
【前スレ】
ゲームプログラムなら俺に聞け28
http://toro.2ch.net/test/read.cgi/tech/1366526476/

次スレは>>950が立てること。
0153デフォルトの名無しさん2014/01/28(火) 16:45:53.35
>>146
何で多重スレッドにするかよく分からないんだけど、
マップとかキャラクターは毎フレーム描画してないの？
毎フレーム描画してるなら単一のスレッドで

マップ描画
キャラクター描画
if ( メッセージを描画しなきゃいけない ){　　　メッセージボックス描画
　　　メッセージ描画
}

とかじゃだめなのかね。
0154デフォルトの名無しさん2014/01/28(火) 19:39:06.70
どうも違和感があると思ったら、多重スレッドって
マルチスレッドの意味で使ってるよね？
多スレッドなら分かるけど、多重はないわ
0155デフォルトの名無しさん2014/01/28(火) 20:44:41.90
おまえの感覚なんでどうでもいい
0156デフォルトの名無しさん2014/01/28(火) 21:35:37.93
>>152 なるほど. 今スタックを使っていて、プレイヤーの入力時メッセージボックスをオブジェクト化して入れてますがやってみます。
>>153 キャラの描画はしていますが、毎フレームかどうかはすみませんが分かりません。表示はそんな感じで書いています。
>>154 そうです。”マルチスレッド”。
0157デフォルトの名無しさん2014/01/29(水) 01:16:08.82
パソコンの時代になってキーボードを打つことも多いですがタッチタイピングをきちんと学んで訓練する機会はなかったように思います。
私の場合は学生のときにレポートなどワープロ打ちする必要がありそうだったことからブラインドタッチの練習の本を買ってきて練習をしてある程度できるようになりました。
そのように個人的に練習する以外は我流でやっている人も多いと思います。
特定の指ばかり使うとどうしても効率が悪いですが一度癖が付いてしまうとなかなか直すのは難しいのではないでしょうか。
最近の学校教育ではもしかしてパソコンの授業もあるようなのでタッチタイピングもある程度学習して訓練の機会もあるのかもしれません。
お年寄りがパソコンが苦手といのはタッチタイピングのハードルもあるのではと思います。

http://toro.2ch.net/test/read.cgi/hp/1382021349/
http://toro.2ch.net/test/read.cgi/hp/1352858999/
0158デフォルトの名無しさん2014/01/29(水) 01:23:04.06
そうですね。
0159デフォルトの名無しさん2014/01/29(水) 03:57:45.47
特に理由がないなら別スレッドにしないほうが楽な気がするが。
処理の順番としては、

バックバッファのクリア
マップの描画
キャラクターの描画
メッセージの描画←別スレ
前面にコピー

でしょ？
当然、「メッセージの描画」の部分で同期とらないと正常に表示されないわけだ。
「メッセージの描画」の直前でメインスレッド止めて、別スレ使ってメッセージを描画して、
別スレを止めて、それからまたメインスレッドを動かす、って流れになるだろ。
シングルスレッドを分割しただけだからマルチスレッドの恩恵ないし面倒なだけだろ。

誰だよ別スレッドにしろって言った奴ｗ
オブジェクトにしろではなくスレッドにしろって言われたのか？
0160デフォルトの名無しさん2014/01/29(水) 07:16:57.42
まずOSのメッセージ処理とデータの読み込み処理はきちんとスレッドを分けないと、
ロード中に操作を受け付けないクソプログラムになる。
また、計算量の多い処理はスレッドを分けて負荷を分散しないと、
マルチコアを活用できない旧世代のプログラムになる。

つまりデータ量が少なく計算量が少ない小規模なプログラムしか作らない程度の人間だと、
必要性に気がつかないというだけの話。
0161デフォルトの名無しさん2014/01/29(水) 07:40:52.57
データ読み込みを非同期をすればいいだけだろ
0162デフォルトの名無しさん2014/01/29(水) 07:52:58.42
データの読み込みはI/O処理だけじゃ無いからな。
展開して利用可能にする計算もあるんだよ。
これだからまともにプログラムを作ったことが無い奴は。
0163デフォルトの名無しさん2014/01/29(水) 08:01:38.66
なんか必死だけど「展開して利用可能にする計算」なんて
読み込みに比べればまったく気にならない場面が多い。
初心者にやらせようとするセンスこそ初心者。
0164デフォルトの名無しさん2014/01/29(水) 08:04:26.53
デッドロックやメモリコヒーレンスをちゃんと扱える人間なんてそういない。
>>160とかマトモにできるように思えないけどな。
0165デフォルトの名無しさん2014/01/29(水) 08:05:26.41
ルナティックドーンやシムシティ、マインクラフトもビックリな超絶ゲームを作りたいんだろ
まあ頑張れや
0166デフォルトの名無しさん2014/01/29(水) 08:50:18.93
超絶ゲーム君は、JAVAでは珍しいメモリー関連のバグをどうにも出来なくて諦めると思う
0167デフォルトの名無しさん2014/01/29(水) 09:05:19.80
>>160
もう一度、>>146の文章を読み直したほうがいいよ
とんでもないあさっての回答していることに気づくから。
0168デフォルトの名無しさん2014/01/29(水) 09:29:10.86
俺マルチスレッドのコード書いたことあるんだぜって言いたいだけでしょ
書かなくてもいいところにスレッド使って原因不明のバグ誘発するってよくある
0169デフォルトの名無しさん2014/01/29(水) 20:06:52.82
>>159
そうです。そんな感じのを実装しようといます。
オブジェクトでは無かったと思います。
マルチスレッドにしたほうが良い理由は多分自分のコードのせい？だと思うのですが。
0170デフォルトの名無しさん2014/01/29(水) 20:32:41.26
>>169
マルチスレッドにした方がいいように思えるなら設計がおかしい。
最初から見直すべきだと思う。
0171デフォルトの名無しさん2014/01/29(水) 20:47:33.29
>>168
原因の分かるバグになら遭遇したことはあるが、
原因不明のバグなど起こったことは無い。

原因不明とか言うのは単純に無能なだけだよ。
0172デフォルトの名無しさん2014/01/29(水) 20:53:26.67
いいね経験浅くて責任ない奴は
0173デフォルトの名無しさん2014/01/29(水) 20:57:14.40
初心者にスレッドデバッグやメモリコヒーレンスの難しさも語れない奴が
他人を無能呼ばわりしてもねｗ
0174デフォルトの名無しさん2014/01/29(水) 21:17:32.94
バグを原因不明のままにする馬鹿が何を言ったところで説得力が無いよ。
原因不明だよ、原因不明。
笑うところなのか？
0175デフォルトの名無しさん2014/01/29(水) 21:40:40.11
いやいや自称天才様にはかないませんわ
0176デフォルトの名無しさん2014/01/29(水) 22:07:43.40
マルチスレッドが原因かは分からんが、数日間連続で動かしたときにたまに発生するバグとかは
期間内に追いきれなくて原因不明のままになったことがあるな
まぁ軽微なバグだから真剣に調べてないってのもあるけど
0177デフォルトの名無しさん2014/01/29(水) 22:23:51.15
OSの不具合、端末の不具合などで
一般開発者には、ほとんど発見不能なバグって稀にあるんだがな。
stackoverflowとかでいまだ未解決の問題あるし
0178デフォルトの名無しさん2014/01/29(水) 22:30:21.27
マルチスレッドを使って起こった原因不明のバグって具体的に何？
原因が分からなくても、やろうとしたことと症状ぐらいは言えるよね。
0179デフォルトの名無しさん2014/01/29(水) 22:32:43.90
>>177
OSの不具合と分かっている時点で、原因不明では無い。
0180デフォルトの名無しさん2014/01/29(水) 22:35:08.74
>>179
不具合と分かるまでは、ずっと原因不明だろ
何をいってるんだよ
0181デフォルトの名無しさん2014/01/29(水) 22:38:19.06
まあマルチスレッドの場合、デバッガで追うのが非常に難しくなるからな
そういう意味では原因究明に手間がかかるってものだ
0182デフォルトの名無しさん2014/01/29(水) 22:51:48.01
>>170
設計ですか。
クラス図も作成せず、java勉強の為にしているので設計などはしてないのでやってみます。
それでは、このドラクエなどの買い物表示はマルチスレッドではなく一つのスレッドで処理可能な事なのでしょうか？
0183デフォルトの名無しさん2014/01/29(水) 22:56:55.61
なんであってもシングルスレッドで実現できないことはないだろ。
流れはしらないが。
マルチスレッドはバグ取りが困難になるからとりあえず作ってからパフォーマンスで不利な点だけ改良したらいい。
0184デフォルトの名無しさん2014/01/29(水) 22:59:24.97
なぜマルチスレッドにするのか、動機があいまいなほど
デバッグがわけわかんなくなっていく
0185デフォルトの名無しさん2014/01/29(水) 23:02:00.14
マルチスレッドは裏で処理を流したほうがユーザビリティが格段とＵＰする場合にのみ使うべきで
それ以外はシングルよりバグをはらむ可能性が高い上、メンテが大変なので避けるべき。

ドラクエのメッセージウインドウくらいでスレッド起こすなんて聞いたことがない
メッセージを表示しながら裏側で頻繁にネット接続でもするなら話は別。
0186デフォルトの名無しさん2014/01/29(水) 23:05:57.58
>>182
十分可能だし、むしろシングルスレッドでやったほうがいい。
0187デフォルトの名無しさん2014/01/29(水) 23:06:43.35
>>180
不具合と分かったのなら原因不明では無いだろう。
お前こそ何を言っているんだ？
0188デフォルトの名無しさん2014/01/29(水) 23:08:19.82
で、マルチスレッドを使って起こった原因不明のバグって具体的に何？
逃げ回らずに答えろよ。
もう一度言う、逃げるなよ。
絶対に逃げるなよ。
0189デフォルトの名無しさん2014/01/29(水) 23:12:45.29
>>182
これ読んで完全に理解できるようならマルチスレッドにするがいい
ざっくりしか分からないようならシングルスレッドにしたほうがいい
ttp://game.watch.impress.co.jp/docs/20070131/3dlp.htm
0190デフォルトの名無しさん2014/01/29(水) 23:13:28.43
無能だからマルチスレッドを避けるというのは、悪い判断では無い。
それによって操作性が低下したり、効率が落ちたりしても、
不具合を出すよりはマシだ。
自分の力量をよく分かっている適切な判断だ。
0191デフォルトの名無しさん2014/01/29(水) 23:16:27.45
ゲームプログラミング界の巨人、Tim Sweeneyが「未来のゲーム開発テクノロジー」を語る
http://game.watch.impress.co.jp/docs/20080911/epic.htm

しかし、現状でさえマルチスレッドプログラミングは開発の困難さが指摘されている分野である。
同時並列的に動作するプログラムがモデルデータやゲーム内状態などの共有情報にアクセスしようとするとき、
そこには必ずデータ競合によるバグの発生や、デッドロックによるプログラムの停止というリスクがつきものである。
しかも、それを効率的にデバッグすることは非常に難しく、開発規模の拡大や期間の長大化を招いているのだ。

Sweeney氏は、これは現在主流の開発言語であるC++の手続き型言語としての特性に由来すると指摘する。
マルチスレッドにおける問題を避けるためのテクニックは各種あるが、Sweeney氏に言わせるとそれは「シングルスレッドのプログラムをアセンブラで書くようなもの」であり、生産性が悪いのである。

Sweeney氏は、この問題を解決するためには、ゲーム開発言語として純粋関数型の言語が必要になるだろうと言う。
純粋関数型言語とは、プログラム中の関数が、戻り値のみによって作用する構造の処理系だ。
この種の処理系では、C++のような共有メモリのアクセスや、I/O操作は基本的に行なえない。
その引き替えとして、各関数のアトミック性が構造的に保証されており、安全に並列実行できるのだ。
しかも、コンパイラが対応さえすれば、関数を自動的に多数のコアに分散処理させることができるというスケーラブルな実行バイナリを作り出せる。

Sweeney氏は純粋関数型言語のもつ並列処理安全性に着目しており、将来的にゲームプログラミングはそういった処理系に移行していくべきだとした。
Sweeney氏はそのひな形として言語“Haskel”を挙げているが、ゲーム開発のメインストリームたり得る言語はまだ登場しておらず、将来に期待しているという。
0192デフォルトの名無しさん2014/01/29(水) 23:17:58.83
メモリコヒーレンス・デッドロック等キーワードが上がってるのに
ピンと来ない時点で話にならないだろ。
たとえばひらしょー本でもマルチスレッドは人智を超えている旨の
記載があったはずだがひらしょーも無能ってことでいいのかな？
0193デフォルトの名無しさん2014/01/29(水) 23:20:06.05
>>191のように開発のプロでも難しい。
想定外が起こる。直したと思っても別の想定外が起こるとかなり得る。
まずはシングルスレッドで。
0194デフォルトの名無しさん2014/01/29(水) 23:24:00.05
>>187
おまえは相当頭が固いな
0195デフォルトの名無しさん2014/01/29(水) 23:27:51.75
具体的に難しさを指摘する記事はすぐに見つかるが
お前は俺にはできるできない奴は無能としか言ってないな。
0196デフォルトの名無しさん2014/01/29(水) 23:31:30.06
>>190の言う通りだ。
無能だと挑発されて使えもしないものを使って失敗するのは救いようのない無能。

ゲームも作ったことのない人間がいきなりマルチスレッドを使ってゲームを作るってのは〇〇したことのない人間がいきなり□□するようなもの。
まさに自殺行為。

良い例えが思い浮かばなかったからまかせた↓
0197デフォルトの名無しさん2014/01/29(水) 23:32:43.02
純粋関数型のスレッドに自動対応する実用的コンパイラを開発するのがいい。
いまだない。
シングルでもマルチでも同一コードで効率的に動く。
0198デフォルトの名無しさん2014/01/29(水) 23:37:42.25
原因不明の不具合に遭遇したことがないと言い切るプログラマーは信用できない
0199デフォルトの名無しさん2014/01/29(水) 23:43:03.38
射精したことない人間がいきなり性交するようなもの。
0200デフォルトの名無しさん2014/01/29(水) 23:46:27.90
原因不明なのに具体的に言えって結構無茶ぶりだよな

原因不明じゃないが、排他制御が抜けてる箇所があってたまーにメモリ破壊を起こしてたのは
特定に時間がかかったな
0201デフォルトの名無しさん2014/01/29(水) 23:52:34.62
Xbox 360 と Microsoft Windows でのロックレス プログラミングの考慮事項
ソフトウェア デザイン エンジニア、Bruce Dawson 著
ロックレス プログラミングとは、刻々と変化するデータを、ロックの取得や解放といったコストを伴うことなく、複数のスレッド間で安全に共有するための方法です。
ロックレス プログラミングには、複雑かつ難解であり、ときには思ったほどの効果が得られない場合もあります。
ロックレス プログラミングは、Xbox 360 では特に複雑です。
ロックレス プログラミングは、マルチ スレッド プログラミングにおいて有効なテクニックですが、安易に使用するべきではありません。
ロックレス プログラミングを使用する前に、必ずさまざまな問題点を理解した上で、期待する効果を得られるかどうかについて慎重に検討を行ってください。
http://msdn.microsoft.com/ja-jp/library/bb310595(v=vs.85).aspx



開発メモ: アトミック演算の性能
GCC拡張のロックフリーなアトミック演算機能と、自分でロックしてアトミックに演算するのとではどれくらい違うかを実験してみた。
まとめ
ロックフリーなアトミック演算が可能であれば使うべきだ。Mutexよりは3倍くらい効率的だし、SpinLockのように並列度が上がると遅くなるようなことはない。
ちなみになんでこれを急に調べたかというと、tmaesaka氏が彼のBlitzDBの実装をDrizzleコミュニティの人に見せたところアトミック演算を使えと言われたというのを横から見ていて、
KCでも使えそうだなと思ったからだ。こんな他愛もないやりとりからもDrizzleコミュニティの並列性への情熱が伝わってくるわけで、Drizzleへの期待がさらに膨らむ今日この頃である。
http://fallabs.com/blog-ja/promenade.cgi?id=68
0202デフォルトの名無しさん2014/01/30(木) 03:22:58.29
マルチスレッドはモルピグの通信にしか使ったことがない。
0203デフォルトの名無しさん2014/01/30(木) 07:11:22.73
>>200
何をやろうとしたかと、症状すら言えないって、
もうプログラムをやるってレベルじゃ無い。

結局、自分で具体例を出せずに逃げ回ってるよね。
あまりにも予想通り。
まあ無能だから逃げるしか無いよね。
本当に操り人形のように、想定通りの行動をとる。
0204デフォルトの名無しさん2014/01/30(木) 07:19:32.57
オマイラ、気に入らない態度の相手だから解答を教えないつもりか？
俺？気が変わったら教える
0205デフォルトの名無しさん2014/01/30(木) 08:00:20.33
俺は良質なエロ画像くれたら教える
0206デフォルトの名無しさん2014/01/30(木) 08:50:28.01
無能連呼君痛すぎ
0207デフォルトの名無しさん2014/01/30(木) 08:55:20.06
具体例って何を期待してんの？
原因不明のバグの原因教えてって頭悪いの？
デットロックやメモリコヒーレンスでおこる不具合もわからないないの？
0208デフォルトの名無しさん2014/01/30(木) 09:55:24.56
「(ゲームタイトル)を作ってたら、(機能)で使っている変数がまれに不正な値になったが、原因を特定できなかった」とか
そういうことが聞きたいんだろうけど
具体的に何を作ってたか言う人はいないだろうし、まぁレッテル貼って誤魔化したいだけなんだろうけど
0209デフォルトの名無しさん2014/01/30(木) 10:14:11.84
タイトルとかは要らないから、変数が稀に不正な値に書きかわったのか
どうかだけでも答えればいいんじゃない？
もしそうなら変数のスコープも知りたいけど
0210デフォルトの名無しさん2014/01/30(木) 12:10:18.53
C/C++だと配列の外側にアクセスしたせいで無関係のデータぶっ壊すとかは稀になくはないが、多分そういう話ではないんよね？
0211デフォルトの名無しさん2014/01/30(木) 12:14:39.72
無能連呼君が一番原因不明だわ
0212デフォルトの名無しさん2014/01/30(木) 12:34:49.92
お後がよろしいようで
0213デフォルトの名無しさん2014/01/30(木) 12:52:48.14
うまくないよ
0214デフォルトの名無しさん2014/01/30(木) 18:28:19.16
具体的に君には何を言ってあげれば満足なのか？ｗ
0215デフォルトの名無しさん2014/01/30(木) 19:57:54.40
原因を特定して、完璧な対策を打って……ってやりたいのは勿論だけど、マルチスレッドだとその特定に時間がかかるんだよね。
だったら対症療法で、「バグの原因になる行動」だけを突き止めてそれを避けさせる方がトータルコストは安かったりする。
そりゃ時間が無限にあって、完璧なプログラムを書けるのであればバグの原因は特定できるし潰せるけど。
0216デフォルトの名無しさん2014/01/30(木) 20:37:48.65
マルチスレッドにするメリットなんてないんだよ結局
将棋ソフトじゃあるまいし
0217デフォルトの名無しさん2014/01/30(木) 20:56:15.59
・明らかにCPUを使ってないのにデバイス待ちしているような関数を呼ぶ
・極限までパフォーマンスを引き出すために小さなジョブを大量に実行する

これ以外はシングルスレッドで動くように書くべき。
0218デフォルトの名無しさん2014/01/30(木) 21:51:12.59
プログレスバーとキャンセルボタンの実装は
スレッドプログラミングの代表的なものじゃね？
0219デフォルトの名無しさん2014/01/30(木) 21:59:38.40
プログレスバーとキャンセルボタンをスレッド管理するんじゃなくて
その対象を非同期化するんだよ。
0220デフォルトの名無しさん2014/01/30(木) 22:28:39.96
メインで動いている処理（画面）上にロード用のプログレスダイアログ表示する場合に
メインで動いているほうを非同期にしろってこと？
0221デフォルトの名無しさん2014/01/30(木) 22:31:21.03
メインで動いてるのが画面なんだったらメインループ回ってるんだろうから
スレッドである必要ないだろ・・・
0222デフォルトの名無しさん2014/01/30(木) 22:37:25.91
>>216
でもPCでもゲーム専用機でもCPUコアは増える一方だから、そこそこの規模のゲームは
イヤでも使わなきゃいけない状況になってきてる

まぁ趣味ならそんな規模にはそうそうならないと思うけど
0223デフォルトの名無しさん2014/01/30(木) 22:39:36.84
>>219
いや、もちろんそういう意味でいったのだが・・・
0224デフォルトの名無しさん2014/01/30(木) 22:40:42.47
必要なのはゲームのコア部分だけ。
メニューなんかでバグ出してたらクビだよ。
スクリプトでいいくらい。
0225デフォルトの名無しさん2014/01/30(木) 22:55:37.24
>>185, 186, 193, 217
わかりました。もう一回シングルスレッドで頑張ってみようと思います。
けど、「もっとこういう風にしたらいいぞ」ってな意見が出来れば欲しいのですが、ソースコードのアドレス貼っていいでしょうか？
0226デフォルトの名無しさん2014/01/30(木) 23:13:14.35
どうぞ
0227デフォルトの名無しさん2014/01/31(金) 00:52:54.81
ありがとうございます。遅れましたがこれです。忍法帖デアドレスが打てません。
pastebin.com/u/nekoNeko
で先頭にハイパーテキストのプロトコルなどお願いします。
0228デフォルトの名無しさん2014/01/31(金) 05:41:29.04
このスレにいる人の宗派

シングルスレッド派
マルチスレッド派
固定fps派
非固定fps派
タスクシステム派
営利企業の現場を前提に考える派
趣味を前提に考える派
0229デフォルトの名無しさん2014/01/31(金) 07:17:52.09
ハイスペック派
ロースペック派
0230デフォルトの名無しさん2014/01/31(金) 07:24:06.98
罵倒派
スルー派
0231デフォルトの名無しさん2014/01/31(金) 07:24:16.19
ドット絵派
ローポリ派
リアルポリゴン派
イラスト派
こうなると絵師さんを巻き込んだ論戦に……
0232デフォルトの名無しさん2014/01/31(金) 07:25:39.54
二枚歯
三枚歯
電動派
0233デフォルトの名無しさん2014/01/31(金) 07:26:32.08
はぐれ刑事
純情派
0234デフォルトの名無しさん2014/01/31(金) 07:37:56.33
お後がよろしいようで
0235デフォルトの名無しさん2014/01/31(金) 08:00:47.09
>>231
何故そこにアニメシェーダ派が無い？
0236デフォルトの名無しさん2014/01/31(金) 08:19:21.48
あの頃は、派
0237デフォルトの名無しさん2014/01/31(金) 08:55:36.38
3DCG派は面倒だなぁ
0238デフォルトの名無しさん2014/01/31(金) 15:47:03.54
僕はボールに顔付けたキャラ派です
0239デフォルトの名無しさん2014/01/31(金) 16:11:46.43
少なくとも自分が最初から全部書いてるコードで原因不明とか陥ったこと無いな
全部解決してきた

ある日突然HDDが死ぬとかは原因不明だけどな
0240デフォルトの名無しさん2014/01/31(金) 16:29:29.61
>>198
0241デフォルトの名無しさん2014/01/31(金) 18:31:40.90
DOS時代にHDDのBIOS層に画像データを書き込んだ事ならあるな
物理フォーマットをする以外に復帰出来なくなった
0242デフォルトの名無しさん2014/01/31(金) 18:35:26.92
ゲームじゃないけど
デバイスドライバとか「原因不明」のままになってるのあるよね
0243デフォルトの名無しさん2014/01/31(金) 18:39:21.23
客の言いがかり　を遠回しにそういってるんだよ
0244デフォルトの名無しさん2014/01/31(金) 18:40:30.80
ドライバー更新されても直らないデバイス結構あるんだけど
まあ、たしかに客の言いがかりもあるのは事実だな
0245デフォルトの名無しさん2014/01/31(金) 21:09:14.31
原因不明って、調べるの諦めたって事だろ
どうせそいつロクなコード書いてないし技術もない
原因調べられるかどうかは、どこまでトレースできるかにかかってる
まぁC++とかで原因不明なバグ起こったら、俺もやんないけどそういうのと縁ないし
0246デフォルトの名無しさん2014/01/31(金) 21:10:44.94
なぜにc++なんだよ
0247デフォルトの名無しさん2014/01/31(金) 21:11:43.84
245にも辛い過去があったんだろう、触れてやるな
0248デフォルトの名無しさん2014/01/31(金) 21:19:59.79
このスレってC++がメインなんじゃ？
どちらにしろ原因不明っていう妥協は精神衛生上あり得ない
0249デフォルトの名無しさん2014/01/31(金) 21:27:27.04
理性的に解決に当たればすべて(時間内に)解決するはずという淡い期待は
経験の浅い責任の軽い立場に起因している。
0250デフォルトの名無しさん2014/01/31(金) 21:39:25.60
いや･･･原因調べられないのは経験の無さとスキルの低さに起因してるよ
言い訳があまりに幼稚ですな
0251デフォルトの名無しさん2014/01/31(金) 21:40:52.45
1万行を越すコードとか見たことも無いんだろうな、きっと。
0252デフォルトの名無しさん2014/01/31(金) 21:41:04.23
いやいや天才さんにはかないませんな
■ このスレッドは過去ログ倉庫に格納されています