タスクシステム総合スレ part6

**名前は開発中のものです。** · 2009/04/03(金) 11:25:39

タスクシステムについての議論、相談、質問、雑談などのスレです

part5 http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/
part4 http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/
part3 http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/
part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

・タスクと呼ばれる実装は、非常に多岐に渡ります
　古典タスクシステムについての話題は「>>2」と明示してください
　そうでない場合はカスタム版であることを明示してください

・人を憎んで言語を憎まず

**名前は開発中のものです。** · 2009/04/11(土) 12:17:32

>>237
相互依存性が 0でもジャンルとかプラットフォームの世代が
異なればそれにあったものに変更すると思うが。

**名前は開発中のものです。** · 2009/04/11(土) 12:18:00

>>235
依存性を排除してモジュール化を進めていけば再利用可能なコードができる。
「再利用」っていうのはプロジェクト毎にコピーしていじるってことじゃないよ。
同時に、既存のコード（ C++ 標準ライブラリや Boost など含む）と組み合わせることが
やりやすくなる。そうなれば理解しやすい形に近づくことにもなる。

お釣りがくるよ。

**名前は開発中のものです。** · 2009/04/11(土) 12:19:09

所詮開発厨なんだから、はりきる必要はないべ
形にさえなればオケオケ
どんなに奇麗に実装したところで、厨にミソカスに言われるだけなのにね

**名前は開発中のものです。** · 2009/04/11(土) 12:21:46

>>238
それは「変更する」部分がジャンルとかプラットフォーム世代に依存してる状態だろ。明らかに。

**名前は開発中のものです。** · 2009/04/11(土) 12:25:31

>>241
それらに一切依存しない、なんてシステムが現実的に使い物になるのかね。
なんか机上の理屈をこねてるだけのような感じがするな。

**名前は開発中のものです。** · 2009/04/11(土) 12:27:26

>>236,240
並列さんの話が「現場の～」だと信じられるのに、依存性の排除は主観で拒絶か。
自分の考えに近いかどうかが判断基準なんだろうな。おめでてーな。

**名前は開発中のものです。** · 2009/04/11(土) 12:31:13

>>237, 243
ジャンルやプラットフォームに依存しないタスクシステムは作れるし、
それでやってるところはあるよ。

ただ、そういうのって汎用的になりすぎてむしろ使いづらいから
ジャンル毎にカスタマイズするところもあるってだけの話。

>自分の考えに近いかどうかが判断基準なんだろうな。おめでてーな。
でた！自己PR！

**名前は開発中のものです。** · 2009/04/11(土) 12:32:24

>>242
たとえば C++ 標準ライブラリはゲームのジャンルやプラットフォームの世代に
一切依存しないが、現実のゲーム開発でもとても有用だ。わかりやすい話だろ。

**名前は開発中のものです。** · 2009/04/11(土) 12:35:37

PS1世代は完全にC++使えなかったし、PS2でもローンチではSCEはC++を非推奨にしてたけど…
C++標準ライブラリがゲーム機で普通に使えるようになったのってXBOX/PS3/360からだよ。

これほどプラットフォームの世代に依存してるものを「一切依存しない」って…

**名前は開発中のものです。** · 2009/04/11(土) 12:37:34

C++標準ライブラリでゲームで便利なものって何かあったっけ？

**名前は開発中のものです。** · 2009/04/11(土) 12:37:59

>>244
その「カスタマイズ」というのがコードを変更することではなく、ジャンルに合わせて
使い方を変えるということなら問題ない。そうではなくてプロジェクト内にコードを
コピーしていじる必要があるのなら、それはまだ依存性の問題が残っているということ。

要するに "Open-Closed Principle" というやつ。
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp-2.html
「モジュールは拡張に対して開いて (Open) おり，修正に対して閉じて (Closed) いなければならない」

**名前は開発中のものです。** · 2009/04/11(土) 12:42:39

>>248
タスクシステムはライブラリではなくフレームワークだからコピーでよい。
コピーしない方針なら、継承使って拡張していくことになるが、
コピーできる環境なら継承よりコピーの方が良い。

