spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ah, ich glaube, dieses Diskussion hatte ich hier schon einmal.
Der Vollständigkeitshalber:



Ich würde bei diesen Code für T ebenso ushort oder gar ubyte verwenden, einfach aus Intuition, und kein int (und wenn, würde ich uint nehmen, ebenfalls aus Intuition) oder size_t. Du jedoch schon, sehe ich das richtig?
Will keine (neue) dieser elendigen Diskussionen, die hier im Forum mittlerweile an der Tagesordnung zu stehen scheinen, ausbrechen lassen, sondern nur sehen, ob ich dich richtig verstanden habe.

Ja du hast mich richtig verstanden.
Ich frage mich halt, wieso sollte ich short oder gar char(bzw. "byte") verwenden?
Die Vorteile sind... ...also mir fallen keine ein.
Nachteile sehe ich dabei, dass Casts notwendig sind und der Wertebereich vollkommen unnötig eingeschränkt ist. Ein Code wie von dir genannt wird in der Realität nirgendwo zu finden sein. Eine solche magische Zahl im Code wäre auch wieder WTF. Die unpassende Auswahl des Datentypen erstreckt sich also in aller Regel über mehrere Variablen, Codestellen und in den meisten Fällen sogar über mehrere Dateien. Ich sehe da im Prinzip nur ein unnötiges Fehlerrisiko und eine Verkomplizierung.

Ich nenne es Intuitiv. Ich mache das meistens so und auch in D, wo implizite Konvertierung *nicht* vom Compiler unterstützt wird, habe ich nur selten eine Verkomplizierung gesehen.
Wenn ich Koordinaten für bspw. ein Fenster empfange, nehme ich eigentlich meistens ushort. Es kann/soll keine negativen by default akzeptieren und sollte nie größer sein, als ushort.max. Somit wird direkt beim Lesen des Funktionskopfs klar, was für ein Range akzeptiert wird. Aber gut, ich hatte die Diskussion schon und ich weiß, dass 90% das absolut anders sehen und immer int nehmen. Daher sollten wir's dabei belassen, habe ja meinen Standpunkt auch einmal kurz erläutert.

edit: die 42 war natürlich nur ein Beispiel, um das ganze zu verdeutlichen.

ich benutze tatsächlich öfters Datentypen wie "short" oder "byte", was allerdings daran liegt dass man damit in manchen Fällen Speicherplatz sparen kann! Man vergleiche lediglich mal ein Tilemap die man zuerst als int (bzw. uint) array (natürlich bitte dynamisch reserviert) mit einer die man als byte array reserviert. Man merkt schnell dass man 4-mal so viel Platz (sowohl auf der Festplatte als auch im Speicher) braucht und wer braucht schon 2³² verschiedene Tiles?! Bis jetzt benutze ich nicht mal 256 und falls das nicht reicht wechsel ich zu ushort und habe 65536 was mich mehr als zufrieden stellen sollte...

Zitat von »Spiele Programmierer«

"WTF" erscheint mir im ersten Augenblick hauptsächlich der "short"-Datentyp der hier irgendwie ziemlich fehl am Platz wirkt.

srsly? y=grid.y y<grid.y

Seit längerem mal wieder ganz kurz angefangen, gleich was Schönes reingehauen:


Sollte da auf jeden Fall noch refaktorisieren, aber nööö... xd Ich fange irgendwann nochmal an.

Ich hab mir mal spassenshalber den Sourcecode von Star Wars Jedi Academy angeschaut. Ein Kommentar, wo ich es runtergeladen hab, war: "Bevor ich so einen Code programmiere spring ich lieber freiwillig vor den bus". Irgendwie kann ich den guten Mann verstehen!

Zitat von »Checkmateing«

srsly? y=grid.y y<grid.y

Echt, da diskutieren die ewig über short oder int oder whatheheck. Aber dass die Schleife totaler Unfug ist, das übersehen sie.

Natürlich habe ich das auch gesehen.
Aber im ersten Momtent fällt halt vorallendingend das blau hervorgehobene "short" im Schleifenkopf auf, dass die Alarmglocken für unsaubere Programmierung bei mir in Gang setzt.

Ich musste heute mal wieder Java-Code von Studenten korrigieren und das hier fand ich besonders schön: