2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

OOとゲームプログラミング

1 :名無しさん@お腹いっぱい。:01/11/07 23:55 ID:HnYWCQK1
OOをどのように用いれば美しくゲームプログラミングを
行うことが出来るのか語り合うスレです。

2 :2:01/11/07 23:56 ID:???
2

3 :名無しさん@お腹いっぱい。:01/11/07 23:57 ID:???
掃除機、OOは素人にはお勧めできない。

4 :名無しさん@お腹いっぱい。:01/11/07 23:59 ID:???
むう、正直、こっちを使って欲しひ。
http://game.2ch.net/test/read.cgi/gamedev/1005040025/

5 :名無しさん@お腹いっぱい。:01/11/08 00:10 ID:???
まずは、データ構造とモジュールについて、しっかり勉強して下さい。
でなければ挫折します。

6 :名無しさん@お腹いっぱい。:01/11/08 10:17 ID:dMTEmYa4
PS2のコンパイラ、クソすぎて複雑なクラス構造理解してくれないYO!

7 :名無しさん@お腹いっぱい。:01/11/08 11:57 ID:kAK1Gifs
YO! とか使う奴多いよね。開発者に。いまだに

8 :名無しさん@お腹いっぱい。:01/11/08 12:27 ID:???
>>6
PS2ってgccでないの?

>>7
そういうのを突っ込むのは板違い

9 :名無しさん@お腹いっぱい。:01/11/08 13:35 ID:hsQUKhnQ
>6
OO的思考はイイんだけど
いざ実装するときにC++とかだと
コンパイラ腐っててできねえ!とかあるわよねえ。
コンパイラ特有の変な制限あったり。
マニュアル見たらテンプレートクラスはファイル1つにブチ込めゴルア!
・・・だそうな。鬱死

10 :名無しさん@お腹いっぱい。:01/11/08 16:53 ID:???
そうだね。テンプレートはOOとはあまり関係ないにしてもだ(コンパイルタイムポリモーフィズムって言われることもあるけど)。

11 :アマプログラマ:01/11/09 04:02 ID:Adk7Pup5
ループを回して、その中でゲームの状態により
switch文とかで分けて処理するとかしたらなーんかいつもながーい
ループが出来上がっちゃうんですが、
みなさんどうされてるんですか?

12 :名無しさん@お腹いっぱい。:01/11/09 04:08 ID:???
>>11
この辺とか
ttp://www.hh.iij4u.or.jp/~peto/Games/games_top.html

タスクシステムって、原始的なOOかも。

13 :名無しさん@お腹いっぱい。:01/11/09 06:22 ID:???
>>11
状態をオブジェクトにする。
そうすると、ゲームのメインループは有限状態マシンとしてモデル化できて
ゲームに依存しないフレームワークを作ることができる。

有限状態マシンのモデル化は、ちょっとしたオブジェクト指向入門書になら
書いてあるでしょう。

14 :名無しさん@お腹いっぱい。:01/11/09 09:06 ID:???
>>13 に加えて、デザインパターンのStateパターンとか
その辺を参考にするといいかもです、はい。

15 :名無しさん@お腹いっぱい。:01/11/09 19:35 ID:???
今までは 12 のサイトに書かれていた処理が多かった。
アマプログラマと名乗っているなら似非タスク処理を作るのが良いと思う。

16 :名無しさん@お腹いっぱい。:01/11/09 20:52 ID:???
OOを使えばタスクは使わなくなるの?

17 :アマプログラマ:01/11/09 21:51 ID:P26OayTW
ふーむ、なるほど。>>12-15ありがとです。
ぜんっぜん思いも寄らなかったけど
>>15読むと時代の流れは先に行ってるようですが、
どないなんでしょう?

18 :名無しさん@お腹いっぱい。:01/11/09 21:53 ID:???
まあ、最初は古典的?っていうか原始的?っていうか
自分なりに力技な方法でやってもいいんじゃないでしょうか。
あまり考えすぎると、理屈倒れのなんとやらになるかもです。

19 :名無しさん@お腹いっぱい。:01/11/09 22:05 ID:f17v7fRl
最近WinSDKプログラミングをはじめたんですが、
WndProcでコールバックされた後やるswich文をMessageHandle用クラスに
持たせて多態化させて、デザパタのStateパターンっぽくやろうと試みてます。
Menu選択とか、ダイアログとかのMessageHandle関係全般につかえるよう
ある程度汎用的に・・・と構想してます。

とりあえずの目標はシンプルである程度汎用的なフレームワークを作って、
DirectXやOpenGLをいじくろうと思っているんですが・・・・

こういうことって、既にみんなやってるモンでしょうか?

20 :名無しさん@お腹いっぱい。:01/11/10 01:13 ID:N+CvjlCZ
>19

やってると思いますよ。
ゲーム作るのなら必須でしょう。

21 :19:01/11/10 02:02 ID:???
いま>>12のリンク先のタスクシステムを見てます。
面白いです。確かに原始的なOOPという感じです。
TCBを見てるとクラス化したくなってしまいますが、
長年培われてきた(?)型だけに、下手な設計ではOO化は
逆効果になりそうですね。

デザパタではState,Strategy,Flyweightあたりがまず不可欠
でしょうねー。

22 :19:01/11/10 02:05 ID:uyB6mt6S
ところで実際のところゲーム開発の現場ってCとC++の比率はどのくらい
なのでしょうか?
C++でやってるのは余裕のある大手くらいってかんじですか?

23 :名無しさん@お腹いっぱい。:01/11/10 03:17 ID:EV3x96b1
C++は遅くて使い物にならんと思うが

24 :_:01/11/10 03:21 ID:weMvVVDK
>>23
マジ?
XboxはVC++がデフォだって聞いたけど。

25 :名無しさん@お腹いっぱい。:01/11/10 03:24 ID:???
>>23
こういうことを言う奴はシッタカ君

26 :19:01/11/10 03:25 ID:???
てことは>>23は C++でゲーム開発してるって話は見たことも聞いたことも無い?

27 :名無しさん@お腹いっぱい。:01/11/10 03:26 ID:EV3x96b1
>>25
そうか?
継承するとパフォーマンスが悲惨なんだが
そんな事はないか?

28 :名無しさん@お腹いっぱい。:01/11/10 03:29 ID:???
VTBLのオーバーヘッドなんかもう無視できるっしょ。

29 :アマグラマ:01/11/10 03:33 ID:???
スターオーシャン2ndストーリーのトライエースのロゴの下に
try-Ace PlayStation Foundation Class Library
とかなんか誇らしげに表示されてるのは見たですが。

30 :名無しさん@お腹いっぱい。:01/11/10 03:34 ID:EV3x96b1
そりゃぁXboxはそうかも知れんが、
我がマシンでは数倍違う

31 :19:01/11/10 03:49 ID:???
C++が遅いのではなくて、Classライブラリに問題があるのでは?
私もOOやC++崇拝者なわけではないんだけど。
C++がCと比べてオーバヘッドあるのは事実だと思うけど、Cの手法だって
インライン関数だってインラインアセンブラだって使えるわけだし。
深すぎる継承を使わないとかクリティカルなところでは伝統的な手法を
使ってゆけば、使い物にならん、ってことはないいんじゃないかと。

32 :名無しさん@お腹いっぱい。:01/11/10 03:59 ID:???
>>27
まさにシッタカ君
全然何も分かってないらしいな
プラットフォームとは関係ない

しょうがないから本を一冊薦めといてやる
「C++/C プログラム改善法」
ただしトッパンはもうつぶれてしまった

仕方ないので
「Efficient C++」
で代用
こちらはピアソン・エデュケーションだからまだ
売ってるだろう

33 :名無しさん@お腹いっぱい。:01/11/10 04:19 ID:EV3x96b1
そうかプラットフォームとは関係ないのか。
そうだとすればC++は使い物にならないという事だな。

34 :名無しさん@お腹いっぱい。:01/11/10 04:27 ID:lPeuTMQg
かたくなだな。

35 :名無しさん@お腹いっぱい。:01/11/10 04:29 ID:EV3x96b1
>>31
同じ会社の(クラス)ライブラリが
CとC++でそう違うものなのか?

36 :とむ ◆TMwDpCZo :01/11/10 05:10 ID:???
なんとなくだけど、C++のようなOOと、ゲームのプログラミングって
相性良くないような気がしています…。
昔はいいと思ったんだけどね…。

37 :_:01/11/10 05:36 ID:/4YFolbK
つうかCオンリーで組むのも相当キツイと思うけど。
延々とグローバル関数作りまくり・・
STL無いし・・

38 :名無しさん@お腹いっぱい。:01/11/10 06:46 ID:???
継承のコストって x86 でいえば
call [v_table+n]
程度じゃない?

どちらかといえば、インスタンスの生成破棄を
無頓着に行うと効率さがるよね。そんなことは
Effecient C++ レベルにでも書いて有るようなことだし。

39 :名無しさん@お腹いっぱい。:01/11/10 06:56 ID:???
C++をCと比較した場合、クラスの使い方を間違えると、
コード量が約2倍になる。コードの書き方を間違えなければ、
Cと等速のコードも書ける。

40 :名無しさん@お腹いっぱい。:01/11/10 07:12 ID:???
オブジェクト指向が本領発揮するのってやっぱ共同開発において、でしょ
一人でシコシコ作る分には無理に移行する必要無しと思われ。