**名前は開発中のものです。** · 2009/04/11(土) 12:43:36

完全にライブラリ化してるタスクシステムあるけど。

というわけで、依存性の話はタスクと関係ないってことで
じゃ、依存性がどーたらという話はこれで終ね。

**名前は開発中のものです。** · 2009/04/11(土) 12:48:00

>>246
それらの制限は当時のコンパイラやライブラリ実装の問題のせい。依存性の問題じゃない。
たとえば同じ仕様の標準ライブラリが、新しい gcc のレベルならそれらのプラットフォームでも
余裕で使えるだろう。

例が理解しにくかったのなら「C 標準ライブラリ」に置き換えて読み直してみるといい。同じ話だ。

**名前は開発中のものです。** · 2009/04/11(土) 12:48:57

だから、タスクシステムはライブラリというよりはむしろフレームワークだ。
頭の悪い奴だな。

**名前は開発中のものです。** · 2009/04/11(土) 12:52:12

>>251
>それらの制限は当時のコンパイラやライブラリ実装の問題のせい。依存性の問題じゃない。
プラットフォームの性能からくる制約を一切無視してるなぁ…
gcc自体は当時でも余裕でC++対応してたのに、なんでPS1で使えないようにしてたか、考えてみた方がいいかも。
それに「C標準ライブラリ」だってSFC時代のゲーム中動的にmalloc使うなんて考えられない、というハード世代を考えると同じこと。

**名前は開発中のものです。** · 2009/04/11(土) 12:55:32

>>249
> コピーできる環境なら継承よりコピーの方が良い。
コードをコピーしたほうが良い？最悪だろ、常識的に考えて。
コピー元がバグってたらいっこずつ直して回るはめになるんだぞ？

それに対して、何が「良い」というの？

「ライブラリではなくフレームワークだからコピーでよい」というのも理屈がわからんな。
ライブラリとフレームワークとのどういう違いからそういう話になるの？
とりあえず Wikipedia 見てみたが、「コピーでよい」となるような話は見当たらなかった。
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF

**名前は開発中のものです。** · 2009/04/11(土) 12:56:31

↑依存君と名付けよう

**名前は開発中のものです。** · 2009/04/11(土) 13:00:19

5年周期でハードが一新されて、そのハードをどこまで使い切るかが
売り上げに影響するゲームプログラムというジャンルで、
どこかの本にのっていた「再利用性」って教義を原理主義者みたいに唱えて
「8bitのハードでも64bitのハードでも変更無く使えるプログラムが正しい。」
なんて、頭がお花畑のゆとり発想だよ…

こーゆー分野ではタスクみたいにハード世代にあわせて、動的メモリ確保しない、とか
リスト＋ポインタ、とか仮想関数で、とか、環境にあった実装を別にした方がいい。

**名前は開発中のものです。** · 2009/04/11(土) 13:04:37

>>254
頭悪いんだったら黙ってろよ。

>コードをコピーしたほうが良い？最悪だろ、常識的に考えて。
>コピー元がバグってたらいっこずつ直して回るはめになるんだぞ？

逆に色んなプロジェクトから参照されまくってたら、
もはやバグを直すタイミングすらないのだが。

**名前は開発中のものです。** · 2009/04/11(土) 13:42:34

>>256
共感できるわ。
自分も再利用性などを考慮していたらいつまで経っても終わらないし、無駄に肥大になったり使い勝手が悪いので、
とりあえずタスクベースとなるコードをコピーしてきてゲーム毎にカスタマイズして使うことにしてる。

**名前は開発中のものです。** · 2009/04/11(土) 13:53:14

>>253
んー。そういう性能の要求っていう依存があることも確かにあるねぇ。

じゃぁ >245 の例を qsort() なり std::sort() なりに置き換えて読み直してみてもらえると
言いたかったことは伝わってくれないだろうか？

**名前は開発中のものです。** · 2009/04/11(土) 13:59:34

>>259
アホ、依存性を無くした方がいいっつーことはみんなわかってんの。

でも、完全に無くすなんてのは現実的に難しいし、
そうするべきでもないことがあんの。
理想と現実っての知れよ。

