1

シナリオは、テクスチャの読み込みと管理を担当する TextureManager クラスを使用してゲームを構築しています。IVisibleGameObject を実装するゲーム オブジェクトには、TextureManager からのテクスチャへのポインタ/参照が必要です。

テクスチャ マネージャは、std::map<std::string, boost::shared_ptr<Texture> >そのオブジェクトを内部に保持するために で実装されます。

テクスチャを実際に公開する方法がよくわからないので、いくつかの可能性を考えましたが、それぞれに欠点があります。

1)const Texture& GetTex(std::string textureKey)

理想的だと思いますが、NULL を返すことでマップ内にテクスチャが見つからなかったことを示したいと思います。（自分で推測する...これは適切ですか？）

2)shared_ptr<const Texture> GetTex(std::string textureKey)

ここでは、null の shared_ptr を返すことができますが、現在は共有オブジェクトであるという意味に不快感を覚えます。TextureManager はオブジェクトの所有者であり、結局のところマネージャーです。しかし、IVisibleGameObject が返された Texture への参照/ポインターを保持し、正しく機能するためにその存在に依存しているという事実を考慮すると、それはオブジェクトの所有者でもなく、共有所有権が適切ではないでしょうか?

3)const Texture* GetTex(stD::string textureKey)

明らかに、これは間違った答えです。

誰かが私のためにこれを片付けてくれることを望みます.おそらく私が考えていないことがあります.

4

2 に答える 2

3

私は標準ライブラリのイディオムに固執し、単純に and を公開findしendます。次に、完全に効率的になります。

auto it = my_objects.find("foo");

if (it == my_objects.end())
{
    // handle "not found"
}
else
{
    it->second->do_magic();
}

標準ライブラリには、コレクションを処理したり、要素の存在または不在を通知したり、insert-new-or-return-exist セマンティクスを組み合わせたりするための、完全にサービス可能な一般的なイディオムが既にあります。なぜ車輪を再発明するのか...

于 2012-08-09T23:29:30.573 に答える
1

私がしたいことは、TextureManager が各テクスチャへの単一の共有ポインターを保持し、GameObjects が弱いポインターを保持するようにすることです。そうすれば、終了時にすべてを適切に解放したことを確認できます (サイクルが保証されません)。

于 2012-08-09T23:03:10.520 に答える