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

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

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

**名前は開発中のものです。** · 02/01/05 06:28

>>383
うん。実際に作らなくてもいい。頭の中で組み立てるだけでもＯＫ。
じゃ将棋。

**名前は開発中のものです。** · 02/01/05 06:31

将棋もなー、みたまんまクラス化すればいい気がする。

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

**名前は開発中のものです。** · 02/01/05 06:41

駒（piece）はＯＯ化できてもゲームはＯＯ化できません。
思考ルーチンは？
判定ルーチンは？
無理すれば出来るけど、決して効率的ではないでしょう。

**名前は開発中のものです。** · 02/01/05 06:45

思考ルーチンは Strategy にすると
プレイヤーからの入力と Com の思考ルーチンを透過的に扱えて素敵だよね？＞ OO 解ってる人

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

**名前は開発中のものです。** · 02/01/05 06:49

>>387
Strategyなぞで問題を先送りにしてどうする？
思考ルーチンこそ将棋のメイン。

判定　勝敗判定

**名前は開発中のものです。** · 02/01/05 06:53

勝敗判定って？王将が取られたかどうか？
Observer で一発じゃん？？

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

**名前は開発中のものです。** · 02/01/05 06:55

あんまり GoF パターン内だけで応答するとデザパタ厨だとばれるね^^;
GoF 以外のパターンを調べに逝ってきます。

02/01/05 06:58

ＯＯ厨を叩こうと思ったのにデザパタ厨が引っかかってしまったＹＯ！

**名前は開発中のものです。** · 02/01/05 07:25

>>391
いいんじゃないの？
デザパタ厨 inherits OO厨. じゃない？

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

02/01/05 07:31

へえー。
思考ルーチンをＯＯで組めないのを示したのにねえ。

**名前は開発中のものです。** · 02/01/05 07:36

>>393

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

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

**名前は開発中のものです。** · 02/01/05 09:30

なんだかんだ言っても反論がないと寂しいと感じてしまう漏れって一体…。

**名前は開発中のものです。** · 02/01/05 12:37

