Du bist nicht angemeldet.

Werbeanzeige

Architekt

Community-Fossil

Beiträge: 2 496

Wohnort: Hamburg

Beruf: Student

  • Private Nachricht senden

251

20.05.2013, 21:42

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

Quellcode

1
for (T x = 0; x < 42; x++) {


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.
Der einfachste Weg eine Kopie zu entfernen ist sie zu löschen.
- Stephan Schmidt -

Beiträge: 1 239

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

252

20.05.2013, 22:00

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.

Architekt

Community-Fossil

Beiträge: 2 496

Wohnort: Hamburg

Beruf: Student

  • Private Nachricht senden

253

20.05.2013, 22:07

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.
Der einfachste Weg eine Kopie zu entfernen ist sie zu löschen.
- Stephan Schmidt -

254

21.05.2013, 18:21

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...

255

21.05.2013, 20:49

"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
:D
Seit längerem mal wieder ganz kurz angefangen, gleich was Schönes reingehauen:

C-/C++-Quelltext

1
2
3
4
for(unsigned int i=0;i<m_vec.size();++i)
    for(unsigned int i=0;i<m_vec[i].size(); ++i)
        if(m_vec[i][i].Intersects(sf::FloatRect(pa))
             m_vec[i][i].MarkMe(true);


Sollte da auf jeden Fall noch refaktorisieren, aber nööö... xd Ich fange irgendwann nochmal an. :D
Das gibt Übersicht! Stay gold. | gnu.org | §\pi\approx\tfrac{7809723338470423412693394150101387872685594299}{2485912146995414187767820081837036927319426665}§ | Jabber: dasnacl@dasnacl.de (online?)

TrommlBomml

Community-Fossil

Beiträge: 2 143

Wohnort: Berlin

Beruf: Software-Entwickler

  • Private Nachricht senden

256

24.05.2013, 09:06

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!

C-/C++-Quelltext

1
2
3
if ( r_norefresh->integer ) {
        return;
    }

BlueCobold

Community-Fossil

Beiträge: 10 890

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

257

24.05.2013, 10:08

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.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Beiträge: 1 239

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

258

24.05.2013, 12:40

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.

259

24.05.2013, 15:59

Ich finde an short nichts verwerfliches. Bringen tut es aus Performance- und/oder Speichersicht vermutlich nichts, aber schlimm finde ich daran auch gar nichts zumal ich mal einfach behaupte, dass ne Schleife die ~32k mal durchläuft im Allgemeinen ehh irgendwie sehr fragwürdig zu sein scheint.

Fred

Supermoderator

Beiträge: 2 132

Beruf: Softwareentwickler

  • Private Nachricht senden

260

31.05.2013, 20:56

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

C-/C++-Quelltext

1
2
3
4
if( i == array.length - 1 )
    i = i - array.length - 1;

array[i] = ...;

Werbeanzeige