Was kompiliert Delphi 10.3.3 da???

[harfes]

@Uwe Raabe: es handelt sich um die TIBCSQL-Komponente aus dem IBDAC-Paket von Devart. Und die eingesetzen Komponenten sind die selben Versionen, die ich auch in 10.2 verwendet.

@jaenicke: ok, Steinigung wird angenommen! Aber: zu meiner "Verteidigung" muss ich sagen, dass ich with schon seit vielen Jahren problemlos nutze (auch in grösseren Projekten) und bisher nie Probleme damit hatte. Aber nach den Erklärungen hier, werde ich das wohl ändern...wenn der Compiler/Debugger nicht wirklich was mit dem Code im with-Bereich anfangen kann, dann hatte ich bisher wohl immer Glück.

@zeras: die gemeldeten Fehler für die 10.3.1 und 10.3.2 hier im Forum sprechen für sich - zumal es bei einigen funktioniert, bei anderen nicht. Das würde ich als unzuverlässig einstufen. Diese Erfahrungen musste auch ich machen, aber die 10.3.3 macht bisher einen guten Eindruck. Des weiteren habe ich alle Delphi-Versionen jeweils in einer eigenen Maschine, so dass ich nur manchmal ein Projekt "hochziehen" muss. Neue Projekte fange ich aber immer in der aktuellsten Version an - sofern diese stabil ist...

Hartmut

[DieDolly]

Ich habe schon seit der ersten kostenlosen Starter-Version seltsame Fehler die es bis heute gibt.
Nicht oft aber immer wieder mal wenn ich ein etwas größeres Projekt kompiliere, wird der Vorgang abgebrochen und mit einem Fehler an einer Zeile quittiert, wo es gar keinen Fehler gibt. Bis vor ein paar Updates war dieser Fehler immer am Ende einer Unit in einer Zeile, wo gar nichts steht. Fehler noch immer da, aber an einer anderen Stelle wo es trotzdem keinen Fehler gibt.

[Bernhard Geyer]

Zitat von DieDolly:

Nicht oft aber immer wieder mal wenn ich ein etwas größeres Projekt kompiliere, wird der Vorgang abgebrochen und mit einem Fehler an einer Zeile quittiert, wo es gar keinen Fehler gibt. Bis vor ein paar Updates war dieser Fehler immer am Ende einer Unit in einer Zeile, wo gar nichts steht. Fehler noch immer da, aber an einer anderen Stelle wo es trotzdem keinen Fehler gibt.

Das könnte aber auch am Virenscanner liegen, der einfach nicht mehr Geschwindigkeit der Compilierung hinterherkommt und zufällig irgendwelche Units blockiert an denen der Compiler/IDE einfach kein Problem erwartet und deshalb auch nicht mit einer vernünftigen Fehlermeldung die eigentliche Ursache beschreibt.

Am besten z.B. die dcu-Dateien vom Scan ausnehmen.

[p80286]

Zitat von harfes:

Aber: zu meiner "Verteidigung" muss ich sagen, dass ich with schon seit vielen Jahren problemlos nutze (auch in grösseren Projekten) und bisher nie Probleme damit hatte.

Du Unglücklicher. Ich war zu TP-Zeiten begeisteter "with"-Nutzer, bis irgendwann einmal die Daten keinen Sinn mehr ergaben. Beim debuggen hat mir ein Vertreter der C-Fraktion über die Schulter geschaut und gemurmelt "woher soll der Compiler wissen was Du meinst?"
Auch ich versuchte es mit "aber bisher.....". Antwort:"aber jetzt nicht!"Natürlich sind Myvalues.Myrecs.Correlation1.recval78.Runtime nicht tippfreundlich oder Übersichtsfördernd aber der Compiler
hat keinen Ermessensspielraum, und das ist's was zählt.

Gruß
K-H

[jaenicke]

Ich bekomme beim einfachen Kompilieren nach einer Änderung im Interface einer Unit auch ab und zu mal einen internen Fehler oder Typ xyz nicht gefunden (der in der Unit deklariert ist). Das lässt sich dann nur mit einem Neuerstellen lösen.

Da das nicht reproduzierbar ist, lässt sich das aber eben kaum melden...

Solche Probleme hatten wir aber auch schon bei XE (dort auch ohne Änderung). Das ist seitdem schon deutlich seltener, tritt aber auch bis mind. 10.3.2 auf.

Zitat von harfes:

wenn der Compiler/Debugger nicht wirklich was mit dem Code im with-Bereich anfangen kann, dann hatte ich bisher wohl immer Glück

Das kannst du ganz einfach testen. Versuche einfach mal per Mouseover den Hint zu der Property SQL zu bekommen. Oder versuche mit Strg + F7 z.B. Params[0].Value aus deinem Code auszuwerten.

Du wirst sehen, dass du da zuerst den Inhalt deines with davor schreiben musst. Und das bremst halt beim Debuggen enorm... zumal du manchmal gar nicht genau siehst, ob du das durch den with-Ausdruck ergänzen musst oder nicht...
Und wenn du dort z.B. Width auswertest und es das außen und im with-Ausdruck gibt, wertet der Debugger von außen aus, z.B auf das Formular bezogen, weil er das woth nicht kennt...

[jaenicke]

Zitat von p80286:

Natürlich sind Myvalues.Myrecs.Correlation1.recval78.Runtime nicht tippfreundlich oder Übersichtsfördernd aber der Compiler
hat keinen Ermessensspielraum, und das ist's was zählt.

Man sollte das ja auch in Variablen zwischenparken.

[p80286]

Eine weitere Möglichkeit!
Hauptsache kein with !

Gruß
K-H

[Bernhard Geyer]

Eine Syntaxerweiterung wie bei VB (ok, ich werde jetzt gesteinigt) würde schon helfen.
Was mit "with" behandelt werden soll muss mit "." anfangen.

[Uwe Raabe]

Zitat von jaenicke:

Man sollte das ja auch in Variablen zwischenparken.

Wobei der MMX Code Explorer beim Eliminieren der with-Bereiche ja diesbezüglich etwas Hilfe anbietet...

[DenkDirNix]

Zitat:

Natürlich sind Myvalues.Myrecs.Correlation1.recval78.Runtime nicht tippfreundlich oder Übersichtsfördernd aber der Compiler hat keinen Ermessensspielraum, und das ist's was zählt.

Einen "Ermessensspielraum" hat der Compiler hier natürlich nicht. Die Reihenfolge der Versuche zum Auflösen der Variablen im with ist durchaus eindeutig vorgegeben.
Das gleiche Problem haben wir ja auch, wenn eingebundene Units identische Bezeichner exportieren. Und dieses Problem ist sogar noch größer, weil kein verdächtiges "with" in der Nähe steht.

Ich halte "with", auf private, lokal deklarierte Strukturen angewendet, für vollkommen okay. Im Debugger muss man dann halt die with-Variable komplett anzeigen und sich ggf durchhangeln. Der Vorteil des with ist gar nicht mal die entfallende Tipparbeit, sondern die Übersichtlichkeit-mangels-Masse des geschriebenen Codes.