トップページ⇒gamedev
1001コメント390KB

ゲームにおけるデータ構造・クラス設計・パターン

■ このスレッドは過去ログ倉庫に格納されています
0001名前は開発中のものです。2006/08/10(木) 20:27:06ID:BnvyxuCB
具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。
0376名前は開発中のものです。2007/05/24(木) 00:19:50ID:4PByfCCv
>>375
画像処理のことなのか?
まぁ、半透明使うならZソートしといたほうがいいけど

>>368はハッシュとかツリーとか勉強するといいかも
0377名前は開発中のものです。2007/05/24(木) 14:14:16ID:MN3OTeQA
>>375
3Dのシーンならそれでいいんですけど、
2D主体で、アルファ付きテクスチャ描画が標準、
アルファブレンドを使うのが当たり前、加算合成などが多めになると、
Zバッファが使えなくないですか？

俺、もしかしたら、基本的なところで、ミスってる？('A`)

>>373
毎フレーム、オブジェクトを数千個ソートするのもそんなには重くはないですけどね。

>>374
実は、昔から(DirectDrawの時代)から使ってるんですが、
使いどころ間違ってるのあｋ−−−−−マジ教えてくれ

>>376
そうです。半透明が多めなんです。

Hashとかﾂﾘｰは普通に使います。OTの実装もHashと同じですし
0378名前は開発中のものです。2007/05/24(木) 15:21:37ID:4PByfCCv
hashとかわかってるならなんでそんなことをココに書き込むのだと小一時間問い詰めたい
0379名前は開発中のものです。2007/05/24(木) 15:43:03ID:a3uG9+mx
・２D主体かつαブレンドを多用
・z値が整数で適当な範囲に収まる場合
ならその方法がいいのかもね
でもゲームによってやり方を変えるのが一番賢いだろうね
0380名前は開発中のものです。2007/05/24(木) 16:17:32ID:aFaY4/D0
>378
最初にネタふりって書いてあるやん
0381名前は開発中のものです。2007/05/24(木) 16:34:16ID:uojugi7P
っていうか、2Dのスプライトの場合はZオーダーなんてそう頻繁に
入れ替わるものではないから、前フレームのソート結果を上手く利用すれば、
もっと軽くできると思う。
0382名前は開発中のものです。2007/05/24(木) 16:58:41ID:FtXKITOW
このスレの90％はネタを振る人間とそれにケチをつける人間でできています
0383名前は開発中のものです。2007/05/24(木) 20:02:03ID:K0O2WDIn
>>382
残りの10%は？
0384名前は開発中のものです。2007/05/24(木) 20:07:39ID:KUhBCX3E
ROM
0385名前は開発中のものです。2007/06/04(月) 17:52:58ID:wXEt1jZx
ROMはいくらいても0%だろう
0386名前は開発中のものです。2007/06/12(火) 16:35:34ID:KXWIMOSu
同人の俺は気にするほどのゲーム作らないからなー。
後から基数ソートやらに書き換えるつもりでSTLのsortでZソートしたけど
どこにも問題ないのでそのままリリースしたよ。めっちゃ富豪的
0387名前は開発中のものです。2007/06/12(火) 20:19:56ID:mHZMnLTI
>>386
PS2 でも、そんなもんでした。STLport にお任せ。
0388名前は開発中のものです。2007/06/18(月) 14:54:09ID:oOcxT9uX
コールバックってどういうときに使うんですか？
タスクシステム(というかハンドラオブジェクト)を使う時の場合において適当な例を教えてください
0389名前は開発中のものです。2007/06/18(月) 15:00:56ID:2wNoPL2v
コールバックする時。

タスクシステムに限らず、メモリの解放を行ってもらうときとか、
進展情報を表示する時によく使うなあ。

とくに前者の場合は、他の開発環境で作ったDLL内でメモリを解放したいときとか。
0390名前は開発中のものです。2007/06/18(月) 16:26:41ID:1gQkyo9F
>>388
オブザーバーパターンは便利だよ。
たとえば敵を倒したときにそいつのはいた弾をすべて消すとか、誘導弾のつけなおしとか
なれてくるとほとんどこれだけでイベントベースでコードが出来上がる。
0391名前は開発中のものです。2007/06/18(月) 20:21:44ID:nIlBSYV8
タイミングが判明する場所と、そのとき行いたい処理との間の結合を
疎にしたいとき使います。
ほとんどこれだけでとか関係なし。必要なところへ必要なだけ使うべし。
0392名前は開発中のものです。2007/06/19(火) 02:59:21ID:cFac+yZB
>>388
C時代のコードを利用するとき。
C++使えるんならほとんどのコールバックが仮想関数で見た目上は消せるだろう。

つまり仮想関数をCで使いたいときにコールバックが出てくる。
0393名前は開発中のものです。2007/06/19(火) 05:07:59ID:AmvqVn7S
>>392
あとは、スクリプト言語との連携とか。
0394名前は開発中のものです。2007/06/22(金) 08:30:52ID:njuyTnq1
Xboxのアレは禁断のボゴソートを使ったとしか思えない
0395名前は開発中のものです。2007/06/22(金) 15:30:47ID:G4eFb+Vh
>>395
Xboxのアレって何ですか？
0396名前は開発中のものです。2007/06/22(金) 17:18:36ID:vqNTOWGn
カルドセプトサーガの事じゃないの？
0397名前は開発中のものです。2007/06/22(金) 20:36:17ID:OntiNUWq
そのタイトル名でググってみたが、これは酷いなw
サイコロが奇数と偶数が交互に出るとかw
0398名前は開発中のものです。2007/06/22(金) 22:02:44ID:qN22ntrp
>>394
ボゴソートって知らなかった。
ttp://ja.wikipedia.org/wiki/%E3%83%9C%E3%82%B4%E3%82%BD%E3%83%BC%E3%83%88

これはひどいあるごりずむ
0399名前は開発中のものです。2007/06/22(金) 22:21:08ID:VTeo1nmT
>>398
これ逆にコーディングの手間がかかるだろｗ
0400名前は開発中のものです。2007/06/22(金) 22:22:42ID:+XVLd04M
＞ボゴソートは、ソートのアルゴリズムの一つ。
＞平均的な計算時間はO(n×n!)で、非常に効率の悪いアルゴリズムとして知られている。
＞安定ソートではない。

最後の一行のオチで吹いたｗ
0401名前は開発中のものです。2007/06/22(金) 22:28:33ID:0YS4QSdj
ここでボゴソートを使ったゲームを考えるのがゲームプログラマの努・・・ごめん無理
0402名前は開発中のものです。2007/06/23(土) 00:06:58ID:WPiear32
ボゴソートﾜﾛﾀｗ
0403名前は開発中のものです。2007/06/24(日) 05:25:19ID:zQnoyhbz
ﾜﾗﾀ
ソートつーか、バラバラに並び変えるアルゴリズムかとｗ
0404名前は開発中のものです。2007/06/24(日) 11:16:29ID:1MtSzEPe
>>400
安定ソートの意味知ってるのかよ('ω`)
0405名前は開発中のものです。2007/06/24(日) 11:33:03ID:NLW3QANP
>>404
安定ソートの意味知ってるのかよ('ω`)
0406名前は開発中のものです。2007/06/24(日) 11:35:30ID:rfvCjIOU
>>404-405
知らないよ！（ﾟДﾟ）
0407名前は開発中のものです。2007/06/24(日) 11:54:44ID:nOj+/xcZ
>>404-405
知らないよ！（ﾟДﾟ）
0408名前は開発中のものです。2007/06/25(月) 03:07:29ID:qVqBESx6
えーっと、同じ順位のアイテム同士はソート前の順番を保つ、であってる？
0409名前は開発中のものです。2007/06/25(月) 09:30:06ID:mc9m8oVn
あってる。
この記事のオチはInfinite monkey theoremだよ。ググレ、笑うから。
0410名前は開発中のものです。2007/06/25(月) 10:06:14ID:U5o2CqSM
セットで RFC2795 もどーぞ。
http://www.ietf.org/rfc/rfc2795.txt
0411名前は開発中のものです。2007/06/25(月) 20:59:14ID:NaYhg1aV
>>394-410
スレ違い
0412名前は開発中のものです。2007/06/25(月) 21:35:29ID:933SMbqm
>>411
既存のゲームにおけるパターンの一端って事で
0413名前は開発中のものです。2007/07/17(火) 22:54:23ID:Mh0Ht4Or
このスレ生きてますか？
基本的？なデータの扱いについて意見を聞きたいです

データに対応する操作クラス以外から値を書き換えることを禁止するためにこういうクラスを考えました
template <typename T> class IData {
public:
　　friend class Mutator<T>;
　　typedef T element_type;
　　typedef boost::shared_ptr< element_type > value_type;
protected:
　　value_type value;
};

template <typename T> class IMutator : public IData<T> {
　　typedef IData<T> data_type;
protected:
　　void assign(data_type& target) { value = target.value; }
　　void swap(data_type& target) { boost::swap(value, target.value); }
};
使う際はこいつを継承して
class CData : public IData<int> {};
class CMutator : public IMutator<int> {};
のようにすれば
CMutatorはIMutatorのassignやswapを使ってCDataのvalueの指すデータを生成から破壊まで自由に扱えるわけです

でもこのようにするとCDataの持つ情報が増えた時に
class CData : public IData<Param>, IData<Graphic>, IData<Sound>のように
継承しまくりになることとか、shared_ptrの機能によるコストが気になったりします

そこでもっと一般的なやり方を知りたいんですが何か良い方法ありませんかね？
0414名前は開発中のものです。2007/07/17(火) 23:05:36ID:oI0Vf9iA
template <typename T> class IData {
public:
　boost::shared_ptr<T> value;　　//!< 漏れ以外勝手に書き換えんなよ！
};
0415名前は開発中のものです。2007/07/17(火) 23:19:26ID:Mh0Ht4Or
いくら防衛策を巡らせても書く人の意思でいくらでも変えられるから
そんな事考えるのは無駄だよってことですか
言われてみればそういう気もしますが…(´・ω・`)
0416名前は開発中のものです。2007/07/17(火) 23:29:43ID:9lPCzUGd
多重継承にパフォーマンス(速度・容量の両面で)上の弊害は無いが
役割が酷似した基底(インターフェース)同士を多重継承って嫌過ぎだろ。常考。
衝突避けるためにインターフェース設計の段階でお互い調整しなくちゃいかんし
衝突上等ならキャストだらけの汚ねぇコードになる。俺ならコンポジットにする




0417名前は開発中のものです。2007/07/17(火) 23:32:47ID:ecw8MgBR
いまいち要求が飲みこめんけど、委譲とかプロキシパターンとか
アダプタパターンとか、ありもののパターンで十分間に合いそうな希ガス。

経験上、複雑な仕組みはロクなことがない。
Keep it simple stupidですよ。

苦労して得られる利益が少なくて割が合わないパターンでは？
0418名前は開発中のものです。2007/07/18(水) 00:07:21ID:xDBgIMCC
どうも
よく考えたらIDataはインターフェースじゃないっすね…
全く異なる型を同士でコンポジットにしてアクセスも上手く制限できる事って出来るんでしょうか

要求としては
・データと動作を分離する事と
・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること
・書き込み専用のクラス以外からのアクセスを制限する事
です

操作されるデータの実体へのポインタを持つIDataと、それを扱うインターフェースIMutatorに分けたのは一番目のため
多重継承したCData経由でデータを扱うのは2番目を実現するため
データの実体へのポインタであるIDataのvalueメンバをprotectedにし
Mutatorをフレンドにしたのは三番目の為

以上によってゲーム内でのオブジェクトの振舞いは全てIMutator派生クラスのCDataに対しての操作として
書くことが出来て、リソースの確保等のシステム的な動作は外部に一任できる

という意図があったんですが、そんなに複雑ですかいね？
0419名前は開発中のものです。2007/07/18(水) 00:28:49ID:JHo6PQLB
・データと動作を分離する事と
・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること
・書き込み専用のクラス以外からのアクセスを制限する事

つまりテンプレートで実装する意味はないよね？
0420名前は開発中のものです。2007/07/18(水) 00:37:53ID:9FpPIZ4u
>>419
ないね
0421名前は開発中のものです。2007/07/18(水) 00:57:12ID:IHWjkDA2
> ・書き込み専用のクラス以外からのアクセスを制限する事

IMutatorを継承すればどんなクラス以外からでもアクセスできる以上、
制限できてるとは言いがたい。

「IMutatorの継承を無闇にするな」と、文書で説明する？
ならば、414でいいでしょ。
0422名前は開発中のものです。2007/07/18(水) 02:48:50ID:vN51PGaN
>>418
> ・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること

「データ」と「ゲーム上のオブジェクト」の違いがよくわかりません。
「動作を〜に対して書ける」ってのもよくわかりません。
「〜を引数とする関数を書くことができる」ってことでしょうか？
0423名前は開発中のものです。2007/07/18(水) 05:52:53ID:1k3Xg7ZP
なんか奇想天外なことになってるのは
＞・データと動作を分離する事と
これのせいだと思う
誰が吹き込んだんだか知らんがまず>>413がしなきゃいけないことはこいつを殺すことだ
0424名前は開発中のものです。2007/07/18(水) 18:10:13ID:sTmzL7Mk
class CData : public IData<Param>, IData<Graphic>, IData<Sound> {};

こうすると、CData::valueの型は何になるの？
04254132007/07/18(水) 19:28:34ID:xDBgIMCC
>>419,>>420
>つまりテンプレートで実装する意味は無いよね
恐らく既存の構造体を利用するためにこうした筈なんですが
普通にそれらをCDataにスマポで持たせた方がいいじゃんじゃんな気もしてきました

>>421
おっしゃるとおりです
細かいところにとらわれて本質を見失うという悪い例を晒してしまいました…

>>422
>「〜を引数とする関数を書くことができる」ってことでしょうか？
そうです
キャラクタの移動や描画の際は、リソースのハンドラを移動クラスや描画クラスに渡すんでなく
CDataを渡すような形で書きたいわけです

>>423
なんかキャラクタのクラスに座標構造体と移動メソッドを定義してたソースを友人に見せると
値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてるんですが
何か思い違いをしてますか…と問うまでもなく明らかにしてますね

>>424
晒したコードでは見事に多重定義のエラーになりました
実際はそれ避けたり多重定義されたIDataのvalueを内部で扱うためにboost::mplとか使って
さらに複雑な事やってるんですが>>417氏の言ってる事に繋がりますね

とりあえず苦労して作った車輪は最発明どころかガラクタですらないナニカだったというオチでした
もっかい一から作り直してみますm(＿ ＿)m
0426名前は開発中のものです。2007/07/18(水) 20:55:21ID:ux1Fssbs
>>425
> 値を保持するクラスと操作するクラスは分けろこのスカポンタン
インターフェースと実装を分離するのは一般論としては間違いじゃないが、粒度が違う。
メンバ変数単位ではなく、意味のあるメンバ変数のセットをインターフェースにしろって
意味だと思うよ。


// 衝突判定後に、消灯判定マネージャから衝突回避のために位置をずらされる
struct IMovable {
　// 現在位置
　virtual void getPosCur(VECTOR3* p) const = 0;
　// 移動したい位置
　virtual void getPosNext(VECTOR3* p) const = 0;
　// 衝突しないようにマネージャがずらした位置
　virtual void setPos(VECTOR3 const& v) = 0;
};

class Player : public IMovable { ... };

class CollisionManager { /* こいつは IMovable だけ使用 */ };

こういう話かと。
0427名前は開発中のものです。2007/07/18(水) 20:55:52ID:ux1Fssbs
>>426
s/メンバ変数のセット/メンバ関数のセット/g
0428名前は開発中のものです。2007/07/18(水) 23:49:47ID:1k3Xg7ZP
>>425
＞値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてる
なんでそうしなくちゃいけないか理由は分からないの？
プログラムは芸術じゃないんだから外の人のどうしたこうしたで中身が変わったりしないよ？
0429名前は開発中のものです。2007/07/19(木) 00:19:41ID:RaZNmmmq
> 値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてるんですが

つかこれ自体間違いだろ。
0430名前は開発中のものです。2007/07/19(木) 00:38:54ID:PDuVn1ka
>>429
だよな多分
0431名前は開発中のものです。2007/07/19(木) 05:21:01ID:5YEt12VO
getterとsetter作って、アクセス管理するくらいしかやったことねえや
触らせたくないなら、関連クラスからのみアクセスとか（C++ならfriend？）

それ以上ってコストかかりすぎねえ？
0432名前は開発中のものです。2007/07/19(木) 11:40:10ID:LxxDZCLh
少人数・小規模製作でアクセス制限も糞もないわな
0433名前は開発中のものです。2007/07/19(木) 15:01:29ID:3ArgKadV
少人数小規模だろうが、
開発期間中に、年単位で空白があったコードを読むこともあるわけで。

そういう場合は、アクセス権は考えといて損はねーですがよ。
0434名前は開発中のものです。2007/07/19(木) 18:50:40ID:TacCeKvZ
アクセス権？になってくるとまた話が変わってきちゃうんだが
そんなファイルのパーミッションみたいな機構小規模だろうが大規模だろうがつけたらあかん
というか無駄、損がないというか何の得もない
0435名前は開発中のものです。2007/07/19(木) 18:59:00ID:ajveBJeZ
とりあえず理由を
0436名前は開発中のものです。2007/07/19(木) 19:27:00ID:3ArgKadV
なんでファイルのパーミッションの話になってるんだ
>>432のアクセス制限って、クラスのメンバーに対することで、
>>433のアクセス権ってのもそのことだろ？
04374362007/07/19(木) 19:27:51ID:3ArgKadV
変な日本語になった

正しくは、
なんでファイルのパーミッションの話になってるんだ
>>433のアクセス権って、クラスのメンバーに対することで、
>>432のアクセス制限ってのもそのことだろ？
0438名前は開発中のものです。2007/07/19(木) 19:39:53ID:/RFbeqQb
「使いたいものを使いたいときに即使えないのはうっとうしい」
ということではなかろうか＞ファイルシステムの例え話

個人管理のLinuxなんかだと、最初からrootでログインして使う人もいるくらいだから
それはそれで別に当人の自由だと思う。


要はアクセス権限を分ける方がトクか分けない方がトクかは
ケースバイケースで判断すればいいってことだけど
0439名前は開発中のものです。2007/07/19(木) 20:12:33ID:TacCeKvZ
＞なんでファイルのパーミッションの話になってるんだ
おまえがアクセス権なんていうからじゃん
0440名前は開発中のものです。2007/07/20(金) 12:39:13ID:vUDuhb3O
スレタイを百回声に出して読んでくれ
0441名前は開発中のものです。2007/07/20(金) 12:40:51ID:vUDuhb3O
ついでに二人とも正座な
0442名前は開発中のものです。2007/07/20(金) 21:52:02ID:+3gqdIHH
難しく考えすぎ。

他のオブジェクトにアクセスして欲しくないメンバは
クラスの中に隠蔽して、プライベートメンバにしておくのがセオリーでは。
アクセス権ってのは本来そうやってコントロールする。

外からオブジェクトにアクセスできるようにしておきながら
アクセスできないように制限する仕組みを作るってのがナンセンス。

0443名前は開発中のものです。2007/07/20(金) 22:07:32ID:lyxTTGt6
「する」「しない」の二択にするという話ならその通りだが
特定の状況でのみ●●に大して××させることを許可するとかいう話なら
ソースレベルで静的に操作するのは困難
0444名前は開発中のものです。2007/07/20(金) 22:32:40ID:+3gqdIHH
動的にアクセス権を与えたいなら、まずは隠蔽しておいて、
状態に応じてアクセスを許すかどうかを決めればいいのでは。
0445名前は開発中のものです。2007/07/20(金) 22:52:28ID:+3gqdIHH
本当にアクセス制御の問題で困っている人が大勢いるなら、
今頃boostにそれらしいクラスが含まれていると思うけどね。

例えばnoncopyableはオブジェクトのコピーを禁止するクラス。
こんなレベルのものでも有用さが認められればboostに仲間入りできる。
http://www.kmonos.net/alang/boost/classes/noncopyable.html

でも今現在boostにアクセス権制御のクラスがないってことは、
需要がないってことでは？

まずはプライベートメンバを使ったシンプルな隠蔽によるアクセス制御で
どこまでできるのか突き詰めてみた方がいいでしょ。
今のところ自分はそれで困ったことはないけどね…。
0446名前は開発中のものです。2007/07/21(土) 00:49:20ID:DMrsrXyJ
ナンセンス。この一語に尽きる。
0447名前は開発中のものです。2007/07/21(土) 01:16:04ID:oWQ5iQEX
progress_displayがあるのにそんなこと言われても説得力無いなぁ

動的にアクセス権決めるならgetter,setterを隠蔽してfunction使ってアクセス権を与えたいクラスに
そのgetter,setterを与えてやるって方法もあるけど
functionは1個で40bytes近く食う割と重たい(？)オブジェクトだから無茶かな、無茶だな
0448名前は開発中のものです。2007/07/21(土) 03:00:31ID:DMrsrXyJ
動的ってことになってくるとそれは普通にインターフェイス呼び出し時の
認証の機能の話になってしまうんじゃ？RMIとかそーいった話の流れ方向での

静的だと外側の構造も知らん一クラスごときが誰に使われるのが良いだ悪いだ
決めるとか何いい気になってんだって話だ

>>443
＞静的に操作するのは困難
困難どうこうより、そのポリシーを決める根拠をどこにも求められないということだよ
適当に決めてしまえば後で直せなくなる
根拠がどこにもないから

0449名前は開発中のものです。2007/07/22(日) 02:55:07ID:/VC165Eo
>>443
インターフェースを多重継承して、必要な時・相手にアップキャストしたものを渡せば。
0450名前は開発中のものです。2007/07/22(日) 03:36:44ID:jrExVTdK
簡単な具体例も挙げてくださいお願いします
0451名前は開発中のものです。2007/07/22(日) 13:24:51ID:/VC165Eo
>>450
struct IFoo { virtual Vec3 getPos(); const = 0; };
struct IBar { virtual setPos(Vec3 const& pos) = 0; };
class CPlayer : IFoo, IBar { ... };

f1(IFoo&);
f2(IBar&);

CPlayer player;
f1(player); // f1には getPos() しかさせない
f2(player); // f2には setPos() でメンバ変数書き換えを許可
0452名前は開発中のものです。2007/07/22(日) 15:08:54ID:PSHVXCKb
>>447
functionって40byteも食うの？
その半分くらいですみそうなんだけどな。
0453名前は開発中のものです。2007/07/22(日) 18:59:44ID:jrExVTdK
なるほど、呼び出す側にインターフェースを渡すんですね
参考になりましたありがとうございます。
0454名前は開発中のものです。2007/08/05(日) 01:30:04ID:CiKwXSKt
boost::functionって便利だけどむちゃくちゃヒープが汚くなりそう
0455名前は開発中のものです。2007/08/05(日) 07:10:10ID:4IAfjfpf
>>454
小さなオブジェクトが多数 new されそうって意味？　気にしなさんな。
0456名前は開発中のものです。2007/08/05(日) 07:37:18ID:CiKwXSKt
まあ、それが気になって使ってない、という訳じゃないけどねえ。
アロケータ作れば何とかなるだろうし。
0457名前は開発中のものです。2007/08/05(日) 20:35:16ID:ki20ixME
javaでTCBを使いたいんだけど、どうしてる？
0458名前は開発中のものです。2007/08/05(日) 20:46:45ID:4IAfjfpf
>>457
ふつーにメンバ変数使えばいいだけでは？　Task Control Block なんてのは、アセンブリ時代の名残だから、
C++, Java あたりでは使わんでしょ。
0459名前は開発中のものです。2007/08/06(月) 00:04:42ID:Mz0XA0lP
ゲームのデータを独自のフォーマットとかにする場合にヘッダを用意する？
04604572007/08/06(月) 00:40:04ID:wjb80OI1
http://ueno.cool.ne.jp/dinna/topic/task.htm
こんな感じに組みたいんだけど、javaには関数ポインタがないので、引っかかり中。
0461名前は開発中のものです。2007/08/06(月) 00:44:36ID:N/EWx1nS
>>460
まじめに勉強したら？
0462名前は開発中のものです。2007/08/06(月) 00:45:37ID:N/EWx1nS
というかあからさますぎて夜釣りに思えてきた
0463名前は開発中のものです。2007/08/06(月) 02:03:36ID:dDj8AjaH
TCBと言えばRTOSなので
ここはeCosに実装されたwabaを紹介してやるのが筋だろうか
0464名前は開発中のものです。2007/08/06(月) 03:43:57ID:r8MqGT/t
ppc arm super wabaなら・・・
0465名前は開発中のものです。2007/08/06(月) 07:16:51ID:R+5scQVe
>>460
Java だとインターフェースもしくは抽象基底クラス使う。
0466457,4602007/08/06(月) 22:38:48ID:dCjdYchV
aを規定クラスにしたb1タスク
aを規定クラスにしたb2タスク
b1、b2タスクが混在したリストを作成したい。
C/C++なんかだと、関数ポインタnextなどにタスクをつなげてゆけるところだが・・・
javaだと関数ポインタがないので、配列にしてインデックス参照にするしかないのだろうか？
インデックス参照だと、個々のタスクごとに属性を割り振って、別々に読み出すか32bit以内に押し込むかなどして値を管理し、switchで分岐
して実行する記述が必要・・・。
C++なら多重継承があるので、b1からb2にたどることもも可能だが、javaには多重継承はないし・・・。
インターフェースは同じインプリメントを保障してくれるだけど、結局タスク切り替えのロジックが必要になるし・・・。
関数ポインタに比べて、これだと積極的に使うにはオーバーヘッドが気になるのと、記述が煩雑でプログラム的にCより退化しているように感じてしまう。
（今はリスト構造にせず、配列でタスクリストを持つ方向性で考慮中・・）
0467457,4602007/08/06(月) 22:41:30ID:dCjdYchV
だれか経験豊かなjavaプログラマた通りかかったりしないかなぁ。
0468名前は開発中のものです。2007/08/07(火) 00:03:46ID:ziyaQFb3
Vectorじゃだめなのか
0469名前は開発中のものです。2007/08/07(火) 00:17:53ID:2nrPyfF8
やはり釣りだったか
0470名前は開発中のものです。2007/08/07(火) 00:42:53ID:lyE3j1c/
HSPでOOPをやろうとするのと同じくらい馬鹿げてるな
0471名前は開発中のものです。2007/08/07(火) 01:25:29ID:/sDbVbxZ
>>466
ぐちゃぐちゃ言ってないで書いてみろ。あんまりにも考察がめちゃくちゃで
どこから突っ込んでいいのかわからん。ソース晒してみれば突っ込みも入れやすい。
0472名前は開発中のものです。2007/08/07(火) 01:55:24ID:sukzLC0P
>>466
日本語でおｋ
0473名前は開発中のものです。2007/08/07(火) 03:33:11ID:jZSDWWPE
>>466
参照使え馬鹿
0474名前は開発中のものです。2007/08/07(火) 03:37:03ID:Qoe4Y4zA
なんでみんな冷たいんだｗｗｗ
0475名前は開発中のものです。2007/08/07(火) 06:44:09ID:vUw1LN3Q
>>468
LinkedList の方が。
■ このスレッドは過去ログ倉庫に格納されています