Unverständliche Compilerwarnung – Erwartet: ')' aber ','enthalten

[Andreas13]

Hallo Community,
Warum gibt der XE5-Compiler hier diese Warnung aus?

Delphi-Quellcode:

Type
  DoubleDouble = Record
  public
    X: Array [0..1] of Double;
  . . . 
End;

  . . . 

Type
  _DoubleDoubleHelper = Record Helper for DoubleDouble
  Const
    Pi: DoubleDouble = (X: (3.141592653589793116E+00,
                            1.224646799147353207E-16));
  . . . 

End;

Compilerwarnung: Erwartet: ')' aber ','enthalten . . .
Fehlerhaft wird das schließende Komma markiert in dieser Zeile:

Delphi-Quellcode:

(X: (3.141592653589793116E+00,

:wall:

Was ist hier falsch und wie kann ich den Fehler beheben?

Danke für Eure Hilfe!

Gruß, Andreas

[EDIT]
Den von mmw in #6 bemerkten Tippfehler habe ich gerade korrigiert. :oops:

[venice2]

zähle mal die offenen und geschlossenen Klammern. Fällt was auf?

[himitsu]

Weil diese Klammer falsch ist?
In die Klammer muß ja ein zweiter Wert für das Array rein. :wink:

Ach ja, nach dem X kommt in dem Record nichts mehr, also sagt dir diese Meldung, dass dort kein Komma kommen kann, weil der Record zu Ende ist.



PS: Es gibt eine Konstante für Pi.


@venice2: Zählen hilft hier nur bedingt.
Ja, die erste Klamme beim )); stimmt nicht (obwohl sie ja eigentlich richtig ist),
aber es löst nicht dieses Problem, dass die Klammer zu früh zu ging.

[venice2]

Zitat:

aber es löst nicht dieses Problem, das die Klammer zu früh zu ging.

Richtig aber alleine das hätte ihn schon stutzig machen müssen ;)

[Andreas13]

Zitat:

Zitat von himitsu (Beitrag 1489496)

PS: Es gibt eine Konstante für Pi.

Ja, aber das ist 128-Bit genau.

Der obige Code ist Teil der Bibliothek

Delphi-Quellcode:

Neslib.MultiPrecision.pas

und diese treibt mich in den Whnsinn. . . https://entwickler-ecke.de/topic_Hil...7d3d26ea45cba5

Dort bin schon seit 2 Wochen mit Sebastian Jänickes tatkräftiger Unterstützung auf der Fehlersuche. Eigentlich wollte ich schon gestern kapitulieren, doch ich kann die Finger doch nicht davon lassen.

Weil ich auf der Suche nach verschleppten Fehlern bin, erschien mir diese Art der Konstanten-Deklaration in der Bibliothek verdächtig. Möglicherweise wird dieses Konstrukt in neueren Delphi-Versionen anders gehandhabt als in XE5 oder XE6.

Was wäre die korrekte Konstanten-Deklaration, die auch XE5 richtig deutet?
Andreas

[mmw]

hallo,

Delphi-Quellcode:

Type
  _DoubleDoubleHelper = Record Helper for DoubleDouble
  Const
    Pi: DoubleDouble = (X: (3.141592653589793116E+00,1.224646799147353207E-16));
end;

so war's glaube ich gemeint. siehe #3

Gruß

[himitsu]

Wie esagt, nicht das Komma, sondern die Klammer davor ist falsch. (die Fehlermeldung "Anzahl" im Array ist falsch, kommt wohl erst später)

[Andreas13]

Zitat:

Zitat von mmw (Beitrag 1489499)

Delphi-Quellcode:

Type
  _DoubleDoubleHelper = Record Helper for DoubleDouble
  Const
    Pi: DoubleDouble = (X: (3.141592653589793116E+00,1.224646799147353207E-16));
end;

Dei gleiche Compilerwarnung bleibt trotzdem erhalten...
Gruß, Andreas

[Andreas13]

Zitat:

Zitat von himitsu (Beitrag 1489500)

Wie esagt, nicht das Komma, sondern die Klammer davor ist falsch. (die Fehlermeldung "Anzahl" im Array ist falsch, kommt wohl erst später)

Ohne Klammer davor "meckert" der Compiler sofort.
Übrigens:
Es gibt noch eine zweite (neben vielen!) Warnung zum obigen Eintrag, vielleicht ist die hilfreich bei der Lösung der Problematik:
"undeklarierter Bezeichner: 'X' in Zeile..."
Das ist für mich genau so unverständlich.

[Andreas13]

Zitat:

Zitat von mmw (Beitrag 1489499)

hallo,

Delphi-Quellcode:

Type
  _DoubleDoubleHelper = Record Helper for DoubleDouble
  Const
    Pi: DoubleDouble = (X: (3.141592653589793116E+00,1.224646799147353207E-16));