41 :名無しさん@お腹いっぱい。:01/11/10 09:20 ID:???
もうOO抜きで組めない俺は就職不可能ですか?(´д`;)

42 :名無しさん@お腹いっぱい。:01/11/10 09:49 ID:???
>>41
OOを完全にマスターしているか、必要以上に使わないなら、
大丈夫かと。中途半端に使うと非効率なんで。

43 :名無しさん@お腹いっぱい。:01/11/10 11:20 ID:???
>>36
なんとなくって書いてるところにつっこむのはアレだけど、
どのへんが相性よくないと思ってる?

44 :名無しさん@お腹いっぱい。:01/11/10 12:11 ID:???
>>42
オレはむしろOOは中途半端がいいと思う。
業務アプリみたいに、完璧なOOPではやはり速度的に厳しいんじゃないか?
OOは中途半端にいいとこだけ使って、古いやり方をラッピング+部品化ってのが
いいじゃないか。
効果的にやるのにOOの理解は中途半端じゃ困るが。

45 :名無しさん@お腹いっぱい。:01/11/10 12:15 ID:lDT42030
C、C++、さらにObjective C。
最後のはなんじゃい、ってのはナシね。アポーに言ってくれ

46 :とむ ◆TMwDpCZo :01/11/10 12:47 ID:???
>>43
難しいなあ…。本当に感覚的な問題なんだけども…。

私は、OOPは何かを分散的に処理するのに向いているような気が
している。分散的ってのは、例えばWindowsのように、多数のタスク
を同時に動かしたりするようなものね。
で、ゲームもまさにそういう分散的なアプリケーションで、確かにそう
いう面ではOOPと良く親和する部分もあると思います。でも、ゲーム
の場合突如として様々なタスクを一元的に管理する(つまり分散的の
逆)必要が出てくる場合があります。このような時、Cのような単純な
言語に比べてちょっとめんどくさいような気がするのですよ。ほんとに
なんとなくなんだけど。

ま、C++は言語仕様上OOPというスタイルが可能になっているだけ
で、Cと全く同じスタイルで組む事は出来ますし、逆にCでもある程度
まではオブジェクト指向なスタイルで組む事も可能は可能ですから、
要は組み方の問題なんですけどね。

単に私の腕がヘボだからそう思うのかも知れません。クラスのスコー
プを考えて、何をどのファイルに入れるかで死ぬほど悩みますから(笑)。
Cの時はここまで悩まなかったのに…って。

47 :名無しさん@お腹いっぱい。:01/11/10 13:19 ID:lDT42030
速度に関して経験がないので分かりませんが、
正直、私もCでゴーリゴリやっていた(今でもそう)んで、
OO的設計に馴染めない自分ってのが居る(笑)
OOに限らず、場合によっては中身が見えないハコって
不安でしょうがない(笑)

48 :名無しさん@お腹いっぱい。:01/11/10 13:28 ID:???
>>46
>でも、ゲーム
>の場合突如として様々なタスクを一元的に管理する(つまり分散的の
>逆)必要が出てくる場合があります。
いや、俺は逆にこの辺のことをスマートにできるからOOPLがいいと思ってるんだが。
タスクって要するに抽象クラスなわけで、そういうことをするのに言語の支援が受け
られるなら、そっちのほうがいいと思うし。
まぁ、もちろん、OOは概念なんだから、実装は一番やりやすいのでやればいいんだけどね。
(Cでも、ゲーム作ってるとOOに近くならない?

>クラスのスコー
>プを考えて、何をどのファイルに入れるかで死ぬほど悩みますから(笑)。
>Cの時はここまで悩まなかったのに…って。
これは激しく同意。
宣言の順序とか考えなきゃならないときもあって激しく萎える。
C++はこれだから…。

49 :名無しさん@お腹いっぱい。:01/11/10 13:35 ID:???
>>47
中身が見えないのはOOとは関係ないなぁ。
C++だってソース公開すればブラックボックスじゃないし、
システムが複雑になってくるとクラス図にしやすい分C++の方がよさげ。

50 :とむ ◆TMwDpCZo :01/11/10 13:37 ID:???
うーん、恐らく私が言っているめんどくささというのは、基本的に私が
まだC等の非オブジェクト志向言語での制作スタイルから脱しきれて
いないからでしょう。これらの言語を何と呼ぶのかな? 良くわからな
いけど、とりあえず私は「処理志向」なんだよね。

本来、OOPというのは、オブジェクトが先にあって、それが動作すべき
処理が従になるのが正しいのだと思います。
しかし、私は頭が古いから、実現したい処理の方ばかりに考えが行って
しまうのですね。で、例えば今動作しているオブジェクト(ここで言うオブ
ジェクトは、ゲームにおけるオブジェクトね)全てに影響する処理、など
というものを考えた時に、処理が主で、クラスが従という考え方をしてし
まうのです。ある処理のためにクラスを使おう、などと思ってしまうと、
処理がプログラム全体のあちこちに散らばっていると、問題とするクラス
をどこにインクルードするかというスコープの問題で頭を抱えてしまう
のです…。

ああ、なんか自分で書いてて良くわからなくなってしまった(笑)。
ヘボコテハンの独り言だと思って下され。

51 :とむ ◆TMwDpCZo :01/11/10 13:44 ID:???
中身が見えない、というのは私も感じるよ。

Cで遊んでた時は、書いたコードが、アセンブラで言うところのどんな
コードに直されるか、うっすら予測しながら書いてたよ。もちろん完璧
じゃないけどね。大体どう書けばどういうループが組まれるか、とかそん
な感じでなんとなーく考えながらコードを組んでた。提供されるライブラ
リも、何がどう処理されるかとか半分くらい予測つくしね。

でもC++の場合、パッと見で「現実にはどういう処理がなされるか」と
いうのが分かりづらいんだよね。パッと見っつーか、良く見てもさっぱり
わからない。あるコードを書いた時、どこをどう参照してどういうコード
にコンパイルされるのか、ほとんど予測つかない。
「別にアセンブラのコードを予測しなくていいよ」というのが正解なんで
しょうが、例えばハードにちょっと近い処理をしたい時に、書かれるコード
の応答性がどうかとか、メモリ管理がクリティカルになる可能性があるの
かどうか、ワイルドな入力に対して堅牢なのかどうかとか、予測つかない
と不安なんだよね…。古い人だから(笑)。

52 :名無しさん@お腹いっぱい。:01/11/10 13:45 ID:???
>>50
はは。
俺も、まだメインループ等全体にかかわることは、OOの外だよ。
どこまでをOOにするのかは意見の分かれる処なのかもしれん。
コリジョンの処理とかどこでやろう?とか、いまだに悩むよ。

53 :名無しさん@お腹いっぱい。:01/11/10 13:50 ID:???
>>50
たぶんそれはオブジェクト指向の「すべての対象はオブジェクトです」みたいな
理想論を見てひいてしまってる感じじゃない?
そういう理想論は結局理想であって、OOPでやっても「全てに影響する」なん
てのは「処理ルーチンをクラス化して順番に解決する」という結局本質的には
>>50のやり方と大差ないものだったりするよ。

54 :とむ ◆TMwDpCZo :01/11/10 13:53 ID:???
>>52
>>53

そうだね、現実的に考えれば、そういった広範囲に及ぶ処理はOO
の外に追い出すのが普通だね。

でも私は理想主義者なのかな?(笑) 例えば設計時に、色んな
物を美しくクラス化して、完全なヘッダを設計したりするでしょ。
けど、結局上記のような問題にぶち当たり、仕方なくそれらのクラス
を呼び出す関数を作り、広範囲な処理時にはその関数を更に呼び
出すような仕掛けにしてしまい、「これじゃC++の意味ないじゃん!」
と机を叩くわけです(笑)。

55 :名無しさん@お腹いっぱい。:01/11/10 14:27 ID:???
>>53
「すべてがオブジェクト」ってのはOOPL自身の設計の話なので、
(しかも言語の効率とか、複雑性とかの話なので)ちょっとちがうかも。
>>54
「すべてに影響する」ってのを実現するにはVisitorパターンを使うわけだけども、
あれは、諸刃の剣だからあぁ。
どっちにしろ、「処理」だってオブジェクトなわけで、そのように設計するかしないかは
あとは慣れだろうな。

56 :名無しさん@お腹いっぱい。:01/11/10 15:40 ID:Pfrth29i
C++が遅いって言っている人がいるよー。
そら、Cよりもオーバーヘッドがあるかもしれないけど、そんなに問題にならんでしょうに。
もしなるとしたら、それは実装に問題ありと思うが。

それに、無理して全部C++で書く必要もないでしょう。
最下位レベルだけアセンブラでかけばいいのでないのか。

57 :とむ ◆TMwDpCZo :01/11/10 15:58 ID:???
…その書き込みを読んだだけでも、「C++は遅い」という事自体は
間違ってない気がするのですが…。

58 :がばろん@Mたんちゅきちゅき:01/11/10 16:02 ID:???
>>50 とむたん。
たぶんCなどの言語の総称は「構造化プログラミング言語」。

C++が、どんなマシン語のコードに変換されるかは、
いちどCでオブジェクト指向的なプログラムを組んでみると、
理解しやすいんじゃないでしょうか。

たしかプログラム板のどこかのスレに、そういう話題があったとおもいます。
virtual function tableとかで検索かければ見つかるかも。

あとオブジェクト指向の内部よりな話なら下の本が、おすすめ。
「 ゲーム&&オブジェクト指向プログラミング」塚越 一雄

>>27たん。
継承より問題は多態性じゃない?
それにしたって考慮するほどのものじゃないけれど。

// スレと関係ないけど、いま名前をいれて書き込んだら
// 「ERROR:名前いれてちょ。」って言われたよ。(TT

59 :とむ ◆TMwDpCZo :01/11/10 16:08 ID:???
>>58
>たぶんCなどの言語の総称は「構造化プログラミング言語」。

あ、いや、「オブジェクト志向」に対する言葉として何か適当な言葉が
あるのかな、と。「構造化〜」は対義語というより、C++の土台になって
る概念でしょう。

60 :名無しさん@お腹いっぱい。:01/11/10 16:09 ID:???
>>51
> でもC++の場合、パッと見で「現実にはどういう処理がなされるか」
> というのが分かりづらいんだよね。

具体例を挙げてみてください。
分かりづらい部分が想像できないんです。

61 :とむ ◆TMwDpCZo :01/11/10 16:14 ID:???
>>60
いや、私は頭が悪いので、ちょっといくつかのクラスを継承してると
「?」になるよ。もう中で何が行われてるかわかんない(笑)。

いや、分かる人も多いとは思うんだけどね。

62 :名無しさん@お腹いっぱい。:01/11/10 16:15 ID:???
>>60
例外処理とRTTI

63 :名無しさん@お腹いっぱい。:01/11/10 16:18 ID:TY+m/yMI
friendでみんな友達(鬱

64 :名無しさん@お腹いっぱい。:01/11/10 16:26 ID:???
多重継承で(以下略

65 :名無しさん@お腹いっぱい。:01/11/10 16:28 ID:???
>>61
それはソースだけ見てるから。
クラス図を横に置いておけば吉。

66 :47:01/11/10 16:29 ID:???
47だけど、アタシもとむさんと同じで、想像できない方のタイプ。
OOって、メモリ上がどのように書き換えられつつ走っているのか
想像しにくい。
なんで?とかどこが?と言われても困る(笑)
一度抽象化された、オブジェクトの意味合い的なイメージでは
もちろん流れが掴めるけど、その具体的な処理の中身の話。
とむさんも同じではないかしら?

だからどっちがどうした、っていう話ではないので誤解なきよう。

67 :60:01/11/10 16:31 ID:???
>>61
>ちょっといくつかのクラスを継承してると
>「?」になるよ。もう中で何が行われてるかわかんない(笑)。

継承したことによって、どのメソッドが呼ばれているか
ぱっと見わからないと、そうおっしゃる
その分かりづらさは、C++だからってわけじゃないですね

#include <stdio.h>
void test0() {printf("0\n");}
void test1() {printf("1\n");}
int main() {
struct {void (*method0)(); void (*method1)();} T;
T.method0 = test1;
T.method1 = test0;
(T.method0)();
(T.method1)();
return 0;
}

こういうことでしょ?

68 :とむ ◆TMwDpCZo :01/11/10 16:36 ID:???
いや、パッと見でわからないというのは、処理の流れ自体ではなくて
(むしろ処理自体はブラックボックス化されて考えなくて良い分わか
りやすいところもある)、「実際にどういう命令になって、CPUがどういう
動作をしているか」がわかりづらい、って事を言いたいのよ。

例外処理はもちろん分かりづらいけど、それはCの頃からちょっとわ
かりづらかった(笑)。アセンブラが一番わかりやすい。

69 :名無しさん@お腹いっぱい。:01/11/10 16:37 ID:???
>>67
まぁ、そんなに問い詰めることもなかろ。
文化の違いに戸惑ってる程度の話でしょ。
マターリいぐべや。

70 :60:01/11/10 16:37 ID:???
>>62
例外処理はCに比べてC++の方が
むしろ見た目わかりやすくなってると思うけど

71 :がばろん@Mたんちゅきちゅき:01/11/10 16:41 ID:???
>>59 とむたん。
んじゃ「手続き型プログラミング」
http://yougo.ascii24.com/gh/21/002131.html

72 :60:01/11/10 16:43 ID:???
>>68
> 「実際にどういう命令になって、CPUがどういう動作をしているか」がわかりづらい

class B : public A;
class C : public A;
B.virtual_method() -> (*(vtbl + 0x50))();
C.virtual_method() -> (*(vtbl + 0x70))();

こんなもんですが

>>69
マターリとこりかたまった頭をほぐしてさしあげましょう

73 :とむ ◆TMwDpCZo :01/11/10 16:43 ID:???
>>71
うーん…「手続き型」が「オブジェクト志向」に対立する言葉かどうか
は微妙だなあ…。

74 :とむ ◆TMwDpCZo :01/11/10 16:45 ID:???
何か私および47さんと、60さんとの間で考えのズレが起きている
気がしないでもない…。

75 :23:01/11/10 16:51 ID:fxXO3W0o
何度やっても遅いって

それはそうと他人の作ったクラスを利用するのは気持ち悪い

76 :60:01/11/10 16:53 ID:???
Cでこう書くとこういう命令になるだろう
C++ではこう書いてあるけどどういう命令になるかわからん

それがどのようなソースコードなのかをすごく知りたいんです。

77 :名無しさん@お腹いっぱい。:01/11/10 16:56 ID:fxXO3W0o
そうそうCはアセンブラの代わりという感覚で使えたけど
C++はそうは行かないんだよね。
名前が似ているだけのまったく違う言語になってしまっている。
Cの単純さを備えて欲しかった

78 :とむ ◆TMwDpCZo :01/11/10 17:00 ID:???
うーん、だからさ…。
Cの場合は、ちょっとしたプログラムなら、向こうにアセンブラのソース
が透けて見えるでしょ。ローカルで作った変数なら、きっとこのへんの
レジスタに割り当てられるな、とか。こういう条件式を書くと、こんな形
のループにコンパイルされるな、とか。主にシングルタスクOSの場合。
多少関数を呼んだって、順次スタックに積んで下ろして、という感じじゃ
ない。
ところがC++の場合、ちょっといくつかの親クラスを継承したクラスの
場合、「どの時点で実体が確保されるか」つまり、メモリが割り当てられ、
あるいはレジスタが割り当てられたのかとかが良くわからなくなるのよ。

Cってのは、ある意味CPUが順次実行している命令のプロセスをほとん
どそのまま追っている言語だと思う。だから、実際のCPUの動作がわか
る。
ところが、C++ってのは実際に実行される順番に命令を並べているのと
はちょっと違うスタイルのプログラミングを(基本的には)する言語でしょ。
だから向こうに実際のコードが見えない、という事なのよ。

79 :名無しさん@お腹いっぱい。:01/11/10 17:07 ID:???
最下位まで気にしなくていいのが良い点なのだと思うが。
ボトルネックになっている部分をインラインアセンブラで書けばいいじゃん。

80 :60:01/11/10 17:09 ID:???
> Cの場合は、ちょっとしたプログラムなら、
> 向こうにアセンブラのソースが透けて見えるでしょ。

本当にわかってますか? 小一時間問い詰めていいですか?

> メモリが割り当てられ、
> あるいはレジスタが割り当てられたのかとかが良くわからなくなるのよ。

int a; はレジスタに割り当てられてー
char b[25]; はスタックでー とか?
Cでstruct {int a; char b[25];} t;はどう配置されるの?

81 :60:01/11/10 17:12 ID:???
> C++ってのは実際に実行される順番に命令を並べているのと
> はちょっと違うスタイルのプログラミングを(基本的には)する言語でしょ。
> だから向こうに実際のコードが見えない、という事なのよ。

Cでもコンパイラによるリオーダリングはありえると思いますが
それは除いたとして
C++で実際に実行される順番が異なってしまう状態例を
あげてくれると非常にうれしいです。感激しちゃう。

82 :がばろん@Mたんちゅきちゅき:01/11/10 17:12 ID:???
>>73 とむたん。
うーん>>50で、とむたん自身が言ってた「処理指向」と
手続き型っていうのは、まさに同じものだと、おもうんだけど。

いかなる言語にしても過去の有効な手法は取り入れているわけだから、
C++や、ほかのオブジェクト指向型の言語が、まったく土台に取り入れていないもので、
純粋にオブジェクト指向と対になるパラダイムなんて、ないんじゃない?

ちょうどエージェント指向に
オブジェクト指向の考え方が取り入れられているようなもので。

// 手続き型プログラミングについては、こっちのほうがわかりやすかも。
// http://www.e-words.ne.jp/view.asp?ID=2397


>>75 23たん。
実行のたびにネイティブコードにコンパイルしているJavaよりは、
C++のほうが、はるかにましだよ。(TT

// あ。ただJITやHotSpotなどでネイティブコードにコンパイルされたあとなら
// JavaはC++よりも高速という話はあるけど、ほんとかな。

83 :とむ ◆TMwDpCZo :01/11/10 17:13 ID:???
>>80
>本当にわかってますか? 小一時間問い詰めていいですか?

 まあ前にも書いたけど、完全に頭でコンパイルできてるわけでは
なくて、なんとなくだってば。小一時間問い詰められたらボロが出るよ。

 あと構造体だけど、それは別にそのまんまメモリに配置されるだけ
では…。構造体の直接読み取りとかやったことない?
 コンパイラによっては間にパディング入れたりするけど…。

84 :とむ ◆TMwDpCZo :01/11/10 17:15 ID:???
81を読むと、やっぱり私と60さんの間で話がきちんと通じてないと
思った…。うーむ。ジェネレーションの差かなあ(笑)。

85 :60:01/11/10 17:19 ID:???
>>83
そこまでわかってればC++でもおんなじだと思うんですよ

メモリだけ考えると
structとclassの違いは virtual method がある場合に
vtblへのポインタが入るかどうかだけなんだから

で逐次実行ってのはCでもC++でもかわらないので
classのコンストラクタが呼ばれるタイミングは
Cでstructを使うのとかわらない
Cにはnewがないけどmallocしたあとコンストラクタが呼ばれるだけ

86 :60:01/11/10 17:23 ID:???
>>85
じゃあじゃあ
> C++ってのは実際に実行される順番に命令を並べているのと
> はちょっと違うスタイルのプログラミング
ってどんなのか聞かせてほしいですー

87 :60:01/11/10 17:24 ID:???
ちゃい >>84 の間違い

88 :とむ ◆TMwDpCZo :01/11/10 17:24 ID:???
まあちょっとPCの前を離れるんで、色々お答えはできませんが、
多分私の言いたい事をわかってくれた人も何人かはいたようなので、
きっと誰かが代弁してくれるでしょう。すまそ>60さん。

89 :名無しさん@お腹いっぱい。:01/11/10 17:31 ID:fxXO3W0o
Cは書いた通りに処理されるけど、
C++ではソースコードでは明示されないポインタのやり取りとか、
プロセスの移行とかがあって気持ち悪い。

90 :60:01/11/10 17:37 ID:???
> C++ではソースコードでは明示されないポインタのやり取りとか、

一番簡単な例はメソッド呼び出しで
インスタンスのポインタが this が行きますね
これは納得

> プロセスの移行とかがあって気持ち悪い。

これはナンゾ??

91 :名無しさん@お腹いっぱい。:01/11/10 17:40 ID:fxXO3W0o
コンストラクタとか
オペレーターとか

92 :名無しさん@お腹いっぱい。:01/11/10 17:41 ID:fxXO3W0o
ボーランドC++のプロパティとかは末期的

93 :がばろん@Mたんちゅきちゅき:01/11/10 17:42 ID:???
じゃ。まとはずれかもしれないけど代弁してみよう。

>>86 60たん。
とむたんの言う「ちょっと違うスタイルのプログラミング」とは、
たぶんオブジェクトどうしがメッセージをやり取りして物事を処理していく
アクターモデル的プログラミングスタイルのことじゃない?

// おれドキュソだから、そこまで複雑に、ものごと考えたことないけど。

94 :名無しさん@お腹いっぱい。:01/11/10 17:45 ID:???
>Cにはnewがないけどmallocしたあとコンストラクタが呼ばれるだけ
なんか誤解を招きそうだな。
まるで、mallocでインスタンスを作成してもコンストラクタが実行されるみたいだ。
こんな誤解をする人間はここにはいないか…。

95 :外野:01/11/10 17:55 ID:???
結局、どこまでブラックボックスを許容するかで、すれ違っているような
気がする。
「Cでアセンブラソースが透けて見えないと気持ち悪い」って人も、CPUの
内部動作自体は気にしないでしょ?トランジスタ1つ1つの働きとか、実際に
は気にしないし、そこまで考えたらやってられない。
OOの場合、プログラムの抽象化のレベルが上がるので、その分ブラック
ボックスとして扱わないとやってられない敷居が上がって、アセンブラレベル
の動作まで考えたらやってられないので、気にしないのが一番って事に
なるのでは?
(ちょっと例えが極端かも。ま、意味は判るのね?)

96 :名無しさん@お腹いっぱい。:01/11/10 17:56 ID:QW8Th0qU
http://life.2ch.net/test/read.cgi/psy/991265343/518

97 :60:01/11/10 18:00 ID:???
> まるで、mallocでインスタンスを作成しても
それはインスタンスと言っていいものなのか聞いていいですか

vtblなしのclassなら実害なし?

98 :名無しさん@お腹いっぱい。:01/11/10 18:12 ID:???
ブラックボックスのレベルをどこまで許せるかということですな。
アセンブラ上がりの人で、勝手にナニやってるかわからないってC言語嫌がる人だっているわけだし。
俺は、まあオブジェクト指向レベルは許せるかなって感じで。
当然ピンポイントでインラインアセンブラは使うけどさ。

まあ、言語のメタ化が進んできてるっとことなんでしょう。
新しいメタ化の手法が普及し始めたら、OOは許容できた俺でもキモチ悪がるかもしれない。

99 :名無しさん@お腹いっぱい。:01/11/10 18:26 ID:???
オブジェクト指向ってのは開発方法論であって
使用する言語は関係ないと思うがどうか。
オブジェクト指向方法論に基づいてアセンブラでコーディングってのは
いまどき特別なことじゃないでしょ。

100 :がばろん@Mたんちゅきちゅき:01/11/10 18:26 ID:???
>>96たん。
全部たどっていったら下のレスからのリンクで
ウイルスがみつかったよ。
// もしかして全板にリンクはりまわってるの?

Jr.ファンのみなさんへお願い
http://music.2ch.net/test/read.cgi/jr/994988000/264

101 :名無しさん@お腹いっぱい。:01/11/10 18:33 ID:???
モジュールを少しでも勉強した事があるなら、
どの部分をブラックボックス化すればいいか?
なんて事は、そこそこ分かる事なんだが・・・

なんでモジュールやデータ構造を勉強せずに、
OOPに手を出すかな?

102 :60:01/11/10 18:50 ID:???
>>93

それが
> C++ってのは実際に実行される順番に命令を並べているのと
> はちょっと違うスタイルのプログラミング
なの?

順番に命令をならべてそれがそのとおりに実行されるのは
変わってないと思うんだけど

それともあれか、C++でクラス作ってインスタンス作ると
それが勝手に並列実行されるのか?

とりあえず http://www.njk.co.jp/otg/Study/ を読みなはれ >> 93

103 :_:01/11/10 18:56 ID:???
みんな中途半端な知識しか持ってないから
こんな中途半端な議論になっちゃうんだよね
意味無し

104 :名無しさん@お腹いっぱい。:01/11/10 19:01 ID:???
>>103
そう思うんなら君も中途半端に煽らずにもっと突っ込みをいれなさい

105 :19:01/11/10 20:19 ID:???
>>101
「モジュールの勉強」とは何ですか?
この業界では一般的な用語?

106 :19:01/11/10 20:29 ID:???
>>99
それは解るし正論だけど、だからといってC++でのゲーム開発の有効性
の議論が無意味ってわけじゃないでしょう。
今ここでは、だれも概念レベルと実装レベルのOOを混同している人は
いない。誰が見ても明らかに実装レベルの議論でしょ。
オブジェクト指向言語についての議論だよ。

107 :アマグラマ:01/11/10 20:45 ID:???
C++でも十分に出力されるアセンブラコードが透けて見えるよん。
ちょっと複雑なだけで。

ていうか、私がC++に移行したのは、
Cで自己流似非OOPモドキ(ていうかモジュール化の延長線上か)やってて
ある日C++の仕組みについてあれこれ読んで
これ俺がやってることとまったく同じじゃ〜ん、
しかも遥かにシンプルに書ける! マンセー!って動機だったですが。

108 :19:01/11/10 20:51 ID:???
>>90

>> C++ではソースコードでは明示されないポインタのやり取りとか、
>一番簡単な例はメソッド呼び出しで
>インスタンスのポインタが this が行きますね
>これは納得

それ納得しちゃうの?
ソースで明示的に書かれていなくても、言語仕様を知っていれば
自明なことでしょう。
裏で何をやっているか本当にわからないような言語でプログラミン
グなんて不可能だと思うけど。

109 :19:01/11/10 21:05 ID:???
亀質問だけど。
>>23==>>75 さん。

遅い遅いというけれど、何を実行しての感想なの?

110 :60:01/11/10 21:05 ID:???
>>108
>それ納得しちゃうの?
んー
「C++のメソッドってソースコードに書いてないのに、
 本当は引数1個多いんだよねー気持ち悪いよねー」
「うん、そーだね C言語だけの知識では想像できないね」
だしょ

> 言語仕様を知っていれば自明なことでしょう。
そりゃそのとおり

111 :がばろん@Mたんちゅきちゅき:01/11/10 21:33 ID:???
>>102 60たん。
とりあえず「オブジェクト指向入門」まで読み終わったよ。

並列実行といえば話の流れは、かわるけど、
むかしJavaでゲームに登場させるすべてのキャラに
ひとつひとつスレッドをわりふって、いっせいに動かしてみたよ。
こういう時こそオブジェクト指向は、べんりかも。

オブジェクト自身が自分の状態を保存してくれるし、
ことなるクラスのオブジェクトを同一のメッセージで処理できるし。

// ただ、それでも「順番に命令をならべてそれがそのとおりに実行される」
// というのは、おれも基本的に変わってないとおもう。

// ところで>>102のリンク。60たんのおすすめのページは、どこ?
// たくさんありすぎて、つぎなに読めばいいのか、わかんないや。(TT

112 :名無しさん@お腹いっぱい。:01/11/10 21:47 ID:???
>>105
・モジュール
構造化プログラミングで、ある機能を有する小部分をモジュールという。
容易に交換し得るような機能単位のプログラムを指す。プログラムを
モジュール化して作れば、次のような利点があり開発効率の向上が期待できる。
1)開発時に分業化できる
2)誤りの部分発生を特定できる
3)機能改善に部分変更で対応しやすい

113 :60:01/11/10 21:54 ID:???
入り口までは案内した 扉は自分で開け

って感じ
自分が興味を感じたタイトルから読んでくのが吉と思われます

明日の自分は今の自分より強いですか?

114 :名無しさん@お腹いっぱい。:01/11/10 21:58 ID:???
>>111
C++のページで半年ほど独学すれば?

115 :名無しさん@お腹いっぱい。:01/11/10 22:11 ID:fxXO3W0o
>>109
何をって何?

C++は仕様が汚くて後々再利用するものをC++で書く気にはなれない。

>言語仕様を知っていれば自明なことでしょう。
もちろん自分で作ったものに関しては自明で大変便利な機能だが
他人のものを読む時にはくだらない労力が増える。
裏で行われているかどうかではなくて、
行われている事を調べるのが大変
継承を繰り返しているともはやあほくさくてやってらんない。

>裏で何をやっているか本当にわからないような
>言語でプログラミングなんて不可能
そんなことはない

116 :19=105:01/11/10 22:11 ID:???
>>112
サンクスです。
要するに構造化プログラミングを勉強しろということですね。

117 :名無しさん@お腹いっぱい。:01/11/10 22:17 ID:???
>>105
モジュールの概念は、開発時にバグを減らすための技法
覚えておけば、かなりバグを減らせる

一応、情報処理技術者試験で出るんだが・・・

118 :名無しさん@お腹いっぱい。:01/11/10 22:18 ID:???
>>115
>継承を繰り返しているともはやあほくさくてやってらんない。

藁。もうプログラミングやめた方がいいんじゃない?

119 :名無しさん@お腹いっぱい。:01/11/10 22:20 ID:???
たぶん最初からやってないと思われ。

120 :名無しさん@お腹いっぱい。:01/11/10 22:20 ID:fxXO3W0o
だから、C++使うな!

121 :名無しさん@お腹いっぱい。:01/11/10 22:21 ID:???
>>116
ま、そーゆー事やね。

122 :名無しさん@お腹いっぱい。:01/11/10 22:22 ID:???
>>120
・・・それでも使っちゃう・・・♪

123 :名無しさん@お腹いっぱい。:01/11/10 22:22 ID:???
こういう本筋とは関係無いどうでもいいスレッドばっかり育ってるなここ

124 : ◆XAJ1OOH6 :01/11/10 22:22 ID:Qp+UDwx7
ゲーム機などのリソースが限られていたときの
伝統が残っていて,どのようにソースを書けば
最適コードになるか意識するという強迫観念が
あるからコードの吐き方がイメージできないと
怖いのではないのでしょうか?

125 :名無しさん@お腹いっぱい。:01/11/10 22:26 ID:???
>>124
でも思ってるほど、最適なコードなんて書けてないのがゲームプログラマ

126 :名無しさん@お腹いっぱい。:01/11/10 22:26 ID:fxXO3W0o
アセンブラで最適化って最高に楽しいよね。
浮動小数点演算のあの糞なスタックをやりくりする
楽しさといったら!

127 :名無しさん@お腹いっぱい。:01/11/10 22:27 ID:???
>>124
単に、プログラムの設計を勉強してないだけの話
そりゃ、命令を適当に組み合わせるだけでも、
プログラムを作る事は出来るケドね

つーか、プログラムの設計を理解してない人に
OOPなんぞを使わせても、猫に小判。

128 :名無しさん@お腹いっぱい。:01/11/10 22:30 ID:9kWZOylY
Cなら向こうにアセンブラソースが透けて見える??
cpuが違っただけで、例えばペンティアムUとVの違い
で全く別言語のような環境と化してしまうアセンブラを
どうやって”透かして見る”んだ?教えて!!

129 :名無しさん@お腹いっぱい。:01/11/10 22:34 ID:???
>>127
いや、そういう人が使うためのOOPでしょ。
汗職人には汗職人のための職場がありますよ。
多分。(藁

130 :名無しさん@お腹いっぱい。:01/11/10 22:41 ID:EimNIGyJ
>>129
ライブラリが充実しているなら、同意するケドね・・・

131 :名無しさん@お腹いっぱい。:01/11/10 22:41 ID:???
>>128
78はプログラミング経験が皆無か、
超環境依存型のクソプログラム書いてるんでしょ。
なんに使うのか謎だけど。気にしないでいいよ。

132 :名無しさん@お腹いっぱい。:01/11/10 22:43 ID:???
ここはアホぷるぐらまのスレか?

133 :名無しさん@お腹いっぱい。:01/11/10 22:46 ID:???
>ペンティアムUとVの違い
>で全く別言語のような環境と化してしまう
オイオイ、
そんなに最適化されたコードはくコンパイラあるのかYO!

134 :名無しさん@お腹いっぱい。:01/11/10 22:49 ID:???
128と131はアセンブラで組んだ経験が皆無

135 :_:01/11/10 22:51 ID:ZOY2QX/S
高級言語ってアセンブラを意識しなくて良いように作られたんちゃうの?
生成されるバイドコードが想像出来ないからダメって、そりゃお門違いも甚だしい。
コンパイラに頼りきりになるであろう、IA64のようなアーキテキチャの場合どうすんの?
俺に言わせればわかろうとする方がおかしい。

136 :名無しさん@お腹いっぱい。:01/11/10 22:51 ID:???
>>133
だからアセンブリ言語の事言ってるんだよ。
コンパイラとアセンブラの違いは分かるかい?

137 :名無しさん@お腹いっぱい。:01/11/10 22:51 ID:???
>>ペンティアムUとVの違い
>>で全く別言語のような環境と化してしまう
>オイオイ、
>そんなに最適化されたコードはくコンパイラあるのかYO!

IntelCは吐き分けてくれると思ったけど、どうでもいい話題なのでsage

138 :名無しさん@お腹いっぱい。:01/11/10 22:55 ID:???
>>136
78はコンパイラについてだよ。分かるかい?

>IntelCは吐き分けてくれると思ったけど、
吐き分けてどうしようって言うんだ、一体?

139 :名無しさん@お腹いっぱい。:01/11/10 23:04 ID:???
>>138
コンパイラなのにアセンブラソースが見えると書いてるよ。
分かるかね?
>吐き分けてどうしようって言うんだ、一体?
どうするのか分からんなら聞かなくていいよ。(藁

140 :名無しさん@お腹いっぱい。:01/11/10 23:08 ID:???
ふう。このスレも某3Dプログラミング系ページに晒されそうだな。

141 :名無しさん@お腹いっぱい。:01/11/10 23:12 ID:???
>>139
それは実際の実行プロセスに非常に近いという事だろう。

142 :名無しさん@お腹いっぱい。:01/11/10 23:18 ID:???
>>141
・・・ハァ?
>それは実際の実行プロセスに非常に近いという事だろう。
言ってることが(危)レベルに達してますな。

143 :名無しさん@お腹いっぱい。:01/11/10 23:21 ID:???
もー全然OOとゲームプログラミングぢゃねーよ
Game Programming Gems並みのネタをキボンヌ

144 :名無しさん@お腹いっぱい。:01/11/10 23:21 ID:???
>>142
ハァ?
分からんの?

145 :名無しさん@お腹いっぱい。:01/11/10 23:33 ID:ArMYUgNW
うう良いスレだったのに

146 :名無しさん@お腹いっぱい。:01/11/10 23:37 ID:???
とりあえずアセンブラソースを実行なんたらと
勘違いしている>>144を放置してOOPに関する
話題で再開しましょうか。

147 :60:01/11/10 23:37 ID:???
貴方がなぜC++を使わないゲームプログラミングをしているのか
理由を書いてくれる人 他にはいないの?

148 :名無しさん@お腹いっぱい。:01/11/10 23:39 ID:???
>>147
あなたって?

149 :名無しさん@お腹いっぱい。:01/11/10 23:40 ID:???
貴方って誰?

150 :名無しさん@お腹いっぱい。:01/11/10 23:47 ID:???
>>146
実行なんたらってなんだ?
あほか?

151 :60:01/11/10 23:59 ID:???
「ゲームプログラミングをする時にC++を選択しませんでした。」
という人がいるなら、その理由を聞きたいわけですよ
非常に興味深い

まぁ、「対象となるターゲット用C++コンパイラがありません」つーのは
ご愁傷様としか言えませんが
コンパイラ移植するって手もあるけどね

152 :とむ ◆TMwDpCZo :01/11/11 00:00 ID:???
やあ、今ログ読んでました。
すみませんね、荒れる原因みたいになっちゃって。

でも全体的に停滞気味の板だから、たまにはいいかな?(笑)

153 :名無しさん@お腹いっぱい。:01/11/11 00:33 ID:kQ4U2tS+
私、ゲーム専用機対象にプログラミングしたこと無い門外漢ですからサパーリで
興味本位に質問ですけど、C++コンパイラ使えるようになったのって
どのあたりからですか?
  +->PCE   +->DC
FC->SFC->PS->PS2
          +->64->GQ
見たいな流れの中で

154 :名無しさん@お腹いっぱい。:01/11/11 01:17 ID:???
3DO,PSあたり?

155 :名無しさん@お腹いっぱい。:01/11/11 01:30 ID:S9ESG1BU
>>151
C++コンパイラの最適化性能が低くて、糞なコードを量産する
そもそも、まともにC++の言語仕様が実装できていない

なんて理由もあるかもね。

156 :47で66:01/11/11 02:41 ID:???
>60
該当者なんで、私もレス書きまーす。
前もって書きますが、私自身、流行の思想については使いこなせれば
良いなーと羨ましいですし、OOについて偏見もありません。

私はCのみでゴリゴリのヒトです。
理由ですが、必要ないから(必要性を感じる局面に遭遇してない)
という事と、やはり
「始めに物ありき」の考え方よりも、
「始めに物事の振る舞いの、法則ありき」の方が、私自身、
皮膚感覚的に馴染めるからです。これは、食わず嫌いではなく、
プログラムに限らず、何かを考える際、「物」(主語、目的語)
ではなく「事」(動詞)から先だって考えてしまう癖が
あるからのようです。

おそらく、このような思考方法の人間が、無理やり似非OO的
プログラムをしたところで、欠陥のある設計しかできないに
違いありません(笑)
そんなわけで、私は大人しくOOには触れずにおります。

157 :名無しさん@お腹いっぱい。:01/11/11 02:59 ID:+9QMetsd
>おそらく、このような思考方法の人間が、無理やり似非OO的
>プログラムをしたところで、欠陥のある設計しかできないに
>違いありません(笑)
>そんなわけで、私は大人しくOOには触れずにおります
 押しつけるつもりはないけど、一通り勉強してから
結論出しても遅くないと思うけど・・・。
なんかもったいない

158 :156:01/11/11 03:23 ID:???
いやいや、現状で「そうだ」というだけで、決して結論を出した
わけではありません(笑)

さらには、まったく勉強してないわけでもありません。
勉強不足の度合いと、それが原因か否かはさておき、
現状では私の仕事に役立っていないというだけの話でして、
今でも関連書籍を読んだり、テストプログラムは書いて
みたりはしております。

159 :名無しさん@お腹いっぱい。:01/11/11 04:37 ID:???
>>158
大規模なものを組み始めるとOOな手法が管理しやすいのだけど
もともとOOはSAと対立する技術ではないので、SAの技法もきちんと
勉強するのも大切なことだと思いますよ。
地盤が脆い状態で高層ビルを立てるのが不可能なように
コードを何十万行も書いて、経験を積んでSAもOOD/OOAも実装も
コストも利点も理解したうえでターゲットに最善な手法を
選べるようになれば結構いい感じになるんじゃないでしょうかね。

ぶっちゃけた話、木造二階建てを作るのにツーバーフォーな手法よりも
大工職人がトンカンやったほうが、ツーバイフォーな会社を作るより
小回りが効くし、でも出来てしまえばツーバイフォーは早い納期で
高層ビルだって立てられる。でもそれを設計するには習熟と経験が
必要不可欠なわけで。

うーん。私も勉強しなくては…。
勉強不足な自分への自戒の意味もこめて。

160 :名無しさん@お腹いっぱい。:01/11/11 04:42 ID:???
今の会社はCマンセー。

Cを使うにしても、使いまわされることを前提に作られているなら
まだいいが、プロジェクト毎にソースコピペかYO!

3年以内に効率の悪い開発体制を変えられなかったら、
会社辞めることになるな。

ま、Cしか使えない厨房は家でおとなしくしてないさい、ってこった。

161 :名無しさん@お腹いっぱい。:01/11/11 05:09 ID:???
プロジェクト毎にソースコピペかYO!

ソースコピペかYO

YO

162 :名無しさん@お腹いっぱい。:01/11/11 05:18 ID:???
160
(・∀・)カコイイ! ゲラゲラ

163 :がばろん@Mたんちゅきちゅき:01/11/11 06:53 ID:???
>>113-114 60たん。114たん。

とりあえず分散オブジェクトと
デザインパターンのとこから読み進めてみる。

ふたりのおかげで気力が、わいてきたよ。
ありがとう。☆⌒(*^-°)v Thanks!!
// こんど開発状況報告スレにも、いってみようかな。

>>50 とむたん。>>156たん。

いっそ、その「物事の振る舞い」だけを集めたクラスを作って
オブジェクト指向してみるって、どうかしら。

つまり仮想関数だけで構成される
通常のメンバ関数もメンバ変数も持たないクラス。

で、その「物事の振る舞い」が、
なにかのデータ群(つまりクラス)で必要になったら、

そのデータ群に仮想関数だけのクラスを継承させて、
そのデータ群に特化した処理を実装するの。

Javaにおけるインターフェイス的な考え方だけど、べんりだよ。
このクラスは、いっさいデータをふくまないから、
多重継承になっても、ややこしさが発生しないし。
// ただ問題は処理速度かも。。。

ところでJavaでゲームを作ろうとしてるおれは、
もしかして、ここではスレ違いで逝ってよしなのでしょうか。

// いや、それ以前にJavaの処理速度で逝ってよしという気もする。
// 鬱朶思王。。。でも氏なないで、がんばる。
// でも、おれが逝くまえにJavaが先に逝きそうな気もするよ。(TT

164 :名無しさん@お腹いっぱい。:01/11/11 07:03 ID:???
インラインアセンブラを多用したプログラムを組みたい
ヘッダをインラインまみれにしても極限まで自分でチューニングしたい
いわゆる汚い泥作業も厭わない任侠気あふれるOOなら C++

165 :名無しさん@お腹いっぱい。:01/11/11 07:22 ID:???
>>163
複数の人が別々にコーディングする場合はその方が吉だろうね。
一人でやる場合はOOPにこだわる必要はあまり無いとは思うけど。
関数の集合クラスを作ったり継承したりっていう余分な作業は一人で
やる時は得るものが少ないんじゃないかな。
JAVAはアメリカでは終わりだとか言われてるけど(MSがサポートを辞めた)
日本ではまだ元気があるみたいだし、しばらくは大丈夫かも。
速度は問題だよね。技術が足りないからだとか言われるけどそこそこの
技術力でももう少し速くなればいいのに思うよ。

166 :名無しさん@お腹いっぱい。:01/11/11 08:14 ID:???
Cでゴリゴリやってる人にはC++はかなり泥臭くて似合ってると思うのだが。
C言語が好きじゃない俺は、C++はいくらOO言語だからっていやだけど

167 :モデルやテクスチャのオプティマイズ>CPUのオプティマイズ:01/11/11 09:56 ID:???
先生!とりあえずC++が遅いって言うのは論外だと思うYO!
どうしても速度的に問題ある部分は、モジュール分けてCで書くっていうのじゃまずいの?
俺はそんなことはしませんが。使える環境なら必ずC++を選択するよ。

っていうかC++ワカランってところってまだ結構あるよね。
この前もローカライズ担当してる下請けがC++解りませんって泣きついてきたよ。(ワラ
C++駄目って奴はとりあえずC++で一本作ってから
反論した方が恥をかかないで済むと思われ。

168 :名無しさん@お腹いっぱい。:01/11/11 10:38 ID:???
>>166
プロのゲーム開発の現場に限ったらASM,C,C++以外に選択肢は無いのでは?
C/C++に負けない実効速度を出せるOOPLってあるのだそうか?
純粋な質問。

169 :名無しさん@お腹いっぱい。:01/11/11 11:27 ID:???
>167

どうも、このスレの流れとして
一部をCとかアセンブラで書くと良いじゃないの? -> やっぱり遅いってことじゃない。アヒャヒャヒャ
って流れらしい。

おれは楽できるところは楽すれば良いと思うけどな。

170 :名無しさん@お腹いっぱい。:01/11/11 11:32 ID:???
一部をCとかアセンブラで書くと良い = 最適化して書く
が前提。

171 :名無しさん@お腹いっぱい。:01/11/11 11:33 ID:???
>>168
コンシューマだとないだろうな。そもそも処理系がない。

172 :名無しさん@お腹いっぱい。:01/11/11 12:32 ID:TZbrGtZW
>>60
>C++で実際に実行される順番が異なってしまう状態例を
>あげてくれると非常にうれしいです。感激しちゃう。

グローバル変数のコンストラクタ/デストラクタ。

173 :名無しさん@お腹いっぱい。:01/11/11 13:12 ID:???
それは最初から不定なので問題なし。

174 :_:01/11/11 15:07 ID:6XiTGObp
>>169
C++が遅いと言われても、そんなことは絶対にないと断言は出来ない。
もしかしたら自分の知らないケースで、めちゃ遅くなるかもしれないし。
そういうことで、逃げうってるだけだと思われ。

175 :名無しさん@お腹いっぱい。:01/11/11 15:16 ID:???
C++がCより遅くなる、具体的なコード例を挙げられる人居る?
仮想関数によるポリモーフィズムは遅いと言われがちだけど、
同じ事をCでやるとif文やら関数ポインタやら使うわけで、少なくともC++より高速に動かせるという保証はないと思われる。

176 :名無しさん@お腹いっぱい。:01/11/11 16:07 ID:???
どっち派でもいいんだけどさ、互いにコッチだ!って啓蒙しあう
必要ないでしょう。(そーいうのはヨソでやろう)
このスレは、前提としてOOで、どの様に良い設計をしていくか
がテーマなんだから、そういう話をしないと
「まったく意味がない」

177 :名無しさん@お腹いっぱい。:01/11/11 16:18 ID:???
確かにCで一つ一つ全て別々に作っていたものを
C++で基本部分からの継承で作ると結構遅くなる。

178 :名無しさん@お腹いっぱい。:01/11/11 16:54 ID:???
深い継承は、その時点で設計が間違ってることが多い(MFCとか)。
デザインパターンを勉強するよろし。

179 :名無しさん@お腹いっぱい。:01/11/11 17:53 ID:???
多少遅くなったぐらいで実際に影響が出る環境で作ってる人が多いみたいですね。
コンシューマの方ばかりなのかな?

180 :19:01/11/11 19:53 ID:???
業界人手あげてー!

現場ではCとC++の使用比率どれくらいですか?
て前にきいたけど、だれも答えてくれない(泣

181 :19:01/11/11 20:29 ID:???
ところで、以前「モジュールの勉強って何?」ときいて恥をかいた漏れです。
結構Cは書いてきたので、処理とデータをまとめてドメインの独立性を高める
努力は必然としてやっていたんですが「構造化プログラミンの勉強」っていうのを
真正面からやったことは確かにない。
で「構造化プログラミング」の参考書を探しに本屋にいったんだけど無いですね、
全然。オブジェクト指向ばっかり。
ためしにオライリーの「C言語実践プログラミング」をぱらぱらと見たら、一応
モジュールとかデータ構造とか書いてあったけどなんか、いまさらなことばかり。
今までやってきた文法以上のCの訓練が実は構造化プログラミングだったてこと
でしょうか。
構造化プログラミングを極めるための本とか、構造化デザインパターンみたいな
ものってあるのでしょうか?
スレ違いでスマソ。

・・・何も買わないのは癪だったので「Game Programing Games」かってしまった。

182 :名無しさん@お腹いっぱい。:01/11/11 20:35 ID:???
>>181
構造化定理って調べてみ

183 :ラム:01/11/11 20:42 ID:BveFsL2V
ageるっちゃ。

184 :19:01/11/11 20:44 ID:???
>>182
サンクス、ザクザク出てきた。
この世界も奥深いね。べんきょー!べんきょー!

185 :名無しさん@お腹いっぱい。:01/11/11 22:05 ID:HcMXioW1
仮想関数には関数ポインタのような柔軟性がないのが嫌。
以前、
CTask{
virtual void Update();
};
CEnemy extends CTask
CEnemy1 extends CEnemy
CEnemy2 extends CEnemy
CEnemy3 extends CEnemy
みたいな設計をして失敗した。

やっぱりコアは構造体と関数ポインタに限るよ。


186 :名無しさん@お腹いっぱい。:01/11/11 22:11 ID:BveFsL2V
>>185
それがどういう不都合があったのか教えてもらえれば、
解決方法を提示できるかも風来のシレン。

187 :名無しさん@お腹いっぱい。:01/11/11 22:40 ID:f4mbVjfS
>>186
・コーディング量が増え、生産性が落ちる。
関数ポインタの場合、関数を作ってアドレスを渡すだけだが、
仮想関数の場合、最低限classの定義、仮想関数の定義、コンストラクタの定義が入るため
余計なコーディングが必要になる。
ましてやクラスごとにcppとhを作っていた場合ファイル数がたいへんなことになる。

・動的なメモリ確保を強制される
関数ポインタの場合、関数アドレスを変更するだけで動作を変更できるが、
仮想関数の場合delete,newを呼び出す必要がある。
オーバーヘッドとメモリの断片化が問題となる。

・他クラスを参照している場合の解放タイミングの問題
参照先のタスクが解放済みか否かの判断が複雑になる。
静的に確保された構造体では、消去済みフラグを立てておけば
参照先が消去済みかはその参照先のフラグを調べることで判断できるが、
deleteされたクラスにこれをやると、不正なメモリアクセスになり落ちる。
もちろん解決方法はあるが、そのオーバーヘッドがばかにならない。

他にもいろいろあるがとりあえず代表的なものを。

188 :19:01/11/11 22:49 ID:???
ム板のゲーム開発スレでも出てたけど、
オブジェクトは必ずしも不要に成ったらdeleteしなければ成らないわけではない。
まとめてワーク用オブジェクトのプールを作っておいて、フラグ、ID管理をする
こともやろうと思えばできる。
これを実現すれば>>187の2,3番目の問題はある程度解消できるよね。

この変が、ゲーム開発的OOPの特徴にになってkるんじゃないかと、
素人ながらに思っています。

189 :187:01/11/11 22:52 ID:f4mbVjfS
後重要なものを忘れていた。
・動的な型情報の取得が簡単にできない。
関数ポインタの場合、function_address == Enemy1?で判断できるが、
クラスの場合CEnemy1クラスであるかどうかの判断が大変面倒になる。

190 :名無しさん@お腹いっぱい。:01/11/11 22:57 ID:???
>>187
どういう場合に型情報が必要ですか?
基本的には抽象化された型情報の実際の型
を知らなくても、振る舞いをさせることが出来るのが
理想な気がしますが…。

191 :名無しさん@お腹いっぱい。:01/11/11 23:04 ID:f4mbVjfS
>>190
特定のタスクを消したい、特定のタスクのみ更新したい。
こうした要求は少なからずある。
MFCでも、IsKindOf(RUNTIME_CLASS())という動的に型情報を取得するための
メソッドが用意されているでしょ?

192 :名無しさん@お腹いっぱい。:01/11/11 23:07 ID:???
>180
んー、ツールではC++使うけど、製品には使わないねぇ。
基本的にCでなんでも出来ちゃうわけだから、「圧倒的に開発効率が良くなる」
とかいうシチュエーションにならない限り使わないと思うなぁ。
出来あがったソースコードはC++の方が綺麗だけど、
他の開発メンバーの書いたコードを理解するのはCの方が
しやすかったり、ヤバめのバグをアセンブラソースレベル
で追跡したりするハメになった時Cの方が楽だったり・・・

ちなみに、スレの本題の「OO」については、言語に
関わらず自然とそうなってる気がしますが。

193 :名無しさん@お腹いっぱい。:01/11/11 23:15 ID:???
完全なOOなんて相当な大規模プロジェクトでない限り、
馬鹿げている。

194 :19:01/11/11 23:19 ID:???
>>192
ありがとうございます・・・
やっぱりまだこの業界では「これから」の技術なのでしょうか。
C++に移行してゆく保証もありませんけど。

>>188でもちょっと書きましたが、ゲーム開発にはゲーム開発の独特の
OOPが必要なのは間違いないはずです。
OOではデザインパターンというものが重要な地位を占めてますが、
ゲーム開発的デザインパターンがまとめられて、それに基づいた設計・実装
ができるようなクラスライブラリが整えばC++への移行もあるかも知れない
というところでしょうか。

195 :名無しさん@お腹いっぱい。:01/11/11 23:19 ID:???
>>191
では、そのIsKindOf(RUNTIME_CLASS())(のようなもの)であるとか、
Updateのメソッド自体に更新の判断をさせるほうが良い気がするのですが…。
それではデメリットがあるのですか?

196 :名無しさん@お腹いっぱい。:01/11/11 23:23 ID:+Lh2D+yi
>>195
IsKindOfを実装するには、これまたクラスごとに面倒なコーディングが増えるわけよ。
関数を作って、SetTask(Function)を呼び出すだけとい
お手軽さとは雲泥の差があるわけ。

Updateに判断させる場合、すべてのクラスにその判断処理を実装する必要があるわけでしょ?
それまた面倒でパフォーマンスも悪いわけ。

197 :187:01/11/11 23:29 ID:+Lh2D+yi
一応、現在の実装例を書いておこう
CTaskManager{
public:
TASK* SetTask(void* function_ptr);
void Update();
private:
TASK mTask[MAX_TASK];
};

CEnemy{
public:
static void Enemy1(TASK*);
static void Enemy2(TASK*);
static void Enemy3(TASK*);
};

198 :_:01/11/11 23:34 ID:Tn36jYF+
>>192
俺もC++の可読性については、ちょっと同意かなあ。
ちらっと読んでもわからないんだよね、他人のソースが。
継承ツリーの根元にあるメンバなんか、いきなり出されても
作った本人しかわからないよねえ。
グローバル変数使いまくりのCでも、そっちの方が読みやすいというのはあるよねえ。

199 :名無しさん@お腹いっぱい。:01/11/11 23:34 ID:???
C++(OO)は圧倒的にデバッグが楽。って思うのは俺だけ?
特に多人数での開発になると顕著だと思うんだけど。
他のプログラマによる不正な操作を制限しやすいのはかなりメリットだと思う。

Cでもキチンと書けば問題無いんだけど、
なんか致命的かつ再現率の低いバグが出やすい気がする。
↑これは自分がへぼいのは自覚してます。

あとまともに動けば例外処理もかなり強力だと思うざんす。

200 :199:01/11/11 23:36 ID:???
圧倒的ってほどでもないですね。誇大表現でした。

201 :名無しさん@お腹いっぱい。:01/11/11 23:36 ID:???
>>196
>Updateに判断させる場合、すべてのクラスにその判断処理を実装する必要があるわけでしょ?
こういう場合、むしろ管理する側がチェックするよりも自分自身が判断する方が
むしろ軽くできそうなすみそうな気がしますけど…(適当でスマソ)
#もちろんこの程度ならC++使わなくても、Cだけでも出来ますけど。
class ab
{
virtual void update(const status& a)=0;
};
class con0 : public ab
{
virtual void update(const status& a){ do_update(); } // これはいつでも更新するクラス
}
class con1 : public ab
{
virtual void update(const status& a){ if(!a->pause){ do_update(); }} // pauseしてないときだけupdate
}

...
for(vector<ab*>::iterator i=obj.begin(); i!=obj.end(); i++){(*i)->update(current_status);}

202 :187:01/11/11 23:46 ID:+Lh2D+yi
>>201
いや、
if (pause){
 for (;;){
  if (task[i]->update == PauseTask){
    (*task[i]->update)(&task[i]);
  }
 }
}else{
 for (;;) (*task[i]->update)(&task[i]);
}

条件分岐をループの外に持っていけるし、妙な引数も必要ない分、
圧倒的に有利だよ。
まあPauseの用途に限定するならタスク構造体に属性を持たしておいた方が便利だけど。

203 :名無しさん@お腹いっぱい。:01/11/11 23:47 ID:???
>>199
なんとなく同意です。
自分自身のヘボさを知るものとしてはCよりもデータへの不正な制限を掛けやすい
C++の方がいいかなぁ…と思ってます。

204 :名無しさん@お腹いっぱい。:01/11/11 23:50 ID:???
>>199
俺も楽だと思うよ。
問題が局所化されるから見る範囲がかなり限定されてくる。
まー、何にせよ慣れでしょうね。
Cべったりな人たちには無理せず使い慣れたCがよござんしょ。

205 :192:01/11/12 00:00 ID:???
>>194
ツールではバリバリ使うんで業界的に(というか、うちの会社的に)
「これから」っていうわけでもないんですけどね。なんでツールで
使うかといえば、クラスライブラリが用意されてたりして「圧倒的
に効率が上がる」から。

ツールとか実用ソフトの場合、インターフェイスの統一性
が重要ですが、ゲームの場合は寧ろゲーム毎の独自性や面白さ
の方が優先されるわけで、その辺も難しいですね。

あと、コンシューマーの場合リソースの管理をかなり見通しが
効くようにしておかないといけないのが、楽に組めない要因で
すね。快適にプレイさせる為には必要になった時にリソース
確保じゃ遅い(先読み対応)とか・・・
メモリも、「メモリ128MB以上推奨」で済まないし、
「最悪仮想記憶で・・・」というわけにもいかない。
C++でやるにしても、メモリ管理は全部自前でしょうね。
まぁこれは、PCでもそうなんでしょうけど。

なんか、愚痴っぽいな。

206 :名無しさん@お腹いっぱい。:01/11/12 00:01 ID:???
>>202
う〜ん、このあたりは判断すべき条件の場合分けの数であるとか、どこの
オブジェクトがその判断に責任を持つかっていう所で実装を分けるかも
しれないっすね。(そういう意味ではpauseは不適当だったか?)

私が>>202のようなソースを見たときに一番危惧するのは、条件分けが
多岐にわたったときに(pauseだけではなく、アドバタイズであるとか、
デバッグ用のモード(?)であるとか)updateの呼び出しが多個所になって
しまい、たとえばupdateメソッドの呼び出し方が変わった場合、変更が多岐
にわたってしまうんでないかい?とか思ってしまうのです。

#このあたりの考え方は好みに近いところだと思うので、なにが正解とも
#思いませんけど…。

207 :名無しさん@お腹いっぱい。:01/11/12 00:44 ID:tWtzB3Ur
>>206
CTaskManager::Update()
{
 switch(mode){
 case UPDAETMODE_DEFAULT:
  for (;;) (*task[i]->update)(&task[i]);
  break;
 case UPDATEMODE_PAUSE:
  for (;;) (*task[i]->update)(&task[i]);
  break;
 case UPDATEMODE_DEBUG:
  for (;;) (*task[i]->update)(&task[i]);
  break;
 }
}

多岐にわたる理由などありませんが。

208 :名無しさん@お腹いっぱい。:01/11/12 00:45 ID:???
>>207
ヲイヲイ・・・

209 :名無しさん@お腹いっぱい。:01/11/12 00:46 ID:tWtzB3Ur
>>208
何か問題でも?

210 :206:01/11/12 01:07 ID:???
>>207
208の煽りは私ではないですよ〜。誤解しないでね。(ニコ

#以下は好みの話し程度に読んでください。
いや、>>202のpauseの時にその呼び出し側に関係ない処理は(OOP抜きとは関係ないですけど)
呼び出し側で制御すべきでないと思うんですよ。(それは例え>>207のような形であっても、結局
caseの数だけupdateメソッドを呼び出す個所が出来るわけで。)
もし一つ一つのオブジェクトで処理を判断するのが重いぜ、やってられないぜというのであれば、

// >>201からのつづきと考えてくださいね
// 文法的に嘘があっても無視の方向で(自虐藁
class ab_collection
{
vector<ab*> abc;
void add_ab(ab* _o){ abc.push_back(_o); }
virtual void update(const status& _stat) = 0;
};
// 見たいな形でオブジェクトをまとめるクラスを一段「かませ」て、
class free_ab_collection : public ab_collection // 判断のひつようなしクラス
{
virtual void update(const status& _stat){
for(vector<ab*>::iterator i=abc.begin(); i!=abc.end(); i++){ (*i)->update(_stat); }
}

class test_ab_collection : public ab_collection // pauseフラグをチェック
{
virtual void update(const status _stat){
if(stat->pause){ return; } // ここでチェックすることで、以下のabの各クラスではチェックする必要が無くなる
for(vector<ab*>::iterator i=abc.begin(); i!=abc.end(); i++){ (*i)->update(_stat);
}

みたいにしてやれば、見通しも良いまま、効率を保つことも可能ではないかと。
(親クラスはab_collectionの塊を持ってupdateを呼び出すだけ。)

実際にプログラムで重いところって大量のメモリのキャッシュミスと回数の非常に多い単純計算
だと思ってるんで、そこさえ気をつければ、見通しよくプログラムするためのコストって許されるんじゃ
ないかと思ってます。
#もちろん、見易さは人によってそれぞれだとおもうんで、>>207さんの方法も尊重します。

211 :206:01/11/12 01:09 ID:???
>>210間違い
それぞれのab_collectionから継承させたオブジェクトで
>for(vector<ab*>::iterator i=abc.begin(); i!=abc.end(); i++){ (*i)->update(_stat); }
を呼ぶのは愚の骨頂ですね。ab_collectionに置くべき処理でした。
失礼…。

212 :名無しさん@お腹いっぱい。:01/11/12 03:36 ID:???
少なくともPCゲームのプログラムを組む場合、
C++を利用したことによるオーバーヘッドはほとんど
気にしなくていいような気がします。

213 :名無しさん@お腹いっぱい。:01/11/12 07:13 ID:???
PC(Windows)のゲームでメモリの断片化気にして組まれてるのはどのくらいあるんだろ…。

214 :名無しさん@お腹いっぱい。:01/11/12 07:56 ID:???
というか断片化の話はoperator newのオーバーロードで対処。
CTaskの継承クラスのサイズに最大128バイトとか制限かけて、
メモリプールから確保するようにする。

215 :名無しさん@お腹いっぱい。:01/11/12 21:17 ID:???
>というか断片化の話はoperator newのオーバーロードで対処。
オーバーライドだと思うが…。
細かい突っ込みかな。

malloc自体が仮想メモリを利用することが前提の関数だし、おそらくnewもそうだろうと思います。
仮想メモリがある環境だと、あまりメモリの分断化は気にしないかも。
コンシューマだとガベージコレクトやメモリコンパクションやらを考えないと
いけないでしょうね。
メモリマップを始めにきっちりと作るというのも手だと思いますけど。

216 :名無しさん@お腹いっぱい。:01/11/12 21:24 ID:???
>>215
オーバーロードでも対処できるよ。
newに特殊なパラメータ(フラグ)を取らせてそれによって、デフォルトのnewとは
動作を変える。
この場合、newの動作が暗黙のうちに最適化されるのではなく、プログラマが必要
に応じてメモリ割り当ての方法を選択できる。
うまくやれば、こっちの方が便利かもしれないよ。

217 :名無しさん@お腹いっぱい。:01/11/12 21:28 ID:???
昔、擬似タスク処理をC++で実現しようとしたとき、処理とその処理で使う
メモリ領域をどうすり合わせるかで挫折した。

Cの場合は、構造体内部に関数へのポインタがあればそれを切りかえることで
簡単に実現できた。
C++の場合、上記メソッドのオーバーロードで簡単に実現できるのはひとつの
メソッドだけ。
無理やりやろうとすると、オーバーロードするメソッドの中で
処理するメソッドへのポインタを利用して処理を飛ばすという、
なんとも汚いものになった。
こんなことするくらいなら、構造体+関数へのポインタで処理させたほうがまし
だと思った。

218 :名無しさん@お腹いっぱい。:01/11/12 21:36 ID:???
>>217
ごめん、ちょっとわかりにくい。
「オーバーロードで簡単に実現できるのは1つだけ」というのは
operator newのオーバーロードが1つだけってこと?

219 :名無しさん@お腹いっぱい。:01/11/12 23:02 ID:aPZmJhKt
>処理するメソッドへのポインタを利用して処理を飛ばすという、
>なんとも汚いものになった。

あまり解釈に自信がないんだけど、例えばこういうの? 汚いかなあ。

typedef void(Task::*TaskFunc)();

class Task {
public:
  void SetMethod(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
  void Update() { (this->*m_updateFunc)(); }
private:
  TaskFunc m_updateFunc;
};

class HogeTask : public Task {
public:
  HogeTask() {
    SetFunc((TaskFunc) Func1);
  }
  void Func1() {
    ...
    SetFunc((TaskFunc) Func2);
  }
  void Func2() { ... }
  void Func3() { ... }
};

220 :219:01/11/12 23:06 ID:???
こうやってTaskManagerから直接呼び出してもいいか。

class Task {
  friend class TaskManager;
public:
  void SetMethod(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
private:
  TaskFunc m_updateFunc;
};

221 :219:01/11/12 23:07 ID:???
ギャース
s/Method/Func/g

222 :名無しさん@お腹いっぱい。:01/11/13 00:29 ID:???
C++のソースはなぜこうも美しく無いのだろうか?

223 :名無しさん@お腹いっぱい。:01/11/13 00:30 ID:???
>>222 Cで同じもん書いてみてみそ。

224 :名無しさん@お腹いっぱい。:01/11/13 04:25 ID:???
Cの人はなぜ、継承だけで解決しようとしたり、
C++で関数ポインタ使うのはイヤみたいに言うのかわからん。

225 :名無しさん@お腹いっぱい。:01/11/13 10:18 ID:???
とりあえず、タスクを1ステップ進行させるメソッドの名前は
みんなUpdateですか。

226 :名無しさん@お腹いっぱい。:01/11/13 13:13 ID:ClbS1Bbe
もうvirtual関数無しではプログラム組めないっす。

ゲーム系だと特に期限ギリギりでの仕様変更が多いので(仕様書な
んてものが存在しない場合も多いけど)、パッチ当てる感覚でその場
がしのげて良いです。

その後の事はしらん(藁。

227 :名無しさん@お腹いっぱい。:01/11/13 14:05 ID:FoEbYEta
>>219
Func1 は
typedef void (HogeTask::*FuncType)();
であって、
typedef void(Task::*TaskFunc)();
ではない。
メンバ関数へのポインタはクラスによってサイズが違うという話を聞いたんだが、
SetFunc((TaskFunc) Func1);
このキャストは安全なのか?


228 :名無しさん@お腹いっぱい。:01/11/13 14:08 ID:???
典型的なC++のタスクと、Game Programming Gemsの3.0みたいな
マクロ使った状態マシン組みあわせてみない?
オレは今から試すにょ。

229 :名無しさん@お腹いっぱい。:01/11/13 14:17 ID:???
>>227
安全じゃないからキャストしてると思われ(w
仕様上は安全じゃない(プログラミング言語C++第3版15.5.1)が、
C++の実装上は上手くいくのではないか。
ちとキモチワルイ感はある。

230 :名無しさん@お腹いっぱい。:01/11/13 14:36 ID:???
ありゃ、キャストしたからってうまくいくのか?
エラーが出そうなものだが。

g++でコンパイルしてみたけど、駄目だった。
コンパイラの問題かな。

231 :名無しさん@お腹いっぱい。:01/11/13 14:58 ID:???
こんなのどう?

#define DECLARE_TASK(TypeName) \
void (TypeName::*m_updateFunc)();\
public:\
virtual void Update(){(this->*m_updateFunc)();}\
private:\

#define SET_TASK_FUNC(FuncName) {m_updateFunc = FuncName;}

class Task
{
public:
  virtual void Update() = 0;
};

class HogeTask : public Task
{
  DECLARE_TASK(HogeTask)
public:
  HogeTask(){
   SET_TASK_FUNC(Func1);
  }

  void Func1(){
   …
   SET_TASK_FUNC(Func2);
  }
  void Func2(){};
};

232 :217:01/11/13 15:31 ID:4q6jfi+W
わたしが昔、書いたのは大体こんな感じでした。
219さんのソースを利用させてもらいます。

extern "C" {
#include <stdio.h>
}

//-----------------------------------------------------------
// 基本擬似タスク
//-----------------------------------------------------------
class Task {
public:
 Task() {};
 virtual ~Task() {};
 virtual void SetFunc(void) {}
 virtual void Update(void) {}
};

//-----------------------------------------------------------
// 擬似タスク定義部
//-----------------------------------------------------------
class HogeTask;

typedef void(HogeTask::*TaskFunc)(void);

class HogeTask : public Task {
public:
 HogeTask() { SetFunc(&HogeTask::Func1); }
 ~HogeTask() {};

 void SetFunc(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
 void Update() { (this->*m_updateFunc)(); };

 void Func1() { printf("Func 1\n"); SetFunc(&HogeTask::Func2); }
 void Func2() { printf("Func 2\n"); SetFunc(&HogeTask::Func3); }
 void Func3() { printf("Func 3\n"); SetFunc(&HogeTask::Func1); }
private:
 TaskFunc m_updateFunc;
};

233 :217:01/11/13 15:32 ID:4q6jfi+W
続き
//-----------------------------------------------------------
// 擬似タスク実行部
//-----------------------------------------------------------
class ExecuteTask {
 Task *taskArray[100];
 int iTaskPoint;
public:
 ExecuteTask() { iTaskPoint = 0; }
 void SetTask(Task* prtTask) { taskArray[iTaskPoint++] = prtTask; }
 void execute(void) {
  {for(int i = 0; i < iTaskPoint; i++) {
   taskArray[i]->Update(); }
  }
 }
};

234 :217:01/11/13 15:34 ID:4q6jfi+W
最後

//-----------------------------------------------------------
// メイン
//-----------------------------------------------------------
int main(int argc, char** argv) {
 HogeTask hogeTask;
 HogeTask hogeTask2;
 ExecuteTask executeTask;

 printf("<<1st>>\n");
 executeTask.SetTask(&hogeTask); // タスク1セット
 executeTask.execute(); // タスク実行

 printf("<<2nd>>\n");
 executeTask.execute(); // タスク実行

 printf("<<3rd>>\n");
 executeTask.SetTask(&hogeTask2); // タスク2セット
 executeTask.execute(); // タスク実行

 return 0;
}

235 :217:01/11/13 15:43 ID:???
実際は、タスク実行終了時の資源の解放とか、タスク実行順序とか
いろいろ機能がありました。
ともあれ、結局構造体+関数へのポインタで実装したほうが
分かりやすい上に、パフォーマンスの上という理由で捨てました。

236 :名無しさん@お腹いっぱい。:01/11/13 15:46 ID:???
>>230
VC だとメンバ関数のアドレスはその名前だけでよいが、
C++ の仕様だと &クラス名::関数名 でないとダメ
そこ以外でエラーはでないと思われ

237 :230:01/11/13 20:52 ID:???
>236
うむ確かに、うまくいった。
つうか、なぜ気がつかない、俺。

こうなると、219のコードが一番スマートなのかな?
キャストが嫌ってことなら、231になるか。

238 :名無しさん@お腹いっぱい。:01/11/13 21:09 ID:xYb3Zs4n
試しにこんな感じにモデル化してみたんですが、どんなもんですかねえ。
これをいかに楽に記述する方法を考えるかみたいなー。
何かタスク記述言語でも作って、
C/C++ソースに変換するフィルタでも用意するのがええかのう。

タスク {
  タスク変数
  タスクの状態

  タスク作成時の処理
  タスク破棄時の処理
  汎用イベント処理

  状態1 {
    状態の初期化
    更新処理
    状態の後始末
    汎用イベント処理
  }
  状態2 {
    状態の初期化
    更新処理
    状態の後始末
    汎用イベント処理
  }
  ...
}

239 :230:01/11/13 21:25 ID:???
なんかここまで来ると、クラスの必要ないじゃないか
って感じもするな…。

#include <iostream>

class Task;
class TaskManager;

typedef void(Task::*TaskFunc)();

class Task {
 friend class TaskManager;
public:
 void SetFunc(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
 // void Update() { (this->*m_updateFunc)(); }
private:
 TaskFunc m_updateFunc;
};

class HogeTask : public Task {
public:
 HogeTask() {
  SetFunc(static_cast <TaskFunc> (&HogeTask::Func1));
 }
 void Func1() {
  cout << "Func 1\n";
  SetFunc(static_cast <TaskFunc> (&HogeTask::Func2));
 }
 void Func2() { cout << "Func 2\n"; }
 void Func3() { cout << "Func 3\n"; }
};

class TaskManager {
 Task *taskArray[100];
 int iPoint;
public:
 TaskManager() { iPoint = 0; }
 ~TaskManager() {}
 void setTask(Task* task) { taskArray[iPoint++] = task; }
 void execute(void) {
  {for(int i = 0; i < iPoint; i++) {
   (taskArray[i]->*(taskArray[i]->m_updateFunc))();
  }}
 }
};

240 :名無しさん@お腹いっぱい。:01/11/13 22:00 ID:???
でも、Cで書いてUpdate関数にp->xとかp->vxとか並びまくったり、さらに
#define VX (p->vx)
みたいな真似をしたりするのもどうも気が引けるとゆーか・・・。

241 :名無しさん@お腹いっぱい。:01/11/14 12:35 ID:???
オブジェクトの挙動のパフォーマンスなんて
多少高かろうが低かろうが屁みたいなもんじゃん。
描画エンジンの都合で……ならわかるけど。

242 :名無しさん@お腹いっぱい。:01/11/14 12:52 ID:???
>>241
文句言っている人は、たぶんコストが無視できないプラットフォームで作ってるんですよ・・・。

243 :名無しさん@お腹いっぱい。:01/11/14 23:11 ID:???
age

244 :名無しさん@お腹いっぱい。:01/11/15 00:27 ID:rnP2aOWi
>>241
んなことはない。
オブジェクト指向ヲタはSetPixel,GetPixelとかまで仮想関数
にしたがるから。
それにパフォーマンスが問題にならないような上位層はスクリプトにするのが普通だし。

245 :名無しさん@お腹いっぱい。:01/11/15 00:36 ID:???
>>244
それ描画まわりじゃねえか

246 :名無しさん@お腹いっぱい。:01/11/15 01:25 ID:???
>>241
そういう簡単な挙動しか実装しない場合は
オブジェクト指向化の恩恵も少ないと思われ。

247 :名無しさん@お腹いっぱい。:01/11/15 02:14 ID:???
>>239
たぶんサンプルコードだからだと思うけど、
Task *taskArray[100]; とかがいや。std::list使おうよぅ

248 :名無しさん@お腹いっぱい。:01/11/15 11:09 ID:???
>>247
禿同。

249 :名無しさん@お腹いっぱい。:01/11/15 12:18 ID:uH85Rn+s
皆さんどうしても関数ポインタ使わないと気が済まないの?
なんで?
パフォーマンスのため?
タスクシステムを忠実にC++で再現したいから?

CSomeTask::update ()
{
 switch(this->mode){
 case UPDAETMODE_DEFAULT:
  this->do_default ();
  break;
 case UPDATEMODE_PAUSE:
  this->do_pause ();
  break;
 case UPDATEMODE_DEBUG:
  this->do_debug ();
  break;
 }
}

実際これでほぼ十分でしょ。

250 :名無しさん@お腹いっぱい。:01/11/15 12:36 ID:???
まあ、実用上はそういうコードでほぼ大丈夫なんだけども。

>タスクシステムを忠実にC++で再現したいから?
それに加えて、激しく状態遷移するタスクのデバッグは
もうこりごりってのもあるです。

251 :名無しさん@お腹いっぱい。:01/11/15 13:55 ID:???
>249
ゲーム全体で擬似的なスレッド処理を実現させたいからだと思われ。
背景をスクロールさせながら、ウィンドウをアニメショーンさせつつ移動させたり
するのをスレッドで実装すると分かりやすいからでしょう。
普通に、ループのなかでやるとifの連発になりそうだし。

>std::list使おうよぅ
STLを使うとついてこれない人がいるから…。
という冗談はさておき、サンプルだからでしょう。

252 :名無しさん@お腹いっぱい。:01/11/15 14:27 ID:???
>>249はその「擬似的なスレッド処理」の中身だと思うですが。

253 :名無しさん@お腹いっぱい。:01/11/15 15:05 ID:???
>>249
汎用性の問題。
関数ポインタの場合はswitchと違って、
機能を増やしても書き直す必要がない。

254 :名無しさん@お腹いっぱい。:01/11/15 17:07 ID:???
ついでに
C++のメンバ関数へのポインタでやると
関数1つ追加ごとにヘッダーへの変更が発生するのも問題。
privateな関数をどうしてヘッダーに書かねばならん!

255 :名無しさん@お腹いっぱい。:01/11/15 17:56 ID:???
>>251
listは遅いのでvector使おう。

256 :名無しさん@お腹いっぱい。:01/11/15 19:27 ID:???
あんまり関数ポインタを多用するのは
オブジェクト志向っぽくない気がする。

257 :名無しさん@お腹いっぱい。:01/11/16 00:18 ID:RSv3E/5D
>254
C++は、クラス定義を見ただけで、だいたい何をやってるか分かって
便利だと思っていた俺は厨なのかしらん。

っていうか、みんなVC++のClassViewを使いませんか?

258 :名無しさん@お腹いっぱい。:01/11/16 00:30 ID:???
>>241
何言ってるのよ
市販品かいとりますがな

259 :名無しさん@お腹いっぱい。:01/11/16 00:31 ID:qXQUQt+7
>257
MFCに不満が山ほどあるから、使ってない。

260 :名無しさん@お腹いっぱい。:01/11/16 00:42 ID:???
>>255
あのコードだとタスクは死なないみたいだけど、
ふつー死ぬでしょ 順番かんけーなく
eraseのコスト考えたらlist

261 :名無しさん@お腹いっぱい。:01/11/16 00:47 ID:???
ClassViewマンセー

>>259
SDKベースでもClassViewは使えるよ。コード補完も。

262 :名無しさん@お腹いっぱい。:01/11/16 00:59 ID:???
>>261
あ、ClassViewか
スマソ、ClassWizardと勘違い

263 :名無しさん@お腹いっぱい。:01/11/16 01:54 ID:???
ちなみに、タスク間のデータの受け渡しって、みなさんどうやってます?

enum{
WORK1,
WORK2,

WORK_MAX,
};
DWORD Work[WORK_MAX];
をグローバルで宣言して共用してます。

もっとスマートで近代的なやり方を教えてプリーズ。

OOと関係無い可能性があるので、sage

264 :名無しさん@お腹いっぱい。:01/11/16 03:09 ID:???
ソケット

265 :254:01/11/16 06:16 ID:???
>>257
べつにヘッダーに書く手間が面倒なわけじゃない。
外部が使用するインターフェースに変更があるわけじゃないのに
内部に機能を追加するだけで、インターフェースを使用している
モジュールに再コンパイルがかかるのが嫌なだけ。

266 :254:01/11/16 06:21 ID:???
しまった、俺もClassWizardと勘違い

267 :名無しさん@お腹いっぱい。:01/11/16 15:25 ID:???
>>265 Bridgeパターン

268 :254:01/11/16 15:58 ID:???
結局、派生先を生成してるファイルは再コンパイルせないかん。
まぁそのくらいはどうでもいいが、いちいち基底クラス作って
どうたらこうたらなんてやってられんと思うのだが…

269 :名無しさん@お腹いっぱい。:01/11/16 18:20 ID:???
>>268
VC++使ってると全然気にならないんだけどな。

270 :名無しさん@お腹いっぱい。:01/11/16 23:37 ID:???
Delphi使ってると再コンパイルの手間すら気にならんけどな。

271 :名無しさん@お腹いっぱい。:01/11/17 00:32 ID:9iW0SS+5
仕様がしっかりしている場合に限るけれど、
こーゆー書き方なら、たまぁにする。
class CMain;
class CSub
{
public:
CSub(){}
virtual ~CSub(){}
virtual void FunkA(CMain*pMain) = 0;
virtual void FunkB(CMain*pMain) = 0;
};
class CSubNull : public CSub
{
public:
void FunkA(CMain*){}
void FunkB(CMain*){}
};
class CMain
{
CSub*m_pSub;
static CSubNull m_SubNull;
public:
CMain(){ m_pSub = &m_SubNull; }
virtual ~CMain(){}
void FunkA(){ m_pSub -> FunkA(this); }
void FunkB(){ m_pSub -> FunkB(this); }
void SetSub(CSub*pSub)
{
if(pSub == NULL)pSub = &m_SubNull;
m_pSub = pSub;
}
CSub*GetSub(){ return m_pSub; }
};

272 :名無しさん@お腹いっぱい。:01/11/17 00:51 ID:???
それは立派なStateパターンでんな。

273 :名無しさん@お腹いっぱい。:01/11/17 13:55 ID:???
C使いでC++がダメ!って言う人は、実装継承とか深い継承とかを試してみてダメって言ってる気がする。
デザインパターン勉強すれば便利に使えるんだけど、使えるかどうか試してみるだけの人にデザパタ勉強しろとは言えないからなぁ。

274 :名無しさん@お腹いっぱい。:01/11/17 18:20 ID:???
OOの真髄はデザインパターンによるコーディングのパターン、及びテンプレート化だからなぁ・・・
ボトルネックとか、無駄な継承等を最適化していったら、どっかで既に使われていたパターンの
亜流だったなんての事は、実際かなりあったよ・・・

275 :名無しさん@お腹いっぱい。:01/11/17 19:25 ID:???
>>273
意味不明

276 :名無しさん@お腹いっぱい。:01/11/18 02:39 ID:???
>>275
デザパタの学習をやり出せば解る。
デザパタはOOを十分理解してる事が前提で話を進めてるので。

277 :ラム:01/11/18 09:59 ID:m/JYi1e1
ageるっちゃ。

278 :名無しさん@お腹いっぱい。:01/11/18 10:48 ID:???
>>276
違う、そういう意味じゃない。デザインパターンまで実務に使ってる。
キミの言ってることのつながりが全然わからないと言っている。

279 :名無しさん@お腹いっぱい。:01/11/18 20:54 ID:???
ゲ技版にもデザパタ馬鹿が出るのか・・・・。

280 :名無しさん@お腹いっぱい。:01/11/18 21:18 ID:???
別になあ、今更デザパタでもなかろうに。
つかっててあたりまえだといいたいんだろう? >>279

281 :名無しさん@お腹いっぱい。:01/11/18 22:29 ID:???
Design Pattern for Computer Games
http://www.totempole.net/patterns/gamepatterns.html
こんな試みもあるがね。

282 :名無しさん@お腹いっぱい。:01/11/19 22:42 ID:???
とてもヨワヨワな質問でスマソ。
カードゲームを作ろうとしたときカード1枚1枚をクラスとして扱う?
カードの枚数だけクラスが出来るんかな…

283 :名無しさん@お腹いっぱい。:01/11/19 23:38 ID:???
>>282
MT:G 系のカードごとにルールがあるカードゲーム?
カードクラスとルールクラスで構成するか、それぞれをクラスにするかだね。
Prototype や Flyweight パターンを参照してみて。
↓だけじゃ分からないと思うけど、参考までに。
http://www.ff.iij4u.or.jp/~ahirusan/Java/patterns/prototype.html
http://www.ff.iij4u.or.jp/~ahirusan/Java/patterns/flyweight.html

284 :名無しさん@お腹いっぱい。:01/11/20 00:08 ID:???
さっそくのお答えありがとです。
Flyweight パターンが近そうなので
もうちょっと勉強してみます。

285 :名無しさん@お腹いっぱい。:01/11/20 20:34 ID:???
太閤立志伝Iは、オールアセンブラと思われる古いゲームだが
オブジェクト志向してたんじゃないだろうか。
基底クラス武将を継承するプレイヤー武将クラス、大名武将クラス、一般武将クラス。
それらのオブジェクトが家臣団ツリー構造で管理され、
マルチスレッド処理で並列で動いてる。
当時これをつくったひとは本当に天才だとおもう。
ずっと後に出た、これと似たシステムのガンパレードマーチはさんざん自慢しまくってたが。

286 :名無しさん@お腹いっぱい。:01/11/20 21:25 ID:???
大抵のゲームプログラマーはとっくの昔に自分でOOPやデザパタ発見してるよ。
本に出てるのは他人に教えても良いゴミテクと知れや。

287 :名無しさん@お腹いっぱい。:01/11/20 23:36 ID:2YNiudBT
>>99

例えば、ゲームボーイとか、タイトなパフォーマンスが要求されるとことか、
まぁあったでしょうけど、やっぱ今後は開発効率の向上が必須項目。

例えば、全部組み込みJavaでゲームが書かれるようなことにも数年後にはなり
かねないしさ。

>101
モジュールやデータ構想の勉強っって何ですか?

288 :名無しさん@お腹いっぱい。:01/11/20 23:43 ID:???
タイトなパフォーマンスが要求されないゲームってPCぐらいしかないんじゃ?
アマですか>287

289 :名無しさん@お腹いっぱい。:01/11/21 07:35 ID:???
>>286
こういうやつよくいるわ。

290 :名無しさん@お腹いっぱい。:01/11/21 11:44 ID:kTxoHJqc
ま、とりあえず>>286がデザインパターンの存在意義を
理解してないのは分かるわねー。

291 :名無しさん@お腹いっぱい。:01/11/21 12:33 ID:???
個人的にはパフォーマンスよりも
開発効率のほうが今後のネックだと思うが。
納期に追われたこと無いの?>288

292 :名無しさん@お腹いっぱい。:01/11/21 17:02 ID:???
+→描画デバイス
+→シーン+→キャラクタ→モーション
     +→キャラクタ→モーション
なんて風にオブジェクトを階層構造にしてるとき
キャラクタの描画メッセージは、どいつがどのように送りますか?
それとも、こんな構造にはしませんか。

293 :名無しさん@お腹いっぱい。:01/11/21 20:28 ID:7vVUdWJ9
>>286
確かにデザパタ厨房は、
今は物理シミュレーションの時代だとか言ってるゲーハー厨並に痛いけど
(そんなのファミコン時代からやってるって…)

デザインパターン自体には、
昔からの手法に共通の名前を与えるという意義はあると思う。

294 :名無しさん@お腹いっぱい。:01/11/21 20:52 ID:BPHGewxM
>>271-272みたいな感じでんな。
プログラマ間の意思疎通がシャア並みに速くなる。

295 :286:01/11/21 23:12 ID:ukm0fF12
>>293
逆に名前がついてないと頑なに認めないのが一杯居て困る事多し。
1)マルチスレッド的プログラム構造の実際。
2)外部からの通信でどのような状態にも自由に遷移できる構造
3)どのような状態でもメッセージを受け取れる構造
4)正規の処理以外のエラー処理への随時対応可能構造
といった事を教えても「スタイルの違い」と理解せず変更せず、
挙句の果てに人のバグだと言い始める逐次プログラマーの多いこと
多いこと。

296 :名無しさん@お腹いっぱい。:01/11/21 23:16 ID:zJxGH1jK
それは、貴殿が新しいパターンを作って文書化すればいいのでわ。
GoFとかに載ってるのだけがすべてじゃないよ。

297 :HN:01/11/21 23:22 ID:qbFQMeve
> http://www1.linkclub.or.jp/~zhidao/zlab/
> オブジェクト指向を用いてぷよぷよを作る記事がある。

ウェブページだけ見ていて、ソースはそんなに真剣には見てはいなんだけど・・・。

これはこれで、イイっていえばイイのかもしれないんですけども。
オブジェクト指向の例題とするには納得しかねるなぁ〜。

1)
連鎖発生時の「ファイヤ〜」「ばよえ〜ん」とか、ここはキャラクター
が変わることによってメッセージが変わるわけだから、ここでこそ、
Character クラスでも作るのがイイのでは。

2)
Puyo クラスの中に座標を持っているんですけど、これは
明らかに無意味なような気が。

まぁもし、ぷよ一つ一つが、特別な性質を持っていて(例えば、
赤ぷよだけ5つ繋がらないと消えないとか、黄色ぷよを消すと
回りのぷよも変色するとか)そういうことなら、Puyo クラス
でも作って、自分が存在する座標とゲームフィールドの参照を
持って設計するのが、正しいと思うんですけど・・・、うーん、
ぷよぷよっていうゲームの場合、ルールは完全にゲームフィー
ルド毎に決められてるんだから、べつにint型の二次元配列
でやっても、一向にかまわないと思いますよ。

後は、MVC の分離をきっちりやるといいのかなぁ〜。でもこれも
単純なゲームにおいてはほとんど無意味だからやらなくていいか。

まぁ、ぷよぷよというゲームの本質とOOPはあまり関係ないやね。

298 :HN:01/11/21 23:27 ID:qbFQMeve
Model(ゲームデザインの部分)のコト書いたんですけども、

View(表示する部分)の話でしたら、Puyo クラス書く意味は
大いにありますよね。消すときのエフェクトは、ぷよの色ごと
に違ったりしますから、その Puyo クラスごとに絵画方法を
定義すればラクチン。

299 :HN:01/11/21 23:28 ID:qbFQMeve
ごめん、↑の2つ、ミス

300 :マルチポストは止めよう:01/11/21 23:36 ID:???
どうでもいいけど語尾の『なぁ〜。』って口癖?

301 :名前は開発中のものです。:01/11/25 17:49 ID:LE15OAAJ
age

302 :きえさっぱ:01/11/26 01:21 ID:???
んー、ぷよぷよをOO学習のサンプル題材として議論しているのは
分かるんだけど、ベーシックでもできるものなので、題材として
適切かどうかはちょっと疑問だと思うー

「再帰呼び出し学習材料」としてなら、ぷよぷよは好材料だと思うけど。

303 :_:01/12/01 02:43 ID:psjJyxPy
age
結局、タスクマネージャC++版は、デキなんですかね?

304 :名前は開発中のものです。:01/12/02 13:44 ID:???
>デキなんですかね?

どう言う意味ですか?

305 :名前は開発中のものです。:01/12/12 13:09 ID:T2PuoAFH
salvAGE

306 :名前は開発中のものです。:01/12/17 16:26 ID:???
OOやるならレミングスとかが良いんじゃないかなー。
正直ぷよぷよはOO向きではないよね。

307 :名前は開発中のものです。:01/12/31 23:56 ID:6Qd2dWNa
下がってる…。

やっぱり RPG 系こそOOの真価が発揮されると思うんだけど。

308 :名前は開発中のものです。:02/01/01 12:43 ID:YwsXNczB
というか日常的に考えてシナリオとかプロジェクトというものをOO的に変換して
うまくいかないんだから
プログラムを全部OOでやろうってのがどだい間違いでは?

309 :名前は開発中のものです。:02/01/01 14:59 ID:7Da5Jozt
>>308
じゃあ何ならうまくできるの?
構造化言語?アセンブラ?

速度的な問題点っていうのは別として、
組み方としてうまくいかないって言う人は絶対 OO 解っていない人だよ。

310 :名前は開発中のものです。:02/01/01 15:56 ID:???
全部OOでやろうってのは非効率的(になることが多い)。

311 :名前は開発中のものです。:02/01/01 16:03 ID:???
デザイナが書くためのスクリプトがオブジェクト指向だった日には
そりゃもう大変。

312 :名前は開発中のものです。:02/01/01 16:47 ID:???
>>309
もうアフォかヴァカかと。

313 :名前は開発中のものです。:02/01/01 17:03 ID:???
とにかく、ゲームプログラミングには適してない。

314 :名前は開発中のものです。:02/01/01 18:36 ID:???
で、OO否定派で、ゲーム以外の物はOOで作ってるって人はいないの?
そういう人のゲームにOOは(どういう理由で)向いてないっていう意見キボーン。

そうじゃないやつはOO理解できてないだけでしょ?
つまり銀行でCOBOL書いてるやつらと一緒。
やつらでさえ最近はJavaにお熱みたいだから、あと数年でCOBOLer以下になるね、君ら。

315 :名前は開発中のものです。:02/01/01 18:43 ID:J6apUrhi
>>314
C言語はそこまでダメじゃないと思うよ。
単純に乗り換えるコストが見合わないってだけだろうね。
その人にとって。ボクにとって。(ぉ

そのうちやるさw

316 :314:02/01/01 19:02 ID:???
>>315
(私以外の)OO派もきっとCとかアセンブラが駄目とは思っていないと思う。実際今までCでたくさんの名作が作られてきているから。

でも、そこには血もにじむような努力があったわけでしょう?
それこそ場合によっては発狂する人が出るくらいの。

そういうの、終わりにしませんか?っていう事です。
OOが解決策になりませんか?って言いたいんです。

みんなが幸せになる技術だと思うから、気づいて欲しい。
一番幸せになるのはプログラマーなのに、そのプログラマーに
「OO使えねぇ」とか、本当に使っても無いのに言われるのは悲しいんです。

でも、たしかに色々な意味で初期コストは高くつきますね…。

317 :名前は開発中のものです。:02/01/01 19:06 ID:???
OO使いたい奴は使えばいいし、使いたくない奴は使わなければ良いじゃん

318 :312:02/01/01 19:11 ID:???
OOはプログラム構造の一部しか記述できないんだよ。
>絶対 OO 解っていない人だよ。
なんて書いてる君こそ判っていない。

319 :315:02/01/01 19:13 ID:J6apUrhi
C言語にかけたコストは伊達じゃないので、そんなにC++にすぐに
移行したいとは思わない。必要な規模の仕事もあんまりないし・・・。
ウチでは使ってるヤツと使ってないやつが混在してるよ。

320 :名前は開発中のものです。:02/01/01 19:17 ID:???
根本的に設計が間違っている場合、OOで記述できない構造もあるわな (藁

321 : :02/01/01 19:55 ID:???
プログラム板追い出されたからってこんなとこで吼えるなや。

322 :316:02/01/01 21:09 ID:EjFgGjPu
>>318
煽り…ですか?マジで言ってるの?
OO向きじゃない部分があるのは認めるけど…。

>OOはプログラム構造の一部しか記述できないんだよ。
これOOをC言語に置き換えて、アセンブラマンセーな人の発言だと思って読んでみるといいですよ。

323 :名前は開発中のものです。:02/01/02 09:54 ID:???
>>318
そうそうアセンブラじゃないと記述できない部分があるよね。
フルアセンブラまんせー。

324 :312:02/01/02 10:44 ID:???
そういう意味じゃない。
アセンブラでもOOは出来るし。

325 :312:02/01/02 10:47 ID:???
ああ、言うの忘れてたけど>>316はOO対Cみたいに書いてるけど
判ってない証拠だね。
OOは言語によらず使える。
戦略ゲームなんかはCでOO使ったけど?10年くらい前か 藁
あと、スプライトはOOだな。
でも全部をOO化するのはアフォです。

326 :名前は開発中のものです。:02/01/02 11:55 ID:???
OO に対する認識が個々違いすぎる

OO 言語派: C++ など OO をサポートした言語を使えば OO である
OO 戦術 派: オブジェクト(敵データ)管理などに OO の考えを使う
一般的 OO 派: OO サポート言語を使用。設計はどうあれ全面的にクラス/継承を使う
OOD 派: UML、デザパタ、RUP や XP の使用が前提

俺は OO をサポートしてない言語でわざわざ OOP する気にはならない。
けど速度がクリティカルじゃなきゃ VC++ で全部 OOP するよ。
その方が楽だからね。

327 : :02/01/02 12:33 ID:???
俺は純OOPLよりC++でファイル分けする方が好きだな。
クラス化するかグローバルで行くかは使い勝手しだい。

>全部OOPするよ。

無理。全部クラス化なら可能かもしれないが。

328 :名前は開発中のものです。:02/01/02 16:54 ID:dWsrnYIE
OO 反対派はゲームクリエイターズバイブル読んだ?
ちなみにゲームクリエイターズバイブルは
Game Architecture and Desing の日本語訳本ね。

ようするに漏れのいいたいことは…
・monostate の化け物みたいなクラスしか書いたことないのに「 OO 駄目」とか言わないように。
・80:20 の法則に基づいて、速度にクリティカルな所以外では関数呼び出しのコストを気にしすぎない。
って事かな?

まぁ、一番惜しいのは >> 326 の分類でいう「 OO 戦術派」の人達。
OO のよさが少しはわかっているのに OOPL による強力なサポートをパフォーマンスを理由に拒んでいる気がする。
反対に早く目を覚ませっ!って言いたいのは「 OO 言語派」だね、
漏れも始めはこのグループだったので、あんまり偉そうな事言えないけど、
OOPL 使うのと OOP するのは違うからね。

OOP のよさが始めに解ってくるのは 「インターフェイスに対するプログラミング」が理解できた所あたりかな?
このあたりからポリモーフィズムとか、有用な所が一気に身についてくると思うから。
そこらへんまでたどり着く前に OO 否定に回っちゃ駄目だと思うなぁ。

329 :名前は開発中のものです。:02/01/02 17:02 ID:539yM+fZ
もうちょっと一派的な方で用語の統一を…

OO … オブジェクト指向
OOP … オブジェクト指向プログラミング
OOPL… オブジェクト指向プログラミング言語

単にOOするのとOOPLでOOPするのとは格段に違うぞ。と言いたい。

330 : :02/01/02 17:22 ID:???
とうとうageちゃったか・・・。
>>328
現場の人間はそんな素人向けの本なぞ読まない。
それ以下の文章は意味不明だ。病院行け。

331 :328:02/01/02 18:49 ID:???
>>330
あなた >>327
>>327 の発言のがよっぽど意味不明なんだけど。

あなたは素人向けの本だと思ったのかもしれないけど、
本当はあなたみたいな頭の固い人の為の本だと思うよ。

と思ったけど、あんたはまずはじめに「達人プログラマー」から読みなさい。

つーかそれ以前に読んでもない本を初心者向けと言い切るあたりが
やってもない「本当の OOP 」を否定してるって態度をあらわしてるね。

332 :315:02/01/02 20:11 ID:???
初期コストが問題なだけですよ。コストってお金だけじゃないからね。
最終的にはお金になるんだけどもw

333 : :02/01/02 20:32 ID:???
やれやれ、ヲタク本列挙して何のつもりなのやら。

334 :名前は開発中のものです。:02/01/02 20:46 ID:???
諸君、ソフトウエア業界は危機に瀕している。
業界は頭の固い旧世代プログラマーに占拠され、発展の可能性を
失っている。
これら旧世代を駆逐し、OOPLを世に広めなければソフトウエア業界
に未来は無い。
立て。若者達よ。
立って諸君らの力でこれら旧世代を駆逐し、明るい未来を切り開くのだ。
日本の未来は諸君の双肩に掛かっている。

みたいなー。
まあ、判りやすくデフォルメするとこんな煽動が
OOPLやOOの解説で行われているわけだ。
んでもってアフォが飛びついて洗脳される。と。

335 :名前は開発中のものです。:02/01/02 21:05 ID:???
OOPL登場の理由はたった一つ、旧世代PGの排除であるってことは
みんな分かってるよね?ね?なら若い奴は必至こいて勉強しろって事だよ。
ただそれだけの事にこんなに議論しちゃって・・・。恥ずかしくない?

336 :名前は開発中のものです。:02/01/02 21:22 ID:???
>>335 さんの発言を見て、なんでゲームプログラマが
OOを嫌うのかわかったよ。

簡単になったら低脳なやつらはクビ切られるからね。
OOが普及するのが怖いんでしょ?

337 :名前は開発中のものです。:02/01/02 21:37 ID:???
結局OOはインネンつける手段かい!

338 :名前は開発中のものです。:02/01/02 21:38 ID:???
>>336
低脳かどうかはどうやって判断するの?

339 :名前は開発中のものです。:02/01/02 21:38 ID:???
OOの理解度で判断します!

340 :名前は開発中のものです。:02/01/02 21:44 ID:???
自己完結哲学というか、オウムそっくりというべきか・・・。
救いようがないですな。

341 :名前は開発中のものです。:02/01/02 22:03 ID:???
単純に C より C++ の方が組みやすいじゃん。

342 :名前は開発中のものです。:02/01/02 22:18 ID:???
      ビビビビ
  ∧_∧  。))))))))  ∧_∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ( `∀´)/        ( @∀@)< OOマンセー
 (Sつ二/)         (    ) | 旧世代を打倒せよ
 | | |           | | |  \_________
 (__)_)          〈_フ__フ