最近本で読んで嬉しくて触れ回りたいんだろうけど、
アホみたいに理想論言ってないで現実を見ろ。

**名前は開発中のものです。** · 2009/04/11(土) 14:11:22

>>256
> 「8bitのハードでも64bitのハードでも変更無く使えるプログラムが正しい。」

そのほうがいいのは確かだろ？

で、今は全体的なスペックの向上やコンパイラの進歩によって移植性の高い、
再利用性の高いプログラムを書くことはかなり現実的になってきている。

今時、動的確保しないとか仮想関数使うかどうか、とか、そんなところの違いで
「ハードをどこまで使い切るか」というような差が出るなんて考えられないでしょ。

**名前は開発中のものです。** · 2009/04/11(土) 14:14:18

>>257
> 逆に色んなプロジェクトから参照されまくってたら、
> もはやバグを直すタイミングすらないのだが。

バージョン管理ツール使ってればそんなことにはならない。
テスト段階に入っていて最新のバグ修正を入れることが得策でないプロジェクトは
バージョン固定するなりブランチ作るなりすればいいよ。

**名前は開発中のものです。** · 2009/04/11(土) 14:19:50

>>258,260
完全に依存をなくせとは言わないけど、せめてプロジェクト毎にコピーしていじるとか
恐ろしいことを堂々と言わない程度にはモジュール化できるだろってこと。

そんなに本質的に切り離しが難しい依存関係ってどんなのがあるの？
そういう例を挙げてもらえると話がわかるかもしれない。

**名前は開発中のものです。** · 2009/04/11(土) 14:24:42

「完全に依存をなくせとは言わない」とか寝ぼけてんのか…？
お前が「完全に依存をなくせ」って言ったからこの議論が発生したのに。

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にすると設計の見通しが利く。小さいようで大切なこと。

**名前は開発中のものです。** · 2009/04/11(土) 14:37:57

>>262
バージョン管理ツールが各プロジェクト責任者に自動で了承取ってくれるのか？

**名前は開発中のものです。** · 2009/04/11(土) 14:39:53

>>264
ごめん、それ、違う人。
あぁ、「最近本で読んで」とか言われてたのはそのせいか。 >218 の本も読んだこと無いよ。

まぁ基本的にその人と考えてることは同じなんだろうけど、「依存」の中に大昔の
ハードの制約とかも入るような話になっちゃったら 0 にしろとは言い切れないねぇ。

**名前は開発中のものです。** · 2009/04/11(土) 14:44:16

結局タクスシステムとは関係ない話ということでよろしいか？

**名前は開発中のものです。** · 2009/04/11(土) 14:47:58

いやあるね。
基本的にタスクシステム自体がゲーム仕様に「依存」するからこういう展開になるわけで。

**名前は開発中のものです。** · 2009/04/11(土) 14:50:55

>>267
依存関係の切り離しも含めてモジュール分割やコード再利用の努力をすれば、
すぐにタスクシステムなんてものは標準コンテナや仮想関数を持った
インターフェースクラスなどに分解され、残るのはゲーム依存部分となり
システムと呼ぶほどのものは残らなくなるだろう、と考えている。

そういう意味でも >263 の質問に答えが欲しい。あと >254 も、かなぁ。

**名前は開発中のものです。** · 2009/04/11(土) 14:51:36

>>266
ハードの制約は大昔も未来も変わらんよ。
非対称マルチコアに最適なタスク管理とか、最近はそっちの方面に流れてるし

実行環境を一切考慮しない唯一の最適なシステムなんてハードが進化し続ける限り不可能。

**名前は開発中のものです。** · 2009/04/11(土) 14:58:23

>>269
答えがほしいってなんだよ。
自分でやってみればよいだろ。すぐに問題に気が付くから。

**名前は開発中のものです。** · 2009/04/11(土) 14:58:59

>>270
唯一最適である必要は無い。適切に分割され、要求に応じて組み合わせられるように
なっていればいい。

それなりのサイズの例としては、 C++ 標準ライブラリとか、 C++0x の
乱数発生器フレームワークとか、 shared_ptr, weak_ptr などのスマートポインタ郡とかね。

**名前は開発中のものです。** · 2009/04/11(土) 15:10:54

だからフレームワークとライブラリは違うってのに。

**名前は開発中のものです。** · 2009/04/11(土) 15:34:22

開発者のオナヌーか
マルチに使えるライブラリうんまーとかは開発者の自己満足
環境に応じて、ゴリゴリに書け

**名前は開発中のものです。** · 2009/04/11(土) 16:07:14

再利用性とか保守性とか、プログラムの一般論としては良いこと、なんだけど
ゲームでそれをするコストに見合うケースは少ないからね…

MMOのクライアントや定番スポーツゲームとか一部の例外を除く
大部分のゲームは再利用も保守も必要ないケースがほとんど。

続編でも旧プラットフォームで作ったチープな仕様のものを再利用して
現行機にもってくる、なんてことはまず無いし。

**名前は開発中のものです。** · 2009/04/11(土) 16:13:26

>>269
>すぐにタスクシステムなんてものは標準コンテナや仮想関数を持った
>インターフェースクラスなどに分解され、残るのはゲーム依存部分となり
>システムと呼ぶほどのものは残らなくなるだろう、

何いってんの？
あらゆるシステムは分解すればシステムと呼ぶものは残らないのは当たり前。
それら使いを組み立てたものをシステムと呼ぶんだろ。

>>272
>それなりのサイズの例としては、 C++ 標準ライブラリとか、 C++0x の
>乱数発生器フレームワークとか、 shared_ptr, weak_ptr などのスマートポインタ郡とかね。
それらを使ってシステムを構築するんだろ。

**名前は開発中のものです。** · 2009/04/11(土) 16:56:46

タスクシステムとフレームワーク関係なくね？

フレームワークってハードウェアの差異を抽象化するためのものでしょ。
つまりゲームに特化したOSでしょ。

タスクシステムってハードウェアの差異を抽象化する機能あったか？
単なる自作マルチスレッドライブラリっていう位置づけがせいぜいじゃね。

**名前は開発中のものです。** · 2009/04/11(土) 18:20:01

タスクシステムはゲーム用フレームワークで重要な位置にいるのがわからんのかね。

**名前は開発中のものです。** · 2009/04/11(土) 19:04:53

ハリウッドの法則とかしらんのかな

**名前は開発中のものです。** · 2009/04/11(土) 20:03:09

このスレのアンチタスク派、頭が悪すぎるだろ。

ろくに実務経験が無いのか、下っ端すぎてゲームライブラリやシステム部分
の製作に参加させてもらえていないのかは知らないが、ゲームの仕様が完全に
決まるまで1行もコード書かない(書けない)とか、いくらなんでもひどいすぎる。

**名前は開発中のものです。** · 2009/04/11(土) 21:11:36

都合の良いレス以外は読めないんですね

**名前は開発中のものです。** · 2009/04/11(土) 21:22:43

いくつもタスクシステムと称するものを使ったソースを読んでるけど(学生レベルのカスレベルのプログラマ作のものもあれば、ファミコン時代から今までやってるベテランのも)
経験の差、思想の違いだけじゃなく
同じ人でもプラットフォームや言語が違うだけで
タスクシステムの役割や意味するもの、形態が違ってた。

タスクシステムはバズワードでしかない
メリットデメリット云々言うのは野暮
あとプロジェクトを特定せずタスクシステムって言葉を使うのは悪だと思う

**名前は開発中のものです。** · 2009/04/11(土) 21:25:34

つーかアンチは喧嘩したいだけで
真面目に議論する気がないんだから決着着くわけ無いじゃん。

**名前は開発中のものです。** · 2009/04/11(土) 21:32:27

にしても、前スレだか前々スレだかに居た引数クンのやり方は無い。
あれはキチガイ。

**名前は開発中のものです。** · 2009/04/12(日) 00:09:59

タスクと聞くとVOWの渡辺タスクを思い出して笑ってしまう

**名前は開発中のものです。** · 2009/04/12(日) 12:42:11

