1. Shto se tiche resource-a i handle-ova - na ovu temu, vezano za programiranje engine-a, je dosta puta pisano. Prva knjiga GPG-a ima par chlanaka na tu temu. U principu, nema univerzalnog reshenja - koristi ono koje ti najbolje lezhi u konkretnom kontekstu. U "domacoj igri" koju Tosa pominje smo, recimo, koristili object/property manager-e i LUA skriptu za instanciranje objekata i vezivanje resursa za iste.
Ovaj tekstic o handle-ovima je pisao moj prijatelj (fenomenalan game programmer), iako je vec dosta mator (tekst, ne on :) i dalje je prilichno relevantan. Doc fajl na ovoj lokaciji :
http://gyurchev.com/docs/resource2.doc
2. Da ne ostanem duzhan odgovora - gornja implementacija, izmedju ostalog, ne valja jer ne koristi nijedan idiom C++a, vec se zasniva na run-time proverama (assert). Ako u Release verziji zaobidjesh assert-check niko ti ne garantuje da necesh imati gomilu instanci tog singletona okolo, u kompletu sa crash-bagovima koje nije lako naci. Sa praktichne strane - zashto ja moram da znam, u trenutku kad mi zatreba instanca singleton-a, da li je on vec instanciran ili ne (jer se singleton inicira u konstruktoru)? Ako pozovem getSingletonPtr() niko mi ne garantuje da cu dobiti validan pointer. Kod singletona ono shto zhelish je da sakrijesh konstruktore i da incijalizaciju izvodish u samoj GetInstance() funkciji. Tu u igru ulazi i thread-safe koncept - odnosno dupli lock koji morash da izvedesh tokom samog instanciranja. Scott Meyers je pisao na temu thread-satefy u singletonu, a Alexandrescu je razradio koncept do kraja.
Na kraju, sa strane sw dizajna - ne valja prisiljavati nekog da koristi nasledjivanje ako ne zheli (hint: prochitati shta chika Herb Sutter ima da kazhe na temu sw dizajna u C++u). Taj templejt je moguce zamotati okolo klase, tako da od svake klase mozhesh da napravish singleton bez potrebe da menjash vec jednom napisanu klasu.