Pracht und Armut der PLO - Seite 2
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Warum sollte ich die Kompilierungsmechanismen verstehen? Nur um zu glauben, dass ein schlechtes Ergebnis besser ist als ein gutes?
Tests richtig zu schreiben und die Leute nicht in die Irre zu führen.
Sie verstehen nicht einmal, was Sie in Ihren Tests geschrieben haben und was Sie tatsächlich testen.
Dies ist die Folge der Massenausbildung in Dotnet und ähnlichen Sprachen. Programmierer haben absolut keine Lust zu verstehen, was wirklich funktioniert und wie es funktioniert.
Tests richtig zu schreiben und die Leute nicht in die Irre zu führen.
Sie verstehen nicht einmal, was Sie in Ihrem Test geschrieben haben und was Sie tatsächlich testen.
Das sind die Folgen der Massenausbildung in Dotnet und ähnlichen Sprachen. Programmierer haben absolut keine Lust zu verstehen, was und wie die Dinge in der Realität funktionieren.
Jeder hat seine eigenen Scheuklappen über den Augen, wie Pferde (damit sie nicht zu viel sehen).
Der eine sieht das Eigene, der andere das Eigene. Das heißt aber nicht, dass beide richtig oder falsch sind.
Die Wahrheit liegt irgendwo in der Nähe.
Der Entwickler wollte das eine und bekam das andere. Das bedeutet nicht, dass die Aufgabe erfüllt ist. Aber es funktioniert. Vielleicht nicht so, wie es erwartet oder gewünscht wurde.
Der Benutzer macht seinen Test (der ziemlich vorhersehbar ist). Das bedeutet nicht, dass der Test alle Parteien zufrieden stellen wird.
Die Wahrheit liegt auf der Hand.
Die Geschwindigkeit der Operationen ist zu wichtig. Das ist nicht meine Laune, das ist das Leben.
Und Sie müssen es mit Tests beweisen, nicht mit Worten.
Die Geschwindigkeit des Betriebs ist zu wichtig. Das ist nicht meine Laune, das ist das Leben.
Und Sie müssen es mit Tests beweisen, nicht mit Worten.
Ich habe sofort auf die Fehler in den vorgeschlagenen Tests hingewiesen. Dann habe ich den Punkt mehrmals erklärt.
Virtuelle Methoden werden immer teurer sein als normale Methoden, aber das Testen von optimierenden Compilern sollte korrekt durchgeführt werden, wenn man weiß, was/wie minimiert und optimiert wird.
In diesem Fall haben wir noch keine Optimierungsmethode implementiert, um eine virtuelle Funktion automatisch in eine reguläre umzuwandeln (andere Compiler tun dies, wenn es möglich ist), was die Ergebnisse dieses Tests sofort ändern und erneut in die Irre führen würde (ein virtueller Methodenaufruf könnte plötzlich schneller sein als ein regulärer).
Virtuelle Methoden werden immer teurer sein als normale Methoden, aber das Testen von optimierenden Compilern sollte korrekt durchgeführt werden, wenn man weiß, was/wie kollabiert und optimiert wird.
In diesem Fall haben wir noch keine Optimierungsmethode implementiert, um eine virtuelle Funktion automatisch in eine reguläre umzuwandeln (andere Compiler tun dies, wenn es möglich ist), was die Ergebnisse dieses Tests sofort ändern und erneut in die Irre führen würde (ein virtueller Methodenaufruf könnte plötzlich schneller sein als ein regulärer).
Das heißt, in diesem Stadium hat Integer Recht. Könntest du das nicht einfach zugeben und sofort erklären? Oder ist da etwas im Weg?
Virtuelle Methoden werden immer teurer sein als konventionelle Methoden, aber das Testen von optimierenden Compilern sollte korrekt durchgeführt werden, wenn man weiß, was/wie minimiert und optimiert wird.
In diesem Fall haben wir die Optimierungsmethode, eine virtuelle Funktion automatisch in eine reguläre Funktion umzuwandeln, noch nicht implementiert (andere Compiler tun dies, wenn es möglich ist), was die Ergebnisse dieses Tests sofort ändern und erneut in die Irre führen würde (ein Aufruf einer virtuellen Methode könnte plötzlich schneller sein als eine reguläre).
Eigentlich wird nicht der Compiler getestet, sondern zwei Methoden zur Lösung desselben Problems. Es ist nicht wichtig, wie der Kühlschrank brummt, sondern wie er einfriert.
Eigentlich war es nicht der Compiler, der getestet wurde, sondern zwei Methoden zur Lösung desselben Problems. Es ist egal, wie der Kühlschrank brummt, wichtig ist, wie er gefriert.
Sie haben einen falschen Test durchgeführt, indem Sie einen vereinfachten und entarteten Testfall vorgelegt haben. Das ist kein Problem, sondern ein zu nichts degeneriertes Beispiel.
Sie haben nicht auf den Optimierer des Compilers geachtet, der die Option der direkten Aufrufe an Dummies stark optimiert.
Sie haben einen falschen Test durchgeführt, indem Sie einen vereinfachten und entarteten Testfall vorgelegt haben. Dies ist keine Aufgabe, sondern gerade ein zu nichts verkommenes Beispiel.
Sie haben nicht auf den Optimierer des Compilers geachtet, der die Option der direkten Aufrufe an Dummies stark optimiert.
Lesen Sie bitte das gesamte Thema noch einmal sorgfältig durch.