Ich wollte noch etwas zu Evreys ansatzt mit den shared_ptr sagen, wenn man das tut sollte man auch weak_ptr verwenden.
Probleme kann es auch bei threads geben dann muss man gegebenenfalls den cache locken (was etwas unschön ist).
Und man sollte wenn man mit shared_ptr arbeitet auch mit weak_ptr arbeiten um z.b. ein cycles vermeide (shared_ptr erhalten sich gegenseiten am leben).
Mit expired() kann man auch z.b. die gültigkeit überprüfen ob irgetn jemand anders gerade die Texture verwendet(z.b. durch weitere shared_ptr) und wenn nicht die ggf. löschen.
Das Aufräumen und managen des caches beim multithread is auch so eine sache.
|
C-/C++-Quelltext
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
std::shared_ptr<Texture> loadTexture(std::string filename) {
static std::vector<std::weak_ptr<Texture>> cache; // lieber vector statt map verwenden .... oder nicht ?
static std::mutex m;
std::lock_guard<mutex> hold (m);
auto find_cache_func = [&](const std::weak_ptr<Texture>& tex){
return !tex.expired() && tex.lock()->getFilename() == filename;
};
auto cache_it = std::find_if(std::begin(cache), std::end(cache), find_cache_func);
std::shared_ptr<Texture> ret;
if (cache_it != std::end(cache) && !cache_it->expired()) {
ret = cache_it->lock();
} else {
ret = loadRealTexture(filename);
if(ret) cache.push_back(ret);
}
return ret;
}
|
Das static cache und mutex ist jetzt wieder global, könnte das auch in ein Manager rein packen.
Soll nur ein denk anstoß mit shared_ptr sein.