Heftiger Bug in RAD Studio 2007 mit auto_ptr und Delphi-Klassen?
-
Hallo
Stimmt, eine Exception wäre besser gewesen. Es gehört eigentlich zum guten Ton Parameter auf Gültigkeit zu prüfen und alles nicht zulässige möglichst nachvollziehbar abzuweisen.
bis bald
akari
-
audacia schrieb:
Wie groß sind eure Quelldateien so im Schnitt, und wie viele Headerdateien werden eingebunden?
Auch wenn das hiesige Projekt von der Codequalität noch weitgehend in Ordnung ist, sind die Dateien leider recht groß und imho auch zu viel inkludieren (Den, was wiederum "aus Übersichtlichkeit" nicht gemacht wurde, ist das auftrennen pro Klasse; auch wenn ich schon gute Argumente dagegen gebracht habe braucht alle Umstellung Zeit).
Von der Projektgröße: Die Gesamtanwendung ist im Release etwa 3MB groß...Ich kann mich "7H3 N4C3R" aber auch Anschließen: Probleme kann ich ebenso bei kleinen Projekten durchaus feststellen, wenn gleich es dort etwas besser ist.
audacia schrieb:
In der Stabilität, ja, aber IntelliSense in VS ist bei weitem nicht so informativ wie Code Completion.
Dem kann ich mich nicht anschließen, da mir zuviel abgeschnitten wird (wenn ich mehrere Sachen zur Auswahl habe, aber nichts sinnvolles mehr erkennen kann, nützt mir auch die Mehrinformation nicht. Und was ich bei der CC noch vermisse ist, das diese auch noch angezeigt wird nachdem man den ersten Parameter eingegeben hat (Ich sehe gerne auch noch die Bezeichnung der nächsten). Aber Grundsätzlich ist weder die C++ Builder- noch die Visual Studio-Lösung ausgereift.
cu André
-
7H3 N4C3R schrieb:
audacia schrieb:
In der Stabilität, ja, aber IntelliSense in VS ist bei weitem nicht so informativ wie Code Completion.
Wobei ich mich frage, ob das nicht zu guten Teilen daran liegt, dass vieles aus Delphi kommt.
Das Code Completion-Backend besteht im Wesentlichen aus comp32x.dll, also dem C++-Compiler. Lediglich die Darstellung ist in Delphi realisiert.
asc schrieb:
Dem kann ich mich nicht anschließen, da mir zuviel abgeschnitten wird (wenn ich mehrere Sachen zur Auswahl habe, aber nichts sinnvolles mehr erkennen kann, nützt mir auch die Mehrinformation nicht.
Ein gültiger Einwand, besonders für templatebasierende Klassen. Seit C++Builder 2007 wird das aber IMHO deutlich besser gehandhabt.
asc schrieb:
Und was ich bei der CC noch vermisse ist, das diese auch noch angezeigt wird nachdem man den ersten Parameter eingegeben hat (Ich sehe gerne auch noch die Bezeichnung der nächsten).
Du meinst Parameter Insight? Dann drücke doch Strg+Shift+Space
asc schrieb:
Aber Grundsätzlich ist weder die C++ Builder- noch die Visual Studio-Lösung ausgereift.
Und beide werden nie auf dem Niveau von Java- oder Delphi-CC ankommen. Leider
-
audacia schrieb:
asc schrieb:
Aber Grundsätzlich ist weder die C++ Builder- noch die Visual Studio-Lösung ausgereift.
Und beide werden nie auf dem Niveau von Java- oder Delphi-CC ankommen. Leider
Das Problem wäre wohl aber eher C++ zuzuschreiben. Für die "perfekte" Lösung bräuchte man ja immer eine vollständige Compilierung.
-
7H3 N4C3R schrieb:
Für die "perfekte" Lösung bräuchte man ja immer eine vollständige Compilierung.
Selbst für die nicht-perfekte Lösung benötigt dies der C++ Builder von Zeit zu Zeit...
-
Lange ist mein Post inzwischen her.
Da es aber endlich (vermutlich) Aufschluss für mich gab, woran das ursprüngliche Problem lag, will ich euch auch nicht dumm lassen. Das Problem, was hier anscheinend auftritt, passiert wohl immmer (oder nur gelegentlich?) dann, wenn man C++-Objekte (Non-POD und größer als 4 Byte) durch eine closure zurück gibt. GodeGuard moniert dann Sachen wie "Method called on illegally casted object".
Wie es aussieht, reserviert der C++-Builder 2007 Compiler immer/hin und wieder (eine genaue Systematik konnte ich nicht feststellen) nur 4 Bytes auf dem Stack für solche Zwecke, was bei komplexen Objekten natürlich den Stack zersägt und kaputte Objekte produziert. Die Konstruktor/Destruktor-Calls scheinen hier auch nicht immer richtig zu funktionieren, was insbesondere zu mehrfach aufgerufenen Destruktoren führen kann.
Was das Problem zu verstärken scheint ist insbesondere eine große Stack-Tiefe. (Stack-Size erhöhen bringt nix, auch die Compilerswitches habe ich wohl inzwischen alle ohne Erfolg durch)
Irgendwie enttäuschend, dass closures immernoch so buggy sind. Eigentlich mochte ich sie als echt tolles Feature für Sachen, die mit Standard-C++ aufwändiger und unflexibler sind. Wenn sie nicht dafür gemacht sind, ist es ja okay - aber dann sollte der Compiler bitte den Code ablehnen.
Eine Lösung über .* und ->* hat mir jetzt zumindest eine funktionierende Abhilfe gebracht.
Mein RAD-Studio 2007 befindet sich übrigens auf dem aktuellsten Patch-Level (der inzwischen auch schon wieder asbach ist). Mit einem Fix ist hier wohl nicht mehr zu rechnen...
-
Das ist in der Tat ein Compiler-Bug; bitte erstelle QC-Report mit reproduzierbarem Testfall.
In den Newsgroups tauchte auch gerade ein Problem mit Rückgabewerten von Closures auf. Ursache der vielen Probleme in diesem Bereich dürfte sein, daß Closures fast immer Typen ohne Rückgabewert sind (per Konvention für die Events in der VCL) und somit praktisch kein Testfall dafür existiert.
-
Jetzt wo ich weiß - bzw. mir ziemlich sicher bin - dass es an der Closure liegt, werde ich, hoffe ich mal, auch einen reproduzierbaren Testfall bauen können. Vorher hatte ich der Closure keine Beachtung geschenkt. An der ursprünglichen Vermutung mit den auto_ptr's lag es nicht - bzw. teilweise selbst geschuldet mit undefiniertem Verhalten.
Wenn ich den QC-Report fertig habe, lass ich dich mal die Nummer wissen.
In der Tat - Closures haben wirklich selten Rückgabewerte und wenn dann i.d.R. primitive Datentypen bzw. Pointer auf Klassen im Delphi-Stil. Da kann der Compiler ja kaum etwas falsch machen. Ich forsche mal weiter hier.
-
Hallo
Wenn es nur an dem Rückgabetyp liegt, dann verleg diese Übergabe doch auf eine Referenz in der Parameterliste. Das sollte keine Probleme machen.
bis bald
akari
-
Das geht nicht, da das Objekt aus gutem Grund nicht Default-Constructible ist.
Wie gesagt, Callbacks über ->* funktionieren prima.