Stimmt's? C++ ist schwer zu parsen.
-
Gregor schrieb:
...anzeigen, sondern stattdessen die Zeile 144 in der betroffenen Datei markieren und dazu sagen, dass da ein const vergessen wurde, dann wäre man schon ein ganzes Stück weiter. Da würde ich mich dann glatt auch wieder für C++ begeistern können.

Code::Blocks markiert mir eigentlich immer die Zeile, wo der Fehler ist. vielleicht mußte für c++ auch ne IDE benutzen.
-
Also solche Error-Meldungen sind schon extream schlecht. Aber mit MSVC7.1 hat sich das schon sehr gebessert. Template-Fehler werden schon recht verständlicher dem User mitgeteilt. MSVC8 soll es wohlsogar besser sein.
Die Zeile markieren kann VC++ in dem ich auf die Fehlermeldung einen Doppelklick mache. Fehler und Warnings werden zus. in der Todo-Liste tabellarisch angezeigt, wo ich dann die Errors/Warnings sortieren lassen kann.
Aber die IDEs sind im Endeffekt tatsächlich noch sehr weit weg von Java-IDEs.
-
volkard schrieb:
Gregor schrieb:
...anzeigen, sondern stattdessen die Zeile 144 in der betroffenen Datei markieren und dazu sagen, dass da ein const vergessen wurde, dann wäre man schon ein ganzes Stück weiter. Da würde ich mich dann glatt auch wieder für C++ begeistern können.

Code::Blocks markiert mir eigentlich immer die Zeile, wo der Fehler ist. vielleicht mußte für c++ auch ne IDE benutzen.
Interessant. Wie ist diese Zeile denn definiert? In der Fehlermeldung da oben taucht die Zeile, in der der Fehler tatsächlich steckt, zumindest an keiner Stelle auf. Woher kriegt die IDE die Zeile, wenn der Compiler sie nicht findet?
-
/home/gregor/vigra/vigra1.4.0/include/vigra/multi_pointoperators.hxx:858: error: passing `const CornerResponseFunctor<3, double>' as `this' argument of `ValueType CornerResponseFunctor<N, ValueType>::operator()(ValueType, ValueType) [with int N = 3, ValueType = double]' discards qualifiershier bitte das sagt alles
- nicht das fehlende const ist für den compiler der fehler, sondern der falsche aufruf. was ja auch stimmt. irgendwie.EDIT: das habe ich tatsächlich durch schnelles überfliegen der meldung gefunden
-
Mr. N schrieb:
/home/gregor/vigra/vigra1.4.0/include/vigra/multi_pointoperators.hxx:858: error: passing `const CornerResponseFunctor<3, double>' as `this' argument of `ValueType CornerResponseFunctor<N, ValueType>::operator()(ValueType, ValueType) [with int N = 3, ValueType = double]' discards qualifiershier bitte das sagt alles
- nicht das fehlende const ist für den compiler der fehler, sondern der falsche aufruf. was ja auch stimmt. irgendwie.EDIT: das habe ich tatsächlich durch schnelles überfliegen der meldung gefunden
Na gratuliere. Dann schickt mich die Fehlermeldung also ganz tief in die von mir genutzte Bibliothek. ...ganz weit vom Fehler weg.

-
Gregor schrieb:
Na gratuliere. Dann schickt mich die Fehlermeldung also ganz tief in die von mir genutzte Bibliothek. ...ganz weit vom Fehler weg.

