Suche Nutzer der aktuellen KDevelop-Version



  • MFK schrieb:

    Was sollte denn da deiner Meinung nach angezeigt werden?

    die Zeile mit dem if wird rot markiert, was einen Syntax-Fehler anzeigen sollte, aber da ist keiner

    MKK schrieb:

    Ob das ein Fehler ist, haengt doch nur davon ab, was in "..." passiert.

    irrelevant, da bereits die if-Anweisung als Fehler angezeigt wird (es war ein simples return innerhalb der Klammern)



  • zwutz schrieb:

    die Zeile mit dem if wird rot markiert, was einen Syntax-Fehler anzeigen sollte, aber da ist keiner

    Ach so. Ich dachte, du meintest, dass da ein Fehler angezeigt werden sollte, das aber nicht passiert. Das war aus deinem ursprünglichen Beitrag nicht genau zu erkennen.

    FYI: Auch KDevelop 3.5.2 zeigt da einen Fehler an.

    Ganz allgemein ist die Syntaxprüfung in KDevelop IMHO ziemlich mies, zumindest was C++ angeht.



  • zwutz schrieb:

    MFK schrieb:

    Was sollte denn da deiner Meinung nach angezeigt werden?

    die Zeile mit dem if wird rot markiert, was einen Syntax-Fehler anzeigen sollte, aber da ist keiner

    wie wär's wenn du dir die Compilerausagebe anschaust? Es kann mehrere Gründe geben, warum diese Zeile syntaktisch fehlerhaft ist.



  • Ob > oder >= da hingehört kann der Compiler doch gar nicht wissen, das hängt ja ganz davon ab was mit a vorher passiert.



  • supertux schrieb:

    wie wär's wenn du dir die Compilerausagebe anschaust? Es kann mehrere Gründe geben, warum diese Zeile syntaktisch fehlerhaft ist.

    KDevelop beklagt sich (zumindest in der mir vorliegenden Version) über den Punkt, was hier totaler Unsinn ist. Der "Fehler" verschwindet übrigens, wenn man den Teil mit a < 0 aus der Bedingung entfernt.



  • supertux schrieb:

    wie waer's wenn du dir die Compilerausagebe anschaust? Es kann mehrere Gruende geben, warum diese Zeile syntaktisch fehlerhaft ist.

    der compiler zeigt wie erwartet keinen Fehler an und auch die Zeile ist syntaktisch richtig. Es ist auch irrelevant, ob da > oder >= stehen muss

    Ich glaube auch, ihr versteht mich falsch. Die Zeile beinhaltet KEINEN Fehler. Auch der Compiler gibt keinerlei Warnung oder gar Fehler aus. Das Problem ist, dass mir KDevelop die Zeile dennoch als falsch hervorhebt. Wahrscheinlich interpretiert er die beiden spitzen Klammern als Templateparameter



  • Und wenn du es umstellst oder die Ausdrücke noch mal klammerst. Sieht er es dann auch noch als Fehler an?

    Naja, C++ ist halt nicht einfach zu parsen :(.

    (:p das kommt davon, wenn man offenbar einen vorzeichenbehafteten Typ für eine Längenangabe nimmt :p)



  • ruediger schrieb:

    Und wenn du es umstellst oder die Ausdruecke noch mal klammerst. Sieht er es dann auch noch als Fehler an?

    Naja, C++ ist halt nicht einfach zu parsen :(.

    (:p das kommt davon, wenn man offenbar einen vorzeichenbehafteten Typ fuer eine Laengenangabe nimmt :p)

    Klammern oder umstellen schafft Abhilfe

    der Typ ist daabei auch irrelevant. Ich kann hernehmen, was ich will, sobald diese operatorkombination in Verbindung mit einem Methodenaufruf beim letzten Operand kommt, wird es als Fehler markiert

    Folgendes geht also:

    if ( a < b || b > a ) { ... }
    


  • Hast du den Bug gemeldet? (Wenn nicht: böse böse.)

    Naja, mit dem Typ hat es ja schon was zu tun, weil der Test a<0 ja unnötig wäre (ganz zu schweigen von möglichen (Sicherheits-)Problemen durch Integeroverflows etc.). Im Grunde wäre hier ein striktes Typesystem besser, so wie ADA. Wo man direkt eine Range angibt. Aber gut, dass führt nun alles zu weit weg von deinem Problem :).

    Und klar, dass ist ein böser Bug! Aber C++ ist leider sehr sehr schwer zu parsen. Da kann man nur hoffen, dass es bald einen vernünftigen freien Parser gibt, den man für solche Analysen benutzen kann. (GCC-Frontend ist ja leider zu sehr mit dem Backend verwoben). Da kann man nur hoffen, dass LLVMs Clang bald einen vernünftigen C++-Support hat.



  • rüdiger schrieb:

    Hast du den Bug gemeldet? (Wenn nicht: böse böse.)

    hab ich getan sobald mir hier gesagt wurde, dass der Fehler in der aktuellen Version auch besteht



  • Im Bugzilla ist der Fehler eingetragen.
    http://bugs.kde.org/show_bug.cgi?id=133504

    Es sind auch noch ein paar andere Parserfehler zu sehen.


Anmelden zum Antworten