>>284
やってないからそう思えるだけ
実は引数を通したほうがバグ数も格段に低くなって結果的に楽
オブジェクト指向なんて役に立たないもの理解してる暇があったら
まずは引数をキチンと通す組み方を学ぶべき

簡単なプログラムから「グローバル変数・関数を一切使わない」ルールで
一度組んでみて徐々に仕事でも自分の担当するところだけでも
グローバル変数・関数の影響をなるべくうけないように組んでいく

これができるだけでプログラマとしてのレベルはそこらにいる奴等とは
比べ物にならないぐらい上がる
これができるようになることで汎用化できるものと汎用化できないものの判断ができるようになる
（お前等はクズだからこの「汎用化『できないもの』」の判断ってのが苦手っていうかできないだろ？）

**名前は開発中のものです。** · 2009/04/12(日) 12:47:22

じゃあ、グローバル変数はともかく、
グローバル関数を使わない理由を説明してみ？

**名前は開発中のものです。** · 2009/04/12(日) 12:52:49

>>286
>オブジェクト指向なんて役に立たないもの理解してる暇があったら
わぉ
構造化プログラム時代のまま20年間時間が止まったままの人がいるよ
80年代のプログラマが現代にタイムスリップですか？

**名前は開発中のものです。** · 2009/04/12(日) 13:01:05

>>286
オブジェクトで渡した方がいいじゃん。
どうせアクセサ経由だし、バラバラに引数渡すよりもバグが入らないね。

**名前は開発中のものです。** · 2009/04/12(日) 13:26:34

スパゲティプログラムをずるずる書くようなレベルの奴が、
オブジェクト指向なんぞに手を出すのは早すぎ、ということを
言い損なってるだけだろ。

**名前は開発中のものです。** · 2009/04/12(日) 13:59:53

グローバル関数使わない利点が真面目に分からないのだが。
グローバル変数使うなってのは聞いたことあるが。
というか、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 );
}

こういうことですね、分かります。

**名前は開発中のものです。** · 2009/04/12(日) 14:10:03

>>288
オブジェクト指向アンチ=構造化プログラミング派ってのは短絡的すぎる
それどころかむしろ遅れているよ

最近日本でも関数型言語が注目されるようになってきたけど、
オブジェクト指向もサポートしている関数型言語(ocaml等)でオブジェクト指向を多用されない理由は型システムとの相性だけじゃないんだぜ

**名前は開発中のものです。** · 2009/04/12(日) 14:13:21

>>292
CやC++が関数型言語なら話は分かる。

**名前は開発中のものです。** · 2009/04/12(日) 14:19:15

>>293
違う違う。
何も理解してないから言語にこだわってCやC++が関数型言語ならとか言い出しちゃうんだよ

**名前は開発中のものです。** · 2009/04/12(日) 14:27:39

>>292
またそのパターンか

**名前は開発中のものです。** · 2009/04/12(日) 15:02:02

入力と出力が一致することは大切。
確かにC++では引数ベースで書くとタルいかもしれんが
自動テストとの相性がいいし、メモリ破壊のチェックも楽になる。

あと>>286と他のレスで、
namespace内の関数やstatic関数はグローバル関数か否かの認識がズレてると思われ

**名前は開発中のものです。** · 2009/04/12(日) 18:59:10

>286
バカだな。

read onlyなら、引数で渡そうがグローバルに置いてあろうが何も変わらない。
その辺のアクセス制御が出来ない無能は、センス無いとしか言いようが無い。

**名前は開発中のものです。** · 2009/04/12(日) 19:10:15

その素晴らしいグローバル関数を一切使わない引数方式とやらで作られた商用ゲーム、
今まで見たこと無いので一本でもあれば教えてくれないかなぁ

タスク使って作られたゲームはたくさん見たけど、そんな素晴らしい方式が
あるなら何で誰も使わないんだろうね。

世界中のゲームプログラマのレベルが君に比べてあまりに低すぎるのかなぁ？

**名前は開発中のものです。** · 2009/04/12(日) 19:10:50

結局アクセス制御の概念をもってCでライブラリとか組むとさ、
オブジェクト指向言語を使用して組むのと殆ど変わらない
考え方で組むことになると思うのですが・・・。

