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

**名無しさん＠お腹いっぱい。** · 01/11/07 23:55

OOをどのように用いれば美しくゲームプログラミングを
行うことが出来るのか語り合うスレです。

**名無しさん＠お腹いっぱい。** · 01/11/10 17:40

コンストラクタとか
オペレーターとか

**名無しさん＠お腹いっぱい。** · 01/11/10 17:41

ボーランドC++のプロパティとかは末期的

**がばろん＠Ｍたんちゅきちゅき** · 01/11/10 17:42

じゃ。まとはずれかもしれないけど代弁してみよう。

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

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

**名無しさん＠お腹いっぱい。** · 01/11/10 17:45

＞Cにはnewがないけどmallocしたあとコンストラクタが呼ばれるだけ
なんか誤解を招きそうだな。
まるで、mallocでインスタンスを作成してもコンストラクタが実行されるみたいだ。
こんな誤解をする人間はここにはいないか…。

外野 · 01/11/10 17:55

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

**名無しさん＠お腹いっぱい。** · 01/11/10 17:56

http://life.2ch.net/test/read.cgi/psy/991265343/518

60 · 01/11/10 18:00

> まるで、mallocでインスタンスを作成しても
それはインスタンスと言っていいものなのか聞いていいですか

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

**名無しさん＠お腹いっぱい。** · 01/11/10 18:12

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

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

**名無しさん＠お腹いっぱい。** · 01/11/10 18:26

オブジェクト指向ってのは開発方法論であって
使用する言語は関係ないと思うがどうか。
オブジェクト指向方法論に基づいてアセンブラでコーディングってのは
いまどき特別なことじゃないでしょ。

**がばろん＠Ｍたんちゅきちゅき** · 01/11/10 18:26

>>96たん。
全部たどっていったら下のレスからのリンクで
ウイルスがみつかったよ。
// もしかして全板にリンクはりまわってるの？

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

**名無しさん＠お腹いっぱい。** · 01/11/10 18:33

モジュールを少しでも勉強した事があるなら、
どの部分をブラックボックス化すればいいか？
なんて事は、そこそこ分かる事なんだが・・・

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

60 · 01/11/10 18:50

>>93

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

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

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

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

＿ · 01/11/10 18:56

みんな中途半端な知識しか持ってないから
こんな中途半端な議論になっちゃうんだよね
意味無し

**名無しさん＠お腹いっぱい。** · 01/11/10 19:01

>>103
そう思うんなら君も中途半端に煽らずにもっと突っ込みをいれなさい

19 · 01/11/10 20:19

>>101
「モジュールの勉強」とは何ですか？
この業界では一般的な用語？

19 · 01/11/10 20:29

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

**アマグラマ** · 01/11/10 20:45

C++でも十分に出力されるアセンブラコードが透けて見えるよん。
ちょっと複雑なだけで。

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

19 · 01/11/10 20:51

>>90

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

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

19 · 01/11/10 21:05

亀質問だけど。
>>23==>>75 さん。

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

60 · 01/11/10 21:05

>>108
>それ納得しちゃうの？
んー
「C++のメソッドってソースコードに書いてないのに、
　本当は引数１個多いんだよねー気持ち悪いよねー」
「うん、そーだね　C言語だけの知識では想像できないね」
だしょ

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

**がばろん＠Ｍたんちゅきちゅき** · 01/11/10 21:33

>>102 60たん。
とりあえず「オブジェクト指向入門」まで読み終わったよ。

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

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

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

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

**名無しさん＠お腹いっぱい。** · 01/11/10 21:47

>>105
・モジュール
構造化プログラミングで、ある機能を有する小部分をモジュールという。
容易に交換し得るような機能単位のプログラムを指す。プログラムを
モジュール化して作れば、次のような利点があり開発効率の向上が期待できる。
１）開発時に分業化できる
２）誤りの部分発生を特定できる
３）機能改善に部分変更で対応しやすい

60 · 01/11/10 21:54

入り口までは案内した扉は自分で開け

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

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

**名無しさん＠お腹いっぱい。** · 01/11/10 21:58

>>111
Ｃ++のページで半年ほど独学すれば？

**名無しさん＠お腹いっぱい。** · 01/11/10 22:11

>>109
何をって何？

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

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

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

**19=105** · 01/11/10 22:11

>>112
サンクスです。
要するに構造化プログラミングを勉強しろということですね。

**名無しさん＠お腹いっぱい。** · 01/11/10 22:17

>>105
モジュールの概念は、開発時にバグを減らすための技法
覚えておけば、かなりバグを減らせる

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

