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

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

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

**名前は開発中のものです。** · 02/08/15 19:30

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

**名前は開発中のものです。** · 02/08/15 19:31

// 永続オブジェクト 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;
};

**名前は開発中のものです。** · 02/08/15 19:32

// ファクトリを 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)))

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

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

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

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;

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

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

修正 · 02/08/15 23:05

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

**あぼーん** · NG

あぼーん

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

シリアライズ＝排他処理

**名前は開発中のものです。** · 02/08/17 20:32

尻穴is=排泄処理

**813** · 02/08/18 17:49

おお、解説＆ソースうｐありがとうございます。
（って、まだ全部ちゃんと読んでないですが）

ちょっくらやってみるか。ってシリアライズなしでやってたものに
シリアライズつけるの厳しそうだな……（いちおうスーパークラスはあるんだけど）

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

>>828

ﾜﾗﾀ

**名無しさん** · 02/10/06 17:40

あ３ｗ４５えｒｇｔｙくぉえぴＶん：http://genie.gaiax.com/home/nakatai
ＨＧＢＴＲ４ＭＨＧＢＰ０Ｔ５え＠ご９ＪＲ４ＱＰＶ「Ｊる５ＶＧ
ＤＢ５ＶＨＧ４ヴぇＲ４ＴＰヴぇＲ５ＭＨＧＢＴじhttp://genie.gaiax.com/home/nakatai
http://genie.gaiax.com/home/nakatai
さＤＲＧヴぁでＲＧＢはえ；んごいえろげいＲ
あえＲＳＨＧべＳＤＲＨＤＳＶＧＤＲＦせＶＤＲＦせＶせＤＦＧＶＲＦせＤヴぇＤＲＦＳげＤＦＳ
http://genie.gaiax.com/home/nakatai

**あぼーん** · NG

あぼーん

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

ほしゅ

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

OOってそれぞれの人で考えてる程度が違うから、
チーム開発に適用するのは難しいよね。

**あぼーん** · NG

あぼーん

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

>>834
＞ OOってそれぞれの人で考えてる程度が違うから、
プログラミング自体それぞれの人で考えてる程度が違う

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

なんつーか、あれだよ。
まずはヘッダファイルの一括インクルードする奴は駄目な奴だと
いうことを同僚にたたき込む方法を教えてくれ。

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

>>837
どいうレバルで？VCとかだとコンパイル時間早くするためにやったりするし。
ライブラリレイヤーなんか#include "KaisyaLib.h"で済ませちゃうのが普通じゃない？

アプリケーションレイヤーでそれやられると結構泣けるな。

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 02/11/03 11:48

てことはstdafx.hもアウトか？

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

>>837
そいつは、ずっと一人（多くてせいぜい2人）で開発をしてきたか
もしくはソースコードの管理はその一人で（しかも人力で）やってきたか
多人数で効率よく開発する仕組みを全く知らなくても良い立場なんだろ。
　
　
他のモジュールとの依存関係を把握してない。orしたくない。orする必要ない。
　　↓
とりあえず全部インクルードしちゃえ。単体テスト不能？知るかボケ。
　　↓
いきなり結合テスト。make時にリンクされるモジュールが具体的に
どれなのか勿論分かってない。まぁ他のモジュールは全て安定版と
確信してるから何も問題ないね。根拠？知るかボケ。
　　↓
不具合を確認。デバッグ作業開始。3日経過。あ、ボスが来た。
「ボス：どうかね、進捗のほうは」「漏れ：はい順調です（苦笑）」

**841** · 02/11/03 16:20

複数メンバーとの並行作業が事実上不可能。
　
実際にやったら
あちこちに（作業上の）クリティカルセクションがありそうだ。
ある一人のデバッグ作業が終了するまで他の全ての人間の作業が
停止することが日常茶飯事みたいな。
　
的外れだったらｽﾏﾝ。

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

>まずはヘッダファイルの一括インクルードする奴は駄目な奴だと
これがよくわからんが、プロジェクト中の自分が使わないヘッダファイルまでインクルードするってことか？

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

開発当初から最後まで一貫して手を入れずに使い続けるようなものは
ある程度の単位にパッケージ化して（安定した）基本セットとして渡す
ことはよくあるな。
　
もっともそれは#include <xxxx.h>がずらーりと並ぶようなヘッダファイルを
用意するということではなく、リリース用の.oファイルと.hファイルのセットを
用意（というか自動生成）するという意味だが。

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

VCなら.libと.hか。

**名前は開発中のものです。** · 02/11/03 18:46

>>843
それやられると、一つのヘッダを書き換えただけで常にフルビルド状態に
なっちゃうんだよね。特に、前方宣言ですむところを #include するのは
犯罪だ。

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

VC++ならプリコンパイル済みヘッダがあるので
コンパイル時間については心配いらないんだけどね。

ヘボいコンパイラしかない環境って悲惨だね。

**名前は開発中のものです。** · 02/11/03 20:55

837ですけど。
841さんと842さんのいう状況そのまんまで爆笑しました。
なんつーか説得は不可能ですよね。
なにいっているかわからない人はわからなくていいです。
そのほうが幸せだと思います。

**名前は開発中のものです。** · 02/11/03 20:56

>>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しても時間を気にする必要がないのか。
　
本当か？

**849** · 02/11/03 21:08

いや、ゴメン。訂正。
　
#include "00.hpp"
#include "01.hpp"
#include "02.hpp"
#include "03.hpp"
(中略)
#include "fe.hpp"
#include "ff.hpp"
　
という内容のmarugoto.hppなるヘッダファイルを用意。
で、全ての.cppファイルの先頭で

#include "marugoto.hpp"

みたいな感じかな。スレの流れ的にいうと。

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

>>849-850
そのケースだと、最初の.cppをコンパイルするときに
プリコンパイル済みヘッダーが作られて(marugoto.hppを指定する)、
それ以降はそのヘッダを使いまわすことになります。
つまりmarugoto.hppとそのファイルが参照するヘッダファイルの読み込み＆処理は
一度しか走らないんです。想像以上に速くなりますよ。

自分の経験ですが、30万行のC++コードのビルドが2分で済みます(P3-800)。
.cppが700ファイル、.hが800ファイルでした。

**名前は開発中のものです。** · 02/11/03 21:17

DelphiやJava信者から言わせると、CやC++のインクルードファイルっていう仕様が腐ってるだけなんだよね。

**名前は開発中のものです。** · 02/11/03 21:19

プリコンパイル済みヘッダを意識すると

> で、全ての.cppファイルの先頭で
>
> #include "marugoto.hpp"

というやりかたになります。
(VC++つかってる人なら知ってると思いますが、
雛形の.cppファイルの先頭でstdafx.hを#includeしてるのがそれです)

逆に、コレがない環境(たとえばgcc)だと、includeするヘッダを
最低限にする必要があるんですよね。これがまた非常にめんどくさい。

STLなんかを使うには事実上必須だと思うんですけど、ねえ・・・

**849-850** · 02/11/03 21:34

>>851-853
丁寧なレスどうもｱﾘｶﾞ㌧。
漏れWindowsで開発したことがないんだわー。
カルチャーショック受けたので今度のボーナスで
VisualStudio.NET買ってみるわ。

**名前は開発中のものです。** · 02/11/03 21:34

そうじゃなくて、自分のモジュールがどのモジュールに
依存するのかを明示しろってことだろ。
その辺があいまいだと、際限なく他モジュールに依存しまくった挙句、
最終的にはどれがどれに依存しているのか分からなくなってしまうからな。

その辺がクリアなら、インクルードファイルをまとめるのもアリだと思うがな。
あとはコンパイル効率の問題だけだし(チーム全体で合意ができればOK)。
合意を形成しようって努力をするプログラマが少ないってのはそのとおりかも。
俺も含めて。

**名前は開発中のものです。** · 02/11/03 21:37

Windowsに関しては、"windows.h"が重過ぎるってのがあるかも。
適当なマクロきれば軽くなるんだけど、あんまりしないよね。

**名前は開発中のものです。** · 02/11/03 21:40

依存関係の明確化は難しいね。
本来は設計の段階でクリアになってなきゃならないんだけど、
ユーティリティー的なモジュールはついついおざなりになってしまう。

モジュールの初期化の順序って問題になりやすくないですか？

**名前は開発中のものです。** · 02/11/03 21:41

>>856
ふつう真っ先にPCHに入れます。むしろそのためのPCH。

**名前は開発中のものです。** · 02/11/03 21:54

つーか問題はコンパイル時間云々の問題じゃないんだけど。
雑魚はウザイから消えてくんない？

**名前は開発中のものです。** · 02/11/03 21:58

>>859
雑魚ってことで妥協するから
君の主張を書いてくれないか。
　
＃喧嘩じゃないだろ。

**名前は開発中のものです。** · 02/11/03 23:29

>>101
少しでもって･･･それってそんなに大仰な話なのか？
モジュール化について深く解説した本とか見たことないけど。

**名前は開発中のものです。** · 02/11/03 23:55

>>854
PCH に頻繁に書き換えるヘッダ、特に開発中のゲーム本体のヘッダを
突っ込むのは止めたほうが。フルビルドのときには早くなるけど、PCH
を作るのに時間かかるからインクリメンタルビルドが遅くなる。

俺は PCH には標準ヘッダと boost、それに変更の頻度は低いがプリ
コンパイルしときたいライブラリ関係のヘッダだけ読ませてる。ライ
ブラリは別のプロジェクト (*.dsp) に分離ね。

>>859
> つーか問題はコンパイル時間云々の問題じゃないんだけど。
設計の問題が重要なのは言うまでもないが、規模が大きくなるとファイルの
物理的な依存関係も無視できない要因になる。CPU は速くなったが I/O は
大して速くなってないから。

**名前は開発中のものです。** · 02/11/03 23:55

>>858
いや、windows.h(とMFC関係?)が大きすぎることがコンパイル時間を遅くしている最大の原因だってこと。
Hello Worldをウィンドウに表示するプログラムを作ってもコンパイル行数10万行ってどうよ？ってことで。

＞まずはヘッダファイルの一括インクルードする奴は駄目な奴だと
っていうこというなら、まず、windows.hとかから言うべきだよな。
(まぁ、OSってことで多少は意味合いが違うけど。)

で、pchってのは、そういう文化の上で必然的に生まれたものだって言うことをお忘れなく。

**名前は開発中のものです。** · 02/11/03 23:56

(というのは実はウソ。DOSのQuick C 1.0の時代から、インクリメンタルコンパイルは既に合ったしね。)
(Turbo Cもそういうのがウリだった。)

**名前は開発中のものです。** · 02/11/04 00:00

>>862
それなら、ディスクキャッシュに納まる程度なら問題ないという結論になりそうだ。

**名前は開発中のものです。** · 02/11/04 00:32

>>852
ハゲ同。
Delphiなら10万行くらいの再構築は10秒くらいで終わるし。

久々にVC++やgcc使って思うのはコンパイル遅いことだ
もうBorland製以外にはもどれん

**名前は開発中のものです。** · 02/11/04 00:32

>>865
充分なメモリを積んでもPCHにしたほうが速いよ。

ヘッダがいくら大量になろうと、PCHはほぼ一定の速度にしてしまうから
これの優秀さにコンパイラベンダは気づくべき。

**名前は開発中のものです。** · 02/11/04 00:37

>>867
プリコンパイル済みヘッダは、CodeWarriorにはたしかあるはず。
gccも3以降に動きがあると聞いたが...違うかも

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

なんでMSやBorlandが10年近くも前に実現してたpchが、
GCCにはないんだぁー！！

by PS2 プログラマー（GCCユーザー）

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

PS2のヘッダファイルもそんなに膨大な量あるの？
というか、G++のコンパイルの遅さ自体が問題なのかな。

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

>>861
ソフトウェア工学の薄くて高い本を読むと
構造化技法、モジュール強度やモジュール結合度について
6 ページくらいは書いてあるよ。

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

>>861
CODE COMPLETE と Writing Solid Code をセットでどうぞ。

>>870
PS2 標準のヘッダはまったく問題ない程度の量。ただ C++ で template を
多用し出すと、ちと気になるかな。（いろんな意味で）

**名前は開発中のものです。** · 02/11/04 23:35

>>872
　プロジェクト規模しだいでは「ちょっと」の領域は超えちゃうなぁ。
あと、一本上げて解ったんだけど、テンプレートはあんまりメモリに
優しくないので、中規模以上のプロジェクトではあんまり多用しない方が
いいような気がした。皆のトコではどーなんだろ？

どうでもいいけど、あんまりOOと関係ない流れだね。

**名前は開発中のものです。** · 02/11/04 23:50

この板だと「終了とゲームプログラミング」って感じだよな～

**名前は開発中のものです。** · 02/11/04 23:53

>>874　どうぞこちらへ
http://game.2ch.net/test/read.cgi/gamedev/1011082291/

**あぼーん** · NG

あぼーん

**逝って良しの１** ◆.CzKQna1OU · 02/11/05 00:00

test

**逝って良しの１** ◆MvRbZL6NeQ · 02/11/05 00:02

結論：
１）再利用可能モジュール以外は手続き型で書く
２）なるべく共通の部品て作れるように設計する。

純ＯＯは効率落とすだけ

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

ム板にお帰りください。

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

とりあえずOOを理解しているやつがすくないってのはわかるね。
まあ結構苦労すると思うよ。なめてかかると。
概念に関しての勉強ってサボルやつが多いからなー。
生まれてから一度も考えたことありませんでした。ってやついるだろ？
だからわかるやつとわからないやつとで差がでかいんだろうね。

**あぼーん** · NG

あぼーん

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

なんとなくage

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

PCH は GCC では3.4からなり。

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

　なー、職業ゲームPGの諸君。おまいらの会社ではテンプレートは活発に
使ってますか？仕事にマイテンプレート集を導入したいのだが、周りは
テンプレートと聞いただけで拒絶反応。「テンプレートは何をやってるか
解からんからイヤ」っておまいら…。

**名前は開発中のものです。** · 03/01/29 03:43

>>884
ピンきりだろうに。STL解析しろて訳じゃないんでしょ？

慣れないとちと読みづらいからね。
後、メモリ使用量が。速度的には良いんだが。

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

Loki を使いたいと言われたら、それはいかがなものかと思う

**あぼーん** · NG

あぼーん

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

STLのないC++なんて、もぅ耐えられないかも。

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

　お、皆さんとこもテンプレートモリモリ系ですか？やっぱ強引に社員教育
して導入するべきですかね。メモリ使用量はアロケータを工夫する事でなん
とかなるんだけど、コード増加量を理由に拒絶されるとどーにもこーにも。

　STLのメモリパフォーマンスについての資料ってどっかにないもんかなぁ。

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

結果的に同じコードになっても、型が違うっちゅうことで
それぞれ別ルーチンになっちゃうのが痛いね。

VC6はそこそこ最適化してたな。
どういう仕組みかしらんが、中身がまったく同じルーチンは一つに
まとめてくれてたようだ。

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

コード量のほうはマップファイル見てたらわかったりしない？
ピンチになったら、いらなさそうな（ポインタ絡みが多いな）奴を探して
特殊化で切っていくとかできる。

あぁ、でも、最適化できってくれるのが理想だよな。
同じテンプレートから生成されたコードを
バイナリコンペアで判定して、まったく同じのを消せばいい、と思うんだけど。

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

そーなんよねー。テンプレートのコードサイズ最適化に関する情報がどこにも
ないからね。プロジェクト末期にコードサイズが５M超えましたとかじゃ怖くて
使えないよな。

まぁマイクロソフトはともかく、GCCやCWに最適化の過度の期待は禁物だしな。

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

インライン化の程度によっては増えたり減ったりするのがなんとも・・・

昔、ポインタのコンテナクラスは、void* のコンテナクラスを作って
それをラッピングしてたじゃないですか。
そういう手間が省けないかなあ、とか。

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

ふむ・・・
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 ); }
・・・
};
とか。
イテレータとか使えなくなるのはイタイか。

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

>>894
template< typename T > class std::vecotr< T* > がほしーなー。
STLportで定義しといてくれたりすると泣いて喜ぶんだが。
そんな話ねーのかなー？

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

こんな情報はいかが？

http://adult.misty.ne.jp/rank/enter.cgi?id=fdeai

**名前は開発中のものです。** · 03/02/02 13:11

　いや、実際テンプレートで消費するメモリリソースなんかたかが知れて
るんだけどなー。sizeofみたいにコードサイズを取得する演算子がほしいな。
sizeofcode( template<T> );
って感じの。演算子じゃなくてもコンパイラの機能でいいんだけど。

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

コード量の削減で思いついたんだけどさ、
リンク時に中身が同じなら一緒にするってことできないかな？
サイズとCRCをフラグメント(関数?)ごとに記録しておいて、
それらが一致したらシンボルをまとめちゃうの。

win32ならゲイツパワーでできそうだけど、
unix系では辛いかな・・・

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

質問ですが、
オブジェクトをCreate()で作成して、Release()で開放する
考え方？スタイル？をなんて言うんでしたっけ？

**名前は開発中のものです。** · 03/02/02 23:55

ところで
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;
}
みたいになるのかなと？

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

>>900
それならインスタンスの型が分かっているので展開可能。

main(){}でいいのに、なんでvoidなんて書くんだ？煽られるだけだぞ。

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

>>899
ファクトリーパターンか？

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 03/02/03 11:36

>>901 可能は可能だけど、
実際にそれをやっているコンパイラがどの程度あるかは
微妙な気がするな。アセンブラコード出して確認するのがいいよ。

**899** · 03/02/03 17:09

>>902
ファクトリーパターンって言うんですか。
C++覚えたての時、自分で試行錯誤していてこのパターンを思いついたんですよ。
実際にこういうスタイルがあると知ったのは、最近の事です。
なんという名前だったのか思い出せなかったもので。

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

うそ教えちゃ遺憾
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

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

あながち間違いでもないと思うが・・・
ファクトリの実装方法の一部、とでも言ったほうがいいのか？

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

別に create() で作るとだけ言われても、
Factory パターンかもしれないし Prototype パターンかもしれないし他のパターンかもしれない

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

他に何が考えられる？

**899** · 03/02/04 01:03

えーと、意味不明かもしれないんですが・・

(図1)
　　 A
　　 |
　|--|--|
　B C D

僕が考えたのは、上の(図1)見たいな構造になってます。
Aは B C Dを内部で、配列やリストなどで管理してます。
Aは B C Dのインスタンス作成メソッドを持ちます(CreateB(B*)みたいな感じ)。
Aのデストラクタで B C Dのインスタンスの開放or終了処理が行われます。

こんな感じです。
具体的なパターン名がありますか？

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

GOF本には載ってないのう
こっちで聞いてください
http://pc2.2ch.net/test/read.cgi/tech/994836140/

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

B,C,Dが共通のインターフェースを持つ？

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

>B,C,Dが共通のインターフェースを持つ？
ちょっと、よく分かりませんが、
すべてのインスタンスを A で管理しているので、
A->Release() ですべて delete 出来て良いかなと思って実装しました。

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

　>>902　は　ネ　タ

**名前は開発中のものです。** · 03/02/04 02:25

　つーかファクトリメソッドパターンだな、それは。微妙に違う気もするが。
ファクトリメソッドパターン＋コンポジットパターンって感じか。

class cHogeManager{
friend class cHoge;
public:
cHoge* Create(...);
};

class cHoge{
privet:
cHoge(...);
};

こーやってcHogeのcreate以外でcHoge生成出来なくなくしたりは良くするね。

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

friendの場所が違うような・・・

あとこのやり方？はいわゆる「ハンドル」だと思ったが、
何かパターンとして命名されてるの？

**名前は開発中のものです。** · 03/02/04 11:24

ファクトリメソッドパターン
コンポジットパターン
ハンドル
・・・どれも関係ないと思うんだが。
あー全部ネタか？

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

コンポジションの関係にある、というだけ。