[過去ログ] C/C++ゲーム製作総合スレッド Part1 (1001レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
1(4): 2012/05/20(日)21:22 ID:iNm25OoA(1) AAS
ゲーム製作におけるC/C++全般に関するスレです。
元スレ
DXライブラリ 総合スレッド その12
2chスレ:gamedev
982(1): 2012/10/22(月)08:33 ID:19qPn/dP(1) AAS
boostの参照カウンタ使えばdelete書かなくてもなんとかなる…かも?
983: 2012/10/22(月)09:11 ID:wKQ4qRL6(1) AAS
>>982
移植の際にコンパイルエラー出たときの対応コストがboostは大きくつく。
ジャンルによってはカウンタ同期のコストが馬鹿にできないこともあるだろうし。
minmalなオレオレsmartptrを作っておくのが一番苦労しない気がする。
984(1): 2012/10/22(月)15:22 ID:buj+NpWL(1) AAS
#include <iostream>
#include <vector>
#include <string>
int main(){
std::vector<std::string> Strings;
std::vector<int> Vector;
Strings.push_back("1-2-3-4-5");
Strings.push_back("9-7-8");
Strings.push_back("6");
for(unsigned int i = 0; i<Strings.size(); i++){
省8
985: 2012/10/22(月)18:04 ID:bfhvnErC(3/5) AAS
誰が調べてあげてたもれ
986: 2012/10/22(月)18:38 ID:yaXLi6zV(1/2) AAS
試してないけどboost::regex_grepに\\d+を突っ込むんじゃダメかな
987: 2012/10/22(月)19:30 ID:GibO9cqH(2/4) AAS
deleteを自分で書くな
std::unique_ptrを使え
ノーコストのスマートポインタだ
スコープから抜けるときに自動的にdeleterを実行してくれる
std::unique_ptrが使えない場面では仕方ないのでstd::shared_ptrを使え
多態が必要なときはstd::shared_ptrじゃないとダメだった気がする
デストラクタを書くのはスマートポインタで自動的に解放できないリソースを扱うクラスのときだけだ
例えば、OpenGLのテクスチャオブジェクトとかな
だがFILEオブジェクトなんかはdeleterにfcloseを指定すればスマートポインタで自動解放可能だ
メンバ変数の解放はメンバ変数のデストラクタに任せて自分で解放しようとするな
省3
988: 2012/10/22(月)20:05 ID:YuwwqXlf(1) AAS
>>984
strtokでググれ
989: 2012/10/22(月)20:11 ID:bfhvnErC(4/5) AAS
でもさ、
あるクラスをアプリ実行期間中、存続させつつづけて、
ゲーム・ステージの切り替わりのタイミングで、
それが持つ配列型メンバをリサイズする場合なんかには
deleteを使わざるを得ないんじゃないか?
こういうケースは頻繁にあるんだが。
全ステージ配列のサイズは固定とか縛り持たせるわけでもあるまい。
990: 2012/10/22(月)20:20 ID:GibO9cqH(3/4) AAS
スマートポインタのvectorを使いなさい
あと、いまどき生配列はないな
固定長配列ならstd::array、可変長ならstd::vectorを使いなさい
Visual C++でデバッグモードでコンパイルすれば、範囲外アクセスしたときに例外投げてくれるはずだ
991(1): 2012/10/22(月)20:56 ID:bfhvnErC(5/5) AAS
相互に関連していて、deleteでトリガーされるデストラクタの実行順を気にしなきゃいけない時もあるよ。
またブラックボックスな配列ってのは、リサイズ後のメモリアクセス効率性への影響が不安じゃない。
992(1): 2012/10/22(月)21:12 ID:yaXLi6zV(2/2) AAS
それなりに寿命が短くて、確実に管理できるなら
new/deleteの方が楽よね
993(1): 2012/10/22(月)21:21 ID:oFyoxOqU(1) AAS
>>991 例えばこういう循環参照を持つやつだよね。
struct B;
struct A{ B* b;};
struct B{ A* a;};
こういうときは、生存期間の管理用に一つ使い捨てのクラスを用意して、
struct C{
A a; B b;
C():a(),b(){ a.b = &b; b.a = &a; }; // 循環してるポインタをセット
~C(){} // デストラクタで a と b が 同時に破棄されるようにする。
}; // struct C自体はスタックか std::unique_ptr<C> にまかす。
省3
994: 2012/10/22(月)23:30 ID:GibO9cqH(4/4) AAS
オブジェクトへの参照を保持していることとオブジェクトを所有していることは別だと思うんだ
例えば木構造でなるべくメモリを局所化したい場合だとこういう感じになると思う
class Node { Node* firstChild; Node* sibling; Node* parent; };
std::vector<Node> vNode;
この場合、Nodeは他のNodeへの参照を持ってるけど、所有しているわけじゃない
所有しているのはvNodeを持つオブジェクトだ
あれこれって>993と同じことじゃね
995: 2012/10/23(火)00:04 ID:jziPb4Rf(1) AAS
weak_ptrを使うのだてめえら
996: 2012/10/23(火)01:15 ID:lf4QviES(1/2) AAS
class Task {
Task* m_pNext;
Task* m_pPrev;
bool m_Head; //デク先頭フラッグ
bool m_ToBeDeleted; //削除フラッグ
virtual void Exec()=0; //
};
class Filament : public Task { //m_EntryPointにTaskクラスをつなげる。
Task m_EntryPoint; //デク先頭
~Filament() { //親delete時に、連鎖的にdeleteする子の削除フラッグを立てる。
省14
997: 2012/10/23(火)01:16 ID:lf4QviES(2/2) AAS
↑極端な例だが、
Repositoryクラス内で、シーン中、必要なインスタンスしか確保しないという条件の場合、
まずSynthesisクラス内の要らないfibers_active要素だけ削除フラッグを立てて、
次にRepositoryクラス内のフラッグが立ったfibers要素をdeleteして、
次にRepositoryクラス内のフラッグが立ったfilaments要素をdeleteして、
最後にRepositoryクラス内のフラッグが立ったtasks要素をdeleteする、
っていうのが効率的なんじゃないか?
要は、麗しのタスクシステムなんだが(笑)
998: 2012/10/23(火)02:02 ID:7yJptL6x(1) AAS
>>992
「確実に管理しなければならない」ポイントを減らすためにライブラリ使うんでしょ
999: 2012/10/23(火)10:35 ID:8kXxMAJY(1) AAS
お疲れ
1000: [age] 2012/10/23(火)10:41 ID:5T7QFGuf(1) AAS
そしてさようなら(#゚Д゚)/~~
1001: 1001 Over 1000 Thread AAS
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
上下前次1-新書関写板覧索設栞歴
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.024s