Thema: Datentypen

[xormore]

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)

[jeb]

ich denke mal das ist so, damit man mit ASM kompatibel bleibt.

[xormore]

diese selbst gebastelten datentypen werden aber an den seltsamsten stellen eingesetzt, die überhaupt keine berührung mit ASM haben.

Beispiel aus videoram.h:

Code: [Auswählen]

void SetAt (int byLine, int byCol, BYTE bySymbol, BYTE byFormat);
/* diese funktion setzt einen buchstaben auf den bildschirm über einen einfachen array zugriff */
(außerdem werden hier native datentypen mit den eigenen gemischt. sehr unschön ...)

eigentlich finde ich, sollten die asm dateien an c angepasst werden und nicht umgekehrt. es werden vielleicht einige hundert zeilen asm anfallen, da kann es nicht sein, dass sich tausende zeilen C++ code anpassen müssen und auf asm-konstrukte ausweichen müssen.

[Golum]

Stimmt ich finde die standart-datentypen auch schöner.
Teilweise auch wegen dem Syntaxhighlighting ^^

[jeb]

*zustimm*
Könnte man nicht in ASM konstanten für int und so definieren? Dann wären die Bezeichnungen auch immer gleich

[n3Ro]

Aber indem man Datentypennamen wie Byte oder Word benutzt, kann man sofort sehen wie breit das Datenwort ist (besonders als LowLevel / Assembler Coder), was bei hardwarenaher Programmierung schon sinnvoll ist.

[Legend]

Beim GCC für x86 sind die eingebauten Datentypen sehr gut definiert und über Versionen hinweg gleich geblieben.

Na dann viel Spass in Teufel's 64-Bit Küche bei Typen wie int. Wenn man die eingebauten Typen direkt benutzt, muss man bei verschiedenen Platformen aufpassen.

[Jidder]

also die typen char, short, int und long long sind beim x86-64-gcc immer noch so groß wie beim x86. ich glaube bei long gibt es aber da unterschiede (x86: sizeof(long) = 4, x86-64: sizeof(long) = 8). dann nimmt man diesen typ einfach nicht und gut is.

diese tabelle zeigt, dass diese annahme auf vielen anderen plattformen auch gültig ist.

[DDR-RAM]

hallo,

diese Datentypen sind an die winapi angelegt, wie unschwer zu erkennen ist. Das ist bis jetzt teilweise unschön umgesetzt, das muss ich selber zugeben. Aber ich denke trotzdem, wir sollten trotzdem die jetztigen typen weiter verwenden.

BYTE ist 1 Byte groß,
WORD ist 2 Byte groß,
DWORD ist 4 Byte groß,
QWORD ist 8 Byte groß.

Das soll für das os gelten *punkt*
Die verwendung von native datentypen sollte meiner meinung nach möglichst vermieden werden. Syntax-hl hin oder her.

MfG
DDR-RAM

[Another Stupid Coder]

Zudem kann man Syntaxhighlightning bei allen halbwegs guten Editoren anpassen

[Golum]

Ich weiß ^^
trotzdem sagen mir die standart-typen mehr zu.
Aber ich bin nicht im Kernel-Team also lass ich das eure sache sein

[Roshl]

man kann doch die standarts trotzdem nutzen wo is das problem?

[Dingsi]

Es sollte schon ne Einigung innerhalb des Teams geben, denn es ist doch schon irgendwie doof, wenn in einem Teil des Codes DWORD in einem anderen int und im nächsten beides benutzt wird und niemand mehr durchsteigt (Bzw. es einfach dämlich aussieht)

[T-Head]

Hi,

is doch eigentlich egal! Aber wenn bis jtz schon viel die neuen Typen benutzt worden sind, dann würd ichsagen, lassen wir sie auch drin, sons müsste mann das ja alles noch mal ändern, was ein unnötiger zeutazfwand währe!  

[Roshl]

Ich finde die Datentypen eh logisch, da sie nach ASM zumeist so definiert sind. Die meisten nutzen hier ja nasm und da ist word=2byte dword=4 usw.
Ich finds logischer wird anstatt short zu nutzen und kürzer qword anstelle von long long zu benutzen. Aber das ist alles Geschmackssache, irgendwie müssen ja Standards definert werden, derjenige der zuerst was festlegt bestimmt halt wos lang geht, so einfach ist das.

[kevin]

Naja, ein Wort als 16 Bit zu definieren, ist bei den heutigen Prozessoren wohl nicht mehr ganz logisch. Nicht daß ich was anderes drunter verstehen würde, aber so grundsätzlich...

[Svenska]

Tja... aber wenn man nicht weiß, was ein Word ist, woher soll man dann wissen, wie man seine Speichereien umschreiben muss?
Mir gefallen die Typen gut, da sie - im Gegensatz zu den Standardtypen - assemblertauglich sind und als solche gelesen werden können.
Bei int wär ich mir da nicht sicher (bei Basic sind es 16 Bit, bei C ist es eine Prozessor- bzw. Compilerentscheidung).
C ist nunmal eine Sprache, aber kein Standard. Pech gehabt... was man sich nicht definiert ist in der Versenkung verschwunden.

[Roshl]

Ich benutze persönlich die typen db dw dd wie in assembler, sieht einfach besser aus, mein Syntaxhighlighting passe ich darauf auch an^^

[hannibal]

ihr duerft nicht vergessen, das unsere "datentypen" nur typedefs fuer standard-typen sind. aendern sich die standard-typen aendern sich auch unsere datentypen.

[Dingsi]

ihr duerft nicht vergessen, das unsere "datentypen" nur typedefs fuer standard-typen sind. aendern sich die standard-typen aendern sich auch unsere datentypen.

Dafür gibts IFDEFs und sizeof..