Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
C-/C++-Quelltext |
|
1 2 3 4 |
int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main |
Gegen den Cache nutze ich shared_ptr.
Die ResourceFactory als Singleton zu machen ist eigentlich keine allzu schlechte Sache.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Solange es sich nicht um Logs handelt, ist das eigentlich schon eine schlechte Idee. Außer Du meinst tatsächlich nur die Factory, die Objekte nur erzeugt und nicht auch noch den entsprechenden Cache dazu, der die Objekte auch irgendwie weiterhin referenziert. Letzteres ist als Singleton eine Katastrophe - wie fast alles, was man nur aus Faulheit nicht übergeben und stattdessen lieber als eine globale Variable unter Singleton verpackt verwendet. Wieso dann nicht gleich eine globale Variable? Im Falle einer Factory wären rein statische Methoden sogar irgendwie noch sinnvoller. Denn wozu überhaupt eine Instanz auf dem Heap erzeugen für eine Factory, die man eigentlich doch wirklich statisch verwenden will?Die ResourceFactory als Singleton zu machen ist eigentlich keine allzu schlechte Sache.
Oder als Context, wie du schon gesagt hast. Aber das macht es komplexer.
Sowas wie LevelContext und ApplicationContext, die jeweils das gleiche Interface implementieren. Der LevelContext sollte dann einen ApplicationContext verlangen und daran weiter delegieren können.
Solange es sich nicht um Logs handelt, ist das eigentlich schon eine schlechte Idee.
C-/C++-Quelltext |
|
1 2 3 4 5 6 |
// hpp extern Logger debug, warn; // cpp Logger debug("./debug.log"); Logger warn("./warnings.log"); |
Na, jeder der z.B. eine Textur verwendet, besitzt sie im Prinzip. (Erstmal. Vielleicht baue ich das ja noch um, weil mir ein Manager dann doch lieber wird, oder so.) Dadurch wird die Textur entfernt, sobald niemand sie mehr haben will. Ein Ressourcen-Cache ist dazu da, Ressourcen am Leben zu erhalten, auch wenn niemand sie mehr haben will, für den Fall, dass später jemand doch wieder gern die Ressource hätte. Damit ließe sich ein Cache ganz einfach basteln, indem noch jemand einen shared_ptr greift und der RefCount dadurch nicht auf 0 fallen kann.Zitat
Wie genau würde das mein beschriebenes Design verändern? Mir fehlt gerade die Vorstellung was du konkret meinst.
C-/C++-Quelltext |
|
1 2 3 4 |
int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main |
Ich bin mir nicht sicher, ob das eine dufte Idee ist, Logger nach Kategorien zu trennen. Ein Error kann durch falsche Daten ausgelöst werden, über die schon bei einer Warning-Nachricht gewarnt wurde, deren Entstehung man hätte bei einer Debug-Nachricht nachvollziehen können. Habe ich eine Log-Datei für alles (oder von mir aus eine pro Programmausführung), sehe ich potenzielle Abhängigkeiten und Querverweise unmittelbar übereinander.
Na, jeder der z.B. eine Textur verwendet, besitzt sie im Prinzip. (Erstmal. Vielleicht baue ich das ja noch um, weil mir ein Manager dann doch lieber wird, oder so.) Dadurch wird die Textur entfernt, sobald niemand sie mehr haben will. Ein Ressourcen-Cache ist dazu da, Ressourcen am Leben zu erhalten, auch wenn niemand sie mehr haben will, für den Fall, dass später jemand doch wieder gern die Ressource hätte. Damit ließe sich ein Cache ganz einfach basteln, indem noch jemand einen shared_ptr greift und der RefCount dadurch nicht auf 0 fallen kann.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Werbeanzeige