343 :名前は開発中のものです。:02/01/02 22:29 ID:???
こうしてアンチOO派は論理的反論ができなくなったので
コピペ荒らしに転向しましたとさ。

               めでたし、めでたし。

344 :名前は開発中のものです。:02/01/02 22:30 ID:???
めでたしめでたし

************* 終了 **************

345 :名前は開発中のものです。:02/01/03 23:00 ID:???
レースゲーとかだったら、OO不要なんだけど。

346 : :02/01/04 00:50 ID:???
そうだね。
ゲームを完全OOで組めるとか言ってる人は実際に組んでみればいいじゃんか。
さらに、それで効率上がるなら自分だけ効率上げて待遇良くなればいいじゃんか。
(やったら自滅するけど)
なんで布教活動するのかなあ。

347 :名前は開発中のものです。:02/01/04 02:23 ID:???
バカのためにわざわざ非OOで組まなければならない
苦労を察してください。

348 :名前は開発中のものです。:02/01/04 02:40 ID:???
>>345
OOが絶対必要だっていう事は(レースゲーに限らず)多分ないよ。
でもレースゲーだってOOならもっと簡単になる可能性がある。

>>346
いいかげんウザすぎる。
本当に頼むから理解してないくせに批判するのやめて欲しい。
というか、逆にきくけどOOの何が不満さ?
「ぼくがりかいできないからです」以外の理由をちゃんと言ってよ。

