- 手打ちでドキュメントを作るのは大変なのでdoxygenを使おうかと思っています。
http://www.doxygen.jp/
ただ、このwikiに公開する方法がなく、コメントの形式もだいぶ変わってしまうので、
ちょっと迷ってます。何か良いアイデアはないでしょうか？
-- (rei) 2009-04-13 07:03:07
- コンテナ選びで困っているのが指摘された点です。
map_ptrでどこから参照されるか分からないと、
参照先が既にdeleteされている可能性がある、ということですね。
現在想定しているのは、
・最初に静的タスクリストを生成する
・シーンの切り替え時に動的タスクリストの削除、生成を行う。
・あるタスクがキー(文字列)で他のタスクを参照できるのは静的タスクリストと、
同一シーンの動的タスクリスト内のもののみ。
・全てのシーン削除後に静的タスクリストを削除する。
この条件が変わらないならptr_mapでもdeleteを心配することはないと思います。
あまり良い設計ではないと思いますが。
multi_index
今回のケースで言えば、描画する順番でソートされたものと、
キー検索用に(ハッシュなどで)ソートされたものを同時に持ちたいのです。
もちろんタスクのコピーやソートをすることなく。
-- (rei) 2009-02-21 07:30:01
- ptr～ multi_indexとも参照しました。
紹介ありがとう。
今回のプロジェクトで、
タスクリストの設計をどのようにするか次第だとは思いますが、
mulit_index については、使いどころが想像できずにいます。
あと ptr_map は、
std::map<string , shared_ptr<Task> >
に対するメリットがわかりにくいところではあります。
所有権を完全にタスクリストへ委譲したいというような用件で使うのかな・・？
自機タスクのような、あらゆるタイミングに、あらゆるタスク等々から
参照されるであろうものを考えると、タスクリストの外にもポインタか参照を
持つという構成になるように思うのですが、（いかかがでしょう？）
そうなると、std::map<string, shared_ptr<Task> >が一歩リードのように思います。
紹介されていたサイトにあった、扱いのわずらわしさというのが、
勉強不足のため、よくわからずにいます。
(参照カウントのためのオーバーヘッドは、なんとなくわかります)
-- (yutap) 2009-02-20 22:15:51
- >> 連続したメモリを確保して空いている部分に詰めていく、
>> というのは現実的だと思いますか？
>もしかしたら、誤解をしているかもしれませんが、
>たとえばcharで配列を確保して、あらゆるサイズのインスタンスを詰めて配置するという
>ようなスタンスだとすると無謀だと思います。
>メモリサイズは無駄が多くなりますが、配置するインスタンスの最大サイズを既定して、
>(あえて最大Taskを意味するクラスを作るのも良いと思います)
>× 要素数 で管理するのが良いかと思います。
以前聞いたときは前者を想像していました。
自分で実装するなら、適当なブロックのサイズを決めて、ブロック単位で移動
(各タスクの先頭アドレス＝確保したメモリの先頭アドレス＋ｎ×ブロックサイズ)
といった感じになると思います。
多重継承さえしなければ問題はなさそうです。
でも、やっぱりポインタのリストの方がシンプルで効率も良いように思います。
-- (rei) 2009-02-19 15:52:51
- >できれば、あえてデフォルトを使用しているという旨を記載してもらえると、
>レビューする側としては助かります
コピーコンストラクタ、仮想デストラクタ、代入演算子のことですよね？
(デフォルトコンストラクタも含まれるのでしょうか？)
おそらく、明示的に定義しないのが不自然な場合にはコメントすると思いますが、
全てに、というのは厳しいです。
代わりに、明示的なデフォルトコンストラクタ、デストラクタ、代入演算子はクラスの先頭に置くことにします。
-- (rei) 2009-02-19 14:57:20
- >(ptr_mapなどの)コンテナについて
はっきり言って資料が少ないです。
ptr_～
http://www.kmonos.net/alang/boost/classes/pointer_container.html
multi_index
http://hw001.gate01.com/eggplant/tcf/cpp/boost_multi_index_container.html
Boost C++ Libraries (書籍) にも載ってないです。
-- (rei) 2009-02-19 14:41:53
- > 「(仮想)デストラクタ」の意図
仮想デストラクタ または 非仮想デストラクタの意味です。
> finalもsealedもない中で非ポリモーフィッククラスを想定するのは間違えてますか？
そんなことはないと思います。
言語側でサポートしていないというだけの問題だと思います。
> もうひとつ、結局重要なのは明示的に定義すること自体でなく、その内容なので、
> 注意喚起ではなく「必ず」とするのには抵抗があります。
了解しました。
できれば、あえてデフォルトを使用しているという旨を記載してもらえると、
レビューする側としては助かります。
> 連続したメモリを確保して空いている部分に詰めていく、
> というのは現実的だと思いますか？
もしかしたら、誤解をしているかもしれませんが、
たとえばcharで配列を確保して、あらゆるサイズのインスタンスを詰めて配置するという
ようなスタンスだとすると無謀だと思います。
メモリサイズは無駄が多くなりますが、配置するインスタンスの最大サイズを既定して、
(あえて最大Taskを意味するクラスを作るのも良いと思います)
× 要素数 で管理するのが良いかと思います。
タスクの特定に文字列をキーにするというのは、
コスト面で折り合いがつくかどうか、または命名の問題が少々気になります。
ただ、試みとしては非常に面白いと思うので、是非トライしていただきたいところです。
(ptr_mapなどの)コンテナについて
色々Web検索はしているのですが、なかなか良い情報が手に入らずにいます。
後日、資料を提示していただけるとコメントできるかと思います。
ちなみに 示野の文苑堂にて Effective STLが売っているのを目撃しました。
時間がなかったので、流し読みすらできなかったのですが、
boostのコンテナを想定しているのであれば、必ずしも必要ではないと思います。
薄い書籍のわりに、3200円と高額なので、僕には手が出る気がしません。
(K大学の図書館に、依頼だけはしておきました)
-- (yutap) 2009-02-17 23:32:56
- ところでタスクのコンテナは何がいいんでしょう？
以前、最初に連続したメモリを確保して空いている部分に詰めていく、
みたいな話をしていたように思いますが、それは現実的だと思いますか？
vtblが存在している時点で無謀っぽいですが。
基本的には文字列をキーにしたいので、
ptr_map、unordered_map、multi_index_container
辺りを調べてみましたが、どれも長所と短所があってなかなか決められないです。
ptr_mapは所有権も請負ってくれるらしい。管理が楽そう。
unordered_mapは要素アクセスが速いらしい。
multi_index_containerは多機能。複数のソート順で管理できるらしい。
-- (rei) 2009-02-16 23:15:59
- 「コピーコンストラクタ、仮想デストラクタ、代入演算子のいずれかを
明示的に定義する場合は、可能なら残りの二つも明示的に定義する。」を追加しました。
「可能なら」としたのは例外があるからなのですが、
(「必ず」だと、非ポリモーフィッククラスはコピーコンストラクタも代入演算子も明示的に定義できない)
そのために「(仮想)デストラクタ」となっていたのでしょうか？
だとしたら規約にするなら厳密に、
・仮想デストラクタ→コピーコンストラクタ、代入演算子
・コピーコンストラクタ、代入演算子→(仮想／非仮想)デストラクタ
の方が良い気がします。
別の理由だったらすみません。
「(仮想)デストラクタ」の意図が気になったので。
・・・もしかしてfinalもsealedもない中で非ポリモーフィッククラスを想定するのは間違えてますか？
もうひとつ、結局重要なのは明示的に定義すること自体ではなく、その内容なので、
注意喚起ではなく「必ず」とするのには抵抗があります。
結果的に殆どのケースではコピーコンストラクタ、仮想デストラクタ、
代入演算子は同時に定義されることになる、というのは分かるのですが。
場合によってはコンパイラが生成する最適化されたコピーコンストラクタ、代入演算子を使いたいということもあります。
-- (rei) 2009-02-16 21:21:38
- > コピーコンストラクタと代入演算子は分かるのですが、
> (仮想)デストラクタが含まれているのは何故ですか？
元来はクラスメンバの内容によって、
必要/不必要を検討する必要があるわけですが、
コピーとデストラクタの関係(危険性)を毎回、熟考するのは面倒
なことだと考えます。
書籍：「C++ FAQ-C++ プログラミングをきわめるためのQ&A集」
にてこれらの3つ(ビッグスリーというそうです)の関係について
常に成立する一般解として、先のルールが紹介されています。
-- (yutap) 2009-02-16 11:59:53
- 名前空間内のクラス一覧、クラス内のメンバ一覧を作ってみました。
直すべき点などあれば教えてください。
-- (rei) 2009-02-15 15:16:35
- boost::noncopyableの項目を追加しました。
>・コピーコンストラクタ
>・(仮想)デストラクタ
>・代入演算子
>
>いずれか一つでも 手作業で定義する場合は
>残りの二つを必ず定義する。
コピーコンストラクタと代入演算子は分かるのですが、
(仮想)デストラクタが含まれているのは何故ですか？
-- (rei) 2009-02-15 01:34:06
- クラスのコーディングスタイルについて。
・コピーコンストラクタ
・(仮想)デストラクタ
・代入演算子
いずれか一つでも 手作業で定義する場合は
残りの二つを必ず定義する。
コピーを想定しないクラスは
boost::noncopyable をprivate継承する
(デフォルトに頼るよりprivateと書くほうが良い？？)
というルール付けを提案します。
常に必要性を熟考するよりは、楽でよいかな・・
と思いますので。
-- (yutap) 2009-02-15 00:24:38
- メンバフィールドは全てprivateか、ということですが、
もちろん基本的にはprivateですが、例外もあると思っています。
a. ()演算子のオーバーロードによる関数的使用を前提としたメンバ。
b. インターフェースとしての直接アクセスを優先させたい場合。但し整合性のチェックが不要であること。
c. パフォーマンスの低下が認められる場合。
今思いつくのはこれくらいです。
bには非ポインタ型であること、を追加した方がいいかもしれません。
cのケースはほとんどないと思っています。
非privateのメンバフィールドにはm_を付けないつもりです。
-- (rei) 2009-02-11 18:53:14
- すみません。質問ごと、こちらに移行させてもらいました。
記録を残すのが大事かと思いますので。
「1. コメントに // と /**/ を混ぜる」
混在は良いと思いますが、
用途には区別があったらよいと思います。
・対象によって区別する
・基本は//で コードの一時キャンセルは/* */
といった具合です。
「2. 例外を使用する」
基本的には賛成です。
boost の一部は例外を発生させる以外の選択肢が
ないものも多いように思います。
ゲーム成立のための前提条件のチェック→復帰
は例外機構の方がすっきり書けるように思います。
ゲームループ内でのエラーは、例外を使っても良い
とは思いますが、基本的に全て停止させてしまう
べきであるように思います。
「3. デフォルト引数を使用する」
否定派です。
オーバーロードで対応すべきだと思っています。
boostの名前つき引数機構(名前忘れた)は
良いと思っています。
「4. ファイル名は小文字で始める」
賛成です。
「5. 名前空間は小文字で始める」
賛成です。
「6. 型名は大文字で始める」
賛成です。
「7-1. メンバ(フィールド)はm_から始める」
賛成です。引数名と かぶるケースが多いので。
ところで、メンバフィールドは全てprivateなのでしょうか？
一般にはそれが正しいと思いますが、
ゲームの場合はパフォーマンスの都合上、
必ずしもそれが正解とはいいづらい部分もあるかと思います。
inlineなら問題ないのかな？？
「7-2. メンバ(関数)は大文字で始める」
個人的にはPublicか否かで分けたいのですが、
どうも、そんなスタイルに肯定的な人は少数派のようです。
お任せしたいと思います。
「7-3. メンバ(アクセサ)はget_, set_から始める」
賛成ですが、7-1と同じ疑問が浮かびます。
また、
Task.x = ～ は
Task.set_x(～)のようになるわけですよね・・・。
Task 関連クラスは特例でも良いように思います。
「8. 変数名は小文字と_だけを使用する」
賛成です。メンバフィールド名を m_ 開始
(全てprivate)と限定するという条件付きですが。
-- (yutap) 2009-02-11 08:20:45
- リージョンについて
実は、メニューの区切り線単位で全てに
リージョンを入れていたのですが、
表示の制御が細かくできなかったので、
一旦、断念しました。
(最近更新されたページのリージョンは消し忘れです)
コメントレベルについて
//* (/* */) レベル1
//** (/** **/) レベル2 .....
といった具合です。
コメントに重みをつけ、重要度をあらわしたり
後々、部分抽出などするのに便利かと・・・。
(記述する対象に応じて、あらかじめ
レベルの範囲を明確にしておくのも良いと思います)
-- (yutap) 2009-02-11 07:29:59
- メニューの「最近変更されたページ」のリージョンですが、
デフォルトでオープンにしました。
ここがメインだと思っているので。
（同期の面や、最近の動向が分かるという面で）
-- (rei) 2009-02-10 14:02:18
- >コメントレベルをアスタリスクの数で表現する(1 ～)
というのはどういう意味でしょう？
雛形があると助かります。
というか、コメントスタイルが定まっていなくてすみません。
-- (rei) 2009-02-09 03:50:12
- 先日、自機イメージを送付しましたが、
キャラクタの交代によって、
・大きさ
・移動速度
・当り判定
なども変化することになるかと思います。
念のため。
-- (yutap) 2009-02-08 18:49:47
- 意見の交換、質問、雑記などは
こちらに行うことにしましょう。
-- (yutap) 2009-02-08 18:43:09
最終更新：2009年02月16日 19:17