**名無しさん＠お腹いっぱい。** · 01/11/10 22:18

>>115
＞継承を繰り返しているともはやあほくさくてやってらんない。

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

**名無しさん＠お腹いっぱい。** · 01/11/10 22:20

たぶん最初からやってないと思われ。

**名無しさん＠お腹いっぱい。** · 01/11/10 22:20

だから、C++使うな！

**名無しさん＠お腹いっぱい。** · 01/11/10 22:21

>>116
ま、そーゆー事やね。

**名無しさん＠お腹いっぱい。** · 01/11/10 22:22

>>120
・・・それでも使っちゃう・・・♪

**名無しさん＠お腹いっぱい。** · 01/11/10 22:22

こういう本筋とは関係無いどうでもいいスレッドばっかり育ってるなここ

◆XAJ1OOH6 · 01/11/10 22:22

ゲーム機などのリソースが限られていたときの
伝統が残っていて，どのようにソースを書けば
最適コードになるか意識するという強迫観念が
あるからコードの吐き方がイメージできないと
怖いのではないのでしょうか？

**名無しさん＠お腹いっぱい。** · 01/11/10 22:26

>>124
でも思ってるほど、最適なコードなんて書けてないのがゲームプログラマ

**名無しさん＠お腹いっぱい。** · 01/11/10 22:26

アセンブラで最適化って最高に楽しいよね。
浮動小数点演算のあの糞なスタックをやりくりする
楽しさといったら！

**名無しさん＠お腹いっぱい。** · 01/11/10 22:27

>>124
単に、プログラムの設計を勉強してないだけの話
そりゃ、命令を適当に組み合わせるだけでも、
プログラムを作る事は出来るケドね

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

**名無しさん＠お腹いっぱい。** · 01/11/10 22:30

Ｃなら向こうにアセンブラソースが透けて見える？？
cpuが違っただけで、例えばペンティアムⅡとⅢの違い
で全く別言語のような環境と化してしまうアセンブラを
どうやって”透かして見る”んだ？教えて！！

**名無しさん＠お腹いっぱい。** · 01/11/10 22:34

>>127
いや、そういう人が使うためのＯＯＰでしょ。
汗職人には汗職人のための職場がありますよ。
多分。（藁

**名無しさん＠お腹いっぱい。** · 01/11/10 22:41

>>129
ライブラリが充実しているなら、同意するケドね・・・

**名無しさん＠お腹いっぱい。** · 01/11/10 22:41

>>128
78はプログラミング経験が皆無か、
超環境依存型のクソプログラム書いてるんでしょ。
なんに使うのか謎だけど。気にしないでいいよ。

**名無しさん＠お腹いっぱい。** · 01/11/10 22:43

ここはアホぷるぐらまのスレか？

**名無しさん＠お腹いっぱい。** · 01/11/10 22:46

＞ペンティアムⅡとⅢの違い
＞で全く別言語のような環境と化してしまう
オイオイ、
そんなに最適化されたコードはくコンパイラあるのかYO！

**名無しさん＠お腹いっぱい。** · 01/11/10 22:49

128と131はアセンブラで組んだ経験が皆無

＿ · 01/11/10 22:51

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

**名無しさん＠お腹いっぱい。** · 01/11/10 22:51

>>133
だからアセンブリ言語の事言ってるんだよ。
コンパイラとアセンブラの違いは分かるかい？

**名無しさん＠お腹いっぱい。** · 01/11/10 22:51

>＞ペンティアムⅡとⅢの違い
>＞で全く別言語のような環境と化してしまう
>オイオイ、
>そんなに最適化されたコードはくコンパイラあるのかYO！

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

**名無しさん＠お腹いっぱい。** · 01/11/10 22:55

>>136
78はコンパイラについてだよ。分かるかい？

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

**名無しさん＠お腹いっぱい。** · 01/11/10 23:04

>>138
コンパイラなのにアセンブラソースが見えると書いてるよ。
分かるかね？
＞吐き分けてどうしようって言うんだ、一体？
どうするのか分からんなら聞かなくていいよ。（藁

**名無しさん＠お腹いっぱい。** · 01/11/10 23:08

ふう。このスレも某3Dプログラミング系ページに晒されそうだな。

**名無しさん＠お腹いっぱい。** · 01/11/10 23:12

>>139
それは実際の実行プロセスに非常に近いという事だろう。

**名無しさん＠お腹いっぱい。** · 01/11/10 23:18

>>141
・・・ハァ？
＞それは実際の実行プロセスに非常に近いという事だろう。
言ってることが（危）レベルに達してますな。

**名無しさん＠お腹いっぱい。** · 01/11/10 23:21

もー全然OOとゲームプログラミングぢゃねーよ
Game Programming Gems並みのネタをｷﾎﾞﾝﾇ

**名無しさん＠お腹いっぱい。** · 01/11/10 23:21

>>142
ハァ？
分からんの？

**名無しさん＠お腹いっぱい。** · 01/11/10 23:33

うう良いスレだったのに

**名無しさん＠お腹いっぱい。** · 01/11/10 23:37

とりあえずアセンブラソースを実行なんたらと
勘違いしている>>144を放置してＯＯＰに関する
話題で再開しましょうか。

60 · 01/11/10 23:37

貴方がなぜC++を使わないゲームプログラミングをしているのか
理由を書いてくれる人　他にはいないの？

**名無しさん＠お腹いっぱい。** · 01/11/10 23:39

>>147
あなたって？

**名無しさん＠お腹いっぱい。** · 01/11/10 23:40

貴方って誰？

**名無しさん＠お腹いっぱい。** · 01/11/10 23:47

>>146
実行なんたらってなんだ？
あほか？

60 · 01/11/10 23:59

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

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

とむ ◆TMwDpCZo · 01/11/11 00:00

やあ、今ログ読んでました。
すみませんね、荒れる原因みたいになっちゃって。

でも全体的に停滞気味の板だから、たまにはいいかな？（笑）

**名無しさん＠お腹いっぱい。** · 01/11/11 00:33

私、ゲーム専用機対象にプログラミングしたこと無い門外漢ですからサパーリで
興味本位に質問ですけど、C++コンパイラ使えるようになったのって
どのあたりからですか？
　　+->PCE　　 +->DC
FC->SFC->PS->PS2
　　　　　　　　　 +->64->GQ
見たいな流れの中で

**名無しさん＠お腹いっぱい。** · 01/11/11 01:17

3DO,PSあたり?

**名無しさん＠お腹いっぱい。** · 01/11/11 01:30

>>151
C++コンパイラの最適化性能が低くて、糞なコードを量産する
そもそも、まともにC++の言語仕様が実装できていない

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

**47で66** · 01/11/11 02:41

>60
該当者なんで、私もレス書きまーす。
前もって書きますが、私自身、流行の思想については使いこなせれば
良いなーと羨ましいですし、ＯＯについて偏見もありません。

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

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

**名無しさん＠お腹いっぱい。** · 01/11/11 02:59

>おそらく、このような思考方法の人間が、無理やり似非ＯＯ的
>プログラムをしたところで、欠陥のある設計しかできないに
>違いありません（笑）
>そんなわけで、私は大人しくＯＯには触れずにおります
　押しつけるつもりはないけど、一通り勉強してから
結論出しても遅くないと思うけど・・・。
なんかもったいない

**156** · 01/11/11 03:23

いやいや、現状で「そうだ」というだけで、決して結論を出した
わけではありません（笑）

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

**名無しさん＠お腹いっぱい。** · 01/11/11 04:37

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

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

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

**名無しさん＠お腹いっぱい。** · 01/11/11 04:42

今の会社はCマンセー。

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

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

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

**名無しさん＠お腹いっぱい。** · 01/11/11 05:09

プロジェクト毎にソースコピペかＹＯ！

ソースコピペかＹＯ

ＹＯ

**名無しさん＠お腹いっぱい。** · 01/11/11 05:18

160
(･∀･)ｶｺｲｲ! ｹﾞﾗｹﾞﾗ

**がばろん＠Ｍたんちゅきちゅき** · 01/11/11 06:53

>>113-114 60たん。114たん。

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

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

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

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

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

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

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

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

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

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

**名無しさん＠お腹いっぱい。** · 01/11/11 07:03

インラインアセンブラを多用したプログラムを組みたい
ヘッダをインラインまみれにしても極限まで自分でチューニングしたい
いわゆる汚い泥作業も厭わない任侠気あふれるOOなら C++

**名無しさん＠お腹いっぱい。** · 01/11/11 07:22

>>163
複数の人が別々にコーディングする場合はその方が吉だろうね。
一人でやる場合はＯＯＰにこだわる必要はあまり無いとは思うけど。
関数の集合クラスを作ったり継承したりっていう余分な作業は一人で
やる時は得るものが少ないんじゃないかな。
ＪＡＶＡはアメリカでは終わりだとか言われてるけど（ＭＳがサポートを辞めた）
日本ではまだ元気があるみたいだし、しばらくは大丈夫かも。
速度は問題だよね。技術が足りないからだとか言われるけどそこそこの
技術力でももう少し速くなればいいのに思うよ。

**名無しさん＠お腹いっぱい。** · 01/11/11 08:14

Cでゴリゴリやってる人にはC++はかなり泥臭くて似合ってると思うのだが。
C言語が好きじゃない俺は、C++はいくらOO言語だからっていやだけど

01/11/11 09:56

先生！とりあえずC++が遅いって言うのは論外だと思うＹＯ！
どうしても速度的に問題ある部分は、モジュール分けてCで書くっていうのじゃまずいの？
俺はそんなことはしませんが。使える環境なら必ずC++を選択するよ。

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

**名無しさん＠お腹いっぱい。** · 01/11/11 10:38

>>166
プロのゲーム開発の現場に限ったらASM,C,C++以外に選択肢は無いのでは？
C/C++に負けない実効速度を出せるＯＯＰＬってあるのだそうか？
純粋な質問。

**名無しさん＠お腹いっぱい。** · 01/11/11 11:27

>167

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

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

**名無しさん＠お腹いっぱい。** · 01/11/11 11:32

一部をCとかアセンブラで書くと良い＝最適化して書く
が前提。

**名無しさん＠お腹いっぱい。** · 01/11/11 11:33

>>168
コンシューマだとないだろうな。そもそも処理系がない。

**名無しさん＠お腹いっぱい。** · 01/11/11 12:32

>>60
>C++で実際に実行される順番が異なってしまう状態例を
>あげてくれると非常にうれしいです。感激しちゃう。

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

**名無しさん＠お腹いっぱい。** · 01/11/11 13:12

それは最初から不定なので問題なし。

＿ · 01/11/11 15:07

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

**名無しさん＠お腹いっぱい。** · 01/11/11 15:16

C++がCより遅くなる、具体的なコード例を挙げられる人居る?
仮想関数によるポリモーフィズムは遅いと言われがちだけど、
同じ事をCでやるとif文やら関数ポインタやら使うわけで、少なくともC++より高速に動かせるという保証はないと思われる。

**名無しさん＠お腹いっぱい。** · 01/11/11 16:07

どっち派でもいいんだけどさ、互いにコッチだ！って啓蒙しあう
必要ないでしょう。（そーいうのはヨソでやろう）
このスレは、前提としてＯＯで、どの様に良い設計をしていくか
がテーマなんだから、そういう話をしないと
「まったく意味がない」

**名無しさん＠お腹いっぱい。** · 01/11/11 16:18

確かにCで一つ一つ全て別々に作っていたものを
C++で基本部分からの継承で作ると結構遅くなる。

**名無しさん＠お腹いっぱい。** · 01/11/11 16:54

深い継承は、その時点で設計が間違ってることが多い(MFCとか)。
デザインパターンを勉強するよろし。

**名無しさん＠お腹いっぱい。** · 01/11/11 17:53

多少遅くなったぐらいで実際に影響が出る環境で作ってる人が多いみたいですね。
コンシューマの方ばかりなのかな？

19 · 01/11/11 19:53

業界人手あげてー！

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

19 · 01/11/11 20:29

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

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

**名無しさん＠お腹いっぱい。** · 01/11/11 20:35

>>181
構造化定理って調べてみ

ラム · 01/11/11 20:42

ageるっちゃ。

19 · 01/11/11 20:44

>>182
サンクス、ザクザク出てきた。
この世界も奥深いね。べんきょー！べんきょー！

**名無しさん＠お腹いっぱい。** · 01/11/11 22:05

仮想関数には関数ポインタのような柔軟性がないのが嫌。
以前、
CTask{
virtual void Update();
};
CEnemy extends CTask
CEnemy1 extends CEnemy
CEnemy2 extends CEnemy
CEnemy3 extends CEnemy
みたいな設計をして失敗した。

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

**名無しさん＠お腹いっぱい。** · 01/11/11 22:11

>>185
それがどういう不都合があったのか教えてもらえれば、
解決方法を提示できるかも風来のシレン。

**名無しさん＠お腹いっぱい。** · 01/11/11 22:40

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

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

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

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

19 · 01/11/11 22:49

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

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

**187** · 01/11/11 22:52

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

**名無しさん＠お腹いっぱい。** · 01/11/11 22:57

>>187
どういう場合に型情報が必要ですか？
基本的には抽象化された型情報の実際の型
を知らなくても、振る舞いをさせることが出来るのが
理想な気がしますが…。