Suchergebnisse

Zitat von xChRoNiKx: „Ich denke hier wäre dann auch ein goto kürzer und eleganter“ Anstatt eines Goto wäre hier ehere eine besseres Datenmodell angebracht welches sich leicht filtern lässt. Dann hast du keine Schleifen mehr und brauchst weder mehrere Breaks, noch Goto. Goto sollte in der allgemeinen Applikationsprogrammierung nicht mehr verwendet bzw. empfohlen werden.

Zitat von jvbsl: „Das hat nichts mit dem Datenmodell zu tun, es gibt genügend Algorithmen wo soetwas nötig ist.“ Du kannst grundsätzlich immer zuerst deine Daten filtern und danach mit den gefilterten Ergebnissen arbeiten. Manchmal ist es dafür halt notwendig das Datenmodell zu verbessern. Goto sollte definitiv nicht mehr verwendet werden. Dass der Compiler das aus Optimierungsgründen macht ist mir bewusst. Und dass alle If und Switch statements zu Jumps kompiliert werden ist mir auch bewusst, a…

Unter den ersten Einträgen auf Google. u.arizona.edu/~rubinson/copyri…o_Considered_Harmful.html Als Programmierer solltest du Code schreiben der gut verständlich und wartbar ist und nicht einfach nur funktioniert

@jvbsl zu 2.: Der C# Compiler ist schon ziemlich gut im optimieren. zu 3.: Das glaube ich kaum. Man kann auch gut leserliche Algorithmen schreiben die trotzdem schnell genug sind. Zitat von ErfinderDesRades: „und noch 'ne Umdrehung...“ Das war keine Umdrehung sondern ein Zusatz. Von den beiden Code Snippets die du gepostet hast ist keines wirklich zu bevorzugen, aber ohne zu wissen was das Ergbnis der Schleifen sein soll, kann ich dir hier leider keinen besseren Algorithmus präsentieren. Viellei…

Also ich hab hier grad einen Test gemacht. Einmal mit zwei for loops und einmal mit LINQ. Die LINQ Version ist nicht nur etwas schneller, sonder drückt auch genauer aus was passieren soll, anstatt wie es passieren soll. Also würde ich mal behaupten dass es sehr wohl optimiert wird. Soweit ich weiß ist LINQ lazy. Dadurch kannst du mehrere Filter zusammenhängen, ohne dass sich das zu sehr auf die Performance auswirkt.

Zitat von ErfinderDesRades: „Aber leider ein Zusatz ohne zusätzliche Information/Argumentation. Dass man gut verständlichen und wartbaren Code schreiben soll, ist ja längst Konsens.“ Dass man keine Goto's mehr verwendet auch. Zitat von jvbsl: „Jeder LinQ Code lässt sich anders und performanter programmieren“ Man kann auch alles in Assembly programmieren. Da kann man noch bessere Optimierungen vornehmen. Zitat von jvbsl: „Und für die Behauptung du hast den Unterschied getestet und LinQ war schnel…

Zitat von jvbsl: „Du hast die Behauptung aufgestellt, dass LinQ performanter sei“ *sein kann. Ich hab nur gesagt dass ich Code habe, der mit Linq besser performt, nicht dass jeder Code mit Linq besser performt. Zitat von jvbsl: „Ich denke sonst ist das Ergebnis nicht ganz fair, da wenn ich das richtig gesehen habe der LinQ teil erst in Zeile 92 evaluated wird“ Richtig. Wenn man das Query zu einer Liste forced ist es gleich schnell wie die For Methode. Aber da man im vorhinein nicht immer weiß, w…

Klar gibt es die und iterator sind auch ein tolles Konzept. Aber ich bin mittlerweile ein riesen Fan von Code der Ausdrückt was passieren soll und nicht wie. Das größte Problem mit Schleifen und iteratoren ist, dass ich mir die Implementierung ansehen muss um zu verstehen was passiert. Das kostet Zeit und es macht es einfacher einen Bug einzubauen. Im Endeffekt muss man sowieso anhand der Problemstellung entscheiden was besser ist, aber grundsätzlich sollte man die höchste Abstraktion die zur Ve…

Ja ist Gewöhnungssache. Bei kleineren Code Beispielen sind die Extension Methods definitiv schöner Ich hab grad den IL angesehen und etwas recherchiert. Unterschiede zwischen LINQ und Iterator:- Iterator werden vom Compiler zu einer Statemachine umgewandelt - LINQ verwendet hingegen einen interne IEnumerable Klasse - LINQ hat (in diesem Beispiel) eine Allozierung mehr als der Iterator - LINQ läuft langsamer als der Iterator Anscheinend wird die generierte Statemachine besser optimiert als das ge…

Ich meinte Verschachtelte Iteratoren