Themen

1

tyndur / Datentypen

« am: 17. June 2005, 21:30 »

Hi,

ich weiss nicht so recht wohin mit meinem anliegen. Es ist mir auch ein wenig unangenehm für jeden Futzel der mir einfällt einen neuen Thread aufzumachen... Naja, ich machs trotzdem.

Also in LOST ist mir aufgefallen, dass ihr so komische selbstgebaute Datentypen wie BYTE, WORD, DWORD, UINT, usw verwendet. Ist das nicht ein bisschen lächerlich? Beim GCC für x86 sind die eingebauten Datentypen sehr gut definiert und über Versionen hinweg gleich geblieben. Ich plädiere deswegen dafür, diese unnötigen Datentypen wieder rauszuschmeissen und stattdessen die "normalen Typen" zu verwenden.  Genauso überflüssig sind BOOL, TRUE und FALSE in C++.

Vorteile:
- schönerer (einheitlicher) und übersichtlicherer Code
- verständlicher (so mancher könnte sich z.B. fragen: "wie ist WORD definiert?" es gibt genug standards, bei denen ein WORD 32 Bit groß ist.)
- keine redundanz (DWORD <-> UINT, BOOL <-> bool (sind eigentlich inkompatibel!), etc)

2

tyndur / CVideoRam & CVideoRamManager - Sinn?

« am: 16. June 2005, 22:39 »

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

3

tyndur / Doku-Team?

« am: 16. June 2005, 20:54 »

Im Wiki steht was von Doku-Team. Gibt es sowas hier überhaupt? Habt ihr was zum Dokumentieren? Wenn nein, dann frage ich mich, warum keiner arbeitet? Wenn aber hier irgendwer an irgendwas arbeitet, warum dokumentiert er das nicht, damit andere das mitverfolgen und sich eventuell daran beteiligen können?

Gibt es sowas wie Zwischenergebnisse? Auf dem SVN-Repository scheint mir ja nicht so viel los zu sein. Ich glaube es wollten einige irgendwas für Milestone 1 erst mal fertigcoden und das dann in einem Schwung bereitstellen. Bloß blöd wenn einfach nix kommt. Ich kann es ja verstehen wenn man aus was für Gründen auch immer keine Zeit oder Lust hat, um sich voll auf LOST zu konzentrieren. Aber wenn man eine Aufgabe übernimmt und damit nicht in absehbarer Zeit fertig wird, dann kann man wenigstens Zwischenergebnisse zur Verfügung stellen, damit jemand anders sich damit befassen kann. Wenigstens theoretisch oder auch nur um Leuten wir mir das Maul zu stopfen.