也許是訪問這些列表沒有好主意,但如果你需要這種存取權限,你可以通過多種方式,全局變量最簡單的做到這一點:
// forward declare Game_object:
class Game_object;
// Declare lists:
typedef std::list <Game_object *> ListObjects;
typedef std::list <Explosion *> ListExplosions;
ListObjects Objects;
ListExplosions Explosions;
class Game_object
{
public:
void Update()
{
// Update Objects...
for (ListObjects::const_iterator O = Objects.begin(); O != Objects.end(); ++O)
{ ... };
// Update Explosions...
for (ListExplosions::const_iterator E = Explosions.begin(); E != Explosions.end(); ++E)
{ ... };
};
void Render()
{
// Render Objects...
for (ListObjects::const_iterator O = Objects.begin(); O != Objects.end(); ++O)
{ ... };
// Render Explosions...
for (ListExplosions::const_iterator E = Explosions.begin(); E != Explosions.end(); ++E)
{ ... };
};
//Other stuff
};
這不是一個好主意,全局變量可能會很麻煩,甚至更糟糕的是全局列表可以被其他類訪問並且改變它的內容,而另一個類嘗試同時修改內容;但如果你不使用線程,它不會那麼麻煩。
其他方法可能是創建一個經理。經理必須是該列表的所有者,並且需要方法Setters
,Getters
和Deleters
方法。要更新列表中的內容可以傳遞給管理者參考,以渲染/更新,並獲得從管理列表的引用:
class ObjectManager
{
public:
typedef std::list <Game_object *> ListObjects;
void AddObject(const ObjectStuff &os)
{ ... };
const ListObjects &GetObjects()
{ return Objects; };
private:
ListObjects Objects;
}
class ExplosionManager
{
public:
typedef std::list <Explosion *> ListExplosions;
void AddExplosion(const ExplosionStuff &es);
{ ... };
const ListExplosions &GetExplosions()
{ return Explosions; };
private:
ListExplosions Explosions;
}
void Render(const ObjectManager &om)
{
// Ask ObjectManager for the object list
}
void Render(const ExplosionManager &em)
{
// Ask ExplosionManager the explosion list
}
上面的代碼是一個天真,漂亮簡單的近似,但僅用於示例目的。上述方法的優點在於,列表僅由所有者對象修改,如果列表需要以管理員身份以只讀方式提供,並且如果您正在使用線程,則非常容易添加鎖和在管理器方法中解鎖以避免使用列表時的修改。
這是不問,但我認爲是值得的說:可能是一個好主意,以避免存儲對象指針到容器和對象實例改變存儲類型:
std::list <Game_object *> VS std::list <Game_object>
當你如果列表是全局的,你將需要一個公共的Close
方法來解除分配列表中存儲的指針所管理的所有內存,如果列表屬於一些對象,你需要在對象析構函數中執行相同的過程。
但是,如果您要存儲對象實例,那麼列表析構函數將釋放所有存儲的對象,這些對象在其生命週期結束時會取消分配,代碼更清晰且更易於維護。
根據我的經驗,對這個問題的更好的解決方案是讓這些類*不需要通過移動其他地方需要的邏輯來訪問這些列表。 – molbdnilo
我必須同意molbdnilo在這裏,搞亂前面的聲明和extern會導致難以維護,相互依賴的意大利麪代碼。最好的方法是重新設計你在做什麼。 –