**名前は開発中のものです。** · 2009/04/12(日) 21:26:04

>>294
言ってる事はカプセル化にしか見えないんだけど.。俺には。

**名前は開発中のものです。** · 2009/04/13(月) 01:03:42

>>298
そういるルールだからです。
「ぬーやる」バーガーはしってますか？

**名前は開発中のものです。** · 2009/04/13(月) 01:07:48

グーバル関数使わない君はマダかね？

**名前は開発中のものです。** · 2009/04/13(月) 01:54:53

悪いｗ
グローバル関数は間違いだなｗ

ただ、ヘッダを一括インクルードして
関数をどこでも使えるようにしてしまう組み方がダメだって話
関数を使う箇所だけでヘッダを呼ぶときと
関数を使わない箇所でもヘッダを呼んでしまうのの違い

これに名前ってついてないので説明しにくいが
必要な箇所で必要な分だけインクルードして関数を呼べってこと
簡単に言えばマスターヘッダを作るなってこと

がいいたかったｗ

**名前は開発中のものです。** · 2009/04/13(月) 01:59:44

そんな当たり前のことを今更自分が発見したように言われてもなぁ…。

**名前は開発中のものです。** · 2009/04/13(月) 02:08:23

>>304
じゃ、俺のいう組み方は普通にわかる？

**名前は開発中のものです。** · 2009/04/13(月) 02:58:53

Cだったらそんなの当たり前なことだと思うけど。
それタスクシステムと関係ないし。

**名前は開発中のものです。** · 2009/04/13(月) 05:55:56

「俺の組み方」とやらが見えないわけだが
いままでの質疑応答をふまえて一旦書き直してもらえないか

**名前は開発中のものです。** · 2009/04/13(月) 06:20:42

>>307
グローバル関数の内容が>>303になるだけ

**名前は開発中のものです。** · 2009/04/13(月) 06:23:07

グローバル関数禁止でも一括インクルード禁止でもいいけど、
引数云々の話とはどう繋がるんだ？
必要なものだけインクルードしようが、一括でインクルードしようが、
引数の数や種類は一切変わらないと思うんだが。

**名前は開発中のものです。** · 2009/04/13(月) 06:35:40

>>309
引数にきちんと渡すことと一括インクルード禁止は両方同時に守らないと
アクセスを制限できない

**名前は開発中のものです。** · 2009/04/13(月) 06:36:49

もちろんグローバル変数は当然禁止な

**名前は開発中のものです。** · 2009/04/13(月) 06:37:56

結局Ｃ＋＋でやるなら　std::list<Task*>　とかで充分だしこの方が簡単じゃないか

**名前は開発中のものです。** · 2009/04/13(月) 06:41:27

>>303

そんな2、3スレ前に原型がでたものは今更たどれないし、
当時から見えていても他人は正確に覚えてないだろうから改めてって意味も含めて

**名前は開発中のものです。** · 2009/04/13(月) 07:02:40

>>313
いやいや、>>286な

**名前は開発中のものです。** · 2009/04/13(月) 07:12:03

引数君じゃないの？　引数君の由来になった話が見えないので分からなかった
>>286レベルの話で「グローバル関数使うなは間違いでした」じゃ今更話すべき内容はないな
今時の言語はネームスペースなりパッケージなりあるし、Cは同一関数名のオーバーロードできないだろ

**名前は開発中のものです。** · 2009/04/13(月) 09:19:54

>>294
そんなことどこにも書いてねーだろw

>>310
意味がわからない。
引数ベースでやることによってどういうアクセス制限を実現できるの？

**名前は開発中のものです。** · 2009/04/13(月) 09:21:42

>>294
そんなことどこにも書いてねーだろw

>>310
意味がわからない。
引数ベースでやることによってどういうアクセス制限を実現できるの？

**名前は開発中のものです。** · 2009/04/13(月) 09:26:59

二重レススマソ

**名前は開発中のものです。** · 2009/04/13(月) 09:37:44

>>303
お前の想定しているレベルが低すぎる。