end;

so war's glaube ich gemeint. siehe #3

Danke, mmw! Den von Dir genannten Tippfehler habe ich erst jetzt bemerkt und korrigiert.
Damit ist mein Post #8 ist hinfällig... :oops:

[Andreas13]

Zitat:

Zitat von himitsu (Beitrag 1489500)

Wie esagt, nicht das Komma, sondern die Klammer davor ist falsch. (die Fehlermeldung "Anzahl" im Array ist falsch, kommt wohl erst später)

Eine eichte Fehlermeldung gibt XE5 nicht aus, nur zahlreiche Warnungen.

[EDIT]
Das Wort Fehler erscheint zwar im Struktur-Fenster, der Compiler setzt sich aber munter darüber hinweg.

[himitsu]

Ja, Error-Insight und Compiler sind unabhängig. Und leider arbeiten sie an vielen Stellen nicht gleich. (hier wird was eingebaut, aber drüben macht man es anders oder vergisst es einfach)
Durch das neue LSP besteht aber die Hoffnung, dass Beides (und Anderes) irgendwann in 200 Jahren mal den selben Code verwenden und auch gleiche Ergebnisse liefern.

[venice2]

Zitat:

Danke, mmw! Den von Dir genannten Tippfehler habe ich erst jetzt bemerkt und korrigiert.

Nun ja darauf habe Ich im 2 Post schon hingewiesen. Scheint aber nicht angekommen zu sein.
2 offene und 3 geschlossene Klammern das konnte es eigentlich nicht sein.

[Andreas13]

@ venice2:
Sorry, ich sehe vor lauter Bäumen den Wald nicht mehr. Beim "Formatieren" habe ich wohl eine überflüssige Klammer eingefügt. :oops:

[EDIT]
Abder das Problem bleibt bestehen!

[venice2]

leeres projekt deinen record addiert kompiliert ohne Fehler oder Warnung. 10.4.2

Delphi-Quellcode:

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs;

Type
  DoubleDouble = Record
  public
    X: Array [0..1] of Double;
  End;

  _DoubleDoubleHelper = Record Helper for DoubleDouble
  Const
    Pi: DoubleDouble = (X: (3.141592653589793116E+00,
                            1.224646799147353207E-16));
End;

type
  TForm1 = class(TForm)
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

end.

[Andreas13]

Danke Emil,
ich glaube es liegt wohl an XE5: s. HardCopy.jpg im Anhang.
Gruß, Andreas

[venice2]

Schallte mal CodeInsight unter Tools\Optionen aus.
Zur Vervollständigung.. mein Shot.

Du hast keinen Fehler (Das Projekt sollte kompilieren) CodeInsight spinnt bei dir rum.
Diese angebliche Fehler Hierarchie wird von CodeInsight im Structure Fenster erstellt das kannst du getrost ignorieren bzw. Schalte CodeInsight aus.

Siehe dazu!

Zitat:

Ja, Error-Insight und Compiler sind unabhängig. Und leider arbeiten sie an vielen Stellen nicht gleich.

Wird sich auch in der Zukunft leider wohl nicht ändern.

EDIT:
Siehe hier!

[Andreas13]

Danke Emil, die Fehlermeldung durch CodeInsight ist verschwunden! :thumb:
Allerdings bleibt mein ursprüngliches Problem mit der Bibliothek leider weiterhin bestehen. Mein Tipp waren etliche derartige Vorbelegungen typisierter Konstanten-Arrays in der MPA-Bibliothek.
Dann muß ich wohl dem Phantom weiter hinterherjagen... :wall:

Vieleicht mache ich dazu demnächst doch ein neues Topic auf, oder ich steige aus Verzweiflung doch auf eine aktuelle Delphi-Version um.

Gruß, Andreas

PS:
Danke für alle Beiträge!

[himitsu]

[edit]
Also der Compiler sagt nun nichts mehr?
[/edit]

Ob da in den Class/Record-Helpern die Konstanten schon richtig funktionieren?

Eine Dummy-Klasse oder ein Record (siehe TColorIrgendwas) sollte aber schon gehn.

Ich hätte die Konstante in den Record gelegt, aber ich denke mal das funktioniert nicht, mit dem eigenem Typen (der dort ja noch nicht fertig definiert ist).
Bei Klassen geht es aber sehr gut.



Hast diese Konstante mal ganz traditionell probiert? (ohne Record/Klasse/Helper drumrum)

[venice2]

Zitat:

Danke Emil, die Fehlermeldung durch CodeInsight ist verschwunden!

Super :) Freut mich.

Zitat:

Vielleicht mache ich dazu demnächst doch ein neues Topic auf, oder ich steige aus Verzweiflung doch auf eine aktuelle Delphi-Version um.

Wäre wohl besser denn das Problem hier scheint ja erledigt zu sein.