Das ist nunmal so mit Callbacks. Der Compiler denkt: "Die Library verwendet deinen Code falsch." - dass es andersrum ist, KANN er garnicht ahnen.
Ja, er könnte bessere Meldungen bringen. Das muss halt jemand implementieren. Und da stecken Sun, MS und IBM bei Java und .NET halt mehr Geld rein als z.B. die GCC-Entwickler.
-
Gregor schrieb:
Wie ist diese Zeile denn definiert?
durch "error:".
eigentlich durch "([ \tA-Za-z0-9_:+/\.-]+):([0-9]+):[ \t](.*)", nachdem ein paar andere regexps warnungen und so schon gefunden haben.In der Fehlermeldung da oben taucht die Zeile, in der der Fehler tatsächlich steckt, zumindest an keiner Stelle auf. Woher kriegt die IDE die Zeile, wenn der Compiler sie nicht findet?
sondern stattdessen die Zeile 144 in der betroffenen Datei markieren und dazu sagen, dass da ein const vergessen wurde
du beklagst dich doch auch nicht bei nem tippfehler in der deklaration, daß die ide gefälligst deine gedanken lesen soll und statt beinm aufruf bei der deklaration den cursor hinsetzen soll. und mal ernsthaft, wie stellste dir das bei const vor? bei jedem aufruf einer stl-funktion soll er in den stl-code springen, weil er annimmt, der aufrufer ist nicht dran schuld, sondern die benutzen klassen haben schlechte deklarationen? oder manchmal andersrum, weil ich der stl was untergejubelt hab. oder speichern wir zu jeder datei den ersteller ab und machen nen intelligenzvergleich und der laut datenbank dümmere kriegt immer den cursor? wenn wir einfach nur davon ausgehen, daß der c++-programmierer ein krasses anfängerbuch und effektiv c++ programmieren gelesen hat, ist ihm mit einer ide, die ihn einfach auf die fehlerzeile schmeißt, viel mehr gedient, als mit einer hypothetischen vermuteter-fehler-anzeige. sollte so viel kraft über sein, ein system zu bauen, das aus fehlerhaftem code korrekten code baut, ist es für eine noch zu erfindende unscharfe programmiersprache sprache benutzen. bei c++-IDEs ist sowas fehl am platze. man will sich ja auch an das immer gleiche verhalten des compilers gewöhnen, so wie man sich an sein auto gewöhnt, und nach kurzer zeit erfasst man solche fehler ohne genauer hinzusehen.
aber ich weiß schon, in "Rund um die Programmierung" ist es zur zeit modern, aus java-sicht mit möglichst wenig fachwissen an c++ rumzunörgeln.zum topic: ja, c++ ist schwer zu parsen.
-
@volkard: Schon gut.
Ich habe hier ja nur ne Frage gestellt und ich hatte den Fehler, als er vor ein paar Tagen auftrat, ja auch gefunden. Aber es ärgert einen halt als Nicht-C++-Profi, dass man bei einem Fehler gleich mit so einer riesigen Fehlermeldung erschlagen wird. Warum kann so eine Fehlermeldung nicht etwas lesbarer sein? ...ok, für Dich ist sicherlich nach 2 Sekunden klar, was da schief gelaufen ist. Für mich zugegebenermaßen nicht. 
MrN hat im Chat angedeutet, dass mit dem neuen Standard "Concepts" kommen sollen, die bei so einer Fehlermeldung wohl etwas bringen. Ich bin da also ganz optimistisch, dass soetwas in Zukunft lesbarer werden wird. Hoffentlich kommt der neue Standard bald.
BTW: Die Java-IDEs machen tatsächlich immer ein paar Vorschläge zur Korrektur von Fehlermeldungen, die natürlich auch mit einbeziehen, was der Nutzer falsch gemacht haben könnte. Da nutzt man Fehlermeldungen nicht nur, um Fehler zu beheben, sondern auch, um mit ein paar Klicks bestimmte Methoden zu deklarieren, also zur Generierung von Code. ...ein durchaus praktisches Feature der IDEs. Einen, zu dem hier geposteten Fehler, äquivalenten Fehler gibt es zwar so bei Java nicht, aber ich sehe keinen Grund, warum eine IDE nicht den passenden Vorschlag zur Korrektur dieses Fehlers anbieten sollte.
-
Gregor schrieb:
...ok, für Dich ist sicherlich nach 2 Sekunden klar, was da schief gelaufen ist. Für mich zugegebenermaßen nicht.

das "discards qualifiers" sagt "du hast nen fehler mit const" gemacht. zusammen mit der angewohnheit, oft zu compilieren, weiß man ja, was man zuletzt gemacht hat und 2 sekunden wären verdammt lang. natürlich ne IDE vorausgesetzt, die den fehlertext des ersten fehlers immer an die gleiche stelle auf dem bildschirm schreibt und die entsprechende codezeile markiert.
MrN hat im Chat angedeutet, dass mit dem neuen Standard "Concepts" kommen sollen, die bei so einer Fehlermeldung wohl etwas bringen. Ich bin da also ganz optimistisch, dass soetwas in Zukunft lesbarer werden wird. Hoffentlich kommt der neue Standard bald.
ja, wird zeit.
BTW: Die Java-IDEs machen tatsächlich immer ein paar Vorschläge zur Korrektur von Fehlermeldungen, die natürlich auch mit einbeziehen, was der Nutzer falsch gemacht haben könnte. Da nutzt man Fehlermeldungen nicht nur, um Fehler zu beheben, sondern auch, um mit ein paar Klicks bestimmte Methoden zu deklarieren, also zur Generierung von Code.
ja, daran könnte ich mich gewöhnen. dem würde ich gleich beibringen, daß ein fehler in einer zeile, wo retrun vorkommt, vermutlich behoben werden kann, wenn man stattdessen return schreibt.
-
Was ich viel interessanter finde: C++ (und eigentlich alle Programmiersprachen) sind so angelegt, dass sie in linearer Zeit zu parsen sind. Find ich persoenlich cool, weil wenns das nicht gaebe gaebs auch kein n'naja-probiern-wir-mal-das-und-schaun-was-es-tut' weil man immer ein paar Wochen auf das Binary warten muesste.
-
Ok vergessen wirs, ich bin blind.
*fg*