Thema: CVideoRam & CVideoRamManager - Sinn?

[xormore]

nabend mal wieder,

na dann will ich mich mal beteiligen. die klassen CVideoRam und CVideoRamManager sind ziemlich sinnlos. in meinen augen sind sie absolut nícht OOP und sehen aus als hätte da jemand auf zwang versucht, den videotreiber in klassen zu verpacken. einen vorteil aus dem inline zieht der code auch nicht, sondern macht ihn eher komplizierter. ich finde es außerdem sehr unelegant, dass ich jedesmal, wenn ich was ausgeben will, das objekt CVideoRamManager erzeugen muss, das darüber hinaus den bildschirm jedesmal löscht.

ich schlage deswegen vor den ganzen kram aus den klassen rauszuschmeissen und stattdessen in statischen methoden zu verpacken.

Code: [Auswählen]

CVideoRam* const g_pVideoRam = (CVideoRam*)0x000B8000;
ist außerdem extra-"pr0nnig". das objekt g_pVideoRam wird nie initialisiert (der konstruktor wird nicht aufgerufen), ich bin nicht sicher ob garantiert ist, dass die daten (genauer gesagt m_woData) immer wie gewünscht an der stelle landen, und das ist mMn nicht compiler- und plattformunabhängig. (jaja, ich weiss was ihr sagen wollt. es geht mir aber ums prinzip.)

ich weiss, es soll später alles im grafikmodus laufen, der code wird also später kaum bis gar nicht benötigt, aber trotzdem entschuldigt das nicht so ein sehr unschönes stück code.

xormore

[Legend]

Darauf nen Konstruktor auszuführen gäbe wohl auch mehr ein paar lustige Zeichen auf dem Bildschirm ...

[Roshl]

So wie es ist, ist es an sich schon OK, es reicht ja wenn du einmal Global so ein Objekt hast, das verwendest du immer wieder. Allerdings sehe ich es auch so, dass es nicht immer Sinn macht alles in krampfhaft in Klassen halten zu wollen. Objektorientierung macht nur Sinn, wenn man mehrere Objekte hat, wir haben aber nur einen VideoRam, also macht OO da absolut keinen Sinn und verlangsamt den ganzen Code, da immer ein Pointer auf das Objekt mit übergeben werden muss, der an sich ja überflüssig ist.

[xormore]

So wie es ist, ist es an sich schon OK, es reicht ja wenn du einmal Global so ein Objekt hast, das verwendest du immer wieder.

das ist ja eben nicht der fall. CVideoRam ist praktisch ein multidimensionales array mit funktionen und wird sehr unelegant in den videospeicher gecastet. das ist nicht ok in meinen augen. und es liegt   nicht eine globale instanz von CVideoRamManager vor, sondern jede funktion (bisher nur _main() und ein exception handler) scheint ihren eigenen CVideoRamManager haben zu müssen.

[DDR-RAM]

hiho,

also

Code: [Auswählen]

CVideoRam* const g_pVideoRam = (CVideoRam*)0x000B8000;
Wird nie initialisiert ja
ich sag dir auch warum, weil der pointer schon zur runtime bekannt ist.
Bei Verwendung von g_pVideoRam muss also kein pointer geladen werden oder so. Der Compiler kann alles wegoptimieren und das tut er, falls ihr mal den asm code angesehen habt.

und, was daran unschön ist weiß ich jetzt ehrlich gesagt nicht.
Den videoram als klasse zu haben und eine klasse, die diesen verwaltet, was soll daran falsch sein?
Ich sag nicht, das der code nicht noch ausbaufähig ist oder so, das wäre ja total vermessen. Aber an dem code ist nichts zwanghaft oop-mäßiges.

Und das mit dem Bildschirm löschen ist ja nun nen guter witz, wie schon vorher gesagt, du kannst ein globales videoram mgr objekt verwenden

Und der code ist nur zum testen des Kernels da, er wird in einer fertigen version nicht mehr benötigt.

MfG
DDR-RAM