わかりやすく言うと、
高校生相手に、小学生のお前が、幼稚園児で習うことを
さも他の奴らがわかってないかのように、
低い説明力で、知識を披露している寒い状況。

**名前は開発中のものです。** · 2009/04/13(月) 12:56:31

わかってないじゃん
わかってないからグローバル変数使ったり、一括インクルードなんてしちゃうんでしょ？

**名前は開発中のものです。** · 2009/04/13(月) 13:17:25

名前空間って知ってるか？

**名前は開発中のものです。** · 2009/04/13(月) 13:18:02

はいはい、してねーよカス

**名前は開発中のものです。** · 2009/04/13(月) 13:32:50

>>319
同意。ちょっと低いと思う。
分割インクルードによるアクセス制限なんて、誰でもやってることでしょ。何をいまさら。

未だ並列君や高専君の方が議論は面白かったぞ。

**名前は開発中のものです。** · 2009/04/13(月) 15:24:05

>>323
突っ込み所が違う気ガス
分割インクルードをアクセス制限だなんて言い出すのはマズいよ

**名前は開発中のものです。** · 2009/04/13(月) 17:02:17

>>323
まぁね。分割インクルードの一番の目的は単体テストができるように癒着を無くす事だもんね。
ヘッダ分割することでアクセス制限を掛ける効果もあるが、あまりに当たり前すぎる事を>>303がさも自分流だと語りだしたのでびっくりしたんさ。

**名前は開発中のものです。** · 2009/04/13(月) 20:04:51

それならそれがとても大事なことだってのはわかるよね？
このルールを破ってはいけないんだ
windows.hを作った人はボケだったけどまねしちゃ駄目なんだ
必要なところで必要なものだけ呼ぶんだ

**名前は開発中のものです。** · 2009/04/13(月) 20:15:21

まあ、あんまりないとは思うけど
必要なものが呼べてないソースも駄目だぞ
さらにこれから必要かもしれない希望的観測も駄目だ
キッチリ必要なもののみな

言うのは楽だけどできるかい？

**名前は開発中のものです。** · 2009/04/13(月) 20:26:29

>>319をもう一回読もうか

**名前は開発中のものです。** · 2009/04/13(月) 21:22:47

引数がどうの言ってるキチガイと
HSPしか使えないゲームも作ったことないド素人は
どっか行ってくんねえかな

**名前は開発中のものです。** · 2009/04/13(月) 21:33:38

>>328
いや、お前は知ってるだけ
理解してるとは天と地の差がある
だからタスクシステムなんて使うんだ

**名前は開発中のものです。** · 2009/04/13(月) 21:48:38

タスクシステムとどういう関係があるんだ？

**名前は開発中のものです。** · 2009/04/13(月) 21:56:36

>>330
どこかのサンプルでタスクシステムって紹介されてるものを、
グローバル変数、一括インクルードなしに改良してみろよ。
できるから。

**名前は開発中のものです。** · 2009/04/13(月) 22:00:08

>>330
がんばれよ

**名前は開発中のものです。** · 2009/04/13(月) 22:07:18

ID:JXX1jutsは凄いのぅ。きめつけで知ってるだけとかどんだけ上からなんだよ。
PG歴と過去にどんな環境でのPGを経験しているのか是非知りたいぜ。
で、このスレの住人スキルレベルをどう想定しているのかを挙げてもらってから、また>>319を読んでくれ。

**名前は開発中のものです。** · 2009/04/13(月) 22:18:46

じゃあ、みんな引数はちゃんと使うしグローバル変数も
一括インクルードも無しで組めてるんだね？

シングルトンとか意味不明なこと言い出すのもダメだぞ

**名前は開発中のものです。** · 2009/04/13(月) 22:35:00

C言語前提だけど、グローバル変数はまったくなくても大丈夫だな。

モジュール内で共通して使用するステータスはstaticで作り、
ヘッダには記載しないことによりカプセル化する。

一括インクルードはアプリケーション向けには作ると便利。
テストは個別にテストできるようにモジュール毎に分けておく。

**名前は開発中のものです。** · 2009/04/13(月) 22:37:14

追記
どこのモジュールからも参照できるグローバル変数は作らないという観点で書きました。