spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

*hust* clang *hust*

Ich könnte mir vorstellen, dass dieses Feature bei großem Sourcecode Volumen und nicht internen Funktionen schon ein wenig Rechenzeit kosten könnte. Die Frage ist, braucht man sowas wirklich?

Zitat von »LukasBanana«

[...] und "identifier XY not found" ist nicht gerade die hilfreichste Information, wie ich finde.

Da hat jemand wohl noch nie mit JavaScript im Internet Explorer 7 gearbeitet, oder? Dort lautet die entsprechende Fehlermeldung einfach nur "Das Objekt unterstützt die Eigenschaft oder Methode nicht!", auch obwohl der Fehler nur bei ungültigen Aufrufen von Methoden (Funktionen unterhalb von Objekten) auftreten kann.
Mit etwas Glück bringt einem die Zeilenangabe auch gar nichts, weil sie einfach nur falsch ist.

Und ich meine bereits weniger aussagekräftige Meldungen bekommen zu haben, nur hatte ich die oben beschriebene schon oft genug.


Unabhängig davon: man sollte sich bei der Anzeige von Alternativen nicht auf 1 Eintrag beschänken. Es kann durchaus sein, dass es mehrere "ähnliche" Methodennamen gibt.
Wenn der Hintergrund der Sprache eher Lernzwecke deinerseits sind, dann sehe ich kein großes Problem, ein solches Feature testweise einzubauen. Ich stimme dir aber dennoch zu, dass aussagekräftigere Fehlermeldungen immer wünschenswert sind, nur hatte mir immer die Aussage gereicht, dass die von mir angegebene Methode nicht vorhanden ist.

Im Normalfall sind es ja auch Tippfehler und da weißt du hoffentlich was du eigentlich tippen wolltest.
Was die Übersetzungszeit angeht, wenn man das ganze jetzt bei einem JIT Compiler einsetzt dann sollte das nicht so ins Gewicht fallen. Der Trend geht dort ja hin. Und interessant ist das Feature alle mal.

Die Sache mit dem JIT Compiler verstehe ich nicht ganz. JIT heißt doch bloß, dass nicht der Code der Plattform ausgeliefert wird sondern der Zwischencode. Warum sollte die Ausführungsart eine Auswirkung auf die Hilfestellungen des Compiler (Front Ends) haben?

Ehrlich gesagt habe ich auch nicht den Eindruck, dass der Trend stark dorthin geht. Die Technik hat ganz klar Grenzen, Microsoft hat zum Beispiel erst vor kurzem eingesehen, dass die Bremse für viele Anwendungen einfach nicht optimal ist und das C# eine Alternative braucht: http://blogs.msdn.com/b/dotnet/archive/2…ve-preview.aspx

Ich finde solche Features übrigens sehr hilfreich. Das Feature kann Zeit sparen, weil man nicht den Namen nachschlagen muss. Besonders weniger erfahrene Programmierer, können von Hilfestellungen profitieren. Das führt zu weniger Frust beim Nutzer. Ich wünschte, mein Compiler würde mehr solche Dinge tun. Mit der Zeit gewöhnt man sich auch an die (schlechten) Fehlermeldungen, weil man einfach lernt, was sie wirklich bedeutet und wie man sie behebt. Besser wäre es, wenn der Compiler da etwas unterstützt! Sacaldur hat da bereits ein gutes Beispiel für eine schlechte Fehlermeldung genannt, aber ich habe früher auch sehr viel häufiger mit Fehlermeldungen gekämpft. Beispielsweise als ich neu wa und noch nicht so genau wusste, was Überladungen sind, war es für mich sehr schwer verständlich wenn der Compiler irgendetwas davon ausgab, dass er keine Überladung gefunden hätte und irgendeine Konvertierung gescheitert wäre. Ich meine, besonders für einen Anfänger wäre es wirklich extrem hilfreich, wenn der Compiler auch noch einen möglichen Lösungsvorschlag macht und die Sache näher erläutert. Ich denke, richtig gute Fehlermeldungen sind echt schwer zu entwickeln, aber so Dinge wie Verbesserungsvorschläge sind definitiv eine gute Idee und die richtige Richtung!

Zitat von »Spiele Programmierer«

Die Sache mit dem JIT Compiler verstehe ich nicht ganz. JIT heißt doch bloß, dass nicht der Code der Plattform ausgeliefert wird sondern der Zwischencode. Warum sollte die Ausführungsart eine Auswirkung auf die Hilfestellungen des Compiler (Front Ends) haben?

Ehrlich gesagt habe ich auch nicht den Eindruck, dass der Trend stark dorthin geht. Die Technik hat ganz klar Grenzen, Microsoft hat zum Beispiel erst vor kurzem eingesehen, dass die Bremse für viele Anwendungen einfach nicht optimal ist und das C# eine Alternative braucht: http://blogs.msdn.com/b/dotnet/archive/2…ve-preview.aspx

Mit dem Unterschied, dass .NET keinen echten JIT Compiler hat, sondern einen Ahead-Of-Time (am Anfang wurde alles beim Starten durch-compiliert, später dann bei der Installation - der Grund wieso .NET Anwendungen ewig zum installieren benötigen). Ein echter JIT ist z.B. der HotSpot Compiler (C1 & C2) in Java. Dieser optimiert und entfernt tatsächlich zur Laufzeit (teils sehr aggressiv) und muss dann auch schon mal Annahmen rückgängig machen. Allgemein erreicht man mit vollem JIT aber tatsächlich native Geschwindigkeit, da nach dem Aufwärmen der Anwendung eh alles hoch-optimierter, nativer Code ist und dieser durch die Analyse des Laufzeitverhalten auch noch ungenutzte Code-Branches entfernt wurden. Als letzter Punkt (natürlich abhängig vom AOT/JIT Compiler) kann dieser exakt auf die verwendete CPU Architektur optimieren.