つーかここ粘着の巣窟だな(藁
ここにいる奴らの誰とも組みたくないと思うのはおれだけか？

**名前は開発中のものです。** · 02/01/05 12:47

まぁOOは気張らず自然に使ってください。

02/01/05 14:51

まあ、勝敗判定は良いとして、>>389の後半は反論するような内容か？

**名前は開発中のものです。** · 02/01/05 16:13

>>386
別にルーチンを要素分解してオブジェクト化しなくてもいい。
C++ にせよ Java にせよ C の派生言語なのだから
メソッドの中はある程度手続き的になる。
その辺の匙加減はお好きなように。

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

**名前は開発中のものです。** · 02/01/05 16:53

うむ。
９５％はＯＯ使えないと言う結論。

**名前は開発中のものです。** · 02/01/05 18:29

いや、
OOPL は手続き型言語の 95% くらいは内包しているという結論。

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

**名前は開発中のものです。** · 02/01/05 19:10

氏ね！>>401

**名前は開発中のものです。** · 02/01/05 19:39

>>401-402
雨の中ぬれている子犬(402)に手をさしのべたら、怯えた目をしたあと噛まれてしまった401。
ここで怒ったりせずに、そのままもう片方の手でなでてやると懐くぞ>>401

**401** · 02/01/05 20:30

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

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

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

**名前は開発中のものです。** · 02/01/05 21:36

…唖然…。
冬休みっていつまでだっけ？

**名前は開発中のものです。** · 02/01/05 22:41

そろそろ終わりじゃない？

**名前は開発中のものです。** · 02/01/06 00:17

唖然って、デザパタ用語を適当に並べてる時点で煽りだと判りましたが
なにか？

**名前は開発中のものです。** · 02/01/06 00:21

デザパタ中毒はしばらくはまってると自然治癒するのでもう少し温かく見守ってあげてください。

**404** · 02/01/06 08:45

>>408
先生…。僕、あとどれくらいで治るんでしょうか…？
この症状が成長の途中の、さなぎの時期だってのは聞きました…。

でも、でも！

こんな症状を発症している所を人に見られたら……(*∀*)ﾊｽﾞｶｼｲ

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

**名前は開発中のものです。** · 02/01/06 09:03

>>409
粘着は個性だから直りません

**409** · 02/01/06 09:22

>>410
冬休みだから暇なだけです。

**名前は開発中のものです。** · 02/01/06 09:29

冬眠は動物の基本。
体と心を休めなさい。
2chから24時間離れると、少しだけ休まった自分を感じる筈。

**411** · 02/01/06 09:34

>>412
2ch を半日以上見ないと禁断症状が出ますがなにか？

**名前は開発中のものです。** · 02/01/06 12:26

余興も終わったみたいですし、仕事始めですし、
そろそろまじめに OO の話をしませんか？

02/01/06 12:54

再発したか・・・。
治療法は上のレスで上げたゲームをＯＯで組んで見る事。
細部はいらない。
１）何をオブジェクトとして
２）どんな処理がどのオブジェクトに属するか
３）オブジェクト間でやり取りされるデータはなにか
を書け。

**405** · 02/01/06 13:00

405までずっとロムってました。

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

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

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

長文ｽﾏｿ

**415** · 02/01/06 13:14

とにかく415を実行してみなさい。
話はそれからだ。

02/01/06 14:26

どっかに　OOなライブラリつくってる人いる？
いままでC++で作ると、速度度外視の厨房みたいな扱い受けたからなぁ
ベターCとしてのC++程度の物しか見たことない

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

**名前は開発中のものです。** · 02/01/06 14:50

>>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

02/01/06 15:04

業務連絡。
重症患者が搬入されました。
救急担当のドクターはＩＣＵへ。

**名前は開発中のものです。** · 02/01/06 15:51

419見て、まあそんなもんだろと思った俺は一体（；´д｀）

**315** · 02/01/06 16:07

完全に一緒に仕事をすることがない相手に対して、布教活動をお互いに（？）
行っていてもしかたないと思ったり。利用しない人はこのスレを見ないだろう
という前提で、どう利用すべきかに集中した方が意義がありそうだね。
まあ、２ちゃん的にはお祭りの方が楽しいかな？

**名前は開発中のものです。** · 02/01/06 16:29

人は皆罪人です。
悔い改めなさい。

**名前は開発中のものです。** · 02/01/07 14:21

下がり始めてるので誰かネタ振りをお願いします......って言ってもな。

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

02/01/07 22:02

GUIは全部成功（効率↑）。
それ以外は全然駄目！ＯＯ氏ね！

**名前は開発中のものです。** · 02/01/08 00:12

>>425
どういう風にして、どんな失敗をしたの？

**名前は開発中のものです。** · 02/01/08 00:14

1000ゲッドォォｫｫ！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

・・・・・・・・・
￣￣￣￣￣∨￣￣￣
　　　　 ∧∧　　　　　　　(´;;
　　⊂（ﾟДﾟ⊂⌒｀つ (´⌒(´

ん？・・・・・・・・・
￣￣￣￣￣∨￣￣￣
　　　　 ∧∧
　　⊂（　ﾟДﾟ⊂⌒｀つ;　(´⌒(´

ﾄﾞｯｺｲｼｮと、・・・・・・・・・
￣￣￣￣￣∨￣￣￣
　　　　 ∧∧
　　　（ﾟДﾟ ,）⌒ヽ
　　　　 U‐U^(,,⊃'～... (´⌒;;

任務失敗と・・・・
￣￣￣￣￣∨￣￣￣
　ﾎﾟ　　∧∧　　ﾎﾟ
　ﾝ　（ﾟДﾟ ,） .　ﾝ
　　 (´;) U,U ）～ (;;).
(´)～(⌒;;UU (´ )...～⌒(｀)

02/01/08 00:19

↑のように映像のパーツ化は巧く行くけど、他の部分は
パーツ化できるほど仕様が固定してないってこと。
ＧＵＩ以外はサブルーチン群が最強。

**名前は開発中のものです。** · 02/01/08 03:00

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

**名前は開発中のものです。** · 02/01/08 03:52

>>428
ライブラリ全般はOOの方がいいと思うけど。
I/Oとかデバイスとか抽象化しておくと便利だし。

**名前は開発中のものです。** · 02/01/08 06:02

結論：慣れている方法を使え

02/01/08 08:37

OOPLとOOを混同しとるらしい>>430

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

**429** · 02/01/08 16:39

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

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

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

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

02/01/08 22:06

部品は小さければ小さい程、変更の可能性は小さくなります。
機械の仕様が変わってもネジを手直ししなくて良いのと同じです。
メソッドをバラしたような、部品化されたサブルーチン群は変更の可能性が
大変小さいです。
それに変更はモジュールに有るのではなく、モジュール間の関係や操作、初期値
などが多いのです。
結果として、ＯＯＰＬでは再利用率が下がります。
Ｃだと７０％－９０％の再利用率を保っていましたが、ＯＯＰＬに切り替えてから
２０％を切っています。

**名前は開発中のものです。** · 02/01/08 22:18

>>434
Ｃ言語のスキルが高いが、ＯＯＰＬはそれほどでもないってことだね。
Ｃで続けた方がいいんじゃない？

02/01/08 22:20

煽ってんのか？

**名前は開発中のものです。** · 02/01/08 23:38

コピペ再利用なら、CもC++も関係なく高い再利用率を達成できそうだね。

**433** · 02/01/09 05:24

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

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

> Ｃだと７０％－９０％の再利用率を保っていましたが、ＯＯＰＬに切り替えてから２０％を切っています。

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

**435** · 02/01/09 22:55

煽ってはいないよ。オレもＣ言語のが得意なのでＣ＋＋を使いたいやつが
チームにいるときでもＣで頑張ってたよ。頑張りどころが違うのかもしれないけど。
ギリギリの納期だったりするので、Ｃ＋＋に進むタイミングがなかなか。
次回のプロジェクトか、ターゲットハードが新しいものになったときでも挑戦しよう
かと思っているけどね。便利だろうなぁとは思うよ。
あと、ＯＯＰＬとＣ＋＋って一緒でいいんだよね・・・？（ぉ

**438** · 02/01/10 03:16

>>439
> あと、ＯＯＰＬとＣ＋＋って一緒でいいんだよね・・・？（ぉ
ゲーム業界では一緒でいい気もしますけど...一般的には違う気がします。
私的には OOP に慣れてないうちは C++ よりも Java とか C# みたいな
単一継承で複数インターフェイス実装の OOPL をオススメしますね。

. · 02/01/10 03:30

>>434
＞Ｃだと７０％－９０％の再利用率を保っていましたが、ＯＯＰＬに切り替えてから２０％を切っています。

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

**名前は開発中のものです。** · 02/01/10 03:45

熟練度が低い＞経験が浅い＞そんなにコード書いてない＞再利用しようがない
て事？

**名前は開発中のものです。** · 02/01/10 03:49

実相継承を使ってみる。Cの遺産が使いにくくなる。
STLを覚える。Cの遺産を使わなくなる。
インタフェース継承とデザインパターンを覚える。それまでのコードを使わなくなる。
templateを使ったGenericProgramingを覚える。それまでのコードを使わなくなる。

**名前は開発中のものです。** · 02/01/10 04:58

燃やすまい、日本の遺産、地球の遺産。

**名前は開発中のものです。** · 02/01/10 05:05

>>443
熟練者ですか？（自分が経験激浅）
ぶっちゃけた話、どういう構造がベストなんですかね？

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

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

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

**名前は開発中のものです。** · 02/01/10 05:08

・・・・・・・・・だから、資源は大切に。

**名前は開発中のものです。** · 02/01/10 05:09

PC 向けだったら資源は浪費できるでしょ

**名前は開発中のものです。** · 02/01/10 07:55

わかってそうでわかってない人が夢見がちな幻想として
「ＯＯＰ＝即座に開発効率が上がると思い込む」
というのがあるのだけど。

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

**名前は開発中のものです。** · 02/01/10 08:21

GenericProgramingのいい資料ってない？

**名前は開発中のものです。** · 02/01/10 12:44

>>449
Ｍｏｄｅｒｎ　Ｃ＋＋　ｄｅｓｉｇｎ／アンドレイ・アレキサンドレスク
今この本を注文しているんだけど、変態っぽくてなかなか良いらしいぞ。

**名前は開発中のものです。** · 02/01/13 22:14

でも、普通にプログラミングやってれば、3割～5割(場合によっては祖霊所)は無意識にOOしてるよね？
だから、べつにOOが良いか悪いかとか言う必要も無いと思う今日この頃。

**名前は開発中のものです。** · 02/01/13 23:45

認めたら最後、言語変更が行われてしまうという罠。

**名前は開発中のものです。** · 02/01/14 19:49

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

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

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

**名前は開発中のものです。** · 02/01/14 19:53

一度Ｊａｖａで組んでみろ。
話はそれからだ。

**名前は開発中のものです。** · 02/01/14 20:23

>>453
罠んところ読んでると泣けてきた。

**名前は開発中のものです。** · 02/01/14 20:26

>>454
GCのふん詰まりを恐れて
オブジェクトがnewできない＆クラス分けできない罠に陥ります。

**名前は開発中のものです。** · 02/01/14 23:13

>>456
インクリメンタルGCと言うものがあるのだよ

**名前は開発中のものです。** · 02/01/15 00:03

>>457
なんだよそれ。参照カウンタＧＣのこと？

**名前は開発中のものです。** · 02/01/15 09:02

>>458
ちょっとづつ断続的にGCしていくやつのことでは。
まとめてGCするのと違って長時間のふん詰まりがない

**名前は開発中のものです。** · 02/01/15 16:48

世代別GCも注目できる技術か？

**445** · 02/01/16 01:57

タスク処理って結局、C++で再現出来るんでしょうか？
考えてみたんですが、やっぱり、関数ポインタ＋（実体）ワークでないと駄目な気がする。

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

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

**名前は開発中のものです。** · 02/01/16 02:20

>>461
デザインパターンマンセー的にはflyweightパターンが適用できると思われ

**名前は開発中のものです。** · 02/01/16 02:22

ＡＢ行き来するときに、delete、newすればいいんじゃないの？

**445** · 02/01/16 03:08

>>462
デザパタはまだ調べてないです。
どういったものなんでしょうか？部分的にでも教えてくだせい。

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

**名前は開発中のものです。** · 02/01/16 03:12

>>461
それならメンバー関数を関数ポインタを登録しようよ・・・。
つか、Aクラス、Bクラスをメンバに持つCクラスを作って
Cクラスで切り替え管理とか。そゆいみじゃない？

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

**名前は開発中のものです。** · 02/01/16 04:10

>>445
それ今うちで作っているライブラリの仕様と全く同じだよ。
その難点はそういう仕様がそのライブラリに無いのが原因だから、
つけてもらえばよいさ。

**445** · 02/01/16 04:34

>>465
>Cクラスで切り替え管理とか。
うーん、具体的には、どうやって切り替えをするのかわからないです。

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

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

**名前は開発中のものです。** · 02/01/16 04:49

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

**名前は開発中のものです。** · 02/01/16 05:00

で、B)の書き方ですが、以前のC++で書いていたプロジェクトでは
状態を整数で持っていて、switch文で切り換えていたね。
#全然、オブジェクト指向じゃないな。

**名前は開発中のものです。** · 02/01/16 05:01

>>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;
}

**名前は開発中のものです。** · 02/01/16 05:19

恰好良く書くなら、
一つの抽象クラス(A)を継承して、関数に相当するクラスを書く。
一つの抽象クラス(B)を継承して、実体ワークに相当するクラスを書く。
Aに、Bへのポインタを引数にとるapply()関数を実装。
Bに、Aへのポインタとexecute()関数と、change_state()関数を実装。
# あっ、ややこしいね。確かに。

**名前は開発中のものです。** · 02/01/16 05:23

あぁ、そういえば、メンバ関数への関数ポインタを使えば
楽なのか。
#おすすめしないけど。

**名前は開発中のものです。** · 02/01/16 06:36

なんか話が思いっきりループしてるよーな気がする。
スレの最初のほうをご覧ありたし。

**名前は開発中のものです。** · 02/01/16 07:59

俺、仮想関数テーブルのポインタ直接書き換えてるよ。
インターフェイスクラスを多重継承して、
自前の仮想関数テーブルへのアドレスを上書きする。
C++の仮想関数と、Cの関数ポインタをオーバーヘッドなしに両立できる。

**名前は開発中のものです。** · 02/01/16 13:04

プロファイルしろｳﾞｫｹども

**名前は開発中のものです。** · 02/01/16 21:30

>>474
メンバ関数ポインタを使えばいいだけ、という気がするが。

**名前は開発中のものです。** · 02/01/16 21:43

>>474
実装継承が絡んだ場合、this にオフセットをかまし忘れて死にそうな予感。

**名前は開発中のものです。** · 02/01/16 22:13

>>476
関数呼び出し方法はあくまで、C++的にしたいんですわ。
メンバ関数ポインタコールをインライン関数でラップする方法もあるけど、
仮想関数としてはつかえんでしょ。

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

**名前は開発中のものです。** · 02/01/16 22:28

>>478
仮想関数へのポインタを取ることは可能だけど、そういう話じゃなくて?

実装継承の話は、

class Deriv : public A, public B
{};

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

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

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

**名前は開発中のものです。** · 02/01/16 22:33

>>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のサイズに依存はしないはず。

**名前は開発中のものです。** · 02/01/16 23:21

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

**名前は開発中のものです。** · 02/01/16 23:24

>>481
趣味でやるなら止めないが、仕事でそんなコード出してきたら肩を叩かせていただく、ってところだな。
ま、コンパイラの吐くコードを探りつつ、いろいろやるのは面白いことは面白いよな。

参考文献
Inside the C++ Object Model

**481** · 02/01/16 23:48

>>482
ゲームプログラムでは必須のテクだと思うぞ。
関数ポインタの使い勝手と、Ｃ++の便利さの両方を享受できる
画期的な手法。

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

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;
}