349 :_:02/01/04 02:53 ID:SxnE1SFQ
何が効率よくて、何が良くないかが、理解出来てない。俺は。
上手く比較デキンというか、理想系がわからんというか。

メンバアクセス関数を用意するのは、面倒かな?
記述量も増えるし。
設計で余計に悩まされるとも思う。

どのぐらいの納期かで使い分けるのがいいのかな。

350 :名前は開発中のものです。:02/01/04 04:15 ID:???
>>349
OOの良さって、なかなか文章にするのは難しいです。
肌で感じてもらうのが一番いいと思うんですけど…。
もしあなたがすごく頭がいい人なら、もしかしたらOOの良さを
肌で感じてもらうには、途方も無く難しい(複雑な)問題に対面して
もらわなければいけないかも知れません。
私はあんまり頭が良くないので、OOを知ってよかった。と日々痛感していますけど。

うーんアクセッサを書くのが面倒っていう心情はわからなくはないけど、カプセル化は必要だから、これは慣れてもらうしかないです。

設計についてはOOが解っていれば逆に簡単になると思います。
ただし一番酷い状態はOOがわかっていない人がOOの設計をしたときかな?
記述量は…たしかに増えているかもしれませんけど、何度も書き直すのに比べれば確実に生産性はいいはずです。
それに本来混みあって見難くなる部分が逆にすっきりしたりする場合が多いので、単純にキーボードを叩く数では決められない生産性があると思います(まともなプログラマーなら多少鍵打数が増えるくらいはたいした負担ではないでしょう?)。

納期での使い分け…、というのはちょっと違うかな…。
もし納期の単位が一週間から一ヶ月とかいうのでもない限りは。
そんなに納期が短いスパンの仕事なら、わざわざOOしなくても
(むしろしない方が)いいでしょう。
すごく小さいプログラム(複雑度が低い)ならばOOはそれほど必要じゃありません。
私の心情的には「本当に速度にクリティカルな部分」はOOの冗長性が邪魔なので、そういう部分は非OOでもかまわないけれど、
それ以外の全てのコードはOOでやって欲しい。と思います。

351 :名前は開発中のものです。:02/01/04 04:23 ID:???
>>350
禿同
アクセッサを書くのは確かに面倒かもしれないけど、カプセル化の恩恵は
それ以上の物がある。

352 :_:02/01/04 05:03 ID:SxnE1SFQ
>>350
そうスか。
ゲームって、そんなに複雑なものでもないと思ってるけどね。
(後、規模的にも)

>もし納期の単位が一週間から一ヶ月とかいうのでもない限りは。

因みに今やってるのは2日です。(1つの目標に割ける時間)
全体で3週間かな?で、C++で書いてる。

そもそもC++ぐらいしか、現状で実用的な環境にない。てのが
問題なのかもね。

>>351
重要なものに関してはCの頃からやってた。
(「マクロ定義関数用意してるから、それ使え」とコメント付けてるだけだが)
テンプレートもマクロ定義のようなものだよね?
コンパイラが型チェックしてくれるようになった。と。

353 :名前は開発中のものです。:02/01/04 12:03 ID:???
OOPは、コピペPGの天敵かもしれんな。
漏れの場合、似たようなコードを何度も書きたくない
という理由でコードを共通化してる部分が山ほどあるケド、
そのために、継承をさかのぼって読まないと、
どんな作業をしているかが分かりづらい所があるんよ。

だから、自分に理解できても、他人には理解出来んコードが
少なくないかもしれん。

354 :名前は開発中のものです。:02/01/04 12:45 ID:???
関数呼び出しを遡っていくのと大して変わらないと思ったり。

355 :名前は開発中のものです。:02/01/04 14:01 ID:???
ライブラリが複数ファイルにまたがっている事に対して、
文句を言ってる厨房がいたような・・・・

356 :名前は開発中のものです。:02/01/04 18:29 ID:???
>>343
泣ける…
モナジェクトXとかにして。

OOで効率が悪くなるとか全部組めないとか言ってる人は、どういう部分が出来ないと思ってるんだろう?
>>355は、だしかにそう思う。
ユースケースごとくらいにシーケンス図があったりすると嬉しいんだけどね。
あと、JavaDocみたいなドキュメントをちょこっと書いておくのも重要だ。
C++はDoxygenだっけ?

357 :名前は開発中のものです。:02/01/04 18:31 ID:???
なお、継承は悪(ただし必要悪)だという事に決まりましたので、
あんまり継承に頼らないようにしましょう。
Template Method とかは別として。

ライブラリ的な部分と利用者部分を分けて考えるのが良いと思います。
ライブラリの中身が実は OO じゃなくても、外っツラがちゃんとした OO っぽく
なっていれば結構ハッピーです。でも意味不明な static 変数やめてね。
(クラスのメンバって意味じゃなくて、関数の中とかのね)

それじゃ!グッドモーニング!!

358 :名前は開発中のものです。:02/01/04 19:00 ID:???
ポリモーフィズムがOOのキモなのに…

359 :初愚痴:02/01/04 19:26 ID:???
必要悪だから頼り過ぎないように、という話だろう。
経験的にインターフェースと実装の分離の為の継承では
ほとんど問題起きないね。

360 :357:02/01/04 19:32 ID:???
>>358
あぁ、言葉が足りなかった!
Java 用語で言う interface を継承するのはちっとも悪くないよ。
実装継承を繰り返すのが悪なの。

むしろインターフェイスだけの継承はバリバリ行うべし。
まさしくポリモーフィズムは OO の華。

まぁ漏れはアクセッサくらいはベースクラスに含めてもいいと思ってるけど。
(まともなロジックは入れない)

共通の基本の振る舞いが欲しければアグリゲートする方向で。

361 : :02/01/04 20:49 ID:???
まあ、コーダーレベルのPGには全てOOで行けると思えるだろうね。

362 :名前は開発中のものです。:02/01/04 22:10 ID:???
じゃぁ、どこが行けないの?

363 : :02/01/04 22:31 ID:???
実際に作ってみれば?
OOは
1)処理とオブジェクトをごちゃ混ぜにしている
2)規模が大きくなり、オブジェクト間の処理が多くなってくると
  クラスが邪魔になる。(OOPL)
3)オブジェクトの無い処理に不向き
4)メモリ上のインスタンス以外をオブジェクトにしようとすると
 たちまち非効率になる。
5)処理だけでオブジェクトが無い場合は無意味。

364 : :02/01/04 22:34 ID:???
あ、3)と5)被ってるw
5)境界のあいまいな処理に不向き。

365 : :02/01/04 22:35 ID:???
例:
Stringクラスは何故Charクラスを継承してないか?

366 :名前は開発中のものです。:02/01/04 23:24 ID:???
はぁ…。
別にすべてクラス(のメソッド)にしなくても、OOはOOだと思うんだけど…。
(「処理」もオブジェクトであるという見方をしてもいいし)
「全て」の定義を聞きたいところ。
全てのコードをクラス内に入れること?
OOPの話だよね?

あと、>>365はネタですか?
文字と文字列は(国際化とか考え出すと)深すぎるのであまり足を突っ込みたくないけど、
それは違うでしょ。
あぁ、でも、言いたい事はだいたい分かった。曖昧なのはあなたの頭です。

367 :名前は開発中のものです。:02/01/04 23:45 ID:???
1)処理はメッセージパッシングの流れであらわすのが基本。できなそうなら、全体を制御するオブジェクトを作るのが普通かな?
2)異なる種類の複数のオブジェクトを処理する場合は、STLばりに「処理をする」オブジェクトを作ろう。
3)意味不明。整数オブジェクトは使いませんか?
4)VRAM上のメモリとかに直接アクセスできない場合とかの事を言っている?非効率なのは単純に設計が悪いだけでしょう。
5)曖昧でなくなるまで設計を見直しましょう。

368 :名前は開発中のものです。:02/01/04 23:47 ID:???
>>361での発言を見ると、チーフか何かなのかも知れないが、
そうだとしたら、こいつの下の人は本当にかわいそうだ。

つーか何だ>>363は?
意味不明。
>実際に作ってみれば?
これはそっくりそのまま返したい。

369 :名前は開発中のものです。:02/01/04 23:49 ID:bk/wkWMf
それでは問題です。
ライフゲームをOOで組んでください。

370 :名前は開発中のものです。:02/01/05 00:13 ID:???
>>365
あなたの作るプログラムの中で
プログラマクラスが人間クラスを継承する必要性が出たらそうしましょう。
そうでないならやめましょう。
真に汎用的なクラスを作るのは無理なのだから設計者の裁量に任せるべし。

371 :名前は開発中のものです。:02/01/05 03:16 ID:???
OO=クラスと思っている時点でかなり理解が危いのだけど。
OOを貶すなら、少なくともOOを極めてからにしましょう。

372 :名前は開発中のものです。:02/01/05 03:27 ID:???
> Stringクラスは何故Charクラスを継承してないか?

こんなバカ見たことねえ。
くくくくく。
下につく人がいたら本当にかわいそうだな。

373 :名前は開発中のものです。:02/01/05 05:03 ID:wxnvSHJ8
じゃ、ブラックジャック。

374 :名前は開発中のものです。:02/01/05 05:37 ID:???
なんかアンチ OO は反論できなくなったようなので、
そろそろまじめに OO によるゲームプログラミングを語ろうか?

375 : :02/01/05 05:43 ID:wxnvSHJ8
じゃオセロ。

376 :名前は開発中のものです。:02/01/05 05:46 ID:???
>>375
Chain of Responsibility でどうぞ。

377 : :02/01/05 05:56 ID:wxnvSHJ8
すごい!英語だ!
じゃ三目並べ

378 :名前は開発中のものです。:02/01/05 06:00 ID:YrC6qkSr
こっちに来てくれ給え

379 : :02/01/05 06:03 ID:wxnvSHJ8
じゃテキストアドベンチャー

380 :名前は開発中のものです。:02/01/05 06:17 ID:???
>>377
まず三目並べのルールをキボンヌ!!
いや、マジで知らん。五目並べの3つ版?

381 :3目並べ:02/01/05 06:19 ID:wxnvSHJ8
  ○
X○
○ X
名前ちがうかもしれん・・・。

382 :名前は開発中のものです。:02/01/05 06:19 ID:???
>>378
求人票キボンヌ!!
この世ならどこへでも伺います!!

383 :名前は開発中のものです。:02/01/05 06:20 ID:???
>>381
マルバツゲームじゃん。
つーか、これくらい単純になると、さすがに OO じゃなくても十分でしょ?

384 :名前は開発中のものです。:02/01/05 06:28 ID:wxnvSHJ8
>>383
うん。実際に作らなくてもいい。頭の中で組み立てるだけでもOK。
じゃ将棋。

385 :名前は開発中のものです。:02/01/05 06:31 ID:???
将棋もなー、みたまんまクラス化すればいい気がする。

abstract な chip (駒って英語でなんていうんだ?わからないのでとりあえず chip で)
とその派生クラス群で…。云々。

386 :名前は開発中のものです。:02/01/05 06:41 ID:wxnvSHJ8
駒(piece)はOO化できてもゲームはOO化できません。
思考ルーチンは?
判定ルーチンは?
無理すれば出来るけど、決して効率的ではないでしょう。

387 :名前は開発中のものです。:02/01/05 06:45 ID:???
思考ルーチンは Strategy にすると
プレイヤーからの入力と Com の思考ルーチンを透過的に扱えて素敵だよね?> OO 解ってる人

将棋の判定ルーチンって?

388 :名前は開発中のものです。:02/01/05 06:49 ID:wxnvSHJ8
>>387
Strategyなぞで問題を先送りにしてどうする?
思考ルーチンこそ将棋のメイン。

判定 勝敗判定

389 :名前は開発中のものです。:02/01/05 06:53 ID:???
勝敗判定って?王将が取られたかどうか?
Observer で一発じゃん??

問題を難しいことをする所一箇所にまとめやすくするのも OO の得意技だよん。
正直言うと将棋の思考ルーチンについて詳しく考えた事がないけど
先読みは Memento の変形がいいかな。

390 :名前は開発中のものです。:02/01/05 06:55 ID:???
あんまり GoF パターン内だけで応答するとデザパタ厨だとばれるね^^;
GoF 以外のパターンを調べに逝ってきます。

391 : :02/01/05 06:58 ID:wxnvSHJ8
OO厨を叩こうと思ったのにデザパタ厨が引っかかってしまったYO!

392 :名前は開発中のものです。:02/01/05 07:25 ID:???
>>391
いいんじゃないの?
デザパタ厨 inherits OO厨. じゃない?

つーか叩こうと思った割にはていよく返り討ちにあってる気がThru.

393 : :02/01/05 07:31 ID:wxnvSHJ8
へえー。
思考ルーチンをOOで組めないのを示したのにねえ。

394 :名前は開発中のものです。:02/01/05 07:36 ID:???
>>393

> 思考ルーチンをOOで組めないのを示した
示して無いじゃん?
どこらへんで示したの?
>>389 への否定意見も出てないし。

つーか
>無理すれば出来るけど、決して効率的ではないでしょう。
に矛盾してるよ?

395 :名前は開発中のものです。:02/01/05 09:30 ID:???
なんだかんだ言っても反論がないと寂しいと感じてしまう漏れって一体…。

396 :名前は開発中のものです。:02/01/05 12:37 ID:???
つーかここ粘着の巣窟だな(藁
ここにいる奴らの誰とも組みたくないと思うのはおれだけか?

397 :名前は開発中のものです。:02/01/05 12:47 ID:???
まぁOOは気張らず自然に使ってください。

398 : :02/01/05 14:51 ID:wxnvSHJ8
まあ、勝敗判定は良いとして、>>389の後半は反論するような内容か?

399 :名前は開発中のものです。:02/01/05 16:13 ID:???
>>386
別にルーチンを要素分解してオブジェクト化しなくてもいい。
C++ にせよ Java にせよ C の派生言語なのだから
メソッドの中はある程度手続き的になる。
その辺の匙加減はお好きなように。

複数のルーチンを管理するときに C では関数ポインタを使うが、
たとえば Strategy パターンを使えば言語の機能に依存せずに
同じことを実現できる。

400 :名前は開発中のものです。:02/01/05 16:53 ID:wxnvSHJ8
うむ。
95%はOO使えないと言う結論。

401 :名前は開発中のものです。:02/01/05 18:29 ID:???
いや、
OOPL は 手続き型言語の 95% くらいは内包しているという結論。

怖がらなくてもいいよ、 今まで手続き型言語で頑張ってきた君達なら、
必ず OOPL も使いこなせるから。

402 :名前は開発中のものです。:02/01/05 19:10 ID:wxnvSHJ8
氏ね!>>401

403 :名前は開発中のものです。:02/01/05 19:39 ID:???
>>401-402
雨の中ぬれている子犬(402)に手をさしのべたら、怯えた目をしたあと噛まれてしまった401。
ここで怒ったりせずに、そのままもう片方の手でなでてやると懐くぞ>>401

404 :401:02/01/05 20:30 ID:???
>>402
ごめんよ、怒らせる気はなかったんだよ。
漏れはクソ兄弟のおかげで口喧嘩がうまいだけ。
正直いえば、漏れは「使い分け」派。
どっちかについちゃったら、負けず嫌いの性格がでちゃっただけ。

つーか、漏れ本当は 3D 技術とか知らないし、必死に勉強中の未熟者よ。
結構論争楽しかった。ありがとう。

でも、口喧嘩のうまさなら絶対負けないから!!

405 :名前は開発中のものです。:02/01/05 21:36 ID:???
…唖然…。
冬休みっていつまでだっけ?

406 :名前は開発中のものです。:02/01/05 22:41 ID:???
そろそろ終わりじゃない?

407 :名前は開発中のものです。:02/01/06 00:17 ID:RXS3Y8Q4
唖然って、デザパタ用語を適当に並べてる時点で煽りだと判りましたが
なにか?

408 :名前は開発中のものです。:02/01/06 00:21 ID:???
デザパタ中毒はしばらくはまってると自然治癒するのでもう少し温かく見守ってあげてください。

409 :404:02/01/06 08:45 ID:???
>>408
先生…。僕、あとどれくらいで治るんでしょうか…?
この症状が成長の途中の、さなぎの時期だってのは聞きました…。

でも、でも!

こんな症状を発症している所を人に見られたら……(*∀*)ハズカシイ

せめてお薬を処方して下さいっ!!

410 :名前は開発中のものです。:02/01/06 09:03 ID:???
>>409
粘着は個性だから直りません

411 :409:02/01/06 09:22 ID:???
>>410
冬休みだから暇なだけです。

412 :名前は開発中のものです。:02/01/06 09:29 ID:???
冬眠は動物の基本。
体と心を休めなさい。
2chから24時間離れると、少しだけ休まった自分を感じる筈。

413 :411:02/01/06 09:34 ID:???
>>412
2ch を半日以上見ないと禁断症状が出ますがなにか?

414 :名前は開発中のものです。:02/01/06 12:26 ID:???
余興も終わったみたいですし、仕事始めですし、
そろそろまじめに OO の話をしませんか?

415 :  :02/01/06 12:54 ID:???
再発したか・・・。
治療法は上のレスで上げたゲームをOOで組んで見る事。
細部はいらない。
1)何をオブジェクトとして
2)どんな処理がどのオブジェクトに属するか
3)オブジェクト間でやり取りされるデータはなにか
を書け。

416 :405:02/01/06 13:00 ID:???
405までずっとロムってました。

冬厨の言葉を使うのは嫌だが、俺も「使い分け派」。
OOの理論だけ振りかざして「素晴らしい!みんな使えYO!」と
布教するやつは愚か。
OOを理解できなくて(というか勉強しないで)「OOは非効率的。
使えねー!」という奴もまた愚か。
ここをロムってた普通の人たちはみんなそう思っているはず。

というわけで、このスレは「ゲームプログラミングにOOは必要かどうか」
ではなくて「どのようにOOを使えば効率的なゲームプログラミングができ
るか」もしくは「OOでどのように構築するか」という風に変更したほうがよい
思うんだけど、どうでしょう?

OOが良い・悪いという議論は不毛。なぜなら良くもあり、悪くもあるから。

長文スマソ

417 :415:02/01/06 13:14 ID:???
とにかく415を実行してみなさい。
話はそれからだ。

418 : :02/01/06 14:26 ID:226Bizrz
どっかに OOなライブラリつくってる人いる?
いままでC++で作ると、速度度外視の厨房みたいな扱い受けたからなぁ
ベターCとしてのC++程度の物しか見たことない

まぁそもそも公開されてるものなんて初心者向けライブラリだから
簡単なものしかないかな?

419 :名前は開発中のものです。:02/01/06 14:50 ID:???
>>418
俺作ってるよ。
I/OはTemplate Method StreamにReader/WriterをDecorate
Saver/LoaderはChain of Responsibirity
DeviceはAdapter、ResourceはSingleton
TaskはState,ControlはInterpriter
Vector/Matrix等のPrimitiveはinlineでoperator overwride

420 : :02/01/06 15:04 ID:???
業務連絡。
重症患者が搬入されました。
救急担当のドクターはICUへ。