[venice2]

Zitat:

Also der Compiler sagt nun nichts mehr?

Warum sollte? Nach der Berichtung der Klammern.

Die anderen Fehler kamen vom stupiden CodeInsight = <> Compiler

[Andreas13]

Zitat:

Zitat von himitsu (Beitrag 1489520)

Also der Compiler sagt nun nichts mehr?

Der Compiler war zuvor auch immer recht still. Anscheinend war es schon immer CodeInsight.

Zitat:

Zitat von himitsu (Beitrag 1489520)

Ob da in den Class/Record-Helpern die Konstanten schon richtig funktionieren?
...
Ich hätte die Konstante in den Record gelegt, aber ich denke mal das funktioniert nicht, mit dem eigenem Typen (der dort ja noch nicht fertig definiert ist).
Bei Klassen geht es aber sehr gut. Hast diese Konstante mal ganz traditionell probiert? (ohne Record/Klasse/Helper drumrum)

In einem meiner zahlreichen Versuche hatte ich mein Glück auch mit globalen Variablen im Implementationsteil der Unit versucht (zuvor natürlich brav initialisiert, was OK war), dann habe ich dem Record-Helper eine neue Funktion hinzugefügt, die den Wert aus den globalen Variablen holt und zurückliefert. Aber der "Haupt-Record" DoubleDouble hat davon gar keine Notiz genommen: also es hat überhaupt nicht funktioniert.

Das Problem, was ich momentan verfolge ist, daß ein Funktionsaufruf z. B. ArcTan2(..) aus den C-Object-Files einmal, zweimal hintereinander korrekt funktioniert, beim 3. Mal kommt ein falsches Ergebnis raus und beim 4. Mal stürzt es ganz ab weil alle Felder des Records -NaN sind.

Manchmal sah ich neben dem DoubleDouble-X-Array auch noch ein namenloses Record-Feld auftauchen und es sah so aus, daß der Wert bei jedem Aufruf der Funktion im Record um 1 weiterspringt, bis ins Leere gegriffen wird. Aber dieses Verhalten kann ich nicht immer reproduzieren.

Ich probiere noch weiter, und mache dazu später ein neues Topic auf.

Danke für Eure Hilfe!

Gruß, Andreas

[Andreas13]

Zitat:

Zitat von venice2 (Beitrag 1489523)

Zitat:

Also der Compiler sagt nun nichts mehr?

Warum sollte? Nach der Berichtung der Klammern...

Nur eine kleine Bemerkung zur Klarstellung: Die überflüssige und irritierende Klammer ')' (s. Post #1) habe ich nur hier im Forum als Tippfehler gehabt. :oops: Im Delphi-Code war alles korrekt und trotdem hat CodeInsight rebelliert.
Andreas

[himitsu]

CodeInsight sind die Infos/Hints zum Code.

ErrorInsight ist die Fehlermarkierung/-info.



Und ja, ErrorInsight hatte schon immer mehr oder weniger Probleme
und zeigt auch gern mal was Falsches an.

Manchmal wird es besser, in der nächsten Version, aber 100% richtig geht es seit Jahrzehnten nicht mehr.
Mit dem neuen LSP gibt es nun Hoffnung, dass es irgendwann mal fast richtig arbeiten könnte. (wenn ErrorInsight auch das LSP benutzt)



Viele nervt das ErrorInsight so sehr, dass sie es abschalten.

[Delphi.Narium]

Das vergleiche ich gerne mit Word oder Openoffice:

Nicht alles, was da unterkringelt ist, ist falsch. Die Software meint das zwar. Ja und?

Was der Kompiler als falsch bemängelt ist falsch, sonst nicht. Egal wer sonst trotzdem behauptet, es sei falsch.

Was der Kompiler nicht bemägelt ist richtig. Egal wer sonst trotzdem behauptet, es sei falsch.

Was der Kompiler als falsch bemängelt ist falsch. Egal wer sonst trotzdem behauptet, es sei richtig.

Und wenn Word oder OpenOffice zuviel als falsch bemängeln, was eindeutig richtig ist, wird die Rechtschreibprüfung eben ausgeschaltet.

Der Kompiler weiß was richtig und was falsch ist. Die anderen stellen nur mehr oder weniger belegbare oder nicht belegbare Behauptungen auf, müssen aber nie den Beweis der Richtigkeit ihrer Aussage erbringen ;-)

[himitsu]

Daher der vermutliche Vorteil vom LSP.

Da ist es dann so, als wenn ein Hintergrundcompilier auf die Unit losgeht
und dessen Ergebnisse dann vom ErrorInsight verwendet werden.
Und wenn Complier und ErrorInsight den selben Code (LSP) verwenden,
müssten da für Compilier und ErrorInsight eben auch die selben Ergebnisse rauskommen. (wenn alles richtig implementiert ist)