[過去ﾛｸﾞ]
C/C++ゲーム製作総合スレッド Part1 (1001ﾚｽ)
C/C++ゲーム製作総合スレッド Part1 http://echo.5ch.net/test/read.cgi/gamedev/1337516528/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
1: 名前は開発中のものです。 [sage] 2012/05/20(日) 21:22:08.41 ID:iNm25OoA ゲーム製作におけるC/C++全般に関するスレです。 元スレ DXライブラリ 総合スレッド その12 http://toro.2ch.net/test/read.cgi/gamedev/1330000532/ http://echo.5ch.net/test/read.cgi/gamedev/1337516528/1
982: 名前は開発中のものです。 [sage] 2012/10/22(月) 08:33:50.88 ID:19qPn/dP boostの参照カウンタ使えばdelete書かなくてもなんとかなる…かも？ http://echo.5ch.net/test/read.cgi/gamedev/1337516528/982
983: 名前は開発中のものです。 [sage] 2012/10/22(月) 09:11:31.91 ID:wKQ4qRL6 >>982 移植の際にコンパイルエラー出たときの対応コストがboostは大きくつく。 ジャンルによってはカウンタ同期のコストが馬鹿にできないこともあるだろうし。 minmalなオレオレsmartptrを作っておくのが一番苦労しない気がする。 http://echo.5ch.net/test/read.cgi/gamedev/1337516528/983
984: 名前は開発中のものです。 [sage] 2012/10/22(月) 15:22:28.62 ID:buj+NpWL #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++){ //VectorにStringsの文字列を正規表現等で格納したい } return 0; } Stringsに格納した文字列を正規表現で数字だけ取り出してVectorに格納したいのですが 正規表現はどうかけばいいのでしょうか？ Vectorを[1,2,3,4,5,9,7,8,6]といった具合です。 よろしくお願いします。 http://echo.5ch.net/test/read.cgi/gamedev/1337516528/984
985: 名前は開発中のものです。 [sage] 2012/10/22(月) 18:04:08.05 ID:bfhvnErC 誰が調べてあげてたもれ http://echo.5ch.net/test/read.cgi/gamedev/1337516528/985
986: 名前は開発中のものです。 [sage] 2012/10/22(月) 18:38:31.04 ID:yaXLi6zV 試してないけどboost::regex_grepに\\d+を突っ込むんじゃダメかな http://echo.5ch.net/test/read.cgi/gamedev/1337516528/986
987: 名前は開発中のものです。 [sage] 2012/10/22(月) 19:30:48.30 ID:GibO9cqH deleteを自分で書くな std::unique_ptrを使え ノーコストのスマートポインタだ スコープから抜けるときに自動的にdeleterを実行してくれる std::unique_ptrが使えない場面では仕方ないのでstd::shared_ptrを使え 多態が必要なときはstd::shared_ptrじゃないとダメだった気がする デストラクタを書くのはスマートポインタで自動的に解放できないリソースを扱うクラスのときだけだ 例えば、OpenGLのテクスチャオブジェクトとかな だがFILEオブジェクトなんかはdeleterにfcloseを指定すればスマートポインタで自動解放可能だ メンバ変数の解放はメンバ変数のデストラクタに任せて自分で解放しようとするな 抱合した子オブジェクトは親が死んだときに勝手に死ぬし newしたオブジェクトはスマートポインタに入れとけば勝手に死ぬ 自分でdeleteする必要がある場面なんてまずないだろう http://echo.5ch.net/test/read.cgi/gamedev/1337516528/987
988: 名前は開発中のものです。 [sage] 2012/10/22(月) 20:05:28.33 ID:YuwwqXlf >>984 strtokでググれ http://echo.5ch.net/test/read.cgi/gamedev/1337516528/988
989: 名前は開発中のものです。 [sage] 2012/10/22(月) 20:11:20.29 ID:bfhvnErC でもさ、 あるクラスをアプリ実行期間中、存続させつつづけて、 ゲーム・ステージの切り替わりのタイミングで、 それが持つ配列型メンバをリサイズする場合なんかには deleteを使わざるを得ないんじゃないか？ こういうケースは頻繁にあるんだが。 全ステージ配列のサイズは固定とか縛り持たせるわけでもあるまい。 http://echo.5ch.net/test/read.cgi/gamedev/1337516528/989
990: 名前は開発中のものです。 [sage] 2012/10/22(月) 20:20:24.89 ID:GibO9cqH スマートポインタのvectorを使いなさい あと、いまどき生配列はないな 固定長配列ならstd::array、可変長ならstd::vectorを使いなさい Visual C++でデバッグモードでコンパイルすれば、範囲外アクセスしたときに例外投げてくれるはずだ http://echo.5ch.net/test/read.cgi/gamedev/1337516528/990
991: 名前は開発中のものです。 [sage] 2012/10/22(月) 20:56:00.85 ID:bfhvnErC 相互に関連していて、deleteでトリガーされるデストラクタの実行順を気にしなきゃいけない時もあるよ。 またブラックボックスな配列ってのは、リサイズ後のメモリアクセス効率性への影響が不安じゃない。 http://echo.5ch.net/test/read.cgi/gamedev/1337516528/991
992: 名前は開発中のものです。 [sage] 2012/10/22(月) 21:12:58.91 ID:yaXLi6zV それなりに寿命が短くて、確実に管理できるなら new/deleteの方が楽よね http://echo.5ch.net/test/read.cgi/gamedev/1337516528/992
993: 名前は開発中のものです。 [sage] 2012/10/22(月) 21:21:39.03 ID:oFyoxOqU >>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> にまかす。 デストラクタが走るときはコンストラクタと逆の順番だから、循環参照してて デストラクタの実行順番を気にしないといけないような状態の場合はそれ自体を struct Cのデストラクタに封じ込めるのはどうだろう。 http://echo.5ch.net/test/read.cgi/gamedev/1337516528/993
994: 名前は開発中のものです。 [sage] 2012/10/22(月) 23:30:02.44 ID:GibO9cqH オブジェクトへの参照を保持していることとオブジェクトを所有していることは別だと思うんだ 例えば木構造でなるべくメモリを局所化したい場合だとこういう感じになると思う class Node { Node* firstChild; Node* sibling; Node* parent; }; std::vector<Node> vNode; この場合、Nodeは他のNodeへの参照を持ってるけど、所有しているわけじゃない 所有しているのはvNodeを持つオブジェクトだ あれこれって>993と同じことじゃね http://echo.5ch.net/test/read.cgi/gamedev/1337516528/994
995: 名前は開発中のものです。 [sage] 2012/10/23(火) 00:04:00.65 ID:jziPb4Rf weak_ptrを使うのだてめえら http://echo.5ch.net/test/read.cgi/gamedev/1337516528/995
996: 名前は開発中のものです。 [sage] 2012/10/23(火) 01:15:06.83 ID:lf4QviES 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する子の削除フラッグを立てる。 Task* child = m_EntryPoint.m_pNext; while (!child->m_Head) { child->m_ToBeDeleted=true; child = child->m_pNext; } }; }; class Fiber : public Filament {...}; //m_EntryPointにFilamentクラスをつなげる。 class Synthesis { Fiber* fibers_active[4]; }; //１次元配列。参照のみ。 class Repository { //シーンの切り替わりで動的に生成・破棄し、インスタンスを必要分だけ保持する。 Task* tasks[1024]; //１次元配列。インスタンスを注入。 Filament* filaments[256]; //１次元配列。インスタンスを注入。 Fiber* fibers[64]; //１次元配列。インスタンスを注入。 }; http://echo.5ch.net/test/read.cgi/gamedev/1337516528/996
997: 名前は開発中のものです。 [sage] 2012/10/23(火) 01:16:10.47 ID:lf4QviES ↑極端な例だが、 Repositoryクラス内で、シーン中、必要なインスタンスしか確保しないという条件の場合、 まずSynthesisクラス内の要らないfibers_active要素だけ削除フラッグを立てて、 次にRepositoryクラス内のフラッグが立ったfibers要素をdeleteして、 次にRepositoryクラス内のフラッグが立ったfilaments要素をdeleteして、 最後にRepositoryクラス内のフラッグが立ったtasks要素をdeleteする、 っていうのが効率的なんじゃないか？ 要は、麗しのタスクシステムなんだが（笑） http://echo.5ch.net/test/read.cgi/gamedev/1337516528/997
998: 名前は開発中のものです。 [sage] 2012/10/23(火) 02:02:33.12 ID:7yJptL6x >>992 「確実に管理しなければならない」ポイントを減らすためにライブラリ使うんでしょ http://echo.5ch.net/test/read.cgi/gamedev/1337516528/998
999: 名前は開発中のものです。 [sage] 2012/10/23(火) 10:35:59.82 ID:8kXxMAJY お疲れ http://echo.5ch.net/test/read.cgi/gamedev/1337516528/999
1000: 名前は開発中のものです。 [age] 2012/10/23(火) 10:41:49.45 ID:5T7QFGuf そしてさようなら(#ﾟДﾟ)/~~ http://echo.5ch.net/test/read.cgi/gamedev/1337516528/1000
1001: １００１ [] Over 1000 Thread このスレッドは１０００を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。 http://echo.5ch.net/test/read.cgi/gamedev/1337516528/1001
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.023s