421 :名前は開発中のものです。:02/01/06 15:51 ID:???
419見て、まあそんなもんだろと思った俺は一体(;´д`)

422 :315:02/01/06 16:07 ID:???
完全に一緒に仕事をすることがない相手に対して、布教活動をお互いに(?)
行っていてもしかたないと思ったり。利用しない人はこのスレを見ないだろう
という前提で、どう利用すべきかに集中した方が意義がありそうだね。
まあ、2ちゃん的にはお祭りの方が楽しいかな?

423 :名前は開発中のものです。:02/01/06 16:29 ID:???
人は皆罪人です。
悔い改めなさい。

424 :名前は開発中のものです。:02/01/07 14:21 ID:???
下がり始めてるので誰かネタ振りをお願いします......って言ってもな。

というワケで私がネタ振りを
ライブラリ以外で OO をこんな風にゲームプログラミングに有効活用した!
という自慢話を聞かせてください。

425 : :02/01/07 22:02 ID:???
GUIは全部成功(効率↑)。
それ以外は全然駄目!OO氏ね!

426 :名前は開発中のものです。:02/01/08 00:12 ID:???
>>425
どういう風にして、どんな失敗をしたの?

427 :名前は開発中のものです。:02/01/08 00:14 ID:???
1000ゲッドォォォォ!!
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄       (´´
     ∧∧   )      (´⌒(´
  ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡
        ̄ ̄  (´⌒(´⌒;;
      ズザーーーーーッ

・・・・・・・・・
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄
     ∧∧        (´;;
  ⊂(゚Д゚⊂⌒`つ (´⌒(´

ん?・・・・・・・・・
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄
     ∧∧
  ⊂(  ゚Д゚⊂⌒`つ; (´⌒(´

ドッコイショと、・・・・・・・・・
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄
     ∧∧
    (゚Д゚ ,)⌒ヽ
     U‐U^(,,⊃'〜... (´⌒;;

任務失敗と・・・・
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄
  ポ  ∧∧  ポ
  ン  (゚Д゚ ,) . ン
   (´;) U,U )〜 (;;).
(´)〜(⌒;;UU (´ )...〜⌒(`)

428 : :02/01/08 00:19 ID:???
↑のように映像のパーツ化は巧く行くけど、他の部分は
パーツ化できるほど仕様が固定してないってこと。
GUI以外はサブルーチン群が最強。

429 :名前は開発中のものです。:02/01/08 03:00 ID:???
>>428
仕様っていうのは?
メソッドのシグネチャさえ固定できれば OO の方が変更は容易だと思うのですが…。
メソッドのシグネチャさえ変更しなければいけないような根本的な部分が変わってしまうのだったらグローバル関数でも全て書き直しだと思うのですが、違うのですか?

430 :名前は開発中のものです。:02/01/08 03:52 ID:RRhnojLH
>>428
ライブラリ全般はOOの方がいいと思うけど。
I/Oとかデバイスとか抽象化しておくと便利だし。

431 :名前は開発中のものです。:02/01/08 06:02 ID:???
結論: 慣れている方法を使え

432 : :02/01/08 08:37 ID:???
OOPLとOOを混同しとるらしい>>430

>>429
変更したら部品にならん。

433 :429:02/01/08 16:39 ID:???
>>432
いや、だからすげ替えるんでしょう?
「抽象的部品」を定義して、
「具体的部品 : 抽象的部品」を作る。
この「具象的部品」を「抽象的部品」として扱っていれば、
「別の具体的部品 : 抽象的部品」に置き換える事ができる。

しかも「サブルーチン群」だったら仕様が変わっても対処できる
という発言の理由は言ってないですよね?

愚推しますが、「サブルーチン群」を使っても、仕様に変更が
あった場合はコードを大量に書き直さないといけないと思いますが、
違いますか?

私が言いたいのは上記のような場合、OOPL ならば
作成するインスタンスを変更するだけで済む場合がほとんどだ。
という事です。
どうでしょうか?

434 : :02/01/08 22:06 ID:???
部品は小さければ小さい程、変更の可能性は小さくなります。
機械の仕様が変わってもネジを手直ししなくて良いのと同じです。
メソッドをバラしたような、部品化されたサブルーチン群は変更の可能性が
大変小さいです。
それに変更はモジュールに有るのではなく、モジュール間の関係や操作、初期値
などが多いのです。
結果として、OOPLでは再利用率が下がります。
Cだと70%−90%の再利用率を保っていましたが、OOPLに切り替えてから
20%を切っています。

435 :名前は開発中のものです。:02/01/08 22:18 ID:???
>>434
C言語のスキルが高いが、OOPLはそれほどでもないってことだね。
Cで続けた方がいいんじゃない?

436 : :02/01/08 22:20 ID:???
煽ってんのか?

437 :名前は開発中のものです。:02/01/08 23:38 ID:???
コピペ再利用なら、CもC++も関係なく高い再利用率を達成できそうだね。

438 :433:02/01/09 05:24 ID:???
>>434
> メソッドをバラしたような、部品化されたサブルーチン群は変更の可能性が
大変小さいです。
小さな部品は、対象が基本的な変数型じゃなければ(インスタンスではなく)クラスのメソッドに。
クラス名が明示される状況なら inline が有効なので呼び出しのコストもかかりません。(そのかわり多態性もない)
もっと局所的な場合には private/protected なメソッドという方法もあります。
これも呼び出しのパフォーマンスが気になる場合は inline するようにできますし、
気にならない状況であれば virtual にしておけば Template Method パターン
等を使ってトリッキーな処理ができる場合があります。

> 変更はモジュールに有るのではなく、モジュール間の関係や操作、初期値
などが多いのです。
434さんのおっしゃる「モジュール」の定義がよく理解できないので、
ちゃんとしたレスは書けないのですが、要するに根本を揺るがすような
変更がままある。という事でしょうか?
あと初期値に関しては埋め込まずに外部リースにしましょう。
これは OO かどうかとか関係なく、当たり前の事だと思うのですが…。

> Cだと70%−90%の再利用率を保っていましたが、OOPLに切り替えてから20%を切っています。

この数字はどういった計算で出されたものでしょうか?
ちゃんとした数字だとしたら、 >>435 さんの言う事も、あながちただの煽りとは
言えないかと思います。

439 :435:02/01/09 22:55 ID:???
煽ってはいないよ。オレもC言語のが得意なのでC++を使いたいやつが
チームにいるときでもCで頑張ってたよ。頑張りどころが違うのかもしれないけど。
ギリギリの納期だったりするので、C++に進むタイミングがなかなか。
次回のプロジェクトか、ターゲットハードが新しいものになったときでも挑戦しよう
かと思っているけどね。便利だろうなぁとは思うよ。
あと、OOPLとC++って一緒でいいんだよね・・・?(ぉ

440 :438:02/01/10 03:16 ID:???
>>439
> あと、OOPLとC++って一緒でいいんだよね・・・?(ぉ
ゲーム業界では一緒でいい気もしますけど...一般的には違う気がします。
私的には OOP に慣れてないうちは C++ よりも Java とか C# みたいな
単一継承で複数インターフェイス実装の OOPL をオススメしますね。

441 :.:02/01/10 03:30 ID:???
>>434
>Cだと70%−90%の再利用率を保っていましたが、OOPLに切り替えてから20%を切っています。

熟練度90の構造化言語での開発技能の成果と
熟練度 5のオブジェクト指向開発技能の成果を比較しても
意味があるとは思えません。
まぁ、熟練度が本当に数値にできない以上は明確な事は言えませんがね。

442 :名前は開発中のものです。:02/01/10 03:45 ID:PNlj8pol
熟練度が低い>経験が浅い>そんなにコード書いてない>再利用しようがない
て事?

443 :名前は開発中のものです。:02/01/10 03:49 ID:FBG0h4Rw
実相継承を使ってみる。Cの遺産が使いにくくなる。
STLを覚える。Cの遺産を使わなくなる。
インタフェース継承とデザインパターンを覚える。それまでのコードを使わなくなる。
templateを使ったGenericProgramingを覚える。それまでのコードを使わなくなる。

444 :名前は開発中のものです。:02/01/10 04:58 ID:???
燃やすまい、日本の遺産、地球の遺産。

445 :名前は開発中のものです。:02/01/10 05:05 ID:PNlj8pol
>>443
熟練者ですか?(自分が経験激浅)
ぶっちゃけた話、どういう構造がベストなんですかね?

今のメイン組んでる人は、あるシーン用素材を元に、
必要なオブジェクトをどんどんnewしていって、
ヒープへのポインタをオブジェを管理するクラスが持つvectorに
pushしてく。
アニメーション関係はコンテナ化されています。
プリミティブ、モデル等はベースクラスから派生してて、
Render等のvirtual関数でそれぞれのCpu処理,描画処理をする。
て感じです。

難点は、殆どの処理が自動化されてて、テスト的な処理をしたくても、
シーンの素材ファイルを読まないと何も出来ない。
シーンはストリームで読み込んでて、手動で自分が作ったオブジェクトを
作る時等、初期化手続きが凄い面倒。等

STLはlist,vectorぐらいしかつかってないなあ。

446 :名前は開発中のものです。:02/01/10 05:08 ID:???
・・・・・・・・・だから、資源は大切に。

447 :名前は開発中のものです。:02/01/10 05:09 ID:???
PC 向けだったら資源は浪費できるでしょ

448 :名前は開発中のものです。:02/01/10 07:55 ID:???
わかってそうでわかってない人が夢見がちな幻想として
「OOP=即座に開発効率が上がると思い込む」
というのがあるのだけど。

OOPはその前に痛みを伴う。初期の設計に欠点があれば
設計が見なおされるまでその禍根は残る。
設計が完璧になればその再利用性は飛躍的に向上するけど
問題はそのコストを支払い、堪えられるかということ。
それでもかまわないという男気あふれる者にこそOOPは
ふさわしい。
(Template Method で実装を切り離せば良いって
いう話ではなくて、より構造的な問題。)

449 :名前は開発中のものです。:02/01/10 08:21 ID:???
GenericProgramingのいい資料ってない?

450 :名前は開発中のものです。:02/01/10 12:44 ID:FBG0h4Rw
>>449
Modern C++ design/アンドレイ・アレキサンドレスク
今この本を注文しているんだけど、変態っぽくてなかなか良いらしいぞ。

451 :名前は開発中のものです。:02/01/13 22:14 ID:UnhLMzSA
でも、普通にプログラミングやってれば、3割〜5割(場合によっては祖霊所)は無意識にOOしてるよね?
だから、べつにOOが良いか悪いかとか言う必要も無いと思う今日この頃。

452 :名前は開発中のものです。:02/01/13 23:45 ID:???
認めたら最後、言語変更が行われてしまうという罠。

453 :名前は開発中のものです。:02/01/14 19:49 ID:f6dWfBQb
>>451
単純にオブジェクトの寿命と接続の関係が整理されるだけでも、
確実にプログラムの堅牢さも作業効率も上がる。
職業プログラマは大抵経験則的にそれを分かってるし、OOP言語を用いなくとも
自前のルールでそれを実装してすらいる。
通常、OOP的アプローチが足を引っ張る状況の全ては「学習不足」に起因する。

ただ、実際の開発行為は、ほとんどの場合常に自身の学習不足と向き合わなければならないわけで…。
既に分かりきったハードで慣れ親しんだ機能を実装する「答えが見えてる」場合はともかく、
学習を伴う開発行為(出たばっかの新ハードを扱うとか)で、アプローチの仕方がわかんにゃい場合、
出だしがやたら遅くなったり、一日紙の上だけで悶々としたり、傍から見てると遊んでるようにしか
(本人苦しんでても)見えないという罠や、最初のアプローチの仕方を間違えると、その遺恨を
いつまでたっても残してしまうという罠も。

>>445
STL は俺も普段は vector と list だけだ。
ツール類なら、string iostream なんかにも出番が回ってくる。
一時期 map も使ってたが、この連想マップがベタな比較コードに勝る
速度を出したことが(経験上)ないので、最近は出番なし。

454 :名前は開発中のものです。:02/01/14 19:53 ID:???
一度Javaで組んでみろ。
話はそれからだ。

455 :名前は開発中のものです。:02/01/14 20:23 ID:???
>>453
罠んところ読んでると泣けてきた。

456 :名前は開発中のものです。:02/01/14 20:26 ID:???
>>454
GCのふん詰まりを恐れて
オブジェクトがnewできない&クラス分けできない罠に陥ります。

457 :名前は開発中のものです。:02/01/14 23:13 ID:???
>>456
インクリメンタルGCと言うものがあるのだよ

458 :名前は開発中のものです。:02/01/15 00:03 ID:???
>>457
なんだよそれ。参照カウンタGCのこと?

459 :名前は開発中のものです。:02/01/15 09:02 ID:???
>>458
ちょっとづつ断続的にGCしていくやつのことでは。
まとめてGCするのと違って長時間のふん詰まりがない

460 :名前は開発中のものです。:02/01/15 16:48 ID:???
世代別GCも注目できる技術か?

461 :445:02/01/16 01:57 ID:???
タスク処理って結局、C++で再現出来るんでしょうか?
考えてみたんですが、やっぱり、関数ポインタ+(実体)ワークでないと駄目な気がする。

理由としては、
関数の切り替えがクラスのポインタだと、別途newしておく必要がある。
てことは、100個のタスクの中身が、全部A、全部Bという状況だと、
A,Bともに100個ずつクラスをnewする必要がある。
て所で詰まりました。

俺の知らない良い、解決方法があるんですかね?やっぱ。

462 :名前は開発中のものです。:02/01/16 02:20 ID:???
>>461
デザインパターンマンセー的にはflyweightパターンが適用できると思われ

463 :名前は開発中のものです。:02/01/16 02:22 ID:???
AB行き来するときに、delete、newすればいいんじゃないの?

464 :445:02/01/16 03:08 ID:???
>>462
デザパタはまだ調べてないです。
どういったものなんでしょうか?部分的にでも教えてくだせい。

>>463
それって、OKなんですかね?CPU負荷とか。
自分はやったことがないです。(ゲーム中にnew/delete)

465 :名前は開発中のものです。:02/01/16 03:12 ID:???
>>461
それならメンバー関数を関数ポインタを登録しようよ・・・。
つか、Aクラス、Bクラスをメンバに持つCクラスを作って
Cクラスで切り替え管理とか。そゆいみじゃない?

 詳しくは割愛するけど、テンプレートを利用するとCに戻れな
くなるぐらい完璧なタスク処理が実現できるよー。

466 :名前は開発中のものです。:02/01/16 04:10 ID:???
>>445
それ今うちで作っているライブラリの仕様と全く同じだよ。
その難点はそういう仕様がそのライブラリに無いのが原因だから、
つけてもらえばよいさ。

467 :445:02/01/16 04:34 ID:???
>>465
>Cクラスで切り替え管理とか。
うーん、具体的には、どうやって切り替えをするのかわからないです。

テンプレートですか、、。
あれって、大雑把に言うと、引数の型チェックしてくれるマクロ関数
ですよね?
taskクラスをテンプレートで作って、taskが使用するリソース
(GraphAPI,SoundAPI,,,等)クラスを引数で渡す。て感じですかね?
ヒント下さい。

>>466
そうすか、、。
ウチは、安くてプラグイン書きやすい3Dツールで吐き出すのを
前提にしたライブラリだと思います。多分

468 :名前は開発中のものです。:02/01/16 04:49 ID:???
タスク処理って
A)優先順位をつけて、処理を割り振る機構

B)処理を割り振られた方が状態を遷移させながら仕事をこなす
のと二つがセットなんですね。
私は、A)だけがタスク処理だと思っていた。

469 :名前は開発中のものです。:02/01/16 05:00 ID:???
で、B)の書き方ですが、以前のC++で書いていたプロジェクトでは
状態を整数で持っていて、switch文で切り換えていたね。
#全然、オブジェクト指向じゃないな。

470 :名前は開発中のものです。:02/01/16 05:01 ID:???
>>467
 うんと、テンプレートの方はとりあえず忘れて。きちんと理解
できた時に必然的に解るとおもう。

 で、下のモデルみたいな感じにすればいいとおもうんだけど。

taskC
{
public:
void changeA(){ pTask = &m_TA; }
void changeB(){ pTask = &m_TB; }
private:
void Exec(){ pTask->Exec(); }

task* pTask;
taskA m_TA;
taskB m_TB;
}

まぁ、これでもいーんだけど

void Exec(){
switch(m_Mode){
case 0: m_TaskA.Exec();break;
case 1: m_TaskB.Exec();break;
}

471 :名前は開発中のものです。:02/01/16 05:19 ID:???
恰好良く書くなら、
一つの抽象クラス(A)を継承して、関数に相当するクラスを書く。
一つの抽象クラス(B)を継承して、実体ワークに相当するクラスを書く。
Aに、Bへのポインタを引数にとるapply()関数を実装。
Bに、Aへのポインタとexecute()関数と、change_state()関数を実装。
# あっ、ややこしいね。確かに。

472 :名前は開発中のものです。:02/01/16 05:23 ID:???
あぁ、そういえば、メンバ関数への関数ポインタを使えば
楽なのか。
#おすすめしないけど。

473 :名前は開発中のものです。:02/01/16 06:36 ID:???
なんか話が思いっきりループしてるよーな気がする。
スレの最初のほうをご覧ありたし。

474 :名前は開発中のものです。:02/01/16 07:59 ID:08gPS5TM
俺、仮想関数テーブルのポインタ直接書き換えてるよ。
インターフェイスクラスを多重継承して、
自前の仮想関数テーブルへのアドレスを上書きする。
C++の仮想関数と、Cの関数ポインタをオーバーヘッドなしに両立できる。

475 :名前は開発中のものです。:02/01/16 13:04 ID:???
プロファイルしろヴォケども

476 :名前は開発中のものです。:02/01/16 21:30 ID:???
>>474
メンバ関数ポインタを使えばいいだけ、という気がするが。

477 :名前は開発中のものです。:02/01/16 21:43 ID:???
>>474
実装継承が絡んだ場合、this にオフセットをかまし忘れて死にそうな予感。

478 :名前は開発中のものです。:02/01/16 22:13 ID:Hxpiv8sA
>>476
関数呼び出し方法はあくまで、C++的にしたいんですわ。
メンバ関数ポインタコールをインライン関数でラップする方法もあるけど、
仮想関数としてはつかえんでしょ。

>>477
だから多重継承を使うの。
最初の4バイトは実装継承用の仮想関数テーブルアドレス、
次の4バイトにオーバーライドするアドレスをマッピングする。
スーパークラスの仮想関数の数に影響されずに上書きできる。

479 :名前は開発中のものです。:02/01/16 22:28 ID:???
>>478
仮想関数へのポインタを取ることは可能だけど、そういう話じゃなくて?

実装継承の話は、

class Deriv : public A, public B
{};

と定義されていた場合、Deriv 経由で B のメソッドを呼び出すときにはメソッドに渡す this ポインタは
Deriv::this では NG だって話と思われ。コンパイラの実装によるけど、たとえば Deriv に A, B のサブ
オブジェクトが順番に並んでる場合には

 reinterpret_cast<char*>(Deriv::this) + sizeof(A)

を this として渡す必要があるよね。

480 :名前は開発中のものです。:02/01/16 22:33 ID:Hxpiv8sA
>>479
まあコンパイラの実装依存ですが、

class Deriv : public A, public B
{
int a;
};
の場合、

virtual table address A
virtual table address B
int a

とマッピングされるので、
virtual table address B
の部分を独自の関数テーブルへのアドレスに書き換えてやれば可能かと。

Bのインターフェイスを渡すときは、
this + 4とされているので、Aのサイズに依存はしないはず。

481 :名前は開発中のものです。:02/01/16 23:21 ID:???
>>478
ハックくせー…つうか、明らかにC++の言語仕様上でやる意味ないぞ?そんなの。
単にシンボル解決の問題みたいだし、やはり>>476が順当だろう。
スレの主旨的には邪道の極みだと思うが、どーさ。
煽るつもりじゃないのでsage

482 :名前は開発中のものです。:02/01/16 23:24 ID:???
>>481
趣味でやるなら止めないが、仕事でそんなコード出してきたら肩を叩かせていただく、ってところだな。
ま、コンパイラの吐くコードを探りつつ、いろいろやるのは面白いことは面白いよな。

参考文献
Inside the C++ Object Model

483 :481:02/01/16 23:48 ID:Hxpiv8sA
>>482
ゲームプログラムでは必須のテクだと思うぞ。
関数ポインタの使い勝手と、C++の便利さの両方を享受できる
画期的な手法。

もし移植性を高めたいなら、
仮想関数テーブルのアドレスをインスタンスメモリ内から検索してやればいい。

class B;
int adr = *((int*)&B);
int* src = ((int*)this);
for (int i=0;i<sizeof(this_class);i++){
if (adr == src[i]) src[i] = overwride_address;
}

484 :名前は開発中のものです。:02/01/16 23:55 ID:???
んー、なんかオレ的にC++で安全面、速度面、使い易さ全てで
不満の無いタスクシステムは完成しているのだが、どーも、生成
時の記述だけ異常に複雑になるんだよなー。

 なんかよさげな方法で実装している人いる?

485 :名前は開発中のものです。:02/01/16 23:58 ID:???
>>483
画期的っていうかswitch分で処理分岐するのじゃダメなの?
コンパイラのコード的には似たようなもんだと思うけど。

486 :名前は開発中のものです。:02/01/17 00:02 ID:???
>>485
まぁ、人間たまに「俺は天才なんじゃないか」って思うことがあるから、落ち着くまではそのままに
しておいてあげるのが良いかと。

487 :名前は開発中のものです。:02/01/17 00:04 ID:BamJYCnx
>>485
switch分岐はオーバーヘッドが大きいでしょ。
1、ステートのフェッチ、
2、範囲チェック×2、
3、ジャンプテーブルのフェッチ、
4、ジャンプ

仮想関数テーブルのオーバーライドなら、
コストは仮想関数を直接呼び出すのと変わらない。

コンパイラのコード的には別物です。

488 :名前は開発中のものです。:02/01/17 00:08 ID:BamJYCnx
>>486
おいおい、折角貴重なノウハウを享受してやっているのに。
お前もちょっとは有益なことを書き込めよ。

489 :485:02/01/17 00:21 ID:???
>>487
つか、ワークシステムにおいてそのオーバヘッドがどれぐらいの
ネックになるのん?1Sync内に1000個もワークは生成しない
しょ?まぁ技術論的には面白いが。

490 :名前は開発中のものです。:02/01/17 00:30 ID:???
>>487
default文の無いswitchは単純なJumpTableにコンパイルされるけど。

491 :名前は開発中のものです。:02/01/17 00:32 ID:BamJYCnx
>>489
まあワークシステムのUpdate程度の用途であれば
オーバーヘッドの差は微々たる物でしょうね。
どちらかというと、new/deleteなしに、
Stateパターンを適応するのが本来の目的なのです。

492 :名前は開発中のものです。:02/01/17 00:35 ID:???
>>491
前にも誰か書いてたが、なぜ関数ポインタを使わないんだ? C++ だと仮想関数へのポインタも取得
できるから、それで何ら問題ないと思うんだが。

493 :名前は開発中のものです。:02/01/17 00:38 ID:BamJYCnx
>>490
それは有り得ません。
なぜなら、例えdefaultがなくとも、
変数が必ずcase内の値を取ることが保証されない限り
範囲チェックは必須だからです。
switch(a){
case 0:break;
case 1:break;
};
という構文において、aが0と1の値以外を取らないことは、
静的に保証できません。
まあ、
switch(a&1){}
とすれば最近の最適化コンパイラならdefaultを省略してくれるかもしれませんが。

494 :名前は開発中のものです。:02/01/17 00:41 ID:???
>>486
ハイハイ。PS2だかPCは偉いね。

495 :名前は開発中のものです。:02/01/17 00:43 ID:BamJYCnx
>>492
外部からクラスメンバを呼び出すとき、
unknown->Method()
としたいからです。

496 : :02/01/17 01:06 ID:???
switch使ったらライブラリ化できないでしょうが。

497 :名前は開発中のものです。:02/01/17 01:10 ID:???
>>495
それは、単純な転送関数を書けば良い気がするけど。たとえば、下のようなコードと比較して得失は
何なんでしょ?

> 仮想関数としてはつかえんでしょ。
これなのかなぁ。

struct State
{
  void exec1() {}
  void exec2() {}
};

class Foo
  : private State
{
  void (Foo::*pMethod)();

public:
  Foo() : pMethod(&State::exec1) {}
  void method() { (this->*pMethod)(); }
};

int
main(void)
{
  Foo foo;
  foo.method();
  return 0;
}

498 :名前は開発中のものです。:02/01/17 01:20 ID:iYo4faYa
>>478でも書いてるけど、ようはmethodを仮想関数にしたいわけです。
methodを仮想関数にすると、インライン展開できないので、
関数コール分のオーバーヘッドが増える。
この両者を解決するのが仮想関数テーブルアドレスの上書きであるということ。

499 :名前は開発中のものです。:02/01/17 01:33 ID:???
もはや日本語じゃなくてC++で話した方がいいような気がしてきた。

500 :名前は開発中のものです。:02/01/17 02:08 ID:jIMgxZOU
ジャンプテーブルの参照なんて、どう組み込んでもおんなじじゃん…
直接vtable書き換えるようなオバカな真似してどうするのさ。
それはコンパイラ提供側の仕様に依存しているという最悪の選択肢。
正直、仮想関数のオーバーヘッドが気になるレベルの性能が必要なら、
もっと別の解決法を考えた方がいい。

仮想関数の機構は、基底を同じくするクラスの多態性を実装するためのものなんだから、
状態別でアッパーキャストするならまだしも(これだってクラスの内容によっては
何が起きるか分からなくなるので、実装依存もいいとこなんだが)、正直その使い方は
およそ賛成しかねるなあ…。


あと、直接関係ないネタだけど。

>methodを仮想関数にすると、インライン展開できないので、

これは多くの人が誤解していることだけど、実際に仮想関数がvtable経由で
コールされるのは、アッパーキャストが絡むときのみ。
わざわざ vtable を辿らなくてもコール先が自明な場合、コンパイラは直接
関数を呼び出すコードを生成する。
inline virtual なんて、珍しくないよ?

煽るつもりじゃないのでsage

501 :500:02/01/17 02:09 ID:???
sage忘れた。
500ゲットに免じてご勘弁。

502 :名前は開発中のものです。:02/01/18 10:04 ID:???
>>500

>実際に仮想関数がvtable経由でコールされるのは、アッパーキャストが絡むときのみ。

まともに OOP してるなら、ベースクラス通して使う事がほとんどだと思うのですが…。

503 :502:02/01/18 10:10 ID:???
書いた後に誤解を受ける文章だと気づいた。

私も vtable 書き換えなんて、よっぽどの事でもないかぎり反対です。
というかゲーム業界のプログラマって、過酷なターゲットいじり過ぎて
「まず速度ありき」なのはちょっとマズイ状況だと思う。

最適化は最後の作業ってのはソフトウェア業界の常識だと思いますけど、
そこらへんは皆さんどうお考えですか?

504 : :02/01/18 10:45 ID:9PXzALQL
まず速度ありき
速度の前にコード無く、コードの後に速度無し。

505 :名前は開発中のものです。:02/01/18 13:19 ID:???
速度を考えるなら、まずはアルゴリズムの最適化


506 :名前は開発中のものです。:02/01/18 15:54 ID:???
>>503
まず、モジュール化ありき。

ボトルネックになる部分はほんの一部に過ぎない。システムを詳細な、依存関係が少ない部分にばらして
おけば、ボトルネックを見つけて改良するもの楽。(後からアルゴリズム差し替えようなんて話は、それこそ
クラスをきっちり分けてモジュール化してないと、危なくて出来ない)

507 :名前は開発中のものです。:02/01/18 16:35 ID:???
>>504
確かに、コードを一行も書かなければ最速だわな。(違う?)

508 :名前は開発中のものです。:02/01/18 17:28 ID:???
>>503
まともなゲームプログラマは、
C++のコードみた瞬間にアセンブリコードが浮かぶので
無駄だらけに感じるのだろう。そっとしておいてやれ。


509 :名前は開発中のものです。:02/01/18 18:54 ID:???
「最も速いプログラムは何もしないプログラム」ってやつか?

510 :名前は開発中のものです。:02/01/18 18:58 ID:B+awXMzd
バグのないプログラムもね(w
しかし、vtable書き換え……俺もやめようよそれは派だな。
Cみたく完全に枯れた言語ならともかく。



511 :名前は開発中のものです。:02/01/18 20:17 ID:???
>>508
その無駄ってのも顕微鏡で覗いてやっと分かる、みたいな
もんだしな。これからの時代はそういう人達をいかにシカトして
作業するかが問題になってくる。ん、時間が経てばいなくなるか(w

512 :名前は開発中のものです。:02/01/18 20:36 ID:???
>>511
ウイルスも何十万集まれば風邪になるってね。

513 :名前は開発中のものです。:02/01/18 20:42 ID:???
ネタとしては面白くないし、比喩としては本質を掴んでない。

514 : :02/01/19 02:08 ID:fEUidKgQ
あのー。ム板ではC++なぞOOPLとは認められて無いようなんですが・・・。


515 :名前は開発中のものです。:02/01/19 02:18 ID:???
>>514
どこでそういう結論になっているのか教えてちょ
SmallTalk以外は認めない、とかかな?

516 : :02/01/19 02:31 ID:fEUidKgQ
俺に聞かれてもわからん。

517 :名前は開発中のものです。:02/01/19 02:34 ID:???
>>516
おいおい(w 少なくとも C++ 相談室スレでは C++ 使って OO な設計する話で盛り上がってたぞ。

C++相談室 Part4
http://pc.2ch.net/test/read.cgi/tech/1009071535/


518 :名前は開発中のものです。:02/01/19 03:06 ID:???
最近は
http://www.amazon.co.jp/exec/obidos/ASIN/4894714353/ref%3Dsr%5Faps%5Fd%5F1%5F1/249-8109842-4582733
こんな本も話題だったような

519 :名前は開発中のものです。:02/01/19 04:13 ID:???
>>511
禿同。

>>515
514じゃないけど、Ruby関係のスレとかでは名文句「C++なぞ問題外」
って言われるね。漏れも(万が一)環境が許すならば C++ よりも Java や C# で逝きたい派だけど。

520 : :02/01/19 04:21 ID:fEUidKgQ
再利用の極意はクラスにあらず。
ファイル分けに有り。


521 :名前は開発中のものです。:02/01/19 06:25 ID:???
>>519
Rubyの煽りは敵を増やしただけだな。
RubyもOOPとしての完成度は低い。たかが一言語としての立場を
わきまえるべきなのだが。作者がそんな厨だからスレが荒れるんだよ。

522 :名前は開発中のものです。:02/01/19 07:51 ID:???
ていうか、rubyをゲーム制作に利用しようとしているドキュソな
言語ヲタな時点で激しく逝ってると思われ


523 :名前は開発中のものです。:02/01/19 11:05 ID:???
>>514-517
Stroustrup先生自身がOO言語じゃないって言ってなかったっけか?
俺的にはOOも可能なてんこもり言語。


524 :名前は開発中のものです。:02/01/19 13:15 ID:???
>>521
>RubyもOOPとしての完成度は低い。

どのへんが?

525 :名前は開発中のものです。:02/01/19 13:41 ID:???
Rubyは結構いけてる言語で、プログラムの側からスクリプトとして呼ぶこともできるのでゲームに応用できなくもない。
しかし、以下の欠点からRubyが使われることは将来にわたっても無いだろうと考えられる。

1:UNIX系生まれなので、@や$みたいな記号に重要な意味を持たせている(Win育ちには読みにくい)
2:実績がない。Python使ったスクリプトや大規模プログラムはいくつか例が見られるが、RubyではせいぜいがCGIで、後は誰も使わないライブラリや技術的テスト物ばかりが大量生産されている。
3:コミュニティがC++を蛇蝎のごとく嫌っている。PythonはC++とのブリッジとなるライブラリがいくつか存在している。

OO的にはどうなんかな? 上記2のように大規模プログラムが全然存在していないので、あまりありがたみを感じられる事例が存在していないだけのようにも思う。

526 :危険レベル3:02/01/19 13:41 ID:???
Rubyの話は終了しましょう。(;´Д`)


527 :名前は開発中のものです。:02/01/19 15:38 ID:???
コンソール機用の C++ コンパイラって、どの程度の物なの?
PS2 とかは GCC って聞いたけど、それ以外は?

そっち系の方教えて下さい。

528 : :02/01/19 17:34 ID:sHB48RIN
gcc以外?
ゲームでは見た事ないなあ。
PCならMS−Cか。


529 :名前は開発中のものです。:02/01/19 17:48 ID:???
CodeWarrior

530 :名前は開発中のものです。:02/01/19 23:19 ID:???
>>523
C++ は

- 手続き型プログラミング
- データ抽象
- オブジェクト指向プログラミング
- 汎用プログラミング

など、複数のパラダイムを支援する言語。OOPL としてみればメタクラスが無いとかクラスが FCO では
ないなど「中途半端」な面もあるが、現実の要求に則してうまく仕様を取捨選択してある。使いこなせば
強力な言語。

っつーことで。

531 :名前は開発中のものです。:02/01/19 23:23 ID:???
>>528
VC じゃなくて MS-C なのか?

いや、俺は XBOX は触ってないから知らないんだが。

532 : :02/01/19 23:57 ID:aWuoIM0Y
コンソール機用=CUIだと解釈したが?違う?

533 :村人A:02/01/20 00:13 ID:???
>>532
その昔、VB1.0という恐ろしいソフトが存在したそうな

534 :名前は開発中のものです。:02/01/20 00:18 ID:???
>>532
ああ、それは勘違い。

ゲーム関係でコンソール/コンソールボックスといったら、いわゆるゲーム専用機のこと。汎用
の PC や Mac なんかとと対比しての呼称ね。

535 :名前は開発中のものです。:02/01/20 01:03 ID:ECljemOC
ヲタ用語なぞ知らんな。


536 :少女∀:02/01/20 01:08 ID:???
>>533
そのソフトはどんな悪さをしたの?おじいちゃん。

537 :名前は開発中のものです。:02/01/20 01:16 ID:???
>>535
ヲタ用語か? 海の向こうだと割と使われてる気がするが。

っつか、話が OO と関係ないな。終わらそう。

538 :名前は開発中のものです。:02/01/20 12:39 ID:???
OO の冗長性がどこらへんでボトルネックになるかっていうのが
判断できないと、勇気をもって OO できないね。

で、結局パフォーマンスを気にしすぎてセコセコした設計をすると
OO のよさが活かされずに「 ゲームは特殊なんだよ。」みたいな
結論に達する厨がいる。と。

539 : :02/01/20 14:30 ID:5pJrXY6Q
>>538
だからC++以外で組んでから言えつうの!
死ね!

540 :  :02/01/20 14:31 ID:5pJrXY6Q
>結局パフォーマンスを気にしすぎて

死ね!

541 :名前は開発中のものです。:02/01/20 14:43 ID:???
>>538
> で、結局パフォーマンスを気にしすぎてセコセコした設計
設計段階からパフォーマンスを意識する必要は、最近はない気がするなぁ。とりあえずプロファイラ
かけてからモノをいえ、に一票。

542 :名前は開発中のものです。:02/01/20 14:53 ID:???
>>538
少なくともPS2の場合だったら、
クラスのサイズが大きくなりすぎない事に注意すればいいだけ
だよ。

543 :  :02/01/20 16:10 ID:5pJrXY6Q
はいはい、PS2以外のプログラマ―はセコセコした設計をする厨房
だと言う事だね。

死ね

544 :名前は開発中のものです。:02/01/20 16:12 ID:???
これはもう、OOの布教というよりOOヲタが周りを見下しに
来てるだけですね。

******** 終了 ********

545 :名前は開発中のものです。:02/01/20 16:21 ID:???
で、結局、ゲーム業界での、C vs C++ の割合ってどの程度なの?
自分はps2でC++使ってる。
未だにC使ってるところが信じられない。Cを使う理由ってなによ?
C++に反対しているオヤジってさ、PS1の時も、Cに反対していなかったっけ。
要は向上心が欠けているだけの人間なんだろ。(当時のオヤジどもが
今ではCにゾッコンで、C++移行へあれこれイーワケつけてる。まぁ
既に引退してイーワケすら聞こえないケースもあるだろうがワラ)

チーム内にC++知らねーヤツいると、足引っ張るんだよね。
よりによって、年上なセンパイだったりするから扱いにくくてよぉ


546 :名前は開発中のものです。:02/01/20 16:24 ID:???
あ、そうか、ゲームにはps2以外のもあったね、そういえば。
まあps2以外のゲームプログラマーなんて糞だし問題外でしょ。


547 :名前は開発中のものです。:02/01/20 16:27 ID:???
出川さんご苦労様です

548 :名前は開発中のものです。:02/01/20 16:35 ID:???
>>543
XBOX, GC あたりも、何ら問題ないと思われ。

i-mode は厳しいな。GBA とかは使ったこと無いから知らん。

549 :名前は開発中のものです。:02/01/20 16:38 ID:???
>>543
ターゲットは何でもいいけど、プロファイルは取りましたか?

550 :名前は開発中のものです。:02/01/20 16:44 ID:???
>>544
少し、実のありそうな話を。

C++ が C より遅いって話に関しては、多くの場合「間違い」。非仮想関数の呼び出しに関しては、
それがメンバ関数だろうがリンク時に静的に解決されるから

 C の関数と同じ

だし、仮想関数も C で同等なことをやろうと思ったら

 コールバック関数を使う
 switch - case で分岐

どちらかになるので、パフォーマンスは変わらん(ただし ADT を使うのか、仮想関数を使うかとい
う設計の選択はある)。


このあたり、実際に C++ がどういうコードを吐くのかを知れば雲散霧消する誤解だと思うな。C++
が裏で何をやってるか分からないから不安だって人は

 Inside the C++ Object Model
 Stanley B. Lippman
 Addison Wesley

を読んでみることを薦めとく。

551 : :02/01/20 16:46 ID:???
>>549
死ね!

552 :名前は開発中のものです。:02/01/20 16:51 ID:???
「C++は何かと遅い」というのは迷信ではない。
C++に移行できない不勉強なやつらが適当な理由材料をでっち上げたもの。
だから、相手にするな >>549

あ、ちなみに、俺は551の「死ね」と書いた短小野郎ではない。

553 :名前は開発中のものです。:02/01/20 16:57 ID:???
             , -‐、   , -.、
           /   ノ  ノ   ノ
          / 、_.ノ ./ 、_.ノ´
            /  ノ /   .ノ  ,,-‐'⌒i
.           / __ノ / /⌒ii´ /、_  .ノ´.
          l.   `iノ /  / |/  ,.'~´  .
           |   ,,,|./ ``´.丿 、_ノ ,-‐'´⌒)
.         l.    |``''' /  .ノ ./ 丶,-‐'´
        |  ,___l    |、. / / 、,,/
.         |   ノ     | `` '´-、 ,ノ
         | _/    |` ‐、__   )    >>C言語信者を軽く流さないでぇー
            | /     ヽ-、 _ ̄`|
         | .      ヽ::::.` 、,|
            | :.       |::::  |
             | ::       |::::  |.
          λ:::      ノ:: 丿
         /      , ::::::'/                __
        /      :/:::::::::/               /ヽ  ヽ―― 、
       /      ::/:::::::::/               /  |   |    \
     _/       :::::::::::::/__________/   |   |      ヽ
 , -‐´ /       ::::::::::::::/                  /   /        ヽ
(,    /       :::::::::::::/                   /  /         |\
 ` ‐- _______ /____________/_________)  )
\___________________________________


554 :名前は開発中のものです。:02/01/20 16:59 ID:???
なんかPS2とC++しか世の中に存在しないと思ってる人がおられるようで
・・・。

555 :名前は開発中のものです。:02/01/20 17:02 ID:???
>>554
XBOX, GC, PC もあるけど。っつか実際に C++ だと困るプラットホームがあるなら、実例挙げて反論して
おけばいいじゃない。

iアプリは Java だし、メモリ厳しいからバリバリに OO ってわけには行かないのかも知れんが、俺はその
辺は知らないのでパス。

556 :名前は開発中のものです。:02/01/20 17:04 ID:???
煽りなのかマジなのか判らん・・・。
マジレスすると、世の中にはgcc以外しか使えないゲーム開発環境が
一杯あるし、また、C++以外のOOPLも一杯有る。
さらにOOPLでないとオブジェクト指向が出来ないかのように
書いてる(ネタ?)けどもちろん違う。基礎の基礎だな。
そんな基本的な知識も無くOOを語ってるのはなんなんだろうか・・・。
ネタとしては面白くないし、天然だったら痛すぎるし・・・。

557 :名前は開発中のものです。:02/01/20 17:07 ID:???
>>556
> OOPLでないとオブジェクト指向が出来ないかのように書いてる(ネタ?)けどもちろん違う。
不可能ではないが、現実的にはメリットが無い、で結論でしょ。

インターフェースを多重継承したときに、手作業で this ポインタ相当のデータのオフセットを
計算したりするのは現実的には無理だって。(そんな汚れ仕事はコンパイラにやらせておけ
ば良い)

558 :名前は開発中のものです。:02/01/20 17:09 ID:???
ps2 gc x-box どれもCを使う理由ない思われ。
i-mode?そんなの知らん。新人研修の餌には丁度いいかもね。


559 :名前は開発中のものです。:02/01/20 17:10 ID:???
> また、C++以外のOOPLも一杯有る。
ゲームプログラミングに限定すると、実際に使える言語は限られると思う。SmallTalk とか Eiffel
でゲームを書ける環境って、そうそうないと思うぞ。

560 :名前は開発中のものです。:02/01/20 17:18 ID:???
>>558
あとは携帯ゲーム機かねぇ。俺は関わったことないから知らないど。

(スペックだけ見るに、初代ゲームボーイあたりだと辛そうだということは想像がつく)

561 :名前は開発中のものです。:02/01/20 17:23 ID:???
お疲れ様です、豊島です。
その後、多少の差し替えが発生いたしましたので
ご連絡さしあげます。

--- cut here ---
dfjdsjfjsdjodsfjpodsjfosjdopjopsfjgosjogprloijfdopgpo
uigdfsgdfhjewudsglkrsisroigthlfglgjklfgfjgkrlhrjkrgdf
ihsifghdifdfhwpwer64i4lvfkfsl;mfldwormldsg:e[rpri03df
sdgf]erlkelkrekgf@gf[:adfnkei458932743kj;lgf;f^fg04kd
ksdfhrriouhtriuiufdifir9r094oka:fglkjflkjasgpoijhjrtg
oirihigfohfoigitfofpofggklreht4340afdkojfj040-ikgflkj
dfoehrkekhfg9404-dflmlgf90gufnoihfkngiohoidioroijt000
0000000000000000000000000000000000000000000000000000e
--- cut end ---
となりました。添付にしたかったのですが、サイズが小さかったという
ことでご勘弁 (^^;

とりえあず、初期化変数のクリアタイミングを若干調整しました。
以上の件、よろしくお願いいたします。


562 :名前は開発中のものです。:02/01/20 17:28 ID:???
>(スペックだけ見るに、初代ゲームボーイあたりだと辛そうだということは想像がつく)
初代ゲームボーイをアセンブラで開発しているメーカは
皆無で今はC言語が主流。
アクションなどが主流なPS2とは違って、データベースアクセスが
頻繁なRPG,SLGなどのジャンルが多いゲームボーイの方がむしろ
OOPの必要性が叫ばれているが、C++の気配は流石にないままGBAへ
世代交代。

もっともC言語でやれなくもないんだけどね。規模的には

563 : :02/01/20 21:23 ID:???
>初代ゲームボーイをアセンブラで開発しているメーカは
>皆無で今はC言語が主流。

出鱈目だな。

564 :名前は開発中のものです。:02/01/20 21:24 ID:???
なんか新米PGか同人ヲタが粋がって、電波知識を披露してるみたい・・・。

565 :名前は開発中のものです。:02/01/20 21:30 ID:???
>>563-564
実例を挙げろとは言わんが、も少し具体的に書きなよ。


566 :名前は開発中のものです。:02/01/20 21:40 ID:???
>なんか新米PGか同人ヲタが粋がって、電波知識を披露してるみたい・・・。
あれ、君はGB未経験?
↓ここにフリーなGBDKの日本語ページがあるよ。
http://www.geocities.co.jp/Playtown/2004/gbdk_j.htm
GameBoy用のCコンパイラの原作者は、当時、高校生。
GNU-Cベースではないので、完全にANSI-C準拠というわけでは
ないけど、有志の手によって、int型が32Bitになるパッチや
floatが扱えるものも出ている。公認のSDKではないのだけど
任天堂は黙認。ROMアクセスもバンク自動切り替えで、64kb問題を
意識しなくても使えるパッチも後に登場。

これとは別に任天堂公認のCコンパイラもミドルウェアメーカから
発売されています。メーカ名、その他詳しいことは守秘義務のため
言えませんが、C++も発売するというアナウンスも2年ほど前に
一度出ていました。


567 :名前は開発中のものです。:02/01/20 21:47 ID:???
>>566
だからどうした?

568 :名前は開発中のものです。:02/01/20 21:48 ID:???
ああ、そうか、
アセンブラ→C→C++と
「発展」的に進化するもんだと思いこんでるのか・・・。
違う?

569 :名前は開発中のものです。:02/01/20 21:50 ID:5pJrXY6Q
進歩的史観そのものだな・・・。
救い難い・・・。

570 :566:02/01/20 21:54 ID:???
GBでC言語開発して、既に5年の月日が流れましたが、
感想としては、規模が小さいだけに、高級言語の恩恵をモロに受けることができました。
int型が32bitになり、またポインタアクセスも64kbの壁がなくなると
本当に汎用コンピュータになります >>GB
もちろん、8bitマシンで32Bit演算をやらせると当然、重くなるわけ
ですが、10倍遅くなる程度。市場がRPG、SLGだったこともあり、
求められる演算量が電卓レベルで済んだこともあり、処理は常に余ってました。

願わくばC++の登場に期待していたところですが・・・

571 : :02/01/20 21:54 ID:5pJrXY6Q
>>545
事実は全然逆だ。
むしろ只のCプログラムソースに「.cpp」なんて拡張子付けて
ハッタリかましてるアフォを俺の周りだけでも二人みたぞw

572 : :02/01/20 21:59 ID:5pJrXY6Q
んー本当かねー。
ラインスクロールやXXXXをやろうとするとCじゃおっつかないんだが
・・・。
GBのCは知らないけどバンク制限を完全に解決できるとは思えない
んだが?

573 : :02/01/20 22:03 ID:5pJrXY6Q
>>570
変な話だね。
GBの問題はバンクであって演算ワード長ではないんだが?


574 : :02/01/20 22:07 ID:5pJrXY6Q
>求められる演算量が電卓レベル

すげー変だ・・・CPUは負荷のメインは演算なのか・・・。

575 :名前は開発中のものです。:02/01/20 22:30 ID:???
>>571
類が友を…

っつーのは単なる煽りだが、現実にどのぐらい「周囲」の話を知ってる? 俺は視界が
狭いから、他の企業の様子なんかはサッパリなんだが。

576 :名前は開発中のものです。:02/01/20 22:54 ID:???
>>572-574
ここ、任意 ID だから自作自演するなら sage た方が良いぞ。

自作自演する気がなければ、とりあえず考えまとめてから一気に書いてくれ。

577 :名前は開発中のものです。:02/01/20 23:04 ID:???
>GBの問題はバンクであって演算ワード長ではないんだが?
大昔にGBいじってたオヤジか?
C言語時代になってからGBの開発環境は様変わりしたのよ。
ポインタも演算ワード長も32Bit。
バンク切り替えもCコンパイラが面倒見てくれる時代に。
Cソースレベルではリニアなアドレスがある。

カートリッジがMBC4移行の話だけどね。


578 : :02/01/20 23:09 ID:???
>>577
今やってる奴だアフォ。




579 : :02/01/20 23:12 ID:???
異バンク呼んだ時のオーバーヘッドの問題にきまってるだろ。
ジャンルによらず、GBでC使おうとするのは、いいかげんな
仕事しかしてない奴だと思うよ。

580 :名前は開発中のものです。:02/01/20 23:33 ID:???
>異バンク呼んだ時のオーバーヘッドの問題にきまってるだろ。
本当に現役な人?
H-Blank中にVDC参照バンクを切り替えて、パターンテーブルを
増やしているMBC2以降のメカニズムは知ってるよね?
異バンク切り替えのコストが高かったのはMBC1のみだよ。


581 : :02/01/20 23:37 ID:???
プログラムバンクじゃボケ!
なんつうか。すげー才能のないPGか、妄想ヲタだな。


582 :アセンブラオヤジ:02/01/20 23:44 ID:???
>ジャンルによらず、GBでC使おうとするのは、いいかげんな
>仕事しかしてない奴だと思うよ。
孟宗大学生、はやく寝ろ。


583 :名前は開発中のものです。:02/01/20 23:53 ID:???
>プログラムバンクじゃボケ!
バンクにデータもプログラムもないよ。
切り替えが重荷にならないし、仮に重かったとしても
C言語による記述が原因じゃないし。(アセンブラでバンク切り替えても一緒)



584 :アセンブラオヤジ:02/01/21 00:10 ID:???
>ジャンルによらず、GBでC使おうとするのは、いいかげんな
>仕事しかしてない奴だと思うよ。
漏れの推測分析によれば、こいつは厨房ではなくただの真正オヤジだと思う。
長年、マジでasmで開発してて、566がGBDKのページを紹介。
もう何年も前にフリーなCコンパイラの存在を知って、己のアンテナの低さに
面食らって愕然としたと見たね。
プログラムのバンク切り替えが遅いだの、言語非依存の欠点を指摘するあたり
自己矛盾自爆がその慌てぶりを露呈する結果に・・・あわれ、オヤジ。

って、折れもオヤジやんけ!漠

585 :名前は開発中のものです。:02/01/21 00:54 ID:???
あのー、そのフリーコンパイラの遥か以前からGB用のCコンパイラ出ているんですが
・・・

586 :逸見厨:02/01/21 01:35 ID:???
                           ヘ ヘ
                          ミ.".ミ
                          ι ~ι )〜
┌────────────────────┐
│                                        │
│OOと関係ない話題はやめまちょうよ。         │
└────────────────────┘

587 ::02/01/21 01:55 ID:???
スゲーな、、漏れコンパイラなんか使ったことないよ。でもGBってアセンブラ
レベルで制御しなきゃいけない部分が多いからCで書いてもコード量は
ちょっとしか減らなさそう。でもコンパイラって言うからには最適化とか
がんばってくれてイイかも。まぁもうGBの仕事なんかしねーからどうでも
いいけど、、。けど、GBにはなんか愛着あるのな。

http://game.2ch.net/test/read.cgi/gamedev/1005161570/

588 :2時:02/01/21 02:02 ID:???
C++はOO取り入れるのに最高の言語だとは思う。
けどCGBでC++はやりたくないな。


589 :2時:02/01/21 02:31 ID:???
このまえCGB開発したんですCGB。
そしたらPGが一杯いて入れないんです。
良く見たら張り紙がしてあって「CGB用フリーコンパイラ」とか
書いてあるんです。もう、アホかと。馬鹿かと。
お前らな、Cコンパイラごときで普段開発してないGBに来てどーするん
だよ。ゲームボーイだよゲームボーイ。
なんか家族連れで来てるのも居るし、親子四人でGB開発か。おめでてーな。
「よーし、お父さんリニアアドレスしちゃうぞ」とか
言ってんの、もうみてられない。
おまえらな、俺のドリキャスの仕事振ってやるからその席空けろと。
GB開発ってのはもっと殺伐としているべきなんだよ。
無理に高速化し、無いRAMに詰めこんだ設計がいつ破綻しても
おかしくない、そんな雰囲気がいいんじゃね−か。
素人はすっこんでろ。

やっと席が開いたと思ったら隣の席の奴が、んじゃオブジェクト指向で組みたい
とか言ってるんです。そこでまたぶち切れですよ。
あのな、オブジェクト指向なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、んじゃオブジェクト指向、だ。
お前は本当にOOPLでプログラム組みたいのかと問いたい。問い詰めたい。小1時間問い詰めたい。
お前、オブジェクト指向にはメタ構造が含まれてないんじゃないかと。

GB通の俺から言わせてもらえば今、GB通の間での最新流行はラインパレット、これだね。
本来4色しか表示できないのを制限付きで多色表示。これが通のGBの作り方。
ラインパレットっての色が多めに入ってる。そん代わりマージン少な目。これ。
で、渋いカラー画面。これ最強。

しかしこれは処理が間に合わないと、どうにも対処出来ないという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前、584は、Cで4色アプリでもつくってなさいってことだ。


590 :名前は開発中のものです。:02/01/21 02:45 ID:???
>>589
一行目だけ、読んだ。

591 :名前は開発中のものです。:02/01/21 03:04 ID:???
>GameBoy用のCコンパイラの原作者は、当時、高校生。
一応、それ以前からCコンパイラはあったんだけど
既存のz80コンパイラにパッチを当てた程度のものだったんだよね。
任天堂もその高校生に直接打診したけど、断られたというのは有名な話。
本人も商売っ気もまるでないし、高級言語がGBの開発言語として
普及してくれさえすればいい任天堂としては、それでも願ったりかなったりなわけで
丸く納まったと。

クリティカルな部分をアセンブラで組まなければならないのは当然として、
携帯機でも高級言語が普及してから久しい。


592 :名前は開発中のものです。:02/01/21 03:10 ID:???
へー、既存のz80コンパイラにパッチを当てた程度でコンパイラになるんだ。
多分高級言語の「高級」を「高級な技術が要求される言語」とか
「高級なプログラマーが使う言語」とかに勘違いしてる君だろうな。

593 :名前は開発中のものです。:02/01/21 03:56 ID:???
>z80コンパイラ

>>591

594 :じじー:02/01/21 04:55 ID:???
>GameBoy用のCコンパイラの原作者は、当時、高校生。
10年ほど前、GBのワイヤーフレーム3DゲーのX(任天堂発売)を
作った高校生とは別の人だよね?
その後、sonyに行って、今はGCCベースのEE-GCCを開発中とマ板で
聞いたことあるけど。


595 :名前は開発中のものです。:02/01/21 05:15 ID:???
任天がカスタマイズしたのは 「Z80/64180コンパイラ」だったと
思う・・・確か。旧ライフボートのね。
http://www.softboat.co.jp/product/iar/ewz80.htm

でも、こっちはセグメント概念とかウザい。
両替機、組み込み系で使ったことあるけど、疲れて欝になった。


596 :名前は開発中のものです。:02/01/21 05:27 ID:???
現在だとz80も160MHz相当で動くので(Z80S190だとか)
高級言語の需要も高まってるね。ま、素直に他のCPUで
高級言語使えや、とそこで言ってしまうのは素人。
z80は他チップとの相性や基盤の量産効果によるコスト削減が見込める・



597 :名前は開発中のものです。:02/01/21 05:28 ID:???
Z80をコンパイルしてどうすんだろ?

598 :名前は開発中のものです。:02/01/21 06:32 ID:pJoFp548
CGBスレッド(真性オヤジPGが立てたらしい(藁))
http://game.2ch.net/test/read.cgi/gamedev/1005161570/l50

599 :名前は開発中のものです。:02/01/21 06:56 ID:???
このスレはASM派とC派の討論スレとして認知されました。

600 :名前は開発中のものです。:02/01/21 07:13 ID:???
ともに傷付け合いながら滅び消え去る運命なのか・・・泣ける(和良

601 :名前は開発中のものです。:02/01/21 13:37 ID:???
プログラマは職人気質で頑固ところがあるからな。しかもプライドが高い。
だから、自分の開発手法以外は認めたくないというのがあるんだろう。
自分がある特定の開発手法に忠誠を誓っていることを自覚したら、
頭を柔らかくする方策を練っても良いかもしれない。

602 :名前は開発中のものです。:02/01/21 17:25 ID:???
プログラマは頭が硬い。これ名言。

603 :名前は開発中のものです。:02/01/21 18:21 ID:???
GB開発論は別のスレでスレ!

604 :名前は開発中のものです。:02/01/21 19:55 ID:???
>>601
俺は頭が固くならないように、言語関係とは別にソフトウェア開発がらみの書籍は年に 5 冊ぐらいは
読むようにしてるよ。去年だと達人プログラマ、リファクタリング、プログラミング作法、コードコンプリー
ト、ライティングソリッドコードってな感じ。

次は XP かねぇ。

605 :名前は開発中のものです。:02/01/21 22:40 ID:???
ふ。本に書いてある固定観念に囚われるだけさ。

606 :名前は開発中のものです。:02/01/21 22:48 ID:???
頭を柔らかくするんだったら、こんなの
「ファインマン物理学」「GS美神極楽大作戦」「日露戦争」
「競馬名人読本」「国際経済学」「超人ロック」「日本書紀解説」
「聖なる侵入」(ディック)

607 :名前は開発中のものです。:02/01/21 23:03 ID:???
>>605
そうなんだけどね。
だから全然本を読んだり他人のソース読んだり開発手法を学んだりせず、
自分の信ずる道をうじうじと追求するというスタイルはあまり健康的ではないような気がする。僕はね。

608 :名前は開発中のものです。:02/01/21 23:06 ID:???
>>604
"毎年"開発手法の本5冊というのが無理があるような
本が列挙されていますが・・・
読むのが無理と言うより、毎年読んでる割には
不自然な古典が含まれているという・・・。まぁどうでも良いんですけど、
頭堅くしたくないなら全然違うジャンル読んだ方が良くない?


609 :名前は開発中のものです。:02/01/21 23:37 ID:???
>>608
わりと昔の本でも読んでないものはあるのよ。

> 頭堅くしたくないなら全然違うジャンル読んだ方が良くない?
板違いになりそうなんで、プログラミングから遠く隔たったやつは書かなかったんだけど、
この一ヶ月以内に読んだプログラミングに絡まない本だと

 論理哲学論考
 ローマ人の物語 X
 同時代史
 死刑囚 最後の瞬間
 日出処の天子
 秋吉家シリーズ

とか。プログラミングがらみだと

 Effective STL
 Inside the C++ Object Model

あたり。(年末は暇だったので読書がはかどったんで。普段はこんなに早いペースでは読めません)

610 :名前は開発中のものです。:02/01/22 01:19 ID:???
>>609
UML関係は読まないの?


611 :名前は開発中のものです。:02/01/22 01:20 ID:???
>>609
「論考」かぁ。読んだけど全部は理解できませんでした。
今はデリダの「言葉にのせて」を読んでますが、なかなかいいです。

プログラミング関連は「Objective-C」(荻原剛志) が面白かった。

612 :名前は開発中のものです。:02/01/22 04:42 ID:???
ワラワラ>>Z80をコンパイルしてどうすんだろ?


613 :名前は開発中のものです。:02/01/22 09:19 ID:???
>>610
そういや「リアルタイムUML」って本が出てるけど、誰か読んだ人いる? タイトルだけ見ると「OOと
ゲームプログラミング」にそのまま使えそうな気もするんだが。

614 :名前は開発中のものです。:02/01/22 10:03 ID:???
このスレはプログラマが読むオススメの本を紹介するスレとなりました。

>>613
面白そうかもね。
クリーム色の本「UMLユーザーガイド」(だっけ?)はリファレンス的色彩が強くて、
わかりにくかったからこれ買っても良いかも。

関係ないけど、オージス総研って大阪ガスの子会社?だったんだね。
知らなかった。大阪ガスマンセー。

615 :名前は開発中のものです。:02/01/22 23:48 ID:???
いまだに導入コストについての理解がないようなんだけど・・・。
ここはなんのスレだっけ?

616 :名前は開発中のものです。:02/01/23 00:44 ID:yYTkkT2E
導入したその日から効率UP!
効率が上がらなかった場合はそのPGは、時代遅れの過去の知識にしがみついている
頭の固い、新しい知識を受け付けない、向上心の無い、廃品、真性、
理解力、好奇心といった健全な精神活動を持たない、怠け者、負け組み、落伍者
のロートルオヤジの烙印を押されます。



617 :名前は開発中のものです。:02/01/23 01:42 ID:???
>>615
> いまだに導入コストについての理解がないようなんだけど・・・。
せっかくなんで、具体的な見解を頼む。

618 :名前は開発中のものです。:02/01/23 01:48 ID:???
>>617
>>616のようなローカルオヤジを首にするコスト。
あるいは>>616のようなローカルオヤジに無理やりOOPやらせて破綻するリスク


619 :名前は開発中のものです。:02/01/23 02:05 ID:???
>>618
さえない突込みでスマンが、ローカルじゃなくてロートルかと。

620 :618:02/01/23 02:14 ID:???
>>619
すまん(死

621 :名前は開発中のものです。:02/01/23 07:02 ID:???
視野とスコープかけてんのかと思ったw


622 :名前は開発中のものです。:02/01/23 10:21 ID:???
導入コスト気は確かに気になる。
気づいたら使っていたのでその辺わからねーんだわ。
他人に勧めるときに参考にしたい。

623 :名前は開発中のものです。:02/01/23 13:17 ID:???
>>622
時間的コスト : 小一時間

624 :名前は開発中のものです。:02/01/23 14:25 ID:???
問いつめたい?

625 :名前は開発中のものです。:02/01/24 00:08 ID:hOwXptDB
ローカル親父あげ

626 :名前は開発中のものです。:02/01/24 00:41 ID:???
string abc( const string& in ){
char* pOut = (char *)in;
return pOut;
}

 このコードを実際に書く人が存在する事を覚えておいた方がいい。

627 :名前は開発中のものです。:02/01/24 00:49 ID:???
>>626
テンプレぐらい使え。な。

628 :名前は開発中のものです。:02/01/24 14:06 ID:c86YUCYA
>>626
ネタ?

629 :名前は開発中のものです。:02/01/24 22:33 ID:t/2EN71K
>>626
俺の自作のstringクラスはoperatorオーバーロードしてるから
そのコードでも問題なく動くけど何か?


630 :名前は開発中のものです。:02/01/25 00:37 ID:???
>>629
そういう問題か?

631 :名前は開発中のものです。:02/01/25 01:23 ID:???
>>629
 あー、こーゆー人が一番困るかも。
機能が違うならstring2とかにするだろうにね。
ま、ウチもstringは置き換えだけど。

632 :名前は開発中のものです。:02/01/25 01:40 ID:???
>>631
ネームスペースを切ってあれば許せる。

633 : :02/01/25 09:39 ID:zRa+G+3a
正解者未だに現れず。

634 :名前は開発中のものです。:02/01/25 12:21 ID:???
>>626
速攻構文エラーでません?これ。
そういうすぐ分かる間違いはミスに入らないよ。
ミスってのはオブジェクト始末した後外部にあるポインタ
で参照するカスコードを言うの。

635 :名前は開発中のものです。:02/01/25 13:01 ID:???
>>634
dangling pointerか。

636 :名前は開発中のものです。:02/01/25 18:27 ID:???
C++ だと、たまに構築が完了していないオブジェクトを触って死ぬことがあるな。
あまりコンストラクタに機能を詰め込まないようにして、まじめにシーケンス図を
書いて考えれば防げるけど。

昨日、久しぶりに pure virtual function で怒られたよ。

637 :名前は開発中のものです。:02/01/27 07:19 ID:???
折れに言わせればOOをするにあたってC++じゃ退屈な役不足。
C++使えたくらいで優越感に浸って満足できてしまうキミら庶民が
初々しくて眩しいぜ。俺なんか、九九覚えるよりもオナニーを覚えたし、
オナニー覚えるよりもC++を先に覚えたもんだぜ。


638 :名前は開発中のものです。:02/01/27 14:55 ID:???
>637
それはどこで笑えばいいんですか?

639 :名前は開発中のものです。:02/01/27 15:44 ID:???
>>638
縦読みするんじゃないのか。

640 :名前は開発中のものです。:02/01/27 16:15 ID:???
>>639
サンクス!縦読みしたら、ナメック語で神のコードが現れたYO!!

641 :637:02/01/27 18:29 ID:???
ったくよぉ、オマエら、もうちっとはオレのアソビにはっついてくるかと
思ってたのによぉ。638の639二人。ちっとは、オレの目にオモロいギャグの
一つや二つ、飛ばしてみろや。

642 :名前は開発中のものです。:02/01/27 18:42 ID:???
>>637
もう来るな。

643 :名前は開発中のものです。:02/01/27 18:47 ID:???
つまらん

644 :637:02/01/27 22:17 ID:???
>>642 647

「しね」だの「くるな」だの「つまらねー」だのしか遠吼えしかできねー
単細胞野郎は、おおかた女日照りと見たね。がっかりさせやがって。
なんていうかさぁ、こう、気の利いたディスカッションできるイけてる
プログラマーっていねーの?


645 :名前は開発中のものです。:02/01/27 23:05 ID:???
>644
オマエが一番イケてねー事に早く気付いてくれ

646 :名前は開発中のものです。:02/01/27 23:36 ID:???
釣り師とお魚

647 :名前は開発中のものです。:02/01/28 04:11 ID:???
>>637=644
正直、2ちゃんねる広しと言えども、こんな寒いヤツ数ヶ月ぶりに見た。


648 :名前は開発中のものです。:02/01/28 23:26 ID:???
>>644
はやく OO 語れよ。待ってるんだから。

649 :名前は開発中のものです。:02/01/29 13:58 ID:???
>>637
私は生まれる前から自分の this ポインタを弄ってましたが何か?

650 : :02/01/29 23:11 ID:AYQZp6YC
http://www.alien-factory.co.uk/main.html
ここのソースを見ろ。
OOなぞとっくに廃れてるYO!

651 :名前は開発中のものです。:02/01/30 00:11 ID:???
やっぱ、Rubyだよな、みんな!

652 :名前は開発中のものです。:02/01/30 01:11 ID:???
そうそう、なんといってもRubyだよな!
Ruby知らないプログラマーは、だいぶ損してるぞ!

653 :名前は開発中のものです。:02/01/30 01:30 ID:???
ム板に帰ってください。

654 :名前は開発中のものです。:02/01/30 01:32 ID:???
>オマエが一番イケてねー事に早く気付いてくれ
なんか図星されて釣られた雑魚が。
釣り人644の舌打ちが聞こえてきそうー


655 :名前は開発中のものです。:02/01/30 01:36 ID:???
>>654
つまらなすぎ。ネタ職人を目指すなら、精進して出直すように。

656 :名前は開発中のものです。:02/01/30 03:03 ID:???
>655
654をネタ崩れと誤認識するシロい男、ハケーン

657 : :02/01/30 03:09 ID:ikWHR0pm
>>637
「役不足」の用法が違うよ。辞書で調べるべし。
それだとC++はOOなどやるのには勿体無いような高機能言語となる。

658 :名前は開発中のものです。:02/01/30 03:54 ID:???
というかOOがゲーム制作にとって必須かと言われるとそれはNO。
だから役不足なC++ぐらいが丁度いいと思う。簡単だしね。


659 :名前は開発中のものです。:02/01/30 04:00 ID:???
>>637
オナニーを小学校高学年あたりで覚えたと仮定すると、九九を覚えたのは中学校あたりですか?
それで役不足の意味もわからないのですね。

660 :名前は開発中のものです。:02/01/30 04:07 ID:???
>>658
>>657の言ってることわかってる?

661 :名前は開発中のものです。:02/01/30 04:11 ID:???
>>660
657に返したレスじゃないんだけど…。

662 :名前は開発中のものです。:02/01/30 04:15 ID:???
>>661
役不足の使い方間違えてるのでもう一度辞書で調べましょう。

663 :名前は開発中のものです。:02/01/30 07:00 ID:???
 
 さて、 今日もシコシコオナニー議論

664 :名前は開発中のものです。:02/01/30 09:33 ID:???
C++で作るのにゲームなんかじゃ役不足なんだよ!


665 :名前は開発中のものです。:02/01/30 17:37 ID:???
いいじゃん、みんな好きなように作れば。

666 :名前は開発中のものです。:02/01/31 00:07 ID:???
九九とOO。

667 :名前は開発中のものです。:02/01/31 23:15 ID:???
こんなゲーム、折れには役不足だ!と言って会社辞めたい。

668 :名前は開発中のものです。:02/02/04 02:52 ID:???
アンチOOな奴が使えるとか使えないとか理解してるかどうかとかどうでもいいよね。
そういう次元の話をしはじめたら面白いゲームつくれよヴァカでおしまいになるから。
面白くて売れるゲームつくれる奴が使える奴。それ以外は使えねぇというのが社会。

669 :名前は開発中のものです。:02/02/04 03:00 ID:???
面白くするのはプランナーとか、ディレクターの仕事じゃないのかなぁ。
と、最近思うようになったが、そうもいっていられない現状。

670 :名前は開発中のものです。:02/02/04 03:09 ID:???
>>668
> 面白くて売れるゲームつくれる奴が使える奴
そりゃそうだが、プログラムに関しては広い意味での「技術力」がモノを言う場面も
多い。

いくらアイデアが良くても、バグバグでしょっちゅう異常終了するようだと論外だし、
新しいアイデアを盛り込もうとしたときに「設計からやり直さないと無理」だと、時間
的に余裕がなくなって、実現可能なことが制約されてしまう。

ここまでは前提で「で、OO はどうなんだい」っつー話をしてるんじゃなかったのか。


671 :名前は開発中のものです。:02/02/04 03:11 ID:???
OOはもう前提として、今はジェネリックなプログラムへとパラダイムが進化しつつあるようです。

672 :名前は開発中のものです。:02/02/04 03:20 ID:???
>>671
OO と Generic Programming の関係は、進化というよりは相補的だが。最近の
流行りだと AOP (アスペクト指向プログラミング) なんつーのもあるやね。

673 :名前は開発中のものです。:02/02/04 09:47 ID:???
>>672
AOPは理念は解るが、具体的に何をするものなのかよく解らん。

674 :名前は開発中のものです。:02/02/04 14:04 ID:???
やっと C が根付いた所のゲーム業界が新しいパラダイムを先取りするとは思えん。

まずはちゃんと OO を当たり前にすることからだ。

675 :名前は開発中のものです。:02/02/07 00:35 ID:PT76Vhl7
おまへ、そんな理想を持ってゲーム業界入ったらすぐ潰れるぞ。
設計ねえ・・・・。デザインねえ・・・。遠い他所の世界の話だ。

676 :名前は開発中のものです。:02/02/07 00:44 ID:???
OOってのはまず設計ありきだから仕様が二転三転するゲームのお仕事
じゃ結構つらいトキもあるのよね。あとC++プロジェクトはメンバーに
一人でもC++を理解していない奴がいると破綻するから要注意。

677 :名前は開発中のものです。:02/02/07 01:03 ID:???
OOとは関係ないが、XPはどうなんだろうか

678 :名前は開発中のものです。:02/02/07 01:15 ID:PT76Vhl7
>>676
大抵の会社ではチームを仕切ってるのは企画屋。
>一人でもC++を理解していない奴がいると・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
・連中がやるのは・・・・変更の前のPG以外への根回し、・・・・・
多数派工作・・・・・・圧力・・・・・追い落とし・・・・・宣伝・・
・・・・・・・とても理解どころの話じゃ・・・・・・・・・・

679 :名前は開発中のものです。:02/02/07 02:00 ID:???
>>673
うまくやると Croscutting を局所化できるらしいけど、俺もイマイチ具体的な
イメージが湧かなかったり。キャッシュとかは確かに綺麗に書けそうだけど。

680 :名前は開発中のものです。:02/02/07 02:26 ID:???
>>676
設計じゅーよーなのは確かだが、いきなりシステム全体を作らずにスパイラル的に
開発するのも可能ですわな。モジュール間のインターフェースを明確にしておけば、
あとで仕様変更が入ったときに、モジュールをゴッソリ入れ替えるのも可能だし。

とはいえ、あまりに仕様変更が大きいとやっぱり作り直しだけど。

681 :名前は開発中のものです。:02/02/07 03:19 ID:???
>>680
 まぁ、ゲーム作成においては設計よりはノリで作ったほうが有利
な事が多いのは確かだよね。どーせ1本上げたらスタッフが半分は
減るのが業界の常なのでC++の再利用性なんてのは業界の体制が変わ
らない限りは全然意味がないよねー(トカ

 ゲームエンジンの切り売りが商売として成り立ってる海外がちょ
っと羨ましいデス。

682 :名前は開発中のものです。:02/02/07 12:21 ID:???
>>681
バイオハザードのシリーズとか、PS 版のドラクエ 4, 7 なんかは、思い切り
使いまわしっつー気がするが。

683 :名前は開発中のものです。:02/02/07 19:40 ID:???
OO のが変更楽じゃん。
変更して問題が発生した時に、変更したモジュールに問題があることが
はっきりするから。

ベタ書きだと 変更した時に他のモジュールに付け焼刃の修正がかかるから
最終的に複雑になりすぎて手におえない。

684 :名前は開発中のものです。:02/02/09 10:41 ID:???
それぞれの認識している「変更」に大きな隔たりがあると思われ…

685 :名前は開発中のものです。:02/02/15 06:22 ID:8zjKt4ip
で、みんなどんな所に OO 使ってるの?

686 :名前は開発中のものです。:02/02/15 06:44 ID:???
>>685
ペニス

687 :名前は開発中のものです。:02/02/15 07:23 ID:AIw8xlxF
自分でゼロから作ったフレームなら
たとえOOを多用していても理解もきいてとっても便利なんだけど
他人が作ったものだと途端にわかりづらくなるよね。
クラスのネストが3つ以上だと、もう読むのもイヤって感じ。
メンバを外部に公開するのは絶対禁止、COMインターフェイスみたいなのだけで
継承をサポートするって形にしないとダメだと思うなあ。
作るのは大変だろうけど。

688 :名前は開発中のものです。:02/02/21 03:36 ID:???
>>687
いきなりソースを読む前に、ふつうはクラス図やシーケンス図を眺めないか?

689 :名前は開発中のものです。:02/02/21 17:25 ID:35NaRfFx
>>688
多分、そんな物なかったんじゃない?(ハウスライブラリでは十分ありうるでしょ)

690 :名前は開発中のものです。:02/02/21 17:32 ID:???
>>683
こいつ本当に開発の経験あんのかよ

691 :名前は開発中のものです。:02/02/21 20:17 ID:C9AJcEPn
>>689

クラス図やシーケンス図を補完している開発会社があるなら、それこそ
無駄だと思う。仕様は日々変わるんだから、そんなものとっておいても
意味がない。

常識的でシンプルな設計すれば、何となく分かってくるものだと思うよ。


692 :名前は開発中のものです。:02/02/21 22:30 ID:???
>>691
> 仕様は日々変わるんだから、そんなものとっておいても意味がない。
…そいつは凄いな。ふつー(非ゲーム業界)は仕様が変わるからこそ、開発資料を
残しておくんだが。

693 :名前は開発中のものです。:02/02/22 00:27 ID:A1Lm+ZAR
>>692
パッケージ売り切りだと日々のメンテがないから、そういう風になるのかな?
まだ普通?(情シス)しか知らないから、パッケージ開発がどういう世界かしらない。

しまった、ワナビ〜暴露しちゃった。

694 :名無しさん@お腹いっぱい。:02/02/22 11:31 ID:???
>>691
で、そういう会社に限ってスタッフに逃げられると、そのままポシャルんだよなぁ・・・
そいつ等の開発水準すら維持できなくて。

695 :名無しさん@お腹いっぱい。:02/02/22 11:33 ID:???
>>694
実際、それでポシャる、もしくは瀕死になったメーカーは相当あるぞ。

696 :名無しさん@お腹いっぱい。:02/02/22 11:46 ID:???
>>691
クラス図やシーケンス図を補完するのは開発者の為ではくて、開発会社の為
なのに、それを否定するって、それでメシ食ってけるのか?
そういうヤシは、すぐ仕事ホサれると思うんだが。


697 :名前は開発中のものです。:02/02/22 17:13 ID:gH0SaIAu
>>696

開発会社が(経営陣の方々か)欲しいというなら、完成した動くコード
とセットで UML図 (といっても、Rose とか自動作成ツールで出力する
ものの可能性が高い)を仕様書と報告書とともに差し上げます。

けど、デザイナーとゲーム開発者と間で、システムの中核の開発が終わってない
ってのに、のんびりと UML図を作っては書き直し、作っては書き直し、なんてマ
ヌケなことはしないでしょう。

698 :名前は開発中のものです。:02/02/22 17:16 ID:???
開発=コーディング なの?

UML で図を書くというのは、何もお絵かきして遊んでるわけじゃなくて、問題の
分析/設計をやってるんだけど。

699 :697:02/02/22 17:20 ID:gH0SaIAu
あ、話の流れを見てみると、
「完成し終わったライブラリのUML図を開発会社が保管」という意味での
UML 図の保管ということみたいですな。

それなら、保管するのは大いにありうることだと思います。
ごめん。


>>698

もちろん、UML図を書くのはいいんですけども、(Extreme Programming 的には)
仕様が変わる可能性を残しているのに、図はとっておくのはムダということでございます。

(なぜなら、どうせすぐに古くなってしまうから・・・)


UML図は紙に描いて意思疎通が終わったら丸めて捨てるのがベストだと思います。


700 :名前は開発中のものです。:02/02/22 17:25 ID:???
>>699
俺は、仕様が変わるからこそ開発資料を作るけどなぁ。

もちろん全部のクラスやシーケンスについて詳細な図を書くことはなくて、中核と
なる部分と例外的な処理をしている部分だけまじめに書いて、後は適当に書くか
まったく書かないけど。

そうでないと、仕様変更が出てきたときに

- その仕様変更によって、どこがどの程度の影響を受けるのか(インパクト分析)
- 作業工程にどのような影響が出るか
 並行して進めてる作業をとめて、こちらを先に進める必要があるのか
- 結果として、スケジュールにどのような影響が出るか

なんてのを、その場で大雑把にでも見積もるのが難しくない?

701 :700:02/02/22 17:31 ID:???
追記

> (なぜなら、どうせすぐに古くなってしまうから・・・)
up to date に保てないような図なら、まるてて捨ててしまえ、というのは同意。
だから何でもかんでも図にしろっつーのは俺も反対。


702 :名前は開発中のものです。:02/02/22 17:37 ID:gH0SaIAu
>>700

いやいや、それが「罠」なんですよ。
また、Extreme Programming を引き合いに出すけど、
未来を予測するのは不可能なのです。

もし、仕様変更が無かったらどうしましょう。
仕様変更のために資料を作ったのがムダになってしまいます。

703 :名前は開発中のものです。:02/02/22 18:27 ID:???
>>702
仕様変更に備えるのは、理由の一つで

- 設計を OO でやってる場合、頭の中に最初に出来るイメージはコードよりは
 UML の図に近い。設計段階で UML の図は自然に出来る。(設計をすっとば
 していきなりコーディングしちゃうヤツを除く)
- コーディングした本人も、数日経つと詳細は忘れる。そのときにコードを追っ
 て理解しなおすよりは、図を見て思い出した方が効率が良い。まして本人で
 はなく、他人がメインで保守しているコードに関してはなおさら。

というのもあるけど。

704 :名前は開発中のものです。:02/02/23 07:28 ID:???
結局売りきりだからね。開発会社も開発ノウハウを蓄積するためのプロジェクト
運営なんて考えないし。(考えているところもあるんだろうけど。)
だいたい、3〜4年たつと新ハードがでて、作ったものがかなり陳腐化するのが
どうしようもない原因であるよ。3DといってもX−BOXとPS2とPS1で
も別世界だし。 もうしばらくはその場しのぎを続けるしかないだろうな。

むろんDQくらい売れるなら使いまわし前提にプログラムを組む余裕はあるだろう。
シナリオ、バランス調整のほうが時間かかってるだろうし。

705 :名前は開発中のものです。:02/02/23 15:06 ID:???
>>704
陳腐化が速くて再利用が厳しいのは確かだが、それでも昔の

 プログラマ一人
 開発期間は数ヶ月

という古き良き(?)世界から、

 プログラマは最低数人
 開発期間は 18 ヶ月

という状況になってしまったわけで、「設計は俺の頭の中にあるよ」では通用しな
くなりつつあるのは確か。

開発期間が伸びた場合に嵩むコストも昔の比じゃないし、外から資金を調達し
てる場合にはスケジュールに関して「プログラマは8割方できてると言ってます」
では済ませてくれないしね。

706 :名無しさん@お腹いっぱい。:02/02/25 14:03 ID:???
それに自分達がその資料や資産をもう必要としなくても、ほぼ同時並行
で進行中の別チームがソレを切実に必要とするケースは結構あるよ。

だから「設計は俺の頭の中にある」っていうのは、ソイツの独り善がりの
台詞としか思われなくなってる。 たとえ腕が確かでも。

707 :名前は開発中のものです。:02/02/25 19:43 ID:JMhB1+u9
注意すべきなのは、ドキュメント使ってる人がいるかどうか、だよね。

もし、見る人がいなければ、そんなものは作っちゃだめ。

見る人がいれば、できるだけ短い分かりやすい文章で解説して、そして
やっぱ一番効率がいいのは面と向かってのやりとりだね。2ch で設計の
議論やろうとしたら全く非効率極まりない。

708 :名前は開発中のものです。:02/02/25 20:27 ID:???
>>707
だから使ってる人がいるかどうかってのは、製作者自身が決める事じゃない
ってーの。
たとえ実際に必要とされなくとも、自分達が作った物に対する詳細な資料を
作製、添付するのは、その完成品で金を貰う人間としては当然の義務だぞ。

ソレを口で説明するのが一番効率がいいとは、何たる言い草だよ・・・
口で説明する。で済むなら、同人とかでやってくれ。

仕事で、そんな事されたら俺は上司にそいつを更迭するよう強く迫るけどな。
第一、ドキュメントもロクに作れん様な奴が人に判りやすく説明できるわけ
無いだろうが。

709 :名前は開発中のものです。:02/02/25 20:42 ID:???
>>708
ドキュメント書かないヤツは論外だが、ドキュメント過剰も良くないとは思う。プロ
ジェクトの規模が大きくなって、それこそ業務用システムのような

 数千人月

みたいな世界になると開発者間で直接コミュニケーションなんてのは不可能だか
ら、細部までドキュメント化してないと話にならないけど、

 開発者数人

という規模だと、コア部分関してはきっちりドキュメント化するのは当然としても、
細部の頻繁に変更される部分までドキュメント化しても無駄になる可能性が高
い。

細部は doxygen あたりのドキュメント作成ツールで済ませることにして、コア部
分だけきっちり資料を作るってのも、現実的な選択肢だと思うよ。

>>707
資料って OO だと UML で大雑把に書いて、そこにノートでコメントを書き込む方
が、文章で書くより分かりやすくないか?

710 :名前は開発中のものです。:02/02/26 03:25 ID:???
>だいたい、3〜4年たつと新ハードがでて、作ったものがかなり陳腐化するのが
>どうしようもない原因であるよ。3DといってもX−BOXとPS2とPS1で
>も別世界だし。 もうしばらくはその場しのぎを続けるしかないだろうな。
いっちゃ悪いけど、「描画系」と「アプリ系」をきっちり分別して開発する
ことに困難を感じている君は修行不足だと思う。


711 :710:02/02/26 03:28 ID:???
特に、PS2 -> X-Box への移植に困難を感じているのならば
開発時の整理整頓を真剣に考えた方がいいと思う。


712 :名前は開発中のものです。:02/02/28 12:39 ID:ssS9vuX/
OO ってプログラムの複雑度を下げるよなぁ…って思ったんだけど、
これについての意見プリーズ。

思いつきだから自分でも確証ないんだよね。どうなんだろう?

713 :名前は開発中のものです。:02/02/28 20:40 ID:???
>712
構造的にはそうかもしらんが
ソースコードは長くなるぞ

というよりアンチOOから怒濤の煽りが来そうなヨカン

714 :名前は開発中のものです。:02/02/28 21:31 ID:???
スパゲッティがほどけて独立性が上がっても、
その独立したものどうしを繋ぐのに複雑性が上がる罠。


715 :712:02/03/01 00:34 ID:???
>>713
ソースコードの長さって問題なのかな?たいした問題じゃないと思うんだけど。
みんなそんなにキーボード打つの遅いの?

>>714
なるほど、だから UML とか デザインパターンズ とかが重要になるんだね。

716 :名前は開発中のものです。:02/03/01 01:55 ID:???


717 :名前は開発中のものです。:02/03/01 02:27 ID:???
そうズら

718 :名前は開発中のものです。:02/03/01 02:48 ID:???
複雑度を下げるというより上げると思うんだが
複雑なことが安全にできるようになるって感じ。
ソースコード対効果比(S/N比)は高い。
掛ける時間は設計90%、コード10%くらいになった。

719 :名前は開発中のものです。:02/03/01 03:50 ID:???
たしかここだったと思うけど、OOPでSTG(凄く簡単な雛型)作った人が、
ソースUPしてたと思うけど、勝手に弄らせて貰ってます。

何か形になりそうだったら、UPします。


720 :名前は開発中のものです。:02/03/01 09:01 ID:2Wt9xxPq
Effective STL買ってきて読んでるけど
shared_ptr(・∀・)イイ!! 怪しい自作スマートポインタとはお別れだな。


721 :名前は開発中のものです。:02/03/01 12:24 ID:???
>>720
weak_ptr も調べると幸せになれる。(boost 1.27 以降だったかな)

722 :名前は開発中のものです。:02/03/01 12:28 ID:???
>>719
ライセンス条件は確認した? BSD ライセンスとかならともかく、そうでないと
「参考にするのは OK だが、コピペで使うと著作権法違反」とかの可能性もあ
るから注意ね。

723 :narucy56:02/03/01 23:18 ID:06YWXjZs
>>718

設計に時間をかけるのはよい心がけ。

ただ、大抵、設計にかける時間というのは言うなれば「どうすれば簡単になるか」
ということを考える勉強の時間なのよ。

OO に慣れた人なら、ちょっとしたディスカッシヨンですぐに設計は完成しちゃう(・・・と思うんだけど、どうかな)

設計に時間費やすのはいいけど、それでデザイナが求めていないところまで
柔軟性を持たせる意味もないし。

だれもが 3分 で内容が理解できるくらい単純な設計でないといけない。
そういう意味じゃ本来は設計には時間を費やさないのが、OO をマスターしてからは
重要なんだと思う。

724 :名前は開発中のものです。:02/03/01 23:40 ID:???
>>723
> OO に慣れた人なら、ちょっとしたディスカッシヨンですぐに設計は完成しちゃう
気のせい。

725 :名前は開発中のものです。:02/03/02 06:07 ID:???
>723
その3分程度でできるのはモデリングだけだろ・・・

726 :718:02/03/02 06:46 ID:???
ありがとうございます。
往々にしてあほ(笑)なので私はまだすぐに設計が完成…という境地には
至ってないですね。がんばりたい。

727 :XP:02/03/04 04:33 ID:fGL1MkkH
先のことを考えて作らないこと。自分が設計にこもりはじめたり、
一般化をはじめたりしているのに気がついたら、ストップ。動作す
るもっとも単純なことを実装して、今しなくてはいけないことをす
るのだ。「あとで必要になるはずだ」と言っている自分に気がつい
たら、あなたは貴重な時間を無駄にしているということだし、顧客
からプライオリティを設定する権利を奪い取っているということだ。


728 :名前は開発中のものです。:02/03/04 04:57 ID:???
>>727
正直、リファクタリングは

 ちゃんと設計できる能力がある人

前提の話だと思う。いい加減な設計しか出来ない/設計しない人が言い訳に
使うのは許さん。

729 :名前は開発中のものです。:02/03/04 06:18 ID:???
もとの設計がダメでそれから派生した多種のクラスもダメだった
その修正がいい加減嫌になって全部捨てて結果
全世界の開発者の貴重な時間を無駄にした例がMFCだよね

730 :名前は開発中のものです。:02/03/04 15:01 ID:???
>>729
MFC 叩きはよそでやれ。

731 :名前は開発中のものです。:02/03/04 17:42 ID:???
>>729-730
秀同(w


732 :名前は開発中のものです。:02/03/06 03:48 ID:d8OL+l1I
良スレ期待age

733 :名前は開発中のものです。:02/03/08 16:14 ID:QLWVytdE
設計のベストなあり方としては、以下のページによいものがあった。

設計の終焉?
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html


設計はやっぱしなきゃだめ。
でもそれは複雑になりすぎちゃだめ。
時間をかけすぎてもだめ。
しっかりできても他人に説明できなきゃだめ。


734 :名前は開発中のものです。:02/03/08 18:16 ID:???
>>733
読んでみたけど、妥当な意見に思えるな。

735 :名前は開発中のものです。:02/03/08 23:38 ID:???
>>733
どうでもいいが、こうあるべきという主張はやめたほうがいいよ。
XPかぶれてるのはわかるけど。

736 :名前は開発中のものです。:02/03/09 00:33 ID:???
>>735
> XPかぶれてるのはわかるけど。
リンク先のドキュメントも >>733 の文章(設計の終焉? の要約だと思うが)も、
むしろ XP の中では穏健派の書いた文章だぞ。

XP について賛成するにせよ反対するにせよ、とりあえず XP について調べて
理解しとけ。話はそれからだ。

737 :名前は開発中のものです。:02/03/09 00:50 ID:zvT+Hk0x
XPを実践できるのは天才だけ?

738 :735:02/03/09 00:51 ID:XwdiXSCe
>>736
んー?ベストなものなんて世の中には無いって言ってるのさ〜。
XPについては何も言ってないぞ。

739 :名前は開発中のものです。:02/03/09 01:23 ID:???
>>738
> XPについては何も言ってないぞ。

XP について何も知らないのに
> XPかぶれてるのはわかるけど。
と言うの? ダメじゃん。

740 :名前は開発中のものです。:02/03/09 01:25 ID:???
>357
>XPかぶれてるのはわかるけど。
>738
日本の政治家みたいなヤシだな(藁

741 :名前は開発中のものです。:02/03/09 01:26 ID:???
ポインタ間違えた・・・
×>357
○>735

742 :名前は開発中のものです。:02/03/09 01:55 ID:???
がんばれよ(藁

743 :名前は開発中のものです。:02/03/09 02:50 ID:???
やだ(w

744 :名前は開発中のものです。:02/03/17 02:50 ID:62wXi74P
age

745 :名前は開発中のものです。:02/03/17 03:13 ID:???
XPなんてガキのションベン臭いものを勝手に作っておいて
勉強しろなんてひどいな

746 :719:02/03/17 07:42 ID:SG2XMPR0
(多分ここで)UPされたOOPSTGに、簡単なタスク管理追加、DIRECTX化、
したものをUPしようかと思います。
(環境、Ein98SE,P31G,GForce3)
著作権法違反は、特に記述がなかったのでOKだと思います。

当り判定(タスク間のやりとり)をまだ入れてないんです。
各(自機の)弾タスクが、(敵の数分の)タスクを総ナメしないと
いけないんですかね?やっぱ。判定に段階を設けるとしても。


747 :名前は開発中のものです。:02/03/17 11:29 ID:mjqfxEH/
>著作権法違反は、特に記述がなかったのでOKだと思います。
 
お〜い、はに丸。著作権は何もしなくても自動的に発生しますよ。
改変と再配布の許可が明示されているのでなければ、
一応作者に問い合わせるしか。


748 :名前は開発中のものです。:02/03/17 13:38 ID:???
>>747
同意。

明示的に再配布可能とか記述がない限りは、勝手に使うとまずいぞ。

っつか C++ で書いたシューティングゲームの雛型なら MIT ライセンス
で公開されてるものがあるぞ。

749 :719:02/03/18 00:39 ID:tIFzPCA5
>>747
はにゃ?そうスか、、。無知を晒してしまったですな。
ソース自体は、殆ど書き換えちゃったんですがね。実は。
やめといた方がよさそうですね。
作者の方へコンタクト取れそうにないし。

>>748
出来れば、詳細を教えて下さい。どんな設計か興味あります。
(特にクラス間の情報のやり取り等)
シューティング C++ で検索しても見つけられなかったです。


750 :名前は開発中のものです。:02/03/18 02:40 ID:VWHiZCDa
ximpactもC++で書いてあった気が

751 :名前は開発中のものです。:02/03/18 04:31 ID:???
>OOPSTG
開発状況報告スレのここらへんじゃない?
http://game.2ch.net/test/read.cgi/gamedev/1005143186/212-

あとここ。
http://www.sm.rim.or.jp/~shishido/gamedev.html

752 :名前は開発中のものです。:02/03/18 19:05 ID:???
>>749
これ。

http://www.issei.org/programming/Windows/DxApp

ただしソースはあるけど操作に必要なリソースファイルは置いてないし、
当たり判定もまだのようだが。

753 :719:02/03/19 01:30 ID:9e3mOAQn
>>751
おお!THX!ビンゴです。早速問い合わせてみます。

>>752
THX!です。見てみます。
でも、本業の方が押してきてるので、作業進まないかも。
(でも、やりたいのはSTGw)

今、某CUBEやってるんですが、コールバック関数のラッピングに手間取ってます。
(static)関数内でクラスにアクセスのに、とりあえず、グローバルポインタ渡すしか
思いつかない、、。


754 :名前は開発中のものです。:02/03/19 01:56 ID:???
>>746
 当たり判定は当たり判定管理クラスにタスクを登録して結果を
コールバックで取得&反映って感じでしょ。

 後は判定管理クラス内をレイヤー化して置く事で様々な状況に
対応できるようにすると。

755 :719:02/03/19 04:05 ID:9e3mOAQn
>>754
すいません。良く解らないです。

コールバックって、キリの良い所で処理を返す必要がないものに
対して使うものだと認識してます。
(メモカ、CDの裏読み等)当り判定って、フレームごとに全て完了
させないとイケナイ気がするんですが・・。


756 :名前は開発中のものです。:02/03/19 04:17 ID:???
>>755
> コールバックって、キリの良い所で処理を返す必要がないものに
> 対して使うものだと認識してます。
認識が間違ってます。

757 :名前は開発中のものです。:02/03/19 05:05 ID:???
>>755
ウンウン、コンシューマな人だねぇ…。
別にハードウェア割り込みから呼ばれる関数をコールバックと限定
するワケじゃないハズだよ。

当たり判定管理クラスを1つのデヴァイスと見なして、そこからの
情報伝達をコールバックという形で見れば大体言いたい事は解って
もらえるかな?

 だから1タスクは他のヒット効果をもつタスク全てを知らなくても
自分と判定管理クラスとの相互関係のみで当たり判定を管理できるよ
うになる訳。719氏のタスクシステムの全貌は知らないけど、
HitMe( Task& enemytask , int layer );
Hit時にこーゆー関数がコールバックされば大体の処理は管理しきれる
し、パワーアップアイテムとかとの住み分けの汎用性も高いっしょ?

 次にレイヤー化する事によるメリットって?みたいな質問がくると
更に嬉しいんだけど。

758 :名前は開発中のものです。:02/03/19 11:42 ID:???
レイヤー化する事によるメリットって?

759 :名前は開発中のものです。:02/03/19 11:53 ID:???
>758
オマエ755じゃないだろ

760 :名前は開発中のものです。:02/03/19 12:07 ID:???
うん

761 :名前は開発中のものです。:02/03/20 01:06 ID:OKAtcaEA
>>757
 それより先に、コールバックで結果を通知することのメリットの方が聞きたい。
(レイヤー化のメリットは、わかる。俺もそうしよ(w )
 当たり判定管理クラスにAddHitData(Task &, int) IsHit(Task &, int) ってなメソッド
を用意して、前者で当たりの登録(これはTaskスタート時1回でいい)、でIsHitで結果
を知るってな方が自然だと思う。
 コールバック方式って、やっぱ、HitMeの時には登録が行われるだけで、タスク処理
が全部終わったあと、当たり判定管理クラスの実際に判定を行うメソッドを呼んでやる
と、その中でコールバックが呼ばれる感じだよね?となるとコールバックの中で進入禁
止の処理やら、アイテム拾ったときの処理やら、攻撃受けたときの処理やら全部やら
なきゃいけないわけで、そういう処理はタスク処理の中に書けた方がわかりやすいので
は?

762 :名前は開発中のものです。:02/03/20 01:11 ID:???
>>761
本筋からずれるが、なんでもかんでも Task クラスに突っ込まずに、

- 当たり判定関係のメソッドだけ抽出したインターフェースを用意
 (純粋仮想関数だけ定義したクラスを容易)
- タスク実装クラスに、そのインターフェースを多重継承

の方が、柔軟性が増すぞ。

763 :761:02/03/20 01:15 ID:OKAtcaEA
あ、わかった。タスク処理の中であたり判定処理しちゃうとタスクの実行順で
当たり判定データが現フレームの物だったり前フレームの物だったりしちゃう
からか。

764 :名前は開発中のものです。:02/03/20 01:20 ID:???
>>761
757 じゃないが、メリットは

1 当たり判定順序をタスク実行順序と切り離せる

2 タスクの状態変化のタイミングと、タスク実行のタイミングを分離できる
 タスクを順次読んでる途中で、タスクの状態が変わって、タスク管理クラス側
 にも影響を与える(たとえばタスクを殺して管理クラスから削除)場合には、
 よくよく考えないと dangling pointer を参照するバグが出る

3 特殊な判定(特定のキャラクタにのみ当たり判定があるとか)を付け加える
 ときに、その処理が各タスクに分離せずに、管理クラスで一括して処理でき
 る

っつーあたりじゃないか。

当たり判定はともかく、タスク実行と描画は実行順序を独立に定義するために、
分離するのが普通だよな。

765 :名前は開発中のものです。:02/03/20 01:21 ID:OKAtcaEA
>>762
多重継承より、オブジェクトコンポジションの方が良いと思われ。

766 :名前は開発中のものです。:02/03/20 01:27 ID:???
>>765
インターフェースの多重継承と、実装の多重継承を勘違いしてないか?

コンポジションだと、タスク内部の情報にアクセスするのが難しくなるぞ。

767 :761:02/03/20 01:33 ID:OKAtcaEA
>>764
>当たり判定はともかく、タスク実行と描画は実行順序を独立に定義するために、
>分離するのが普通だよな。
うい、そうですな。

 俺のタスクシステムの場合、タスク処理本体を二つの関数に分けてあって、基本
的な処理は1番目の関数をオーバーライドして定義し、実行順の問題がある処理
は2番目の関数をオーバーライドして、ってな感じでやってるんですが、これだと、
2つじゃたんない、3つ必要!ってな事になったらおいそれと足せない。
 なんかもっといい実装例ないかなぁ。それか、実行順に依存させたくない処理は
ぜんぶコールバックでやるべきなんだろうか?(この方式にこだわるのは、処理の
流れがソースからわかりやすい、から)

#ちなみにその二つのメソッドはanimate、renderという名前。renderといいつつ、
当たり判定とそれによる位置変更もやる……名前と内容が一致してない……。

768 :766:02/03/20 01:38 ID:???
実例を挙げた方が良いか。

struct hittable {
  virtual void get_hit_rect(rect&, hit_type&) = 0;
};

class player_task : public hittable
{
  bool invisiable_;
public:
  void get_hit_rect(rect& rc, hit_type& htype)
  {
    if (invisible_)
      rc = INVALID_RECT;  // 不可視状態の時には、当たり判定なし
    else
      ...
  }
};

インターフェースの多重継承を利用すれば、こんな感じでタスクの内部状態
を利用して当たり判定を変更することが、容易に可能になる。コンポジション
で同じ事をやろうとしたら、思い切り不自然なコードを書くことになるぞ。

769 :名前は開発中のものです。:02/03/20 01:40 ID:???
>>766
ん、勘違いしてた。
ああ、762が言っている方式では、タスクマネージャーの方から当たり判定用の
メソッドを呼び出して当たり判定を実現するって事なのかな?(柔軟、か?)

770 :719:02/03/20 01:52 ID:3YnMUW/P
winのような、イベント駆動型とかをイメージすればいいのかな?
いやー。正直、よくわからんスw避けてました。
勉強してきます。

>719氏のタスクシステムの全貌は知らないけど、
HitMe( Task& enemytask , int layer );
Hit時にこーゆー関数がコールバックされば大体の処理は管理しきれる
し、パワーアップアイテムとかとの住み分けの汎用性も高いっしょ?

自分が今実装してる方法は、
UpdateFrame()、(全タスクに対するAI処理等)
EndScene()、(全タスクのキルスク、チェンジタスク要求チェック、実行)
Draw()、全描画
てな感じです。
判定は、キルタスク同様、大まかな範囲チェックに引っ掛かったものを、
EndScene()内でさらに判定、て感じで考えてました。

で、判定関数は、矩形,球ぐらいを用意しといて、タスククラスに
持たせようと思ってました。

>次にレイヤー化する事によるメリットって?みたいな質問がくると
更に嬉しいんだけど。

それじゃ、
次にレイヤー化する事によるメリットって?


771 :名前は開発中のものです。:02/03/20 01:54 ID:???
>>767
> 実行順に依存させたくない処理は ぜんぶコールバックでやるべきなんだ
> ろうか?
そう思う。

上のほうで挙がってた DxApp だけど、あれは描画とタスク実行を切り離して
別々の優先順位で処理するようになってる。

 タスク関係  ITask, CTaskManager
 描画関係 IObject, CObjectManager

が対応するクラスなんで、読むと参考にはなるかも。

(あと優先順位無し、登録順で処理する IObjectCommand っつーのもある)

772 :名前は開発中のものです。:02/03/20 01:56 ID:OKAtcaEA
 >>768 の方式だと、オブジェクトごとに当たり判定の実装が必ず
違うのであれば問題ないけど、このオブジェクトとこのオブジェクトは
実装一緒ってな事が多いとコピペが氾濫したり、もう一個クラス作って
へんちくりんなメッセージングすることになったりしない?

 俺は757のいう当たり判定管理クラスってのを導入した方が
スマートだと思うから。
 メンバとして持ったhittableのインスタンスの参照を当たり判定
管理クラスに丸投げしてやるだけでいいと思うので、複雑にはな
らないと思う。

773 :名前は開発中のものです。:02/03/20 02:05 ID:???
>>772
> このオブジェクトとこのオブジェクトは実装一緒ってな事が多いと
そのときには template を使って Mixin すれば OK。

っつか 768 も

- 当たり判定管理クラスを作り
- そこに当たり判定チェックを行うインスタンスを登録
- 管理クラスから、各インスタンスをコールバック的に呼び出す

のは同じだけど。設計方針は変わらず、たんに C++ で都合がいい実装方法を
紹介しただけ。(コールバックの代わりに多重継承を使うと this の受け渡しが楽
だぜ、という程度の話)

774 :767:02/03/20 02:11 ID:OKAtcaEA
 俺のは2つだけど、>>770 のは3つに別れている、って事なのね(w
 こうなるとじゃぁ4つに分割、5つに分割と仕様要求次第じゃきりがない
って話になるな。
 タスク処理メソッドを可変長リストで持って、とかすると無駄に複雑に
なりそうだから、>>771 の言う通り、「実行順に依存させたくない処理は
ぜんぶコールバックでやるべき」なのかも。

>上のほうで挙がってた DxApp だけど、あれは描画とタスク実行を切り離して
>別々の優先順位で処理するようになってる。
 フロー制御はタスク機構だけで十分、というのは強引かな、やっぱ。(あ、俺
のシステムだとanimate、renderメソッドの呼び出しそれぞれに別々の実行順を
設定できるから、同じ事が実現できてはいる)

>>773
>> このオブジェクトとこのオブジェクトは実装一緒ってな事が多いと
>そのときには template を使って Mixin すれば OK。
あ、なるほど(w

775 :名前は開発中のものです。:02/03/20 02:17 ID:OKAtcaEA
>>773
>(コールバックの代わりに多重継承を使うと this の受け渡しが楽
だぜ、という程度の話)
たしかに、関数のポインタを渡すより、オブジェクトのインスタンス
渡した方がいいですな。

 つまり、基本はタスクでフロー制御して、その実行順に依存したく
ない物は全部GoFの言うところのCommandパターンでやるのが吉、
ってことかな?

776 :名前は開発中のものです。:02/03/20 02:29 ID:???
>>772
C++ 限定の手法だが、template を使った Mixin の例。

template <class T>
struct hittable_invisible : public hittable
  void get_hit_rect(rect& rc, hit_type& htype)
  {
    T& obj = static_cast<T&>(*this);
    if (obj.invisible_)
      rc = INVALID_RECT;
    else
      ...
  }
};

class player : public hittable_invisible<player>
{
  bool invisible_;
public:
  ...
};

効率と汎用性、そして型安全性を全て損なわずに実現してる。ペナルティは
コードサイズの増大。

777 :719:02/03/20 02:47 ID:3YnMUW/P
>>774
3つ?ですか?

大まかな流れはさっき書いたものなんですが、言葉足らずだったかも。
ちょっと細かく言うと、
UpdateFrame()は,ゲームアプリ、タスクマネージャ、
描画エンジン、vプリミティブ(描画)、v各TCB、v各タスククラスが持ってて、
vがついてる奴が仮想関数です。

EndScene()は今の所、託すマネージャのみのメンバ間数です。

Draw()はタスク処理とは関係ないです。
こちらは描画エンジン、各(と言っても今実装してるのはスプライトのみ)
プリミティブクラスで使ってます。

タスククラスは、
tcbBase<-tcbSprite(今これだけ)
tskBase<-各キャラタスク となってて、
tcbSpriteのメンバにVectorでtskを保持して、チェンジタスクで
切り替えています。

tcbSpriteが、(スプライト)プリミティブからリソースを貰って
UpdateFrameで更新してます。

描画エンジンの方にも、UpdateFrameはあって、アニメ処理、タスクが
弄った頂点データをビデオボードに転送したりしてます。


778 :名前は開発中のものです。:02/03/20 02:51 ID:???
>>757
話が落ち着いたところで、そろそろ「レイヤー化する事によるメリット」を
語ってくれると嬉しいトコロだが。

そもそも「レイヤー化」を、どういう意味で使ってるのか分かってなかったり
するので、単語の定義からお願いします。

779 :名前は開発中のものです。:02/03/20 03:03 ID:???
>>777
 ああ、タスク毎の処理は1種類で、当たり判定の処理(タスク実行順に
依存したくない処理)はタスクマネージャーがグローバルに行う、ってわ
けですね。
(´ー`)。oO( 本当、人それぞれだなぁ ) 

780 :名前は開発中のものです。:02/03/20 06:31 ID:9RjuXxJB
このスレの最初のほうにCとC++ではCの方がC++で作ったときよりも
実行速度が速い、もしくは同等と書かれていたんだけど、
ヘボプログラマはCで作っておいたほうが無難ということなの?
そこで言われているCとC++との違いはクラスの使用から来るもの?

781 :名前は開発中のものです。:02/03/20 07:15 ID:???
>>780
実際にわずかなオーバーヘッドがあるし、まずい設計では
暗黙のコンストラクタ/デストラクタによって積み重なって遅くなる。
C++についてよく理解してないと、ただ遅いだけの道具になるよ。

782 :781:02/03/20 07:18 ID:???
C と C++ の違いは主にクラスによる。
同一な C プログラムなら C++ でコンパイルしても
速度はほぼ同一なはず。ライブラリとか最適化の具合にももちろんよるけど。

783 :名前は開発中のものです。:02/03/20 11:13 ID:???
>>780
書籍「Inside the C++ Object Model」で詳細に解析してるから、それを
読むのがいいと思うが。

メンバ関数(メソッド)を呼び出す場合に this が暗黙のうちに渡されたり、
仮想関数を呼び出すと間接参照が何度か(一般には 2 回)入ったりす
る。ただ、このあたりのことは C でも同じ処理をやろうと思ったら、

 関数の引数として、構造体へのポインタを渡す
 関数ポインタを使う

必要があるから、ホントは変わらないんだけど。

> 暗黙のコンストラクタ/デストラクタによって積み重なって遅くなる。
synthesize constructor / destructor のことを言ってるんだと思うが、
それなら C だって「初期化処理を入れたら遅くなる」というのと同じ。
trivial constructor / destructor で済むクラスなら、初期化・終了処
理を省くことも出来るし。

C でも C++ でも「同じ処理をさせよう」と思うと、実際には「同じだけの
コストがかかる」ことになる。ただ C++ では、synthesize constructor/
destrurctor や temporary object のように

 コンパイラが、見えないところでコードを付け加える

ことがあるから、そこを意識していないと、たった数行のコードなのに
コンパイルすると数千命令に展開されていた、ということが有りうるの
で注意が必要。

784 :名前は開発中のものです。:02/03/21 00:42 ID:I/OXI3by
>>778
 フォトショップのレイヤーを思い浮かべると良いと思われ。
 当たり判定を取る当たり同士をグループ化して、グループに番号を付けておく。

 進入禁止系のあたりをレイヤー0番に置くとして、壁、NPC、敵キャラのあたりは
HitMe( ???, 0)と呼び出してやる。プレイヤーオブジェクトはそれが壁なのかNPCな
のか区別せずにすむ。
 で、レイヤー1番はアイテム系の判定として、アイテムオブジェクトとプレイヤー
オブジェクトだけが所属する。そうすればNPCオブジェクトの方で接触のあった
オブジェクトがアイテムだったら何もしない、なんてコードを書かなくて済む、と。

 こんな感じ?

785 :名前は開発中のものです。:02/03/21 11:11 ID:???
すげぇ、この板に役に立つスレがあったのか。


786 :名前は開発中のものです。:02/03/21 13:39 ID:???
>>784
なるほど。参考になったよ。

787 :名前は開発中のものです。:02/03/22 10:21 ID:???
レイヤー化って、OS−ミドルウェア−アプリケーションみたいなプログラムの階層化と思ってたけど、違ったのね

788 :名前は開発中のものです。:02/03/22 23:51 ID:???
>>784
 すまそん。マスター入れてやっと家に帰って来れました。

 レイヤー化のメリットはまさに784さんの言うとおり。汎用的な当たり判定管理クラスを
1つ作ってあとはゲームデザイン次第でプログラマが自由にレイヤーを利用みたいな感じね。

 更なるメリットとしてヒットアルゴリズムの分離ってのもありまして。
「矩形の重なりによるヒット判定」
「球形や線分との距離による判定」
「背景物のようなn次元マップデータとの判定」
「ランドスケープやポリゴン等のベクトルデータとの判定」
など、これまたゲームデザインの要求に応じて利用/拡張すればいいと。
はっきりいってこの機構自体は1個作っちゃえば3Dゲームにもバリバリ
に応用できるし、斑鳩みたいな2Dの3Dの混在なんかも結構簡単に出来
るよね?

 ただまぁ、C++としての実装は自分はヘタッピなのでだれか上手い実装例
をみせてくれないかなーと。テヘッ。

789 :名前は開発中のものです。:02/03/23 01:20 ID:???
コールバック関数による当たり判定って

全キャラクタのタスク更新

判定管理クラスの関数を呼び出し→各キャラクタのタスクのコールバック関数呼び出し

描画

みたいな流れかと思ったんですが、
コールバック関数内でタスクの状態(位置など)を変化させられないと、
キャラクタ同士めり込んだ状態とかで描画されてしまいますよね?
その辺はどう処理されてるのでしょうか?

790 :名前は開発中のものです。:02/03/24 05:59 ID:WWKNmPMo
良スレなのでage

791 : :02/03/24 09:15 ID:DgRqu+K2
C++なんぞOOPLではないのでsage

792 :名前は開発中のものです。:02/03/24 11:04 ID:???
>>788
なるほど、それは便利だ。
ちゅうか今、当たり判定で困ってるところなんだわ。

>>791
すでにそんなことはどうでもいい

793 :名前は開発中のものです。:02/03/24 11:12 ID:???
>791
マ板で語り尽くされた事を隔離板で吠えられてもナァ...
つーか、sagaってねぇし(藁

794 :名前は開発中のものです。:02/03/25 12:06 ID:???
>>789
俺の場合、基本的にあたり判定の中では当たったかどうかの判定だけで
めり込んでも無視です。
当たり中に状態変化(移動、フラグ立てなど)を行うと実効順によってそれ
以降の判定が異なってしまうからです。
どうしてもやりたい場合、完全な例外処理ですね。
こいつはこういう処理だから気をつけるとかコメント書いてます。
つーか、うまい処理が思いつかん。


795 :名前は開発中のものです。:02/03/31 00:07 ID:???
このスレに影響されて、当たり判定管理クラスを構築中age

796 :名前は開発中のものです。:02/03/31 06:17 ID:???
頑張れー&公開キボン。

797 :名前は開発中のものです。:02/03/31 08:22 ID:???
当たり判定はその処理のタイミングも必要なので、
それ単体をクラスで定義しただけでは難しいと思うのだが
何かいい解決手段あったらよろしく

798 :名前は開発中のものです。:02/03/31 09:34 ID:???
>>764
それだと、当たり判定の種類毎にレイヤー用意しなきゃいけなくなって面倒じゃない?



799 :798:02/03/31 09:40 ID:???
>>764
じゃなくて
>>784
でした。

800 :名前は開発中のものです。:02/03/31 11:32 ID:???
800get

801 :関係ないが:02/04/01 00:49 ID:z86bt0A7
最近C++でゲーム開発しているんだが、ヘッダーファイルをincludeするだけで
最終コードのサイズが増えるという現象に遭遇して思いっきり萎え。
コンパイラのバグだがあまりにもひどいっす。
Cならこんなことはならないよなぁ・・

802 :名前は開発中のものです。:02/04/01 00:56 ID:???
どのコンパイラ?

803 :名前は開発中のものです。:02/04/01 01:01 ID:???
CWだな…。オレも経験済み。

804 :名前は開発中のものです。:02/04/01 01:35 ID:???
参照してないシンボルもリンクしちゃうってこと? >>801

805 :801:02/04/01 02:25 ID:z86bt0A7
g++なんだがCWでもあるんか・・。
classの中のstaticなinline関数が関数ローカルのstatic変数を持つコードが
あると、その関数を一度も使わなくともコード、データ領域ともその翻訳処理
単位で展開されてしまうんだよ。いわゆるシングルトンパターンの構造をもつ
ヘッダファイルをインクルードするだけで飛躍的にコード、データサイズが増加する
罠。
やっぱC++は組み込みには向いてないよな・・・。

806 :名前は開発中のものです。:02/04/01 02:31 ID:???
組み込みだからって、そんな関数なんでinlineにすんだよ?>>801


807 :名前は開発中のものです。:02/04/01 02:34 ID:???
>>805
ちなみに gcc のバージョンいくつ?

808 :801:02/04/01 02:34 ID:z86bt0A7
class foo {
static foo& Instance() {
static foo bar;
reurn bar;
}
}

これだけですが何か?


809 :801:02/04/01 02:36 ID:z86bt0A7
>>807
2.9-9911、2.96-1003、2.96-1003-1で確認したよ。


810 :名前は開発中のものです。:02/04/01 02:58 ID:???
>>808
parse error だぞ(w まぁ、言いたい事は分かるから問題ないけど。

今、手元の gcc 2.95.3 (cygwin-special) で

class foo
{
public:
  static foo& Instance()
  {
    static foo bar;
    return bar;
  }
};

void func() { foo s; }

だけのコードを g++ -S でコンパイルしてみたが、確かに .lcomm セクションに
変数 bar が確保されちゃうね。Borland C++ Compiler 5.5.1 や Visual C++
6.0 だと

警告 W8027 singleton.cpp 6: <静的変数>を含む関数はインライン展開できない(関数 fo
o::Instance() )
singleton.cpp(15) : warning C4514: 'Instance' : 参照されていないインライン関数は削除
されました。

となって、いずれのケースでも出力されたアセンブリコードに bar は存在しない。

811 :名前は開発中のものです。:02/04/01 03:06 ID:???
>>801
inlineにしなくてもまともな実現方法がいくらでもあるんだから、
> C++は組み込みには向いてない
なんてことにはならんだろ。

812 :名前は開発中のものです。:02/05/16 11:00 ID:3bT9vj92
保守ageついでに。上っ面撫でてるだけの記事だけど。

GameDev.net - Object-Oriented Scene Management
http://www.gamedev.net/reference/articles/article1812.asp

813 :名前は開発中のものです。:02/08/15 13:27 ID:EIasLKDH
保守age

OOのゲームプログラミングへの応用ということで、シリアライズの話を。
いつでもどこでもセーブできて、その場の状況を完全再現するには
シリアライズしかないと思うが、やったこと無いので良くわからず。

MFCなんかでやれるオブジェクトの動的生成って全部自前で実装する場合
どうやったら良いんだ?


814 :名前は開発中のものです。:02/08/15 14:23 ID:???
クラスファクトリを作って、
IDとクラスを1:1でマッピング。
読み込み時にIDによって生成するクラスを決める。

815 :名前は開発中のものです。:02/08/15 14:47 ID:???
>>813
> MFCなんかでやれるオブジェクトの動的生成って全部自前で実装する場合
> どうやったら良いんだ?
エピステーメーの「オブジェクト指向的日常」って本で、簡単な解説と実装例を
紹介をしてた。(初版ではコードに致命的なミスがあったりしたが……)

816 :名前は開発中のものです。:02/08/15 14:57 ID:???
生成プログラムをスマートに抽象化するとしたら?

817 :名前は開発中のものです。:02/08/15 17:33 ID:???
>>816
クラスファクトリを static オブジェクト化して、別の static オブジェクトに登録。
main が走り始めた段階で準備完了、としておく。

818 :名前は開発中のものです。:02/08/15 17:58 ID:???
簡単な実装例キボン

819 :名前は開発中のものです。:02/08/15 19:30 ID:???
>>818
マジメに書くと長くなるんだが…。昔のコードから抜粋すると、こんな感じ。

// 永続オブジェクト基底クラス
class CPObject {
private:
  static const BYTE bytMagic[3];
  static const UINT MAGICLEN;

public:
  virtual ~CPObject() {}
  virtual BOOL equalsTo(const CPObject* obj) const {
    return this == obj;
  }
  virtual BOOL saveIt (FILE*) const = 0;
  virtual BOOL restoreIt(FILE*) = 0;
  void save(FILE*) const;
  static CPObject* restore(FILE*);

  virtual UINT isA() const = 0;
};

820 :名前は開発中のものです。:02/08/15 19:31 ID:???
// 永続オブジェクト ID 辞書クラス
class CPIDDict {
private:
  struct CPIDRec {
    UINT id;
    CPObject* (*func)();
  };
  CPIDRec* array;
  UINT size;
  UINT cap;
  CPIDDict(const CPIDDict&);
  CPIDDict& operator=(const CPIDDict&);

public:
  CPIDDict();
  ~CPIDDict();
  static CPIDDict* theCreator();
  void regist(UINT, CPObject* (*)());
  CPObject* create(UINT) const;
};

821 :名前は開発中のものです。:02/08/15 19:32 ID:???
// ファクトリを ID 辞書に登録する
// クラス実装ファイル (*.cpp) の先頭に記述
#define REGISTER_CPOBJECT(X, ID) \
static CPObject* X ## creator() { return new X; } \
class X ## Creator { public: X ## Creator(); }; \
X ## Creator::X ## Creator() {\
    CPIDDict::theCreator()->regist(ID, X ## creator);\
};\
static X ## Creator X ## dummy __UNUSED__;

// 永続オブジェクト関連メソッドの宣言
// クラスへッダファイル (*.h) の public セクションに記述
#define DECLARE_CPOBJECT(ID) \
virtual BOOL saveIt(FILE*) const;\
virtual BOOL restoreIt(FILE*);\
virtual UINT isA() const {\
    return ID;\
}

#define RESTORE_CPOBJECT(TYPE, FP) \
    (dynamic_cast<TYPE>(CPObject::restore(FP)))

822 :名前は開発中のものです。:02/08/15 22:55 ID:LqMXg9lL
class Class { public: virtual ~Class(){} };
typedef int ID;
class IGenerator;
class ClassFactory : private map<ID,IGenerator*>
{
typedef map<ID,IGenerator*> Base;
public:
bool can_create( const ID& id ) const { return ( Base::find( id ) != Base::end() ); }
void insert( const ID& id , IGenerator* const p ) { Base::insert( make_pair( id , p ) ); }

template<class CLASS>
auto_ptr<CLASS> create( const ID& id ) const
{
Base::const_iterator const found = Base::find( id );
return auto_ptr<CLASS>( ( found != Base::end() && found->second )
? dynamic_cast<CLASS*>( found->second->Generate().release() )
: 0 );
}
};
ClassFactory& getClassFactory() { static ClassFactory instance; return instance; }
struct IGenerator
{
IGenerator( ID id ) { getClassFactory().insert( id , this ); }
virtual ~IGenerator(){}
virtual auto_ptr<Class> Generate() = 0;
};


823 :名前は開発中のものです。:02/08/15 22:55 ID:LqMXg9lL
class MyClass : public Class
{
public:
static const ID key;
MyClass(){}
private:
struct Generator : IGenerator
{
Generator() : IGenerator( MyClass::key ) {}
auto_ptr<Class> Generate() { return auto_ptr<Class>( new MyClass ); }
};
static Generator generator;
};
const ID MyClass::key = 12345;
MyClass::Generator MyClass::generator;


824 :名前は開発中のものです。:02/08/15 22:57 ID:???
int main()
{
cout << "create MyClass by correct key... ";
auto_ptr<MyClass> p1 = getClassFactory().create<MyClass>( MyClass::key );
cout << ( p1.get() ? "ok" : "ng" ) << endl;

cout << "create MyClass by wrong key... ";
auto_ptr<MyClass> p2 = getClassFactory().create<MyClass>( 100 );
cout << ( p2.get() ? "ok" : "ng" ) << endl;

return 0;
}


825 :修正:02/08/15 23:05 ID:???
template<class CLASS>
auto_ptr<CLASS> ClassFactory::create( const ID& id ) const
{
Base::const_iterator const found = Base::find( id );
if( found != Base::end() )
{
IGenerator* const p = found->second;
if( p )
{
auto_ptr<Class> pbase = p->Generate();
CLASS* const ptest = dynamic_cast<CLASS*>( pbase.get() );
if( ptest )
{
pbase.release();
return auto_ptr<CLASS>( ptest );
}
}
}
return auto_ptr<CLASS>();
}


826 :あぼーん:あぼーん
あぼーん

827 :名前は開発中のものです。:02/08/16 00:57 ID:???
シリアライズ=排他処理

828 :名前は開発中のものです。:02/08/17 20:32 ID:???
尻穴is=排泄処理

829 :813:02/08/18 17:49 ID:???
おお、解説&ソースうpありがとうございます。
(って、まだ全部ちゃんと読んでないですが)

ちょっくらやってみるか。ってシリアライズなしでやってたものに
シリアライズつけるの厳しそうだな……(いちおうスーパークラスはあるんだけど)

830 :名前は開発中のものです。:02/10/06 17:36 ID:4VoU6WQ6
>>828

ワラタ

831 :名無しさん:02/10/06 17:40 ID:???
あ3w45えrgtyくぉえぴVん:http://genie.gaiax.com/home/nakatai
HGBTR4MHGBP0T5え@ご9JR4QPV「Jる5VG
DB5VHG4ヴぇR4TPヴぇR5MHGBTじhttp://genie.gaiax.com/home/nakatai
http://genie.gaiax.com/home/nakatai
さDRGヴぁでRGBはえ;んごいえろげいR
あえRSHGべSDRHDSVGDRFせVDRFせVせDFGVRFせDヴぇDRFSげDFS
http://genie.gaiax.com/home/nakatai



832 :あぼーん:あぼーん
あぼーん

833 :名前は開発中のものです。:02/10/28 04:08 ID:???
ほしゅ

834 :名前は開発中のものです。:02/11/03 01:14 ID:???
OOってそれぞれの人で考えてる程度が違うから、
チーム開発に適用するのは難しいよね。

835 :あぼーん:あぼーん
あぼーん

836 :名前は開発中のものです。:02/11/03 01:35 ID:???
>>834
> OOってそれぞれの人で考えてる程度が違うから、
プログラミング自体それぞれの人で考えてる程度が違う

837 :名前は開発中のものです。:02/11/03 10:51 ID:ZJseP0w7
なんつーか、あれだよ。
まずはヘッダファイルの一括インクルードする奴は駄目な奴だと
いうことを同僚にたたき込む方法を教えてくれ。

838 :名前は開発中のものです。:02/11/03 10:59 ID:???
>>837
どいうレバルで?VCとかだとコンパイル時間早くするためにやったりするし。
ライブラリレイヤーなんか#include "KaisyaLib.h"で済ませちゃうのが普通じゃない?

アプリケーションレイヤーでそれやられると結構泣けるな。

839 :あぼーん:あぼーん
あぼーん

840 :名前は開発中のものです。:02/11/03 11:48 ID:???
てことはstdafx.hもアウトか?

841 :名前は開発中のものです。:02/11/03 16:12 ID:???
>>837
そいつは、ずっと一人(多くてせいぜい2人)で開発をしてきたか
もしくはソースコードの管理はその一人で(しかも人力で)やってきたか
多人数で効率よく開発する仕組みを全く知らなくても良い立場なんだろ。
 
 
他のモジュールとの依存関係を把握してない。orしたくない。orする必要ない。
  ↓
とりあえず全部インクルードしちゃえ。単体テスト不能?知るかボケ。
  ↓
いきなり結合テスト。make時にリンクされるモジュールが具体的に
どれなのか勿論分かってない。まぁ他のモジュールは全て安定版と
確信してるから何も問題ないね。根拠?知るかボケ。
  ↓
不具合を確認。デバッグ作業開始。3日経過。あ、ボスが来た。
「ボス:どうかね、進捗のほうは」「漏れ:はい順調です(苦笑)」


842 :841:02/11/03 16:20 ID:???
複数メンバーとの並行作業が事実上不可能。
 
実際にやったら
あちこちに(作業上の)クリティカルセクションがありそうだ。
ある一人のデバッグ作業が終了するまで他の全ての人間の作業が
停止することが日常茶飯事みたいな。
 
的外れだったらスマン。

843 :名前は開発中のものです。:02/11/03 16:30 ID:???
>まずはヘッダファイルの一括インクルードする奴は駄目な奴だと
これがよくわからんが、プロジェクト中の自分が使わないヘッダファイルまでインクルードするってことか?

844 :名前は開発中のものです。:02/11/03 17:06 ID:???
開発当初から最後まで一貫して手を入れずに使い続けるようなものは
ある程度の単位にパッケージ化して(安定した)基本セットとして渡す
ことはよくあるな。
 
もっともそれは#include <xxxx.h>がずらーりと並ぶようなヘッダファイルを
用意するということではなく、リリース用の.oファイルと.hファイルのセットを
用意(というか自動生成)するという意味だが。

845 :名前は開発中のものです。:02/11/03 17:06 ID:???
VCなら.libと.hか。

846 :名前は開発中のものです。:02/11/03 18:46 ID:???
>>843
それやられると、一つのヘッダを書き換えただけで常にフルビルド状態に
なっちゃうんだよね。特に、前方宣言ですむところを #include するのは
犯罪だ。

847 :名前は開発中のものです。:02/11/03 19:14 ID:???
VC++ならプリコンパイル済みヘッダがあるので
コンパイル時間については心配いらないんだけどね。

ヘボいコンパイラしかない環境って悲惨だね。

848 :名前は開発中のものです。:02/11/03 20:55 ID:rqxcf8ww
837ですけど。
841さんと842さんのいう状況そのまんまで爆笑しました。
なんつーか説得は不可能ですよね。
なにいっているかわからない人はわからなくていいです。
そのほうが幸せだと思います。


849 :名前は開発中のものです。:02/11/03 20:56 ID:???
>>847
意地の悪い質問で恐縮だが、ぜひ質問させてくれ。
 
00.cpp
01.cpp
02.cpp
03.cpp
(中略)
fe.cpp
ff.cpp
の先頭部分でそれぞれ
#include "00.hpp"
#include "01.hpp"
#include "02.hpp"
#include "03.hpp"
(中略)
#include "fe.hpp"
#include "ff.hpp"
という具合にインクルードしてたとして
00.hppを書き換えてmakeしても時間を気にする必要がないのか。
 
本当か?

850 :849:02/11/03 21:08 ID:???
いや、ゴメン。訂正。
 
#include "00.hpp"
#include "01.hpp"
#include "02.hpp"
#include "03.hpp"
(中略)
#include "fe.hpp"
#include "ff.hpp"
 
という内容のmarugoto.hppなるヘッダファイルを用意。
で、全ての.cppファイルの先頭で

#include "marugoto.hpp"

みたいな感じかな。スレの流れ的にいうと。

851 :名前は開発中のものです。:02/11/03 21:10 ID:???
>>849-850
そのケースだと、最初の.cppをコンパイルするときに
プリコンパイル済みヘッダーが作られて(marugoto.hppを指定する)、
それ以降はそのヘッダを使いまわすことになります。
つまりmarugoto.hppとそのファイルが参照するヘッダファイルの読み込み&処理は
一度しか走らないんです。想像以上に速くなりますよ。

自分の経験ですが、30万行のC++コードのビルドが2分で済みます(P3-800)。
.cppが700ファイル、.hが800ファイルでした。

852 :名前は開発中のものです。:02/11/03 21:17 ID:???
DelphiやJava信者から言わせると、CやC++のインクルードファイルっていう仕様が腐ってるだけなんだよね。

853 :名前は開発中のものです。:02/11/03 21:19 ID:???
プリコンパイル済みヘッダを意識すると

> で、全ての.cppファイルの先頭で
>
> #include "marugoto.hpp"

というやりかたになります。
(VC++つかってる人なら知ってると思いますが、
雛形の.cppファイルの先頭でstdafx.hを#includeしてるのがそれです)

逆に、コレがない環境(たとえばgcc)だと、includeするヘッダを
最低限にする必要があるんですよね。これがまた非常にめんどくさい。

STLなんかを使うには事実上必須だと思うんですけど、ねえ・・・

854 :849-850:02/11/03 21:34 ID:???
>>851-853
丁寧なレスどうもアリガd。
漏れWindowsで開発したことがないんだわー。
カルチャーショック受けたので今度のボーナスで
VisualStudio.NET買ってみるわ。

855 :名前は開発中のものです。:02/11/03 21:34 ID:???
そうじゃなくて、自分のモジュールがどのモジュールに
依存するのかを明示しろってことだろ。
その辺があいまいだと、際限なく他モジュールに依存しまくった挙句、
最終的にはどれがどれに依存しているのか分からなくなってしまうからな。

その辺がクリアなら、インクルードファイルをまとめるのもアリだと思うがな。
あとはコンパイル効率の問題だけだし(チーム全体で合意ができればOK)。
合意を形成しようって努力をするプログラマが少ないってのはそのとおりかも。
俺も含めて。


856 :名前は開発中のものです。:02/11/03 21:37 ID:???
Windowsに関しては、"windows.h"が重過ぎるってのがあるかも。
適当なマクロきれば軽くなるんだけど、あんまりしないよね。

857 :名前は開発中のものです。:02/11/03 21:40 ID:???
依存関係の明確化は難しいね。
本来は設計の段階でクリアになってなきゃならないんだけど、
ユーティリティー的なモジュールはついついおざなりになってしまう。

モジュールの初期化の順序って問題になりやすくないですか?

858 :名前は開発中のものです。:02/11/03 21:41 ID:???
>>856
ふつう真っ先にPCHに入れます。むしろそのためのPCH。

859 :名前は開発中のものです。:02/11/03 21:54 ID:itYckWtp
つーか問題はコンパイル時間云々の問題じゃないんだけど。
雑魚はウザイから消えてくんない?


860 :名前は開発中のものです。:02/11/03 21:58 ID:???
>>859
雑魚ってことで妥協するから
君の主張を書いてくれないか。
 
#喧嘩じゃないだろ。

861 :名前は開発中のものです。:02/11/03 23:29 ID:???
>>101
少しでもって・・・それってそんなに大仰な話なのか?
モジュール化について深く解説した本とか見たことないけど。

862 :名前は開発中のものです。:02/11/03 23:55 ID:???
>>854
PCH に頻繁に書き換えるヘッダ、特に開発中のゲーム本体のヘッダを
突っ込むのは止めたほうが。フルビルドのときには早くなるけど、PCH
を作るのに時間かかるからインクリメンタルビルドが遅くなる。

俺は PCH には標準ヘッダと boost、それに変更の頻度は低いがプリ
コンパイルしときたいライブラリ関係のヘッダだけ読ませてる。ライ
ブラリは別のプロジェクト (*.dsp) に分離ね。

>>859
> つーか問題はコンパイル時間云々の問題じゃないんだけど。
設計の問題が重要なのは言うまでもないが、規模が大きくなるとファイルの
物理的な依存関係も無視できない要因になる。CPU は速くなったが I/O は
大して速くなってないから。

863 :名前は開発中のものです。:02/11/03 23:55 ID:???
>>858
いや、windows.h(とMFC関係?)が大きすぎることがコンパイル時間を遅くしている最大の原因だってこと。
Hello Worldをウィンドウに表示するプログラムを作ってもコンパイル行数10万行ってどうよ?ってことで。

>まずはヘッダファイルの一括インクルードする奴は駄目な奴だと
っていうこというなら、まず、windows.hとかから言うべきだよな。
(まぁ、OSってことで多少は意味合いが違うけど。)

で、pchってのは、そういう文化の上で必然的に生まれたものだって言うことをお忘れなく。



864 :名前は開発中のものです。:02/11/03 23:56 ID:???
(というのは実はウソ。DOSのQuick C 1.0の時代から、インクリメンタルコンパイルは既に合ったしね。)
(Turbo Cもそういうのがウリだった。)

865 :名前は開発中のものです。:02/11/04 00:00 ID:???
>>862
それなら、ディスクキャッシュに納まる程度なら問題ないという結論になりそうだ。

866 :名前は開発中のものです。:02/11/04 00:32 ID:???
>>852
ハゲ同。
Delphiなら10万行くらいの再構築は10秒くらいで終わるし。

久々にVC++やgcc使って思うのはコンパイル遅いことだ
もうBorland製以外にはもどれん

867 :名前は開発中のものです。:02/11/04 00:32 ID:???
>>865
充分なメモリを積んでもPCHにしたほうが速いよ。

ヘッダがいくら大量になろうと、PCHはほぼ一定の速度にしてしまうから
これの優秀さにコンパイラベンダは気づくべき。

868 :名前は開発中のものです。:02/11/04 00:37 ID:???
>>867
プリコンパイル済みヘッダは、CodeWarriorにはたしかあるはず。
gccも3以降に動きがあると聞いたが...違うかも

869 :名前は開発中のものです。:02/11/04 01:48 ID:???
なんでMSやBorlandが10年近くも前に実現してたpchが、
GCCにはないんだぁー!!

by PS2 プログラマー(GCCユーザー)


870 :名前は開発中のものです。:02/11/04 04:02 ID:???
PS2のヘッダファイルもそんなに膨大な量あるの?
というか、G++のコンパイルの遅さ自体が問題なのかな。

871 :名前は開発中のものです。:02/11/04 04:10 ID:???
>>861
ソフトウェア工学の薄くて高い本を読むと
構造化技法、モジュール強度やモジュール結合度について
6 ページくらいは書いてあるよ。

872 :名前は開発中のものです。:02/11/04 13:00 ID:???
>>861
CODE COMPLETE と Writing Solid Code をセットでどうぞ。

>>870
PS2 標準のヘッダはまったく問題ない程度の量。ただ C++ で template を
多用し出すと、ちと気になるかな。(いろんな意味で)

873 :名前は開発中のものです。:02/11/04 23:35 ID:Fll59Laa
>>872
 プロジェクト規模しだいでは「ちょっと」の領域は超えちゃうなぁ。
あと、一本上げて解ったんだけど、テンプレートはあんまりメモリに
優しくないので、中規模以上のプロジェクトではあんまり多用しない方が
いいような気がした。皆のトコではどーなんだろ?

どうでもいいけど、あんまりOOと関係ない流れだね。

874 :名前は開発中のものです。:02/11/04 23:50 ID:???
この板だと「終了とゲームプログラミング」って感じだよな〜

875 :名前は開発中のものです。:02/11/04 23:53 ID:???
>>874 どうぞこちらへ
http://game.2ch.net/test/read.cgi/gamedev/1011082291/

876 :あぼーん:あぼーん
あぼーん

877 :逝って良しの1 ◆.CzKQna1OU :02/11/05 00:00 ID:jHnnn7PQ
test

878 :逝って良しの1 ◆MvRbZL6NeQ :02/11/05 00:02 ID:jHnnn7PQ
結論:
1)再利用可能モジュール以外は手続き型で書く
2)なるべく共通の部品て作れるように設計する。

純OOは効率落とすだけ

879 :名前は開発中のものです。:02/11/05 00:15 ID:???
ム板にお帰りください。

880 :名前は開発中のものです。:02/11/05 00:38 ID:2UkT6p85
とりあえずOOを理解しているやつがすくないってのはわかるね。
まあ結構苦労すると思うよ。なめてかかると。
概念に関しての勉強ってサボルやつが多いからなー。
生まれてから一度も考えたことありませんでした。ってやついるだろ?
だからわかるやつとわからないやつとで差がでかいんだろうね。

881 :あぼーん:あぼーん
あぼーん

882 :名前は開発中のものです。:03/01/29 00:07 ID:pDS/kJyx
なんとなくage

883 :名前は開発中のものです。:03/01/29 02:06 ID:aSd9akLd
PCH は GCC では3.4からなり。

884 :名前は開発中のものです。:03/01/29 02:19 ID:NJepGLCB
 なー、職業ゲームPGの諸君。おまいらの会社ではテンプレートは活発に
使ってますか?仕事にマイテンプレート集を導入したいのだが、周りは
テンプレートと聞いただけで拒絶反応。「テンプレートは何をやってるか
解からんからイヤ」っておまいら…。


885 :名前は開発中のものです。:03/01/29 03:43 ID:L0pVR/JC
>>884
ピンきりだろうに。STL解析しろて訳じゃないんでしょ?

慣れないとちと読みづらいからね。
後、メモリ使用量が。速度的には良いんだが。


886 :名前は開発中のものです。:03/01/29 05:08 ID:i6h+T8DP
Loki を使いたいと言われたら、それはいかがなものかと思う

887 :あぼーん:あぼーん
あぼーん

888 :名前は開発中のものです。:03/01/29 07:45 ID:Psv7UOXb
STLのないC++なんて、もぅ耐えられないかも。

889 :名前は開発中のものです。:03/01/30 01:08 ID:Cu+ZSbHF
 お、皆さんとこもテンプレートモリモリ系ですか?やっぱ強引に社員教育
して導入するべきですかね。メモリ使用量はアロケータを工夫する事でなん
とかなるんだけど、コード増加量を理由に拒絶されるとどーにもこーにも。

 STLのメモリパフォーマンスについての資料ってどっかにないもんかなぁ。

890 :名前は開発中のものです。:03/01/30 02:17 ID:L8+k5MAr
結果的に同じコードになっても、型が違うっちゅうことで
それぞれ別ルーチンになっちゃうのが痛いね。

VC6はそこそこ最適化してたな。
どういう仕組みかしらんが、中身がまったく同じルーチンは一つに
まとめてくれてたようだ。

891 :名前は開発中のものです。:03/01/30 11:52 ID:/VkjZaaB
コード量のほうはマップファイル見てたらわかったりしない?
ピンチになったら、いらなさそうな(ポインタ絡みが多いな)奴を探して
特殊化で切っていくとかできる。

あぁ、でも、最適化できってくれるのが理想だよな。
同じテンプレートから生成されたコードを
バイナリコンペアで判定して、まったく同じのを消せばいい、と思うんだけど。

892 :名前は開発中のものです。:03/02/01 13:20 ID:qAhwu2Kc
そーなんよねー。テンプレートのコードサイズ最適化に関する情報がどこにも
ないからね。プロジェクト末期にコードサイズが5M超えましたとかじゃ怖くて
使えないよな。

まぁマイクロソフトはともかく、GCCやCWに最適化の過度の期待は禁物だしな。

893 :名前は開発中のものです。:03/02/01 13:32 ID:2fuADtqt
インライン化の程度によっては増えたり減ったりするのがなんとも・・・

昔、ポインタのコンテナクラスは、void* のコンテナクラスを作って
それをラッピングしてたじゃないですか。
そういう手間が省けないかなあ、とか。

894 :名前は開発中のものです。:03/02/01 20:32 ID:D+RPtyeL
ふむ・・・
STLでvoid *のコンテナだけ使うことにして、
それにtemplateで任意の型にキャストして使うとか、どうかなー。
やったことないけど。

template< class T >
class WrappedList
{
protected:
vector< void * > m_vec;
public:
void push_back( T *pItem ) { m_vec.push_back( (void * ) pItem ); }
・・・
};
とか。
イテレータとか使えなくなるのはイタイか。

895 :名前は開発中のものです。:03/02/01 22:48 ID:3xQxr2iu
>>894
template< typename T > class std::vecotr< T* > がほしーなー。
STLportで定義しといてくれたりすると泣いて喜ぶんだが。
そんな話ねーのかなー?

896 :名前は開発中のものです。:03/02/01 23:33 ID:r8hHPPWq
こんな情報はいかが?

http://adult.misty.ne.jp/rank/enter.cgi?id=fdeai

897 :名前は開発中のものです。:03/02/02 13:11 ID:TNSSpbv4
 いや、実際テンプレートで消費するメモリリソースなんかたかが知れて
るんだけどなー。sizeofみたいにコードサイズを取得する演算子がほしいな。
sizeofcode( template<T> );
って感じの。演算子じゃなくてもコンパイラの機能でいいんだけど。

898 :名前は開発中のものです。:03/02/02 14:23 ID:9DYxK8lo
コード量の削減で思いついたんだけどさ、
リンク時に中身が同じなら一緒にするってことできないかな?
サイズとCRCをフラグメント(関数?)ごとに記録しておいて、
それらが一致したらシンボルをまとめちゃうの。

win32ならゲイツパワーでできそうだけど、
unix系では辛いかな・・・

899 :名前は開発中のものです。:03/02/02 22:50 ID:G3FgB81u
質問ですが、
オブジェクトをCreate()で作成して、Release()で開放する
考え方? スタイル? をなんて言うんでしたっけ?

900 :名前は開発中のものです。:03/02/02 23:55 ID:Uu0vPcKD
ところで
virtual inline関数って実体がコードに埋めこまれる?

int g; // グローバル変数
class X{
virtual inline void f(){ g = 1; }
};
class Y : public X{
virtual inline void f(){ g = 2; }
};

void main(){
Y yy;
yy.f();
}
これがインライン展開されて
void main(){
Y yy;
g = 2;
}
みたいになるのかなと?


901 :名前は開発中のものです。:03/02/03 00:25 ID:rEcoP6s1
>>900
それならインスタンスの型が分かっているので展開可能。

main(){}でいいのに、なんでvoidなんて書くんだ?煽られるだけだぞ。

902 :名前は開発中のものです。:03/02/03 05:08 ID:JqqWIodK
>>899
ファクトリーパターンか?

903 :あぼーん:あぼーん
あぼーん

904 :名前は開発中のものです。:03/02/03 11:36 ID:flCV13vo
>>901 可能は可能だけど、
実際にそれをやっているコンパイラがどの程度あるかは
微妙な気がするな。アセンブラコード出して確認するのがいいよ。

905 :899:03/02/03 17:09 ID:xLCE72Gt
>>902
ファクトリーパターンって言うんですか。
C++覚えたての時、自分で試行錯誤していてこのパターンを思いついたんですよ。
実際にこういうスタイルがあると知ったのは、最近の事です。
なんという名前だったのか思い出せなかったもので。

906 :名前は開発中のものです。:03/02/04 00:18 ID:hx50gtdt
うそ教えちゃ遺憾
http://www.google.com/search?hl=ja&ie=Shift_JIS&q=%83t%83%40%83N%83g%83%8A%81%5B%83p%83%5E%81%5B%83%93

907 :名前は開発中のものです。:03/02/04 00:24 ID:iI+staQY
あながち間違いでもないと思うが・・・
ファクトリの実装方法の一部、とでも言ったほうがいいのか?

908 :名前は開発中のものです。:03/02/04 00:28 ID:f3Zc1toq
別に create() で作るとだけ言われても、
Factory パターンかもしれないし Prototype パターンかもしれないし他のパターンかもしれない

909 :名前は開発中のものです。:03/02/04 00:40 ID:iI+staQY
他に何が考えられる?

910 :899:03/02/04 01:03 ID:27K59mYC
えーと、意味不明かもしれないんですが・・

(図1)
   A
   |
 |--|--|
 B C D

僕が考えたのは、上の(図1)見たいな構造になってます。
Aは B C Dを内部で、配列やリストなどで管理してます。
Aは B C Dのインスタンス作成メソッドを持ちます(CreateB(B*)みたいな感じ)。
Aのデストラクタで B C Dのインスタンスの開放or終了処理が行われます。

こんな感じです。
具体的なパターン名がありますか?

911 :名前は開発中のものです。:03/02/04 01:27 ID:hx50gtdt
GOF本には載ってないのう
こっちで聞いてください
http://pc2.2ch.net/test/read.cgi/tech/994836140/


912 :名前は開発中のものです。:03/02/04 01:29 ID:iI+staQY
B,C,Dが共通のインターフェースを持つ?

913 :名前は開発中のものです。:03/02/04 01:39 ID:27K59mYC
>B,C,Dが共通のインターフェースを持つ?
ちょっと、よく分かりませんが、
すべてのインスタンスを A で管理しているので、
A->Release() ですべて delete 出来て良いかなと思って実装しました。

914 :名前は開発中のものです。:03/02/04 02:16 ID:BGqxd6sP
 >>902 は ネ タ

915 :名前は開発中のものです。:03/02/04 02:25 ID:xtMOPMMZ
 つーかファクトリメソッドパターンだな、それは。微妙に違う気もするが。
ファクトリメソッドパターン+コンポジットパターンって感じか。

class cHogeManager{
friend class cHoge;
public:
cHoge* Create(...);
};

class cHoge{
privet:
cHoge(...);
};

こーやってcHogeのcreate以外でcHoge生成出来なくなくしたりは良くするね。

916 :名前は開発中のものです。:03/02/04 09:02 ID:iI+staQY
friendの場所が違うような・・・

あとこのやり方?はいわゆる「ハンドル」だと思ったが、
何かパターンとして命名されてるの?

917 :名前は開発中のものです。:03/02/04 11:24 ID:BGqxd6sP
ファクトリメソッドパターン
コンポジットパターン
ハンドル
・・・どれも関係ないと思うんだが。
あー全部ネタか?

918 :名前は開発中のものです。:03/02/04 23:05 ID:1eGNQOWM
コンポジションの関係にある、というだけ。

919 :名前は開発中のものです。:03/02/05 00:32 ID:BDykyC1l
なんかいい名前ないの?
そのための「パターン」なんじゃないのかなあ。

920 :名前は開発中のものです。:03/02/05 01:17 ID:4k9yyPJp
そういう単純なものは名前をつけるまでもない。

921 :名前は開発中のものです。:03/02/05 01:45 ID:BDykyC1l
単純かな?誰も一言で説明してないっしょ。

922 :名前は開発中のものです。:03/02/05 02:34 ID:jPrzM36E
一言で説明したけど…

923 :名前は開発中のものです。:03/02/05 21:29 ID:C5KaH66+
終了厨必死だな

924 :名前は開発中のものです。:03/02/08 07:27 ID:EGa9pqBX
>>910
ただの集約じゃないの?

925 :名前は開発中のものです。:03/05/11 16:50 ID:e4w5V65t
アグリゲートとマルゲリート二人はとても仲良し♪(^o^)八(^o^)♪

926 :名前は開発中のものです。:03/06/19 16:04 ID:HRxe0laA
あげとくか

927 :名前は開発中のものです。:03/06/20 02:15 ID:XRWJvaJP
アイドルのコラージュを発見したでつ。
あと、つるつるオマ○コも見れました。いいの?(*´Д`*)ハァハァ
http://plaza16.mbn.or.jp/~satchel/turuturu/

928 :名前は開発中のものです。:03/06/20 03:27 ID:NoymN1Rz
(。_。)

929 :_:03/06/20 04:49 ID:u/8p8Vlx
http://homepage.mac.com/hiroyuki44/

930 :名前は開発中のものです。:03/06/20 06:27 ID:fKckAdYD
☆A級美女が貴方を癒します☆
http://endou.kir.jp/yuminet/link.html

931 :名前は開発中のものです。:03/07/25 00:24 ID:MxA3qw0U
うちの会社OO禁止。
つうかC++禁止。

どうよこれ?

932 :名前は開発中のものです。:03/07/25 00:57 ID:fakPmJ3A
禁止に至った理由を聞きたいな。
こういうのって壮絶なのが多くて面白いから。

933 :名前は開発中のものです。:03/07/25 06:26 ID:kY6mthGv
コンパイラにバグがあるから(DC)

934 :名前は開発中のものです。:03/07/25 11:23 ID:P6XtV6Vm
DCのコンパイラにバグがあるから、
PS2用やGC用やXBOX用やPC用や内部ツール用のコード書くときまで
C++禁止というのを「今でも」やっている、とか?

935 :931:03/07/28 02:50 ID:Ee0efPhD
「処理が重くなるから」だって。
一度やってみたら上手くいかなかったんだと。

>>934
>PS2用やGC用やXBOX用やPC用や内部ツール用のコード書くときまで
>C++禁止というのを「今でも」やっている、とか?
YES!
理由は上述のとおりだけど。

自分の会社の技術力やプロジェクト管理力がどんなもんなのか、
ぜひ他社と比較したいよ。

278 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)