09/04/04 22:41:09 DtrzgWRJ
>>14
その話とタスクシステムはどう結びつくの？
スレ違いじゃない？
もちろんタスクシステムのメリットとの話ともリンクしてるんだろうな？
16:名前は開発中のものです。
09/04/04 23:57:30 MhD49aWD
頭悪いんだから放っておいてやれよ
17:名前は開発中のものです。
09/04/05 01:47:17 A6XSNxaW
>>12
R&Dがあるような会社はタスクシステムも気にする必要無いんじゃね？
18:並列さん ◆dPfetnROQg
09/04/05 03:23:57 KXq+7Jyb
>>15
俺は14ではないが、メモリのコンパクションを行なうには、それぞれのオブジェクトに対するstd::listのようなものが
必要になるので、(典型的な)タスクシステムに搭載されているstd::listのようなものをそのまま流用すれば一石二鳥だから、
タスクシステムはメモリのコンパクションまで行なうように拡張しておけば、タスクシステムのフレームワークとしての
利用価値がさらにあがるという風にタスクシステムとメモリのコンパクションとは密接に関係している。
まあ、このスレのアンチタスク派は、まともな規模のゲームプログラムなんて作ったことなさそうだから、
メモリのコンパクションなんてやる必要性すら理解してないんだろうけども。
19:名前は開発中のものです。
09/04/05 04:03:20 SofMJMSf
なら、テクスチャや音声や、その他mallocやnewするもの全部をタスクとして実装するの？
頭おかしいんじゃない？大丈夫？
20:名前は開発中のものです。
09/04/05 04:14:18 XP6NPTaD
16bit機から現行機までコンシューマ機で動的にメモリコンパクションしてるのなんて見たこと無いな。
馬鹿でかい連続領域を確保するものと、パーティクルみたいに小さい固定領域を大量に確保するもの
だけを別扱いに管理する、ぐらいでやりくりできてたし。
そんなの必要になるのサーバー側とかだけじゃない？
21:名前は開発中のものです。
09/04/05 04:43:57 SofMJMSf
サーバーにはMMUついてるだろ。
22:並列さん ◆dPfetnROQg
09/04/05 04:57:03 KXq+7Jyb
>>19
> なら、テクスチャや音声や、その他mallocやnewするもの全部をタスクとして実装するの？
そんなことは誰も言ってない。
そもそもテクスチャやサウンドのような巨大なresourceにとって必要なのはメモリのコンパクションではなく、
(cacheのような仕組みを提供する)マネージメントだろ。
それはcacheを実現するためのシステムを別で用意する。
それ以外でmallocやnewを使うかだが、ゲームによっては、タスクオブジェクトとテクスチャ/サウンド等の
巨大リソース以外ではmalloc/newでのメモリ確保は不要なことが多いので、そういう作りをここでは俺は
想定している。
23:並列さん ◆dPfetnROQg
09/04/05 04:59:24 KXq+7Jyb
>>20
> 16bit機から現行機までコンシューマ機で動的にメモリコンパクションしてるのなんて見たこと無いな。
その"現行機"にXNA環境は含まれてないの？
24:名前は開発中のものです。
09/04/05 05:02:06 XP6NPTaD
MMUの有無だけでいえばMSハードはMMUついてるよ。メモリスワッピングしないだけで。
そしてサーバー側はメーカーによるけど意外とチープな民生用32bit Linuxマシンを使ってたり
するので4Gの壁でMMUとは別の理由でメモリコンパクションが必要になったり。
クライアント側はメーカーのエージングチェック通る時間動けばいいけど、サーバー側は連続稼働時間
長いからねぇ
>>23
>その"現行機"にXNA環境は含まれてないの？
含まれてます。がネイティブじゃなくXNAで動いてるゲームはまだサンプル以外見たことが無いな。
25:名前は開発中のものです。
09/04/05 05:08:36 SofMJMSf
>>22
では、タスクにだけメモリコンパクションかけるつもり？意味無くない？
どっちにしろ頭沸いてるとしか思えないのだが。
26:並列さん ◆dPfetnROQg
09/04/05 05:26:56 KXq+7Jyb
>>25
> では、タスクにだけメモリコンパクションかけるつもり？意味無くない？
メモリのコンパクションを行なうことで、CPU cacheに載りやすくなるし、
タスクに対してtraverseするときになるべくメモリをリニアにアクセスできるようになっていれば
プリフェッチした分が無駄にならないから、そこでも効果があがる。
計測してみればすぐにわかると思うが。
27:名前は開発中のものです。
09/04/05 05:31:54 w7j54ekv
>>25
同意
もうなにいってるのかさっぱりわからない
っていうか馬鹿黙れよって感じ
28:名前は開発中のものです。
09/04/05 05:41:29 SofMJMSf
現実問題として、リニアにアクセスなんて出来ないし、意味ないね。
29:並列さん ◆dPfetnROQg
09/04/05 05:46:00 KXq+7Jyb
>>27
馬鹿はお前
>>28
> 現実問題として、リニアにアクセスなんて出来ない
出来る。
典型的なタスクシステムならタスクプライオリティを持っているので、
コンパクションのときにメモリ上でタスクプライオリティ順に並ぶように配置しなおしてやれば
タスクに対してtraverseする効率があがる。
30:名前は開発中のものです。
09/04/05 05:50:57 SofMJMSf
どうせタスクの中で他のタスクにアクセスするだろうし、
そんなところをちまちま最適化しても意味無いって。
どうせ他のところが重いから。
31:名前は開発中のものです。
09/04/05 06:04:17 SofMJMSf
だいたい、市販ゲームでも、メモリコンパクションしているゲームってそんなに無いだろ。
やってる奴あっても、メモリ制限が厳しいから仕方なく導入しているってだけで、
速度向上を狙ったものは聞いたことが無い。
32:並列さん ◆dPfetnROQg
09/04/05 06:14:40 KXq+7Jyb
>>30
> そんなところをちまちま最適化しても意味無いって。
そんなことないよ。
最近のプロセッサになればなるほどDRAMが(CPUに較べて)相対的に遅く、
扱うオブジェクトの数が多いとプリフェッチ出来ているのと出来てないのとでは大違いなんだが。
「他のタスクにアクセスする」部分にしても、シューティングで自機と弾との衝突判定をするなら
弾オブジェクトはメモリ上でリニアに並んでいるほうがアクセス効率が良いのは自明。
33:並列さん ◆dPfetnROQg
09/04/05 06:19:31 KXq+7Jyb
>>31
> やってる奴あっても、メモリ制限が厳しいから仕方なく導入しているってだけで、
あんた何もわかってないね。
近代的な言語が、GCを搭載するのはメモリ制限を回避するためだけかい？違うだろ。
34:名前は開発中のものです。
09/04/05 06:35:18 SofMJMSf
何も分かってないのはお前だって。
タスクシステムのタスクのコンパクションによるキャッシュヒット率の向上が有効になるのは、
小さなタスクが何万も有る場合だが、
タスクシステムの特性から、updateが仮想関数になる以上、
やってる事がチグハグなんだよ。
ストーブつけながらクーラーつけてるみたいなものだな。
35:名前は開発中のものです。
09/04/05 06:36:15 XP6NPTaD
DRAMメモリアクセス速度みたいなハード寄りな理由で近代的なGC搭載言語の話をするのは何かずれてるような…
36:並列さん ◆dPfetnROQg
09/04/05 06:59:38 KXq+7Jyb
>>34
> タスクシステムの特性から、updateが仮想関数になる以上、
そうとは限らない。
>>35
ずれてない。あんたもGCが何のためにあるのか理解してなさそう。
37:名前は開発中のものです。
09/04/05 09:37:40 w7j54ekv
並列さん黙れよ
あんた自分がなにやってるかさっぱりわかってないじゃん
38:名前は開発中のものです。
09/04/05 11:11:35 3oSTBu7p
＞タスクシステムの特性から、updateが仮想関数になる以上、
･･･ﾊｧ????
39:名前は開発中のものです。
09/04/05 14:46:01 ZnQmmsrk
並列さんは、updateのなかで型を見ながらswitchするつもりなんじゃね？
40:名前は開発中のものです。
09/04/05 15:41:58 MilQiQIm
久しぶりに来たら次スレ建ってて笑った。
相変わらずタスクじゃない話題で賑わっているね。
メモリコンパクション実装する前に他にやることあるんじゃねぇの～
41:並列さん ◆dPfetnROQg
09/04/05 18:18:06 KXq+7Jyb
>>37
あんたがわかってないだけ。内容についてこれないなら、黙れ。
>>39
そんなへたれなコードはさすがに書かない。
template typename<T> update(T& actor);
こういうtemplateを用意して、これが呼び出される。(以下略)
>>40
> メモリコンパクション実装する前に他にやることあるんじゃねぇの～
他にやることはやってあるという前提で話している。
また>18で書いたようにこれはタスクと関係ない話題ではない。
42:並列さん ◆dPfetnROQg
09/04/05 18:25:43 KXq+7Jyb
戻り値の型を書き忘れた。こう。
template typename<T> void update(T& actor);
で、型ごとに特殊化されたupdateを用意する。
言うまでもなく、updateはcollectionに対しても定義されてて
template typename<T> void update(const collection<T*>& actors)
{
foreach(var t in actors)
update(*t);
}
collectionはstd::vector/listを汎化したもの。foreachはマクロとでも思ってもらえれば良い。
上のようになっているので、最適化によってinliningされる。
もちろん、関数呼び出しのオーバーヘッドは存在しない。
43:名前は開発中のものです。
09/04/05 18:25:46 MilQiQIm
>>41
1点だけ知りたいのだが、並列さんはタスクシステムをメモリコンパクション仕様で書いて実装し、実際に運用したことがあるのかい？
必然的に粒度の大きくてしかもタスク切り替えの少ない場合のみのタスクしか適用できないとおもうのだが。正気の沙汰とは思えない。
44:名前は開発中のものです。
09/04/05 19:25:11 ZnQmmsrk
>42
> もちろん、関数呼び出しのオーバーヘッドは存在しない。
全てのTに対して同じupdateが呼び出されるけどな。
45:並列さん ◆dPfetnROQg
09/04/05 20:48:32 KXq+7Jyb
>>43
> 1点だけ知りたいのだが、並列さんはタスクシステムをメモリコンパクション仕様で書いて実装し、実際に運用したことがあるのかい？
もちろんだよ。ある大手の商用ゲームで使ってるよ。
> 必然的に粒度の大きくて
逆だよ。GC環境は粒度の小さいオブジェクトを大量に
newしたりdeleteしたりするのに適している。
それは、GC環境下ならnewの実装が単純化されるので
通常のheap allocとは比べものにならないほど高速だから。
>>44
もちろん。update(const collection<T*>& actors)の呼び出し側で
もうひと工夫してある。あんたなら、みなまで言わずともわかるだろ。
46:名前は開発中のものです。
09/04/05 22:29:45 qdg6blW7
テクスチャとか、でかい連続領域が欲しいときにメモリコンパクションしたくなるのは
まぁわからんでもないんだけど、 new/delete する C++ オブジェクトの話だったの？
そうなるとまるで必要性がわからん。
だれか並列さんの話についていけてる人がいるのか？
47:名前は開発中のものです。
09/04/05 22:43:11 ZnQmmsrk
>45
あぁ、switch～caseじゃダメっぽいから、関数テーブルにでも変更してみたか？
48:並列さん ◆dPfetnROQg
09/04/05 22:44:01 KXq+7Jyb
>>46
> そうなるとまるで必要性がわからん。
"必要"なのではない。誰もそんなことは言っていない。
GCがあったほうが設計が楽になるというのと、
メモリのコンパクション(とオブジェクトの並び替え)を行なったほうが
メモリアクセスの効率が上がる(>>26 >>29 >>32)と俺は言っている。
49:名前は開発中のものです。
09/04/05 22:45:59 XP6NPTaD
>>45
>それは、GC環境下ならnewの実装が単純化されるので
”GC環境”ってひとくちにいっても”タスクシステム”並に千差万別だけど…
どんな前提のGC環境なら、GC環境を構築したC/C++よりもheap allocが高速になるのか、教えて欲しいなぁ
スレッドを使わないスクリプト系言語で、同期処理が不要だから、とかheap独自管理だから、とかか？
それならスレッド使わない、heap独自管理したC/C++系の方が高速になりそうだが。
50:名前は開発中のものです。
09/04/05 22:48:37 SofMJMSf
>>42
それだったら、ただのstd::vectorと同じじゃん。
自分でも書いてるけど、本当ただのcollectionでしかなく、どのあたりを工夫しているのかも不明。
そのレベルのコンパクションでよいのなら、std::vectorでもしてくれる。
個人的には、タスクシステムにメモリ管理までさせている時点で糞だな。
タスクを何処にどういう風に確保するかは、タスクシステムの利用者が決めれるようにしておいた方が良い。
どういうメモリ配置にすべきかはケースバイケースで、
ベストな配置はゲームの仕様を知ってるであろうタスクシステムの利用者にしか分からない。
逆に言えば、タスクシステム内で、変なメモリ管理なんてしようとするから、
メモリコンパクションなんていう、どうでも良いことを考えなきゃいけなくなる。
ゲームの仕様も分からないのに、適切なデータ配置が出来るわけが無い。
まぁ、そうやって自分の権力の範囲を伸ばすことで、食いっぱぐれないようにしてるんだろうけどな。
老害というやつだな。
51:名前は開発中のものです。
09/04/05 22:51:31 SofMJMSf
もう一度いうが、キャッシュヒット率まで考えてデータの配置をするというのなら、
タスクシステムに勝手にデータを並べ替えられるのは迷惑だ。
タスクシステムはゲームの仕様を知らないからな。
52:名前は開発中のものです。
09/04/05 22:54:56 qdg6blW7
"Premature optimization is the root of all evil" ってやつだな。
こういう話してると、また「言うまでもなく、この最適化を行うかどうかはユーザーが
選択できるようになっている」とか返ってきそうだけど。
53:並列さん ◆dPfetnROQg
09/04/05 22:55:09 KXq+7Jyb
>>47
> 関数テーブルにでも変更してみたか？
関数テーブルがどういうコードを指してるのか意味不明なんだが。
もしかして
var function_table = [ update<collection<TekiTask*> > , update<collection<TamaTask*> > , update<collection<JikiTask*> > ];
みたいなものを用意する話か？それなら、テーブルではなしに、
TekiTask* → update<collection<TekiTask*> >
のようなhashこそが必要だろう。
「タスクの型Tからupdate<collection<T*> >へのhashを用意してあるのか？」と尋ねるのなら、
「そういう実装でもいいけどね」と答えるが、「update<collection<T*> >の関数テーブルを用意するのか？」と
いう質問なら、「そんな馬鹿な実装にはするはずがない」と答えるよ。
54:名前は開発中のものです。
09/04/05 22:57:12 SofMJMSf
>template typename<T> void update(T& actor);
はインライン関数で書いても同じなのに、いちいちテンプレート使うのはコンパイラへの嫌がらせか。
わざわざテンプレートでかく意図が分からない。
コンパイラによるのかもしれんが。
55:名前は開発中のものです。
09/04/05 23:04:40 qdg6blW7
>>53
メモリアクセスの最適化が要るループの中でインスタンス単品のアドレスをキーにした
ハッシュテーブルをひくのが「いいけどね」なの？もうわけわからん。
56:並列さん ◆dPfetnROQg
09/04/05 23:07:06 KXq+7Jyb
>>49
> どんな前提のGC環境なら、GC環境を構築したC/C++よりもheap allocが
> 高速になるのか、教えて欲しいなぁ
日本語が意味不明。
俺は、>>45 では、GC環境なら、C/C++のheap allocより高速なnewの実装が可能に
なることは言ったが、「GC環境を構築したC/C++よりも」だなんて一言も言ってない。
>>50
> そのレベルのコンパクションでよいのなら、std::vectorでもしてくれる。
これも意味不明。
std::vector<XXXTask>のようなものを用意して、XXXTask型のオブジェクトは
全部そこに突っ込む(push_back)するつもりか？
> ゲームの仕様も分からないのに、適切なデータ配置が出来るわけが無い。
その理屈はおかしい。
あんたはゲームの仕様が決まるまでnewやdeleteの実装をしないつもりか？
57:並列さん ◆dPfetnROQg
09/04/05 23:20:19 KXq+7Jyb
>>55
> メモリアクセスの最適化が要るループの中でインスタンス単品のアドレスをキーにした
> ハッシュテーブルをひくのが「いいけどね」なの？
「メモリアクセスの最適化が要るループの中で」呼び出すだなんて
俺は一言も言ってないんだが。
どうやれば本当に効率が改善されるのか自分の頭を使って考えたらどうだ？
58:名前は開発中のものです。
09/04/05 23:21:29 XP6NPTaD
>>56
>俺は、>>45 では、GC環境なら、C/C++のheap allocより高速なnewの実装が可能に
>なることは言ったが、「GC環境を構築したC/C++よりも」だなんて一言も言ってない。
矛盾した返答だなぁ
そのGC環境は比較対照のC/C++とは違うアーキテクチャのマシンで動いているのかい？
同じマシンならその高速とやらのheap allocと同じ原理を、高級アセンブラであるC/C++なら実装可能だろ。逆は無理だけど。
GC環境とやらがネイティブのC/C++(≠ASM)にパフォーマンスで勝負するのは勝ち目が無いんで無い？
59:名前は開発中のものです。
09/04/05 23:22:09 ZnQmmsrk
>53
C++っぽいけど全然違う脳内言語を使って脳内コンパイルしてるだけなら、その程度の話でいいのかもね。
60:名前は開発中のものです。
09/04/05 23:24:28 SofMJMSf
>>56
>その理屈はおかしい。
>あんたはゲームの仕様が決まるまでnewやdeleteの実装をしないつもりか？
その理屈でいくのなら、自前のcollectionなんて実装せずにnewやdeleteを使ってれば良い話になるだろ。
ところがお前は、newやdeleteはタスクシステムの仕様に無頓着だから、
タスクシステムの仕様にあったアロケータを自前で開発すべきだと主張してる。
それに対して俺は、タスクシステムはゲームの仕様に無頓着だから、
ゲームの仕様にあった方法でデータは確保すべきだ、と返しているわけで。
61:名前は開発中のものです。
09/04/05 23:30:02 qdg6blW7
>>56
> std::vector<XXXTask>のようなものを用意して、XXXTask型のオブジェクトは
> 全部そこに突っ込む(push_back)するつもりか？
その vector をまっすぐ走査すればキャッシュヒット率の目的は達成できるよね？
何かマズイの？
> あんたはゲームの仕様が決まるまでnewやdeleteの実装をしないつもりか？
いや、しないだろ、当然。コンパイラが一般的な実装は提供してくれるんだから。
ゲームの仕様がなければ自分で実装する目的が無い。
62:並列さん ◆dPfetnROQg
09/04/05 23:31:38 KXq+7Jyb
>>58
何か話が噛み合ってない気がする。
俺が想定しているGC環境でのmallocは、次のコードだ。
void* malloc(size_t size)
{
void* adr = (void*)heap; // heapはbyte*
heap += size; // この分、確保した
return adr;
}
これはGC環境下ではないC/C++で書くカスタムアロケータより
十分高速だと思うが、これより速い実装が可能だと言うなら教えてくれ。
63:並列さん ◆dPfetnROQg
09/04/05 23:34:08 KXq+7Jyb
>>62
自己レスだが、メモリを上位から下位に確保していくheapなら
void* malloc(size_t size)
{
heap -= size; // この分、確保した
return (void*)heap;
}
こうなる。こっちでもいい。
64:名前は開発中のものです。
09/04/05 23:34:12 qdg6blW7
>>57
collection の要素型がポインタになってるけど、別に派生クラスとか update の詳細が
異なるインスタンスをいっしょに入れるわけじゃなくて、単一クラスのコレクションなの？
それなら、なおさら std::vector に生で入れたほうが速そうだなぁ。
65:名前は開発中のものです。
09/04/05 23:36:14 XP6NPTaD
>>62
あのー、これheap allocでなくstackでない？
66:名前は開発中のものです。
09/04/05 23:37:09 w7j54ekv
どう考えてもゲームの仕様依存の問題にここまでしつこいのって馬鹿じゃね？
設計失敗してるのにねばってて馬鹿みたい
プログラマやる前にまず大人になれよｗ
67:名前は開発中のものです。
09/04/05 23:38:02 SofMJMSf
>std::vector<XXXTask>のようなものを用意して、XXXTask型のオブジェクトは
>全部そこに突っ込む(push_back)するつもりか？
型ごちゃまぜ状態でコンパクションかけるよりは、
同じ型は同じ配列に集めてコンパクションかけた方が、まだましだろう。
同じ型のデータは連続的にアクセスされる可能性が高いからな。
型ごちゃ混ぜ状態でコンパクションかけますっていうのなら、
頭どうかしてますとしか言いようが無い。ゲームでそこまでする必要なし。
68:並列さん ◆dPfetnROQg
09/04/05 23:41:04 KXq+7Jyb
>>60
なんか話が噛み合ってない原因がわかった。
> ところがお前は、newやdeleteはタスクシステムの仕様に無頓着だから、
> タスクシステムの仕様にあったアロケータを自前で開発すべきだと主張してる。
俺は最初からそんなことは主張していない。
GC環境下のほうが、小さなオブジェクトの生成/解体には有利で、
どうせGCを搭載するなら、コンパクションをやるついでにタスクの再配置も
したほうがCPU cacheの効率があがるということを主張している。
69:並列さん ◆dPfetnROQg
09/04/05 23:42:24 KXq+7Jyb
>>65
> あのー、これheap allocでなくstackでない？
それがGC環境下のheap allocだよ。
定期的にGCがメモリのコンパクションを行なうから、heap allocはただひたすら
メモリの上位(or 下位)に向かって確保していくだけでいいんだ。
70:名前は開発中のものです。
09/04/05 23:43:40 w7j54ekv
なんで話がかみ合ってないとか言い出すの？
もう疑いようもなく頭悪いのにｗ
なんでかみ合ってないとかやめてよ
きたねぇなさわんなよ気持ち悪い
71:並列さん ◆dPfetnROQg
09/04/05 23:44:27 KXq+7Jyb
>>66,70
馬鹿はお前。話についてこれないなら黙れ。
72:名前は開発中のものです。
09/04/05 23:44:39 XP6NPTaD
>>69
これがGC環境のどんな言語のソースかわからんけど、
GCアルゴリズムが使われる以上、allocについてもGCのコストを考えんといけんわけだが…
「コード上」の見た目だけはC/C++で書くカスタムアロケータより速そうだね。見た目だけは。
73:名前は開発中のものです。
09/04/05 23:48:22 w7j54ekv
>>71
だってすっげ頭悪いじゃん
全然意味ないことやってるじゃん
74:並列さん ◆dPfetnROQg
09/04/05 23:50:27 KXq+7Jyb
>>72
> allocについてもGCのコストを考えんといけんわけだが…
もちろん、そう。
> 「コード上」の見た目だけはC/C++で書くカスタムアロケータより速そうだね。
> 見た目だけは。
実際速いよ。大量に小さなオブジェクトの生成/解体を繰り返すなら。
Boehm GCでも導入して測定してみなよ。
まあ、もちろん、本当に速度が必要ならなるべくオブジェクトの動的な
生成/解体はせず、poolingするけどな。
GCの話題はスレ違いっぽいから、これ以上は自分の目で確かめてくれ。
75:名前は開発中のものです。
09/04/05 23:51:52 qdg6blW7
>>62
これ、ちゃんと適用範囲限定して、ゲームの仕様にあわせて使えば GC のコストもなしに
使えてもっと速いのに。っていうか、そういう使い方ならわりと実際に使われてるはず。
region allocator ってやつね。
これが「GC環境下のheap alloc」と言い切ってしまうのが、なんとも、ねぇ。
76:名前は開発中のものです。
09/04/05 23:53:14 SofMJMSf
>GC環境下のほうが、小さなオブジェクトの生成/解体には有利で、
>どうせGCを搭載するなら、コンパクションをやるついでにタスクの再配置も
>したほうがCPU cacheの効率があがるということを主張している。
いつからGCが前提になったんだ？
>18 名前：並列さん ◆dPfetnROQg [sage] 投稿日：2009/04/05(日) 03:23:57 ID:KXq+7Jyb
>>>15
>俺は14ではないが、メモリのコンパクションを行なうには、それぞれのオブジェクトに対するstd::listのようなものが
>必要になるので、(典型的な)タスクシステムに搭載されているstd::listのようなものをそのまま流用すれば一石二鳥だから、
>タスクシステムはメモリのコンパクションまで行なうように拡張しておけば、タスクシステムのフレームワークとしての
>利用価値がさらにあがるという風にタスクシステムとメモリのコンパクションとは密接に関係している。
77:並列さん ◆dPfetnROQg
09/04/05 23:54:02 KXq+7Jyb
>>67
> 型ごちゃまぜ状態でコンパクションかけるよりは、
> 同じ型は同じ配列に集めてコンパクションかけた方が、まだましだろう。
そうとは限らない。
普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。
78:名前は開発中のものです。
09/04/05 23:57:17 XP6NPTaD
Boehm GCを使いながらキャッシュヒットの利点を持ち出すのか…
やはり根本的に矛盾しているというか何というか。
79:並列さん ◆dPfetnROQg
09/04/05 23:58:02 KXq+7Jyb
>>75
> これ、ちゃんと適用範囲限定して、ゲームの仕様にあわせて使えば GC のコストもなしに
> 使えてもっと速いのに。
もちろんそうだよ。
80:並列さん ◆dPfetnROQg
09/04/05 23:59:48 KXq+7Jyb
>>78
> Boehm GCを使いながらキャッシュヒットの利点を持ち出すのか…
> やはり根本的に矛盾しているというか何というか。
Boehm GCは、GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を
含めても)速いということを示すために挙げただけだ。
81:名前は開発中のものです。
09/04/06 00:05:36 kRCgeJ2q
>>80
>GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を含めても)速いということを示すために挙げただけだ。
この文章だと全てのGC環境が非GC環境に比べてオブジェクトの生成/解体が速いって意味になりそうだけど
ほんとにそー思ってる？
それとも何か自分だけ常識と思ってる前提でもあるのかね。
82:名前は開発中のものです。
09/04/06 00:07:16 SofMJMSf
>普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。
メモリ使用量を減らすためだろ。
今は高速化についての話をしているはずでは？
83:名前は開発中のものです。
09/04/06 00:13:08 B8zjnpJZ
>Boehm GCは、GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を
>含めても)速いということを示すために挙げただけだ。
速かろうが遅かろうが、タスクシステム内でやるべきことでは無いわけで。
タスクをどう確保するかはタスクシステムの利用者に委ねるべき。
84:並列さん ◆dPfetnROQg
09/04/06 00:13:20 yXbkibtb
>>81
> この文章だと全てのGC環境が非GC環境に比べてオブジェクトの生成/解体が速いって意味になりそうだけど
> ほんとにそー思ってる？
もちろん、GCにしてもピンキリ。
Boehm GCは、オブジェクトの型情報を持っていないから効率の面では
あまり良くない実装だけど、参考に挙げるのはそれくらいでいいかなと思った。
> それとも何か自分だけ常識と思ってる前提でもあるのかね。
.NET FrameworkのGCは結構練られてると思う。
.NET FrameworkのGCに関してはいろんな環境と比較したり
速度を計測したりしたし、俺GCを実装するときの参考にさせてもらった。
85:名前は開発中のものです。
09/04/06 00:14:51 QqdC07mx
GCスレ立てろよw
86:並列さん ◆dPfetnROQg
09/04/06 00:20:34 yXbkibtb
>>82
>>普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。
> メモリ使用量を減らすためだろ。
違うね。速度面でもメリットがある。
>>83
> 速かろうが遅かろうが、タスクシステム内でやるべきことでは無いわけで。
> タスクをどう確保するかはタスクシステムの利用者に委ねるべき。
俺は>>78に対して>>80と答えただけで、あんたの突っ込みは適切じゃない。
また、「タスクメモリをどう確保するか」は、タスクシステム側が決めても
構わないと俺は思う。タスク"システム"なんだから、嫌なら、そのシステムを
使わなければいいだけのことじゃん。
87:名前は開発中のものです。
09/04/06 00:30:13 B8zjnpJZ
>違うね。速度面でもメリットがある。
無いね。ごちゃ混ぜにするより、同じ型を隣に並べた方がゲームの場合キャッシュヒット率が上がる。
同一型は同一ループ内で処理されるのが普通だからな。
88:名前は開発中のものです。
09/04/06 00:32:14 B8zjnpJZ
つーかいつからGC前提の話になったんだよ。
>>18の発言はどうするつもりだ？
タスクシステム実装するならコンパクションも実装した方が一石二鳥だって話じゃなかったのかよ。
89:名前は開発中のものです。
09/04/06 00:40:06 QqdC07mx
タスク厨はマジでしょうもないなwww
コンパクションやGCが必要になるほどの規模で、モノ作ってるワケでもあるまいにwww
たかがタスクのコレクションを順次処理していくだけなのに、キャッシュ効率だの速度だの気にしてる方が
バカらしいwww
90:名前は開発中のものです。
09/04/06 00:40:40 gHjH+Kkr
>>87
ごちゃ混ぜコンパクションの速度面のメリットも、同じ型を隣に並べた場合の
キャッシュヒット率向上も、同じぐらいにいいかげんな話だと思うよ。
速度を上げたかったら、まず計測してボトルネックを見つけて、そこを叩かなきゃ。
91:90
09/04/06 00:42:54 gHjH+Kkr
あ、ボトルネックを見つけた後の対処としては、コンパクションを実装するより
オブジェクトを配列にまとめたほうがはるかに簡単で効果的だと思うけどね。
92:並列さん ◆dPfetnROQg
09/04/06 01:05:15 yXbkibtb
>>87
> 無いね。ごちゃ混ぜにするより、同じ型を隣に並べた方がゲームの場合キャッシュヒット率が上がる。
> 同一型は同一ループ内で処理されるのが普通だからな。
なんか言葉不足で何がどうなっているのか俺にはわからないのだが、
A. newで確保した時点でvector<T>にpush_backする
B. 動的にオブジェクトを移動させvector<T>に入れる
のA,Bのどちらの話をしているんだ？
Aなら話もわからなくはない。そんな風にコーディングしていいならな。
しかし、その確保された順番にタスクプライオリティが割り振られているわけではないだろうから、
タスクシステムからこれを呼び出したときにcacheのヒット率がいいのかは別問題。
そもそも、メモリイメージは詰められて配置はされるが、Aは普通はコンパクションとは呼ばない
んじゃないかな。これをコンパクションと呼ばれると俺には紛らわしくて仕方がない。
B.なら、上に書いたのと同じ理由に加えて、動的な型を判定してvector<T>に突っ込んだり、
その参照を書き換えたりするコストが必要になるので、あんたが思っているようには速くならない。
93:名前は開発中のものです。
09/04/06 01:08:56 B8zjnpJZ
並列さん ◆dPfetnROQgは、
キャッシュヒット率が上がるからと、わざわざコンパクションをかけ、さらにはタスクの並べ替えまで行うという。
最適なデータ配置はゲームの仕様によりけりで、
ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は無意味だと言うのに。
しかも、コンパクションの実装もまずい。
型ごとに配列で保持してコンパクションかければ良いだけのものを、
わざわざごちゃ混ぜ状態で保持して折角のキャッシュヒット率を落としてしまうというセンスの無さ。
なにやってんだか。
よくよく聞けば、本職がソフト屋で、さらにゲーム関係に携わってるとか。
ハード屋の俺と争ってる時点で終わってるね。
極めつけは、タスクをどう確保するかはタスクシステム側が決める、嫌なら使わなければ良いだけだ、
などという、ソフト屋独特の独善的な恥ずかしい発想。
まずは大人になってください。
94:名前は開発中のものです。
09/04/06 01:13:04 QqdC07mx
構図が一緒なんだよなw
タスク厨とアンチタスク
GCコンパクション厨と不必要派
95:名前は開発中のものです。
09/04/06 01:18:54 /+Me6qfs
結論は意味がないのに話にのるなよ馬鹿だろ？
根本がまずい
ゲームの仕様によって変わるものをその下の層に
無理やりねじ込もうとしてる時点でもうダメなんだよ
話を受けるほうも根幹で間違ってる問題でそれが解決できないまま話を進めるな
無意味だろ
こんな議論何時間したって無駄じゃん
すればするほど馬鹿になってくだけ
96:名前は開発中のものです。
09/04/06 01:19:40 /+Me6qfs
ああ、それと
>並列さん ◆dPfetnROQg
そんなに馬鹿ならＰＧやめちゃえよ
97:名前は開発中のものです。
09/04/06 01:31:57 B8zjnpJZ
>>92
Bだな。
ところで、お前が>>42で示した実装だと、型ごとにポインタをcollectionしてるから、
型を飛び越えて処理順序のプライオリティーをつけることは出来ない。
だから、>>92で言うプライオリティーとは、同一型内での処理順序のプライオリティーだと考える。
だからvector<T>（のようなもの）に実態を持っておいて、プライオリティーの変更があれば、
その都度vector<T>内の該当要素を挿入しなおす実装で問題ない。
>B.なら、上に書いたのと同じ理由に加えて、動的な型を判定してvector<T>に突っ込んだり、
>その参照を書き換えたりするコストが必要になるので、あんたが思っているようには速くならない。
テンプレートを使えばよい。
template < class _T >
std::vector< _T > *get_heap(){ static std::vector< _T > heap; return &heap; }
template < class _T >
_T *New()
{
get_heap<_T>()->resize( get_heap<_T>()->size()+1 );
return &get_heap<_T>()->back();
}
hoge_task *p = New< hoge_task >();
お前本当にソフト屋か？
98:名前は開発中のものです。
09/04/06 01:51:15 y7ZcPLoJ
>>93
> 最適なデータ配置はゲームの仕様によりけりで、
> ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は
> 無意味だと言うのに。
全くその通りなんだけど、ほぼ
タスクシステムを実装する人＝それを使う人
なんじゃないのかな。
少なくとも仕様について直接話ができる関係でないと
タスクシステム自体を使えないと思う。
つまりありえない仮定を置いて否定するのはフェアじゃないし
技術の話としても意味が無いと言いたい。
99:名前は開発中のものです。
09/04/06 01:53:56 B8zjnpJZ
並列さん ◆dPfetnROQg よ・・・
現実逃避目的にプログラム書くのなら、もうプロ辞めろ。
タスクシステムでキャッシュヒット率を上げようという目的も不味ければ、
その実装手段も不味い。
普通、どちらかぐらい真っ当なものなのだが。
これからは農業の時代だと聞くぞ。
100:98
09/04/06 01:59:15 iTEC611J
一応書いとくと並列さんの味方したいわけじゃなくて
並列さんの主張は独善的で視野が狭いと思う。
# 技術的な話を盛り上げるためにつっこみどころ満載の
# ネタを意図的に投下してるのかもしれんけど
101:名前は開発中のものです。
09/04/06 02:07:50 B8zjnpJZ
>>98
>タスクシステムを実装する人＝それを使う人
だったとしても、
>ゲームの仕様を知れないタスクシステム側
であることには変わりないわけで。
どうであれ、キャッシュヒット率まで考えたデータの配置を考えると言うのなら、
(タスクシステムを実装する人＝それを使う人、で有ろうが無かろうが)
タスクシステムの外から行う方が話が早い。
102:98
09/04/06 02:44:56 H9N6h/U7
>>101
ごめん。ゲームの仕様に合わせて毎回設計するという仮定をしてることに
101で気がついた。書かなきゃわからないのに話があうわけないよね。
話に参加できるほど賢くないとわかったので観客に戻ります。
103:並列さん ◆dPfetnROQg
09/04/06 02:57:00 yXbkibtb
>>93
> 最適なデータ配置はゲームの仕様によりけりで、
> ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は無意味だ> と言うのに。
違うね。タスクシステムであるからには、タスクプライオリティに従って
タスクが呼び出されることは保証されるわけで、呼び出し順がわかっているので
それに従ってGCするときに配置換えすることは出来る。
> 型ごとに配列で保持してコンパクションかければ良いだけのものを、
これも違うね。型ごとに集めればworking setは小さくなるが、
その集合に対してメモリの先頭から逐次的にアクセスしていく
保証はされない。
104:並列さん ◆dPfetnROQg
09/04/06 03:00:20 yXbkibtb
>>95
> ゲームの仕様によって変わるものをその下の層に
> 無理やりねじ込もうとしてる時点でもうダメなんだよ
これも違うね。
GCはどんなゲームを作る場合でもあって困るということはあまりない。
GC環境下(例えばXNAでも.NET Framework + WPFでも)で
プログラムをすればその便利さがわかると思うのだが。
GCを否定する馬鹿がこんなにいるんだな。このスレ阿呆の集まりか？
>>96
馬鹿はあんただろろ。ろくにプログラミング経験もないなら
口出ししてくるなよ。
105:並列さん ◆dPfetnROQg
09/04/06 03:10:23 yXbkibtb
>>97
> プライオリティーの変更があれば、
> その都度vector<T>内の該当要素を挿入しなおす実装で問題ない。
「挿入しなおす」って、removeしてinsertするって意味？
プライオリティが変わるごとにstd::vectorに対してそんなことしたら
重くて仕方ないんだけど。
何がどう問題ないと思えるの？頭大丈夫？
> hoge_task *p = New< hoge_task >();
> お前本当にソフト屋か？
それnewしたときに型がわかっていて、その型のvectorに
突っ込んでるだけじゃん。>>92のBじゃなく、Aでしょうに。
あと「その参照を書き換えたりする」必要があると俺は書いてるが、
それはどうやって解決するつもり？
106:並列さん ◆dPfetnROQg
09/04/06 03:13:17 yXbkibtb
>>99
> 現実逃避目的にプログラム書くのなら、もうプロ辞めろ。
あんたが俺が言ってる内容を何も理解してないだけじゃん。
あんたは日本語の勉強しなおしてきたほうがいいよ。
107:並列さん ◆dPfetnROQg
09/04/06 03:14:58 yXbkibtb
>>101
> どうであれ、キャッシュヒット率まで考えたデータの配置を考えると言うのなら、
> タスクシステムの外から行う方が話が早い。
わかっちゃいると思うが、俺の言っている
GCは実際はタスクシステムの"外"に実装されているよ。
GCにタスクの呼び出し順というヒントを与えて、それを利用して
うまくオブジェクトをアレンジメントできるかということを
問題にしているだけなんだが。
108:名前は開発中のものです。
09/04/06 03:20:24 B8zjnpJZ
>違うね。タスクシステムであるからには、タスクプライオリティに従って
>タスクが呼び出されることは保証されるわけで、
>>42 を見る限り、型ごとにcollectionを持っているようだが。
どの型のcollectionのupdateから実行していくかは、for_eachを記述した順に決定されるわけで、
プライオリティーによらないと考えるが。
>その集合に対してメモリの先頭から逐次的にアクセスしていく
>保証はされない。
だったら並べ替えればよい。要は最適化する順番が逆。
まず型ごとに集めることを考えて、それから並べ替えることを考える。
まぁそれすら意味がないどころか余計なことだと思うがな。
どうせやるならということで。
>GCはどんなゲームを作る場合でもあって困るということはあまりない。
だから、いつからGCの話になったんだ？
109:名前は開発中のものです。
09/04/06 03:33:51 B8zjnpJZ
>プライオリティが変わるごとにstd::vectorに対してそんなことしたら
>重くて仕方ないんだけど。
プライオリティーなんて滅多に変わらないだろうし、現実問題として、それで問題ないだろう。
付け加えて、俺はそもそもコンパクションなんて要らないといってるわけで。
それにはコンパクションが重い処理だからという理由も含まれている。
>それnewしたときに型がわかっていて、その型のvectorに
>突っ込んでるだけじゃん。>>92のBじゃなく、Aでしょうに。
お前の日本語が分かりにくいんだよ。自分の世界の定義で言葉使うから。
>B. 動的にオブジェクトを移動させvector<T>に入れる
の意味が謎。型なんて生まれてから死ぬまで変わらないんだから動的に管理する意味なんてないだろ。
>あと「その参照を書き換えたりする」必要があると俺は書いてるが、
>それはどうやって解決するつもり？
好きな方法でやれば？これはお前の言うところのコンパクションでも同じ問題が発生するでしょ。
110:並列さん ◆dPfetnROQg
09/04/06 03:36:49 yXbkibtb
>>108
> >>42 を見る限り、型ごとにcollectionを持っているようだが。
> どの型のcollectionのupdateから実行していくかは、for_eachを記述した順に決定され> るわけで、
それは、俺がGC側でcompactionを行なうときにタスクを並び替えて、
並び変わったあとのcollectionを返しているからそうなっている。
あんたが、自前でcompactionを行なうなら、自分でタスクプライオリティに
従って並び替えをしないといけないし、並び替えをした上で同じ型のcollection同士を
集めたものを用意してからupdate(vector<T>)のような関数を呼び出す必要がある。
> まず型ごとに集めることを考えて、それから並べ替えることを考える。
「型ごとに集めることを考えて、それから並べ替える」ほうが、
「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは限らないんだが。
そんな自分のやりやすい方法を言われても。
111:名前は開発中のものです。
09/04/06 03:38:52 B8zjnpJZ
>>107
タスクシステムの外と言う言葉を使ったが、下位層は含まず、上位層という意味で使った。
ごめんね、そこまで細かく言ってあげなきゃ分からないよね。
それとも、下位とか上位という概念がなく、内か外でしか物事を考えられないのかな？
まぁ、GCにタスクの呼び出し順を食わせようとしている時点で既にアレなのだが。
112:並列さん ◆dPfetnROQg
09/04/06 03:41:43 yXbkibtb
>>109
>>B. 動的にオブジェクトを移動させvector<T>に入れる
>の意味が謎。型なんて生まれてから死ぬまで変わらないんだから動的に管理する意味なんてないだろ。
確かに上の(俺の)日本語、わかりにくいな。それはすまんかった。
生成時にいったんvector<T>に入れてオブジェクトが死ぬまで
アドレスの変更などが発生しないのがA。
それに対して、描画フレーム毎に、オブジェクトを移動させ
compactionを行なうという意味がB。
113:並列さん ◆dPfetnROQg
09/04/06 03:45:41 yXbkibtb
>>109
>>プライオリティが変わるごとにstd::vectorに対してそんなことしたら
> プライオリティーなんて滅多に変わらないだろうし、現実問題として、
> それで問題ないだろう。
あんたの実装、vector<T*>ではなく、vector<T>だよな？
オブジェクトが死ぬごとにremoveが発生してそこ以降のオブジェクト全部
コピーすることになるんだが、これ、いつ後始末するつもりだ？
また死んだオブジェクト(タスク)はどうやって判定するつもりだ？
オブジェクトひとつずつにデリートマークがあって、foreachのときに
デリートマークをチェックしながらiterationを行なうのか？
それともどこかで死んだオブジェクトを詰める(removeする)作業をするのか？
そのときにそこ以降のオブジェクトのアドレスが書き換わるから、
それを参照しているポインタ全部書き換えなきゃならんのだが。
本当にそんな実装が速いと思うのか？
114:名前は開発中のものです。
09/04/06 03:53:18 B8zjnpJZ
>あんたが、自前でcompactionを行なうなら、自分でタスクプライオリティに
>従って並び替えをしないといけないし、並び替えをした上で同じ型のcollection同士を
>集めたものを用意してからupdate(vector<T>)のような関数を呼び出す必要がある。
型ごとにheapを持つようにすれば同じ型同士を集める必要はないし、
タスクプライオリティーも、変更されるその都度挿入し直せば、並べ替えを行う必要もなくなる。
当たり前だが、挿入と並べ替えだと、並べ替えの方が重い。
>「型ごとに集めることを考えて、それから並べ替える」ほうが、
>「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは限らないんだが。
>そんな自分のやりやすい方法を言われても。
後者よりも前者の方が常に速い。
前者だと、
１．型ごとに集める処理を端折れる。
２．型ごとに並べ替えた方が速い。なぜなら並べ替えの計算量はO(n*logn)だから。
115:並列さん ◆dPfetnROQg
09/04/06 04:00:55 yXbkibtb
>>114
> タスクプライオリティーも、変更されるその都度挿入し直せば、
> 並べ替えを行う必要もなくなる。
> 当たり前だが、挿入と並べ替えだと、並べ替えの方が重い。
並べ替えは毎フレームしなくとも良いが(GCが走るのはときどきなわけだし)、
タスクプライオリティは変更と同時に挿入しなおさなければならないから
その比較はおかしい。
まあ、タスクプライオリティを頻繁に変更するかと言われれば
確かに普通はノーだと思うんだが、生成は頻繁に行なうわけで、生成時にタスク
プライオリティが与えられていてその適切なところにinsertする
コストはとても無視できない。
116:ID:B8zjnpJZ
09/04/06 04:01:06 RuQXDnG2
>>113
それは好きにすればよいと思うが。
>それを参照しているポインタ全部書き換えなきゃならんのだが。
オブジェクトに不変なハンドルつけて間接参照にしたり、
ポインタをラップしてリストアップしたり。
>本当にそんな実装が速いと思うのか？
コンパクションを行うということはそういうことだろうに。(だから要らないと言ってるのだが)
つーか、並列さん ◆dPfetnROQg はコンパクションを何だと思ってるんだ？
117:名前は開発中のものです。
09/04/06 04:09:51 RuQXDnG2
>生成は頻繁に行なうわけで、生成時にタスク
>プライオリティが与えられていてその適切なところにinsertする
>コストはとても無視できない。
型ごとにheapを持ってればそんなむちゃくちゃな事にはならないし、
どちらかというと、不定期にGCが発動して、そのフレームだけ局所的に負荷が高くなる方が困る。
ゲームでGC使うのが嫌われる理由と同じだな。
118:名前は開発中のものです。
09/04/06 04:13:47 RuQXDnG2
>並べ替えは毎フレームしなくとも良いが(GCが走るのはときどきなわけだし)、
>タスクプライオリティは変更と同時に挿入しなおさなければならないから
>その比較はおかしい。
リアルタイム処理では一番負荷の高い瞬間で比較しなければならないので、
その比較であってる。いわゆるボトルネックという奴。
119:並列さん ◆dPfetnROQg
09/04/06 04:19:36 yXbkibtb
>>114
>>「型ごとに集めることを考えて、それから並べ替える」ほうが、
>>「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは
>> 限らないんだが。
>> そんな自分のやりやすい方法を言われても。
>後者よりも前者の方が常に速い。
>前者だと、
>１．型ごとに集める処理を端折れる。
>２．型ごとに並べ替えた方が速い。なぜなら並べ替えの計算量はO(n*logn)だから。
1.は、意味不明。「型ごとに集めることを考えて」なのだから、端折れてないと
思うんだが。
2.は、どうもあんたはまだ話がわかっちゃいないと思う。
120:並列さん ◆dPfetnROQg
09/04/06 04:22:45 yXbkibtb
>>114
次の4つのインスタンスがあるとしよう。
Task A : プライオリティ = 1
Task A : プライオリティ = 4
Task B : プライオリティ = 2
Task B : プライオリティ = 3
Task A,BはTaskという基底クラスの派生型でvector<Task*>にぶち込まれていて
これをいま呼び出し順を考慮しながら型ごとに分類しないといけないとしよう。
collection I.
Task A : プライオリティ = 1
collection II.
Task B : プライオリティ = 2
Task B : プライオリティ = 3
collection III.
Task A : プライオリティ = 4
呼び出し順を考慮して、上のように分類されてcollectionが
生成されなければならない。
「型ごとに集めることを考えて、それから並べ替える」ほうが速いか？
それに同じ型に対するcollectionは上のように複数いるぞ。
この意味で、>>97のような実装は不可だ。
121:並列さん ◆dPfetnROQg
09/04/06 04:32:06 yXbkibtb
>>116
> オブジェクトに不変なハンドルつけて間接参照にしたり、
> ポインタをラップしてリストアップしたり。
だから、そんなプログラムが速いわけないだろ。
ハンドルに対する実アドレスのテーブルをcompactionのときに
更新しないといけないぞ。
他のタスクオブジェクトを参照するごとに
TaskA taskA= dynamic_cast<TaskA*>HandleToPtr(taskA_handle);
みたいに書く必要が出てくる。
プログラムが汚い上にハンドルだから型が不明になってしまう。
これひどくないか？
> コンパクションを行うということはそういうことだろうに。
それは、全然違うと思うぞ…。
少なくとも俺のシステムにあんたの実装のような欠陥はないな。
122:並列さん ◆dPfetnROQg
09/04/06 04:33:07 yXbkibtb
>>116
> 型ごとにheapを持ってればそんなむちゃくちゃな事にはならないし、
(一般的には)型ごとにheapを持てない。理由 >>120。
123:名前は開発中のものです。
09/04/06 04:35:38 RuQXDnG2
>>119
型ごとに既に集まってるんだから、型ごとに集め直す必要はないだろ。
例えば、林檎と蜜柑と梨が何個かずつ有って、それぞれ種類別に箱に入ってるとする。
それぞれの果物には賞味期限があり、売れ残りを防ぐため、古いもが手前に来るように陳列したい。
A：林檎と蜜柑と梨をごちゃまぜにして、賞味期限順に並べ替えてから、改めて種類別に分け直す。
B：単にそれぞれの種類内で賞味期限順に並べ替える。
どっちが早いか。
124:並列さん ◆dPfetnROQg
09/04/06 04:38:38 yXbkibtb
>>117
> どちらかというと、不定期にGCが発動して、そのフレームだけ局所的に負荷が高くなる方が困る。
さすがにそんなことは普通はない。
いや、あるにはあるが、そうならないように気をつけてコーディングする。
それすら出来ないなら、そもそもXNAでゲームプログラムなんて出来ないわけで…。
>>118
> リアルタイム処理では一番負荷の高い瞬間で比較しなければならないので、
> その比較であってる。いわゆるボトルネックという奴。
ボトルネックがコマ落ちしたりするほど大きくないなら、全体的なスループットのほうが大切。
125:並列さん ◆dPfetnROQg
09/04/06 04:39:51 yXbkibtb
>>123は>>120を読む前に書かれたものだと思うので無視する。
126:名前は開発中のものです。
09/04/06 04:46:06 gHjH+Kkr
もうね、
タスクシステムありきでいろんな問題（コンパクション・キャッシュヒット）に対処していくと、
最終的にはこんなことになってしまうかもしれないという悲劇の具体例にしか見えない。
127:並列さん ◆dPfetnROQg
09/04/06 04:50:53 yXbkibtb
このスレではなんかメモリのコンパクション不要論を唱えてる
馬鹿ばっかりなんだが実際「ワンダと巨像」でもメモリの
コンパクションは、行なっている。
しかも「ワンダと巨像」ではテクスチャ、地形データのみならず、
プログラムコード自体も再配置の対象となっている。
ある程度の規模のゲームなら、やらざるを得ないと思うんだが。
お前たちは、本当にゲームを作っているのか？
夢のなかで作ってるだけなんじゃね？
プログラミング見習いとか、同人ゲー作ってますとか
サブプログラマーとしてスプライト処理手伝いましたとか
そんなゴミクズみたいな奴ばっかり出てくんなよ。
俺はもう寝るぞ。明日も早いからな。おやすみ。
128:名前は開発中のものです。
09/04/06 04:55:46 RuQXDnG2
>>120
後出しじゃんけんのごとく次から次へと変な実装例を出してくるなよ。
プライオリティーも型として扱えば？まぁプライオリティー固定になるが。
template < class t, int priority > とかして。
>>121
>プログラムが汚い上にハンドルだから型が不明になってしまう。
>これひどくないか？
そう思うのならラップすればよいだろ。本質的には同じこと。
129:名前は開発中のものです。
09/04/06 05:18:01 WGJzP9Yk
＞プログラミング見習いとか、同人ゲー作ってますとか
いや、そもそもここはそういう人のための場だろ。
メイン張ってるプロ中のプロがこんな場所に出てくるんだったら、
そういう人たちに分かるように説明すべきじゃないのか？
つか、場当たり的に情報小出しにするより、ちゃんとまとめて本でも書いてくれ。
次のやねう本より先に出せば結構売れるんじゃないか。
130:名前は開発中のものです。
09/04/06 05:24:15 B8zjnpJZ
>>124
>そうならないように気をつけてコーディングする。
だったら、普通にメモリプールで十分なわけで。
>ボトルネックがコマ落ちしたりするほど大きくないなら、全体的なスループットのほうが大切。
意味不明。コマ落ちしないなら、既に仕様を満たしているわけで、スループットも糞もないだろ。
>>127
ほとんどのゲームでは行ってないだろ。でもちゃんと動いている。それが現実。
一部の例外だけ取り上げて、さも当たり前かのように言うな。
131:名前は開発中のものです。
09/04/06 05:40:29 FyQkrEyW
横からだけど、ID:B8zjnpJZさんはちょっと素人っぽいよね。
私から見てても、なんか言ってることのレベルが低いというか。
実際に商用である程度の規模のゲームを作った経験のある人が
もっと並列さんに質問してほしいな。
132:名前は開発中のものです。
09/04/06 06:20:06 /+Me6qfs
まだ、やってんの？
あったまわるい
話受けるほうも相手にするなよ
133:名前は開発中のものです。
09/04/06 06:43:47 VcqDZA+W
夜を徹して生産性を下げる工作が成功してるようだな
しかしまともな議論をするなら情報後出しと言われないように議論命題に関する
クラス図なり、シーケンス図（サンプルシナリオ）なりを先に明示すべきだと思う
土台が無い状態で前提の違う俺言語同士の闘いをしてて不毛すぎる
134:名前は開発中のものです。
09/04/06 07:10:15 QqdC07mx
>103
> これも違うね。型ごとに集めればworking setは小さくなるが、
> その集合に対してメモリの先頭から逐次的にアクセスしていく
> 保証はされない。
アクセスループに入る前にキャッシュの先読みくらいしとけよ。
135:名前は開発中のものです。
09/04/06 07:24:50 QqdC07mx
>127
> ある程度の規模のゲームなら、やらざるを得ないと思うんだが。
フリーラン系でも無い限り、プレイ中にコンパクションなんてやらない。
シーン切り替えのタイミングでコンパクションすることはあるけどもね。
それよりも、シーンごとに破棄できるデータと常駐データを幾つかのレベルに分けて管理したほうが
楽だよ。
136:並列さん ◆dPfetnROQg
09/04/06 09:03:31 yXbkibtb
>>128
> そう思うのならラップすればよいだろ。本質的には同じこと。
全然同じじゃない。
>>133
> しかしまともな議論をするなら情報後出しと言われないように議論命題に関する
そんなもん誰が読むんだ？悪いけど俺はそんなもの作成するのは嫌だ。
>>134
> アクセスループに入る前にキャッシュの先読みくらいしとけよ。
そんなことで解決する問題じゃない。
一般的に言って、L1に相当するメモリは極端に小さいからループに入る前に読み込んでも無駄だし、
指定しなくともどこか1バイトを読み込んだら、次のalignmentまで自動的に読み込む設計になってるのが
普通だから、いまどきのCPUアーキテクチャはランダムアクセスに対してはすこぶる弱い。
だから、先読みでは解決しない。
137:並列さん ◆dPfetnROQg
09/04/06 09:06:56 yXbkibtb
>>135
> それよりも、シーンごとに破棄できるデータと常駐データを幾つかのレベルに分けて管理したほうが楽だよ。
そりゃ、仕様が事前にわかっていればそりゃそうしたほうが楽だろう。
しかし、いまどきのゲーム、シーン切り替えなんてほとんどなくてシームレスにつながっていることが多いから、
そういうケースに備えて、ライブラリ的なものを準備するのが俺の仕事。
138:並列さん ◆dPfetnROQg
09/04/06 09:14:12 yXbkibtb
>>129
> メイン張ってるプロ中のプロがこんな場所に出てくるんだったら、
> そういう人たちに分かるように説明すべきじゃないのか？
そんな面倒な説明、俺は嫌だ。
少なくとも商用ゲーム開発してるプログラマだけ俺に質問してくれ。
それ未満の見習い君は黙ってROMってて欲しい。
>>131
確かにID:B8zjnpJZは素人っぽいではある。>128,130とかひどすぎて答える気にもならん。もうスルーしとく。
そもそもGC環境下でゲームプログラムを書くメリットとか、俺がこのスレで説明するこっちゃないと思うんだ。
実際に自分でXNAとかで開発して理解するか、もっとお偉方に聞いて欲しいなぁ。
139:名前は開発中のものです。
09/04/06 09:49:19 ptgzTYVC
アンチの中に配列好きの厨が混じってて吹いたw
140:名前は開発中のものです。
09/04/06 09:58:39 LCTic4Nk
つーかこの分量になると流し読みすらせずに流しちゃうな
141:名前は開発中のものです。
09/04/06 12:07:22 10SNKjhU
アンチかつプロの人はステージとかシーンでゲームをくぎって、その場面に必要な物だけをハードコーディングするような昭和ゲームつくってるんだろ
now loadingとかやめろよwww
142:名前は開発中のものです。
09/04/06 12:13:20 2tToa48s
本当に叩きたい人に当たるようにブーメラン投げてるんですね。
わかります。よくある手ですから。
143:名前は開発中のものです。
09/04/06 18:50:33 EhlRmjEd
速度の話に区切り付けてから次の話題振れよ
144:名前は開発中のものです。
09/04/06 19:12:19 /+Me6qfs
>並列さん
根幹がズレてるのに
まだ、長々と話してるの？
自分のはじめた話のケツぐらいふけるようになってから議論しろよ
理論的にはじめの一歩目ですでにダメなのにそこには目を瞑って
オレオレシステムのいいとこ探しなんてはじめた時点で
お前はもう技術者でもなんでもねぇ
ただのクズだ
145:名前は開発中のものです。
09/04/06 19:25:58 TigQ7s0b
まだ続けるつもりか
いいぞもっとやれ
146:名前は開発中のものです。
09/04/06 19:30:18 YVQYCAyD
古典タスクシステムとそうでないのとの違いを教えてください。
比較があるHPが有りましたら教えてください。
147:名前は開発中のものです。
09/04/06 19:36:40 /+Me6qfs
>>146
そんな受身で技術なんか見に付くわけない
やめちゃえ
148:名前は開発中のものです。
09/04/06 19:39:57 VcqDZA+W
つかえない子が頑張ってるのがたのしいな
まともに説明できてない時点で自分の脳内でしか認められないものだと気付かないの？
149:名前は開発中のものです。
09/04/06 19:52:04 kenh3Yca
ワンだと虚像って前評判ほど面白くなかったな。
見た目が派手なだけでパターン憶えゲーの中でも平凡なゲーム。
150:名前は開発中のものです。
09/04/06 20:15:34 uIjIdPYQ
面白さがタスクシステムと関係あるの？
151:名前は開発中のものです。
09/04/06 21:21:10 B8zjnpJZ
ゲーム業界VSアマチュアという構図が出来つつなるな。
ゲーム業界でがんばって来た人には、それなりにプライドもあるだろうし、触れられたくないこともあるのだろうな。
すべてが無駄だと薄々感づいてはいるのだろうが、気づかないふりをして毎日がんばってるのだろう。
152:名前は開発中のものです。
09/04/06 21:23:11 QqdC07mx
>136
> そんなことで解決する問題じゃない。
> 一般的に言って、L1に相当するメモリは極端に小さいからループに入る前に読み込んでも無駄だし、
> 指定しなくともどこか1バイトを読み込んだら、次のalignmentまで自動的に読み込む設計になってるのが
> 普通だから、いまどきのCPUアーキテクチャはランダムアクセスに対してはすこぶる弱い。
> だから、先読みでは解決しない。
コンシューマ触ったこと無いのバレバレだな。
153:名前は開発中のものです。
09/04/06 22:20:23 kRCgeJ2q
XNAで開発された商用ゲームってあるのかなぁ？今のところ国内メーカーはネイティブで作ってるみたいだけど。
カンファレンスでもXNAはホビーユース向けって感じだったし。
まぁそもそもMSと心中するつもりがなきゃMS縛りのXNAで開発なんてしたくないけどな。
154:名前は開発中のものです。
09/04/06 23:13:38 lXwqXQrR
>>153
黙ってろ
155:名前は開発中のものです。
09/04/06 23:17:12 /+Me6qfs
>>154
ＭＳ社員m9（＾Д＾）プギャー
156:ID:EEKBitmg ◆HSP4mee/SU
09/04/07 00:14:39 lzvNjqQS
ガキの直感だけど
並列君ってやねうらおさんの臭いがする
157:ID:EEKBitmg ◆HSP4mee/SU
09/04/07 00:44:42 lzvNjqQS
>>10
（；・∀・）えー、なにそれ。そんなむつかしーこと考えたことないよ厨房だから
ぜーんぶダイレクトエックスにお任せだよ
テクスチャは基本的にD3DPOOL_MANAGEDでロードしてる
（ポストエフェクト用のバッファとかはD3DPOOL_DEFAULTだけど）
＞一括解放するタイミングは存在せず、仕様切りなおしもできないとして
ナニそれよくわかんない。どんなゲームなの。
厨房はレベルデータをロードするときにテクスチャも何もかもまとめて
ガバーって読み込んじゃってるけど
数GBのメインメモリに数百MBのオンボードメモリを使い放題のやりたい放題だし
メモリ足りないド貧乏PCユーザーはHDDにスワップでジリジリやってろってかんじ
＞使用期間不定の大量のサイズ不定テクスチャをコンパクションを使わずにどう管理する？
寿命がわかんねー大量のサイズ不定テクスチャがあるってどんな状況なの？
厨房が作るゲームはリソースの寿命が明らかだから、よくわからない
158:名前は開発中のものです。
09/04/07 00:46:51 chqHE1jh
並列さんはポリアンナ症候群だろ
159:名前は開発中のものです。
09/04/07 01:22:29 TxMcBONy
>>155
本当に知ったかウザい
心中云々言ってたらBrewもiPhoneもDirectXもやってられません
160:名前は開発中のものです。
09/04/07 02:06:38 6TbCKYIt
HSPにXNA…
このスレにはマイナー言語に命かけてる人たちがいるねぇ
どっちもタスクシステム向きでないけど
161:名前は開発中のものです。
09/04/07 02:23:02 5k9r+ezc
HSPはともかくXNAをマイナー言語扱いするのはどうだろう
162:名前は開発中のものです。
09/04/07 03:00:31 7U5MSg6Z
>>159
任天堂系もＳＣＥ系もダメですね・・・
163:名前は開発中のものです。
09/04/07 12:38:34 d98F5Avl
>>156
あんたそのレベルの人なのか
164:名前は開発中のものです。
09/04/07 13:00:48 t5WTHMua
なんとかシステムとかつけるなら
スクラッチパッドみたいな局所メモリを活用するとか
ある程度ハード特化した実装にするのも手なのかな
GDC2009のGOW3の解説がなんというか燃える内容だったんだけど
URLﾘﾝｸ(game.watch.impress.co.jp)
これはもはやなんとかシステムとか呼ぶ範疇を超えてる気がするけど
将来はこういうのがなんとかシステムとか呼ばれるようになるのかね
165:名前は開発中のものです。
09/04/07 17:07:05 CbUdK8rx
確かにワンダつまんなかった。
ムービー見て終わり。
メタルギア4もそう。
166:名前は開発中のものです。
09/04/07 17:28:04 rVXLClOu
で？
技術批判できなくなったら今度はゲームそのものに攻撃か。
あたたかい頭してるな。
167:名前は開発中のものです。
09/04/07 19:14:31 1GDmqaJq
タスクシステム関係無いじゃん
168:名前は開発中のものです。
09/04/07 19:21:43 1GDmqaJq
タスクシステムもメリット挙げてみろって言われると
途端にはぐらかすからな
いろいろ虎の威を借るなんとやらで参考文献および資料ばっかりもってくるけど
そういうの自分の言葉で説明できるようになってからやらないと説得力ないよね
引用レスも引用したものがメインじゃ誰も相手にしないって
169:名前は開発中のものです。
09/04/07 19:25:38 CBx7pnt0
だからメリットはリンスインシャンプーだっての！
170:名前は開発中のものです。
09/04/07 20:08:43 WMY4fAPQ
お金稼げてるからいいんじゃね？
それを否定するともっとお金稼げるなら俺もアンチになる
171:名前は開発中のものです。
09/04/07 20:20:07 chqHE1jh
>>170
金がほしいならゲーム会社なんて辞めたほうがいいぞ
かなりマジで
業務系いけば、ゲーム系で月１４～５万でこき使われてる人ならいきなり給料倍とかある
172:名前は開発中のものです。
09/04/07 21:33:44 ulVvxTge
ID:EEKBitmgはもうあまりにレベルが低すぎて、みんなスルー状態だな。
173:名前は開発中のものです。
09/04/07 23:00:06 chqHE1jh
>>172
俺は並列のがうぜぇ
174:名前は開発中のものです。
09/04/07 23:06:56 2stCxtH4
まあフェードアウトオヤジ臭という意味では
並列さんとやね先生は同じ体臭を放ってるけどな
175:名前は開発中のものです。
09/04/07 23:23:22 wsnDcgD2
だいたい、アタマがまともな本職やセミプロは、こんなところで『オレ様スゲーだろwww』とか
書き散らかさないって。
176:名前は開発中のものです。
09/04/08 00:39:13 DU4wvLd/
本人も、今頃しまったと思ってるころだろ。
177:名前は開発中のものです。
09/04/08 01:29:22 9bhojcbs
てゆーかここ
どんだけ偉人ばっかりなんですかｗ
みんなめちゃくちゃ上から目線なんですけどｗｗｗｗ
178:名前は開発中のものです。
09/04/08 07:38:26 uu59oW9Z
別にそんな感じはしないけど
何か気に入らないレスが付いちゃった？
179:名前は開発中のものです。
09/04/08 09:16:12 Ju8SopqO
並列擁護は「第三者の"人達"から見て」 的なレスが多くてうんざりだな
国際社会とか地球市民とかそういう匂いがする
語ってる内容はどっちも滅茶苦茶なのでもうどうでもいいんだが
まあ勘違い分裂君劇場みたいなノリでヲチしようや
180:名前は開発中のものです。
09/04/08 09:18:37 0OsF5j6c
ワンダつまらんかったな。初日にクリアしてすぐ売った。
181:名前は開発中のものです。
09/04/08 10:02:02 DTjWnb4t
じゃ、そろそろタスクシステムについて議論していこうか。
182:名前は開発中のものです。
09/04/08 11:29:12 ZcZVPfWq
タスクシステムの主な役割
・単位時間内に1回何かを実行する為の窓口
・生存管理
・依存の管理
こんなものかな？
183:名前は開発中のものです。
09/04/08 12:10:26 6q9I65fW
タスクシステムはそこにある、ただそれだけだ
184:名前は開発中のものです。
09/04/08 20:23:55 uu59oW9Z
メリットやデメリットのあるタスクシステムなんてタスクシステムとは言えない
女子供は黙ってみてろ？
185:名前は開発中のものです。
09/04/08 23:24:44 Ju8SopqO
その疑問符は何だ？
186:名前は開発中のものです。
09/04/08 23:41:33 P81F6nRk
語尾上げで、柳原可奈子的可愛さを演出してみたんじゃないか？
187:名前は開発中のものです。
09/04/09 00:22:04 q+cTqKgL
むしろ姫ちゃん的な～？
188:名前は開発中のものです。
09/04/09 01:27:01 FGj8z8j8
そういう使い方にしても間違ってるような
189:名前は開発中のものです。
09/04/09 05:09:42 0O2qwazX
雑談ストップ？
190:名前は開発中のものです。
09/04/09 18:55:18 /k3TfSjT
タスクってCしかできない人のための技法？
191:名前は開発中のものです。
09/04/09 19:04:45 trH83J91
あまねく言語でタスクパターンは実装可能ですよ。
192:名前は開発中のものです。
09/04/09 20:14:35 /k3TfSjT
非常にサラッと内容をチラ見してきたけど、まあ特に議論するべきことでもないな
193:名前は開発中のものです。
09/04/09 22:57:42 n4y/QroV
FlashのSTGで、EntityとかActorとか作ってやってるのを見たことがあるな。
194:ID:EEKBitmg ◆HSP4mee/SU
09/04/09 23:40:00 vLLC2UDG
バカにつける薬は無いと言われることもあるけれど厨房は今日も元気です
さて、そんな厨房でもタスクシステムとかいう怪しげなものに取り憑かれる
人々というのが、なーんか筋の悪そうな人が多そうだなーということに気付く
筋が悪いというのは、ガラが悪いという意味では区、頭が鈍いというかバカ
というか、一から十まで具体的に作り方を手解きしてもらわないとなーんにも
動かすことができないセンスの悪そうな人、という意味
こういう生意気書くとまたボコられるわけですが、この直感は当たってると思う
>>128
例えばこういうの。もう何言ってるのかサッパリ分からない。思考が腐臭を放ってる。
＞・単位時間内に1回何かを実行する為の窓口
なにそれ。役立たずの糞みたいな仕掛けをねじ込もうとしてるだけじゃん。
居るだけ詐欺の盲腸の無駄飯食らいの穀潰しのないほうがマシな無駄な機構を
何故かゲームプログラムの中に噛ませたがるタスクバカの香りを放ってる
＞・生存管理
なにそれ。something managerなの？生存管理？何してくれるの？
タスクディスパッチャーが何で生死を司るの？ゲームのシミュレーション結果で
決定されることを、なぜタスクディスパッチャーごときが口を挟むの？設計腐ってない？
余計なお節介をして茶々を入れてくる強烈にウザイものにしか見えない。吐き気がする
＞・依存の管理
なにそれ。またsomething manager？依存の管理？何してくれるの？
タスクディスパッチャーに把握させる依存関係って具体的に何？それをどうしてくれるの？
なんか臭そう。
195:ID:EEKBitmg ◆HSP4mee/SU
09/04/09 23:43:36 vLLC2UDG
>>193
EntityやらActorやらいう要素があるのはごく自然なことだよね
でも、このスレのタスクバカに言わせれば、それはタスクシステムらしいよ。
バッチイからあっち行けって思う
196:名前は開発中のものです。
09/04/10 00:22:24 1GdYQJdO
なんで>>128が叩かれてるんだろうと思ったら>>182か
2chブラウザとか使ってないのかな
197:名前は開発中のものです。
09/04/10 00:25:41 4YdM/w1Y
関数インポがメインのタスクシステムを使わずにC++の仮想関数でやるのは速度不足か？
CPU４００MHZのPDA用に上記の方法で作ったことあるがとても快適に動作したがなあ。
携帯ならともかく今のハイスペックのマシンでタスクシステムいらんだろ
198:ID:EEKBitmg ◆HSP4mee/SU
09/04/10 00:33:26 FNQAiqo/
>>194
間違えた！>>182だった。>>128ごめんなさい＞＜
まぁ別に>>182にしても恨みはないからごめんなさい
199:名前は開発中のものです。
09/04/10 00:38:46 RpmvrcVd
>>197
関数いんぽとC++の仮想関数なら(規格には無いけど)同じ仕組みだから
もともと差はないはずだよ。
まあ、ろくに定義されてない言葉でループ必至のネタに
自転車置場の議論を楽しんでるだけなんでそういう真面目な話いらんねん。
200:ID:EEKBitmg ◆HSP4mee/SU
09/04/10 00:39:22 FNQAiqo/
>>197
別に関数アドレスや仮想関数が絶対悪だと言ってるわけじゃない
使い方の問題。使いどころの問題
わけも分からず処理を細切れにバラしてごちゃ混ぜ連結リストにぶち込んでなめて
スバラシーデース。自動デース。窓口デース。とか寝言ほざいてる間抜けが嫌いなんだ
201:名前は開発中のものです。
09/04/10 00:59:03 zmUDuwgv
>>199
C++の仮想関数は、関数ポインタからの関数呼び出しと比べると
普通の実装なら間接参照が1回増えるんじゃない？
差は無いってことは無いと思うよ。まぁ大した差じゃないと思うけど。
あとタスクシステムの場合の関数ポインタの使い方は、仮想関数の代わりというよりは
状態に合わせた処理に直接ジャンプする（状態による場合分けをなくす）という
意味合いが大きいんではなかろうか。
これもまぁテーブルジャンプを一段挟めばいいだけではあるけれど。
202:ID:EEKBitmg ◆HSP4mee/SU
09/04/10 01:21:33 FNQAiqo/
タスクバカのことだからvptrを書き換えて関数セットを丸ごと取り替えて喜んでそうだけどな
タスクバカって脳みそが中二のオジチャンだからさ、クラス図を完全無視して自在に変化する
オブジェクト、とかにワクワクするんじゃないかな
203:名前は開発中のものです。
09/04/10 01:34:48 zmUDuwgv
>>202
だからなんだよ。
うぜぇ。
204:名前は開発中のものです。
09/04/10 07:27:26 fVKjkvAM
まあ、要は退化してるってことだな
205:名前は開発中のものです。
09/04/10 08:01:06 Enyn0370
小沢 「外食しないと言ったんだから、チャーハン作れ」
麻生 「じゃあまずご飯炊かないと・・・・・」
小沢 「なぜご飯を炊くんだ！ご飯を炊く暇があったらチャーハン作れよ！」
麻生 「ご飯を炊かなきゃチャーハン作れないよ。お米研いだだけだし」
小沢 「そんなことは聞いていない。今すぐチャーハンは作れるのか」
麻生 「（まずご飯炊かないといけないから）今すぐには作れない」
小沢 「外食止めたんだぞ、今すぐに作るのが筋じゃないか！」
麻生 「お米研ぐ→ご飯炊く→チャーハン作る、なのわかる？三・段・階。わかる？」
小沢 「とにかく、すぐチャーハン作れ！」
206:名前は開発中のものです。
09/04/10 09:36:54 yz3HG861
>>205 +民は巣でやってろ
207:名前は開発中のものです。
09/04/10 11:21:34 BJAImmDI
ID:EEKBitmg ◆HSP4mee/SU は
メモリ何ギガもあるマシンだけを対象にしたゲームをシコシコ作ってなさい。
208:名前は開発中のものです。
09/04/10 12:00:12 GpZ/KC5r
なんか面白そうな話題だったのにHSPしか使えない馬鹿が
暴れたせいで途端にスレのレベルが下がったな
こいつ、いい加減、いなくならねーかな
209:名前は開発中のものです。
09/04/10 12:54:33 Y8VaBVxa
このお題（タスクシステムの是非）に関しては、アンチ側が中東の米軍並みに有利なはずなのに
なんで互角以下の劣勢なんだ？
210:名前は開発中のものです。
09/04/10 13:04:18 ytUDTzAB
コテつけてまで自己顕示するほどのアンチってタスクバカよりたちわるいね
211:名前は開発中のものです。
09/04/10 13:05:59 ytUDTzAB
クラス図とか、オブジェクト指向言語、オブジェクト指向プログラミングはこうあるべしという強迫観念の最たるものだよね
212:名前は開発中のものです。
09/04/10 17:33:29 1zCtaiSY
>面白そうな話題
kwsk
213:名前は開発中のものです。
09/04/10 18:30:28 LKxV/Lgc
誰でもいいからそろそろ、
タスクシステムはこうこうこういうところがダメだから
これからはこうこうこういうものを使うべきだ！
って主張してくれねーかな。
ちなみにタスクシステムを実際に使ったことなかったりするのは論外。
説得力がまるで無いし、比較しないと意味が無い。
あと、机上の理論を聞いてもしょうがないので、
こういうものに移行したらこういうメリットがあったって話も聞きたい。
喧嘩したいだけのお子様や
妄想たっぷりのニートはもうお腹いっぱいです。
214:名前は開発中のものです。
09/04/10 19:08:05 KfvFah+k
実際にお仕事してきてるなら、タスクシステムは経験してるはずだよね
215:名前は開発中のものです。
09/04/10 19:56:07 fVKjkvAM
ダメだの前にメリットをあげてくれよ
話を元に戻そうか？(笑)
タスクシステムのメリットってなんですか？
216:名前は開発中のものです。
09/04/10 20:02:44 sH8kBZbv
本職の人は守秘義務とかあるし、具体的な話はできないんじゃない？
217:名前は開発中のものです。
09/04/10 20:06:05 0HZaI+RC
タスク厨:デメリットあげろ
アンチタスク:メリットあげろ
どっちも説明するつもりないんだな
まぁ面倒なのはよくわかるけど
218:名前は開発中のものです。
09/04/10 20:52:43 GZm91cCj
タスクシステム派に足りないのは
「大規模C++ソフトウェアデザイン」の「5.2 昇位（escalation）」の概念。
上位レベルコンポーネントの存在を軽視しすぎ。
そして巡回依存性、相互依存性の怖さを軽視しすぎ。
5ページだけ、立ち読みでいいから１度読むといい
219:名前は開発中のものです。
09/04/10 21:03:03 KfvFah+k
教えてもらったとおりの発想とスタイルでしかプログラミングできないんすなぁ
220:名前は開発中のものです。
09/04/10 21:07:37 GZm91cCj
>>219
お仕事でタスクシステムを教わったんですね
分かります
221:名前は開発中のものです。
09/04/10 21:13:36 9juAqapQ
タスクシステムを使った イコール 相互依存性があがる
というわけではないしなぁ。
222:名前は開発中のものです。
09/04/10 21:19:09 I/tIMbxt
俺良く分らんながら考えてたんだがＣ＋＋でタスクシステム実装しようとすると面倒にならないか
Ｃのが合うんじゃないの
223:名前は開発中のものです。
09/04/10 21:22:56 o/eQJnMQ
もともとCやアセンブラで考え出されたものだからね
224:名前は開発中のものです。
09/04/10 21:26:49 o/eQJnMQ
Windowsプログラムのカーネルはタスク処理だが、（イメージが違うけど）
窓AP作成のユーザーから見れば、イベントドリブンのシステムだから。
タスク部分はフレームワークに吸収してもいいかもしれん。
225:名前は開発中のものです。
09/04/10 22:34:08 GZm91cCj
>>221
そこでもう一押し、「相互依存性を完全除去」まで行くと違いが見える。
10から1にするのはどっちもできるが、1から0にできるのは片方だけ。
0にすると設計の見通しが利く。小さいようで大切なこと。
226:名前は開発中のものです。
09/04/10 23:09:59 GZm91cCj
具体的に脱タスクシステムでやることは単純、・・・でもないけど下記の通り。
もし相互依存性があるオブジェクト群があったら、
１、オブジェクト群の上位に親クラスを作成する
２、オブジェクト群の相互依存箇所を抽出して親クラスのメソッドにまとめる
これを相互依存性が無くなるまで繰り返す。（相互依存性の多さにあらビックリ）
同位のオブジェクト間の相互依存性は上位に丸投げして解決してもらう。
１アンチとしてはこれお勧め。
227:名前は開発中のものです。
09/04/11 02:21:52 GEBPDovg
タスクにはデメリットになりうる注意点が多々あると思うが、利用者側が注意してタスク実装していけば回避できる箇所も多い
あと、汎用的なタスク設計は存在しなくて、作るゲームによってその都度チューニングしてる
なんだかんだ言ってもタスクは便利なんだよね
228:名前は開発中のものです。
09/04/11 02:23:50 pUi3qAut
汎用部分はベースクラスにして継承して振る舞いを実装するとおもうのだが・・・
229:名前は開発中のものです。
09/04/11 02:30:57 FAassbBg
とりあえず確認させてくれ
おまえらバズワードって言葉知ってるか？
230:名前は開発中のものです。
09/04/11 02:36:07 pR/Rfe6E
「>>2」のことか？
231:名前は開発中のものです。
09/04/11 02:39:50 GEBPDovg
勿論継承するのがいいんだけど、色々と制限厳しい開発なんで、タスク周りはプロジェクト毎に直すようにしてる
タスクは総じて癖が強いが、扱い慣れるとごりごり書けるのがいいよね。プロジェクト終盤のデスマで有用だった。
232:名前は開発中のものです。
09/04/11 07:11:31 JQKbxyD0
スレッドでいいじゃん
233:名前は開発中のものです。
09/04/11 08:44:55 VwbI10yZ
並列はもう出てこれないだろうな
234:名前は開発中のものです。
09/04/11 09:54:27 BwFqfbII
>>225
別に相互に依存する必要がないならば、
タスクシステムでも相互依存性は0にできると思うけど。
235:名前は開発中のものです。
09/04/11 12:09:00 shgrRKkW
>>226
結局コードが膨れ上がるだけじゃないすか
本人は奇麗にまとめ上げた気分で気持ちいいかもしれないけど、無駄な作業すなぁ
236:名前は開発中のものです。
09/04/11 12:10:53 shgrRKkW
アンチの意見で、なるほどコレは参考になるっていうのが無いのう
まだ並列さんのが実際の現場の実装の片鱗を語ってるだけあってよかった
237:名前は開発中のものです。
09/04/11 12:13:12 lG5C2wBT
>>234
相互依存性が 0 ならプロジェクト毎に直すなんてことにはならない。
238:名前は開発中のものです。
09/04/11 12:17:32 FPJVr62U
>>237
相互依存性が 0でもジャンルとかプラットフォームの世代が
異なればそれにあったものに変更すると思うが。
239:名前は開発中のものです。
09/04/11 12:18:00 lG5C2wBT
>>235
依存性を排除してモジュール化を進めていけば再利用可能なコードができる。
「再利用」っていうのはプロジェクト毎にコピーしていじるってことじゃないよ。
同時に、既存のコード（ C++ 標準ライブラリや Boost など含む）と組み合わせることが
やりやすくなる。そうなれば理解しやすい形に近づくことにもなる。
お釣りがくるよ。
240:名前は開発中のものです。
09/04/11 12:19:09 shgrRKkW
所詮開発厨なんだから、はりきる必要はないべ
形にさえなればオケオケ
どんなに奇麗に実装したところで、厨にミソカスに言われるだけなのにね
241:名前は開発中のものです。
09/04/11 12:21:46 lG5C2wBT
>>238
それは「変更する」部分がジャンルとかプラットフォーム世代に依存してる状態だろ。明らかに。
242:名前は開発中のものです。
09/04/11 12:25:31 FPJVr62U
>>241
それらに一切依存しない、なんてシステムが現実的に使い物になるのかね。
なんか机上の理屈をこねてるだけのような感じがするな。
243:名前は開発中のものです。
09/04/11 12:27:26 lG5C2wBT
>>236,240
並列さんの話が「現場の～」だと信じられるのに、依存性の排除は主観で拒絶か。
自分の考えに近いかどうかが判断基準なんだろうな。おめでてーな。
244:名前は開発中のものです。
09/04/11 12:31:13 hS6DOynO
>>237, 243
ジャンルやプラットフォームに依存しないタスクシステムは作れるし、
それでやってるところはあるよ。
ただ、そういうのって汎用的になりすぎてむしろ使いづらいから
ジャンル毎にカスタマイズするところもあるってだけの話。
>自分の考えに近いかどうかが判断基準なんだろうな。おめでてーな。
でた！自己PR！
245:名前は開発中のものです。
09/04/11 12:32:24 lG5C2wBT
>>242
たとえば C++ 標準ライブラリはゲームのジャンルやプラットフォームの世代に
一切依存しないが、現実のゲーム開発でもとても有用だ。わかりやすい話だろ。
246:名前は開発中のものです。
09/04/11 12:35:37 FPJVr62U
PS1世代は完全にC++使えなかったし、PS2でもローンチではSCEはC++を非推奨にしてたけど…
C++標準ライブラリがゲーム機で普通に使えるようになったのってXBOX/PS3/360からだよ。
これほどプラットフォームの世代に依存してるものを「一切依存しない」って…
247:名前は開発中のものです。
09/04/11 12:37:34 VwbI10yZ
C++標準ライブラリでゲームで便利なものって何かあったっけ？
248:名前は開発中のものです。
09/04/11 12:37:59 lG5C2wBT
>>244
その「カスタマイズ」というのがコードを変更することではなく、ジャンルに合わせて
使い方を変えるということなら問題ない。そうではなくてプロジェクト内にコードを
コピーしていじる必要があるのなら、それはまだ依存性の問題が残っているということ。
要するに "Open-Closed Principle" というやつ。
URLﾘﾝｸ(www.morijp.com)
「モジュールは拡張に対して開いて (Open) おり，修正に対して閉じて (Closed) いなければならない」
249:名前は開発中のものです。
09/04/11 12:42:39 VwbI10yZ
>>248
タスクシステムはライブラリではなくフレームワークだからコピーでよい。
コピーしない方針なら、継承使って拡張していくことになるが、
コピーできる環境なら継承よりコピーの方が良い。
250:名前は開発中のものです。
09/04/11 12:43:36 hS6DOynO
完全にライブラリ化してるタスクシステムあるけど。
というわけで、依存性の話はタスクと関係ないってことで
じゃ、依存性がどーたらという話はこれで終ね。
251:名前は開発中のものです。
09/04/11 12:48:00 lG5C2wBT
>>246
それらの制限は当時のコンパイラやライブラリ実装の問題のせい。依存性の問題じゃない。
たとえば同じ仕様の標準ライブラリが、新しい gcc のレベルならそれらのプラットフォームでも
余裕で使えるだろう。
例が理解しにくかったのなら「C 標準ライブラリ」に置き換えて読み直してみるといい。同じ話だ。
252:名前は開発中のものです。
09/04/11 12:48:57 VwbI10yZ
だから、タスクシステムはライブラリというよりはむしろフレームワークだ。
頭の悪い奴だな。
253:名前は開発中のものです。
09/04/11 12:52:12 FPJVr62U
>>251
>それらの制限は当時のコンパイラやライブラリ実装の問題のせい。依存性の問題じゃない。
プラットフォームの性能からくる制約を一切無視してるなぁ…
gcc自体は当時でも余裕でC++対応してたのに、なんでPS1で使えないようにしてたか、考えてみた方がいいかも。
それに「C標準ライブラリ」だってSFC時代のゲーム中動的にmalloc使うなんて考えられない、というハード世代を考えると同じこと。
254:名前は開発中のものです。
09/04/11 12:55:32 lG5C2wBT
>>249
> コピーできる環境なら継承よりコピーの方が良い。
コードをコピーしたほうが良い？最悪だろ、常識的に考えて。
コピー元がバグってたらいっこずつ直して回るはめになるんだぞ？
それに対して、何が「良い」というの？
「ライブラリではなくフレームワークだからコピーでよい」というのも理屈がわからんな。
ライブラリとフレームワークとのどういう違いからそういう話になるの？
とりあえず Wikipedia 見てみたが、「コピーでよい」となるような話は見当たらなかった。
URLﾘﾝｸ(ja.wikipedia.org)
255:名前は開発中のものです。
09/04/11 12:56:31 hS6DOynO
↑依存君と名付けよう
256:名前は開発中のものです。
09/04/11 13:00:19 FPJVr62U
5年周期でハードが一新されて、そのハードをどこまで使い切るかが
売り上げに影響するゲームプログラムというジャンルで、
どこかの本にのっていた「再利用性」って教義を原理主義者みたいに唱えて
「8bitのハードでも64bitのハードでも変更無く使えるプログラムが正しい。」
なんて、頭がお花畑のゆとり発想だよ…
こーゆー分野ではタスクみたいにハード世代にあわせて、動的メモリ確保しない、とか
リスト＋ポインタ、とか仮想関数で、とか、環境にあった実装を別にした方がいい。
257:名前は開発中のものです。
09/04/11 13:04:37 VwbI10yZ
>>254
頭悪いんだったら黙ってろよ。
>コードをコピーしたほうが良い？最悪だろ、常識的に考えて。
>コピー元がバグってたらいっこずつ直して回るはめになるんだぞ？
逆に色んなプロジェクトから参照されまくってたら、
もはやバグを直すタイミングすらないのだが。
258:名前は開発中のものです。
09/04/11 13:42:34 GEBPDovg
>>256
共感できるわ。
自分も再利用性などを考慮していたらいつまで経っても終わらないし、無駄に肥大になったり使い勝手が悪いので、
とりあえずタスクベースとなるコードをコピーしてきてゲーム毎にカスタマイズして使うことにしてる。
259:名前は開発中のものです。
09/04/11 13:53:14 lG5C2wBT
>>253
んー。そういう性能の要求っていう依存があることも確かにあるねぇ。
じゃぁ >245 の例を qsort() なり std::sort() なりに置き換えて読み直してみてもらえると
言いたかったことは伝わってくれないだろうか？
260:名前は開発中のものです。
09/04/11 13:59:34 hS6DOynO
>>259
アホ、依存性を無くした方がいいっつーことはみんなわかってんの。
でも、完全に無くすなんてのは現実的に難しいし、
そうするべきでもないことがあんの。
理想と現実っての知れよ。
最近本で読んで嬉しくて触れ回りたいんだろうけど、
アホみたいに理想論言ってないで現実を見ろ。
261:名前は開発中のものです。
09/04/11 14:11:22 lG5C2wBT
>>256
> 「8bitのハードでも64bitのハードでも変更無く使えるプログラムが正しい。」
そのほうがいいのは確かだろ？
で、今は全体的なスペックの向上やコンパイラの進歩によって移植性の高い、
再利用性の高いプログラムを書くことはかなり現実的になってきている。
今時、動的確保しないとか仮想関数使うかどうか、とか、そんなところの違いで
「ハードをどこまで使い切るか」というような差が出るなんて考えられないでしょ。
262:名前は開発中のものです。
09/04/11 14:14:18 lG5C2wBT
>>257
> 逆に色んなプロジェクトから参照されまくってたら、
> もはやバグを直すタイミングすらないのだが。
バージョン管理ツール使ってればそんなことにはならない。
テスト段階に入っていて最新のバグ修正を入れることが得策でないプロジェクトは
バージョン固定するなりブランチ作るなりすればいいよ。
263:名前は開発中のものです。
09/04/11 14:19:50 lG5C2wBT
>>258,260
完全に依存をなくせとは言わないけど、せめてプロジェクト毎にコピーしていじるとか
恐ろしいことを堂々と言わない程度にはモジュール化できるだろってこと。
そんなに本質的に切り離しが難しい依存関係ってどんなのがあるの？
そういう例を挙げてもらえると話がわかるかもしれない。
264:名前は開発中のものです。
09/04/11 14:24:42 hS6DOynO
「完全に依存をなくせとは言わない」とか寝ぼけてんのか…？
お前が「完全に依存をなくせ」って言ったからこの議論が発生したのに。
221 名前：名前は開発中のものです。[sage] 投稿日：2009/04/10(金) 21:13:36 ID:9juAqapQ
タスクシステムを使った イコール 相互依存性があがる
というわけではないしなぁ。
225 名前：名前は開発中のものです。[sage] 投稿日：2009/04/10(金) 22:34:08 ID:GZm91cCj
>>221
そこでもう一押し、「相互依存性を完全除去」まで行くと違いが見える。
10から1にするのはどっちもできるが、1から0にできるのは片方だけ。
0にすると設計の見通しが利く。小さいようで大切なこと。
265:名前は開発中のものです。
09/04/11 14:37:57 VwbI10yZ
>>262
バージョン管理ツールが各プロジェクト責任者に自動で了承取ってくれるのか？
266:名前は開発中のものです。
09/04/11 14:39:53 lG5C2wBT
>>264
ごめん、それ、違う人。
あぁ、「最近本で読んで」とか言われてたのはそのせいか。 >218 の本も読んだこと無いよ。
まぁ基本的にその人と考えてることは同じなんだろうけど、「依存」の中に大昔の
ハードの制約とかも入るような話になっちゃったら 0 にしろとは言い切れないねぇ。
267:名前は開発中のものです。
09/04/11 14:44:16 hS6DOynO
結局タクスシステムとは関係ない話ということでよろしいか？
268:名前は開発中のものです。
09/04/11 14:47:58 VwbI10yZ
いやあるね。
基本的にタスクシステム自体がゲーム仕様に「依存」するからこういう展開になるわけで。
269:名前は開発中のものです。
09/04/11 14:50:55 lG5C2wBT
>>267
依存関係の切り離しも含めてモジュール分割やコード再利用の努力をすれば、
すぐにタスクシステムなんてものは標準コンテナや仮想関数を持った
インターフェースクラスなどに分解され、残るのはゲーム依存部分となり
システムと呼ぶほどのものは残らなくなるだろう、と考えている。
そういう意味でも >263 の質問に答えが欲しい。あと >254 も、かなぁ。
270:名前は開発中のものです。
09/04/11 14:51:36 FPJVr62U
>>266
ハードの制約は大昔も未来も変わらんよ。
非対称マルチコアに最適なタスク管理とか、最近はそっちの方面に流れてるし
実行環境を一切考慮しない唯一の最適なシステムなんてハードが進化し続ける限り不可能。
271:名前は開発中のものです。
09/04/11 14:58:23 VwbI10yZ
>>269
答えがほしいってなんだよ。
自分でやってみればよいだろ。すぐに問題に気が付くから。
272:名前は開発中のものです。
09/04/11 14:58:59 lG5C2wBT
>>270
唯一最適である必要は無い。適切に分割され、要求に応じて組み合わせられるように
なっていればいい。
それなりのサイズの例としては、 C++ 標準ライブラリとか、 C++0x の
乱数発生器フレームワークとか、 shared_ptr, weak_ptr などのスマートポインタ郡とかね。
273:名前は開発中のものです。
09/04/11 15:10:54 VwbI10yZ
だからフレームワークとライブラリは違うってのに。
274:名前は開発中のものです。
09/04/11 15:34:22 62IWIIqa
開発者のオナヌーか
マルチに使えるライブラリうんまーとかは開発者の自己満足
環境に応じて、ゴリゴリに書け
275:名前は開発中のものです。
09/04/11 16:07:14 FPJVr62U
再利用性とか保守性とか、プログラムの一般論としては良いこと、なんだけど
ゲームでそれをするコストに見合うケースは少ないからね…
MMOのクライアントや定番スポーツゲームとか一部の例外を除く
大部分のゲームは再利用も保守も必要ないケースがほとんど。
続編でも旧プラットフォームで作ったチープな仕様のものを再利用して
現行機にもってくる、なんてことはまず無いし。
276:名前は開発中のものです。
09/04/11 16:13:26 hS6DOynO
>>269
>すぐにタスクシステムなんてものは標準コンテナや仮想関数を持った
>インターフェースクラスなどに分解され、残るのはゲーム依存部分となり
>システムと呼ぶほどのものは残らなくなるだろう、
何いってんの？
あらゆるシステムは分解すればシステムと呼ぶものは残らないのは当たり前。
それら使いを組み立てたものをシステムと呼ぶんだろ。
>>272
>それなりのサイズの例としては、 C++ 標準ライブラリとか、 C++0x の
>乱数発生器フレームワークとか、 shared_ptr, weak_ptr などのスマートポインタ郡とかね。
それらを使ってシステムを構築するんだろ。
277:名前は開発中のものです。
09/04/11 16:56:46 xXQkL000
タスクシステムとフレームワーク関係なくね？
フレームワークってハードウェアの差異を抽象化するためのものでしょ。
つまりゲームに特化したOSでしょ。
タスクシステムってハードウェアの差異を抽象化する機能あったか？
単なる自作マルチスレッドライブラリっていう位置づけがせいぜいじゃね。
278:名前は開発中のものです。
09/04/11 18:20:01 pUi3qAut
タスクシステムはゲーム用フレームワークで重要な位置にいるのがわからんのかね。
279:名前は開発中のものです。
09/04/11 19:04:53 si1b3yop
ハリウッドの法則とかしらんのかな
280:名前は開発中のものです。
09/04/11 20:03:09 H/Wfcxcz
このスレのアンチタスク派、頭が悪すぎるだろ。
ろくに実務経験が無いのか、下っ端すぎてゲームライブラリやシステム部分
の製作に参加させてもらえていないのかは知らないが、ゲームの仕様が完全に
決まるまで1行もコード書かない(書けない)とか、いくらなんでもひどいすぎる。
281:名前は開発中のものです。
09/04/11 21:11:36 FAassbBg
都合の良いレス以外は読めないんですね
282:名前は開発中のものです。
09/04/11 21:22:43 FAassbBg
いくつもタスクシステムと称するものを使ったソースを読んでるけど(学生レベルのカスレベルのプログラマ作のものもあれば、ファミコン時代から今までやってるベテランのも)
経験の差、思想の違いだけじゃなく
同じ人でもプラットフォームや言語が違うだけで
タスクシステムの役割や意味するもの、形態が違ってた。
タスクシステムはバズワードでしかない
メリットデメリット云々言うのは野暮
あとプロジェクトを特定せずタスクシステムって言葉を使うのは悪だと思う
283:名前は開発中のものです。
09/04/11 21:25:34 xh1QSD+J
つーかアンチは喧嘩したいだけで
真面目に議論する気がないんだから決着着くわけ無いじゃん。
284:名前は開発中のものです。
09/04/11 21:32:27 xQkqf/c4
にしても、前スレだか前々スレだかに居た引数クンのやり方は無い。
あれはキチガイ。
285:名前は開発中のものです。
09/04/12 00:09:59 dmMqUOrY
タスクと聞くとVOWの渡辺タスクを思い出して笑ってしまう
286:名前は開発中のものです。
09/04/12 12:42:11 BK6ZAbdT
>>284
やってないからそう思えるだけ
実は引数を通したほうがバグ数も格段に低くなって結果的に楽
オブジェクト指向なんて役に立たないもの理解してる暇があったら
まずは引数をキチンと通す組み方を学ぶべき
簡単なプログラムから「グローバル変数・関数を一切使わない」ルールで
一度組んでみて徐々に仕事でも自分の担当するところだけでも
グローバル変数・関数の影響をなるべくうけないように組んでいく
これができるだけでプログラマとしてのレベルはそこらにいる奴等とは
比べ物にならないぐらい上がる
これができるようになることで汎用化できるものと汎用化できないものの判断ができるようになる
（お前等はクズだからこの「汎用化『できないもの』」の判断ってのが苦手っていうかできないだろ？）
287:名前は開発中のものです。
09/04/12 12:47:22 zCE7iHyh
じゃあ、グローバル変数はともかく、
グローバル関数を使わない理由を説明してみ？
288:名前は開発中のものです。
09/04/12 12:52:49 kray0MQN
>>286
>オブジェクト指向なんて役に立たないもの理解してる暇があったら
わぉ
構造化プログラム時代のまま20年間時間が止まったままの人がいるよ
80年代のプログラマが現代にタイムスリップですか？
289:名前は開発中のものです。
09/04/12 13:01:05 dWUYp7ZA
>>286
オブジェクトで渡した方がいいじゃん。
どうせアクセサ経由だし、バラバラに引数渡すよりもバグが入らないね。
290:名前は開発中のものです。
09/04/12 13:26:34 vw2uNoL2
スパゲティプログラムをずるずる書くようなレベルの奴が、
オブジェクト指向なんぞに手を出すのは早すぎ、ということを
言い損なってるだけだろ。
291:名前は開発中のものです。
09/04/12 13:59:53 bCeAm0TS
グローバル関数使わない利点が真面目に分からないのだが。
グローバル変数使うなってのは聞いたことあるが。
というか、Cだと基本的にグローバル関数だよな。
てことはC++でメソッドのみで書けってことなんだろうけど、
C++のメンバ変数ってある意味クラス内でのグローバル変数だから、
グローバルがダメならメンバ変数もダメだよな。
てことは一体・・・。
struct hoge
{
int x, y, z;
};
class hoge_funcs
{
public:
static void func1(int &x, int &y, int &z){}
static void func2(int &x, int &y, int &z){}
};
int main()
{
hoge h;
hoge_funcs::func1( h.x, h.y, h.z );
hoge_funcs::func1( h.x, h.y, h.z );
}
こういうことですね、分かります。