Fehlende Features in C++Builder
-
Linnea schrieb:
- beim Debuggen werden Werte von AnsiString-Variablen nicht gleich angezeigt, sondern man muß erst den Unterpunkt 'Data' aufmachen. Hierbei ist es egal ob man bei überwachte Ausdrücke oder bei lokalen Variablen schaut.
Ja, das ist eine der Konsequenzen der Tatsache, daß AnsiString jetzt eine Template-Klasse ist (
typedef AnsiStringT <0> AnsiString;
). Ein ähnliches Problem ergibt sich bei std::string infolge der dort üblichen SSO; der Debugger könnte in der Tat mal etwas intelligentere Auswertung ermöglichen.Linnea schrieb:
- der ClassExplorer mit den dazugehörigen Funktionen aus dem BCB6 fehlt (z.B. "neue Eigenschaft", "neue Funktion" usw.)
Persönlich konnte ich das zwar nie nachvollziehen - das Tippen im Code ging bei mir immer schneller -, aber das ist eines der meistgeforderten Features (271 Votes für QC #23836).
asc schrieb:
Diverse Mängel im Debugger (zum Großteil schon angegeben)
Der Kleinteil interessiert mich auch
asc schrieb:
Fehlende (zudem realistisch funktionierende) Refactoringwerkzeuge.
Ja, gerade in bezug auf das in realen Anwendungen gewöhnlich dysfunktionale "Search references/Rename" stimme ich zu. Dazu gibt es einige Fehlerberichte, z.B. QC #67099.
asc schrieb:
Fehlende const-correctness in Bezug mit VCL-Klassen (const Objekte die ohne Probleme geändert werden können - so wie die Datumsklassen).
Das (QC #67988) scheint ein Compiler-Problem mit einigen DELPHIRETURN-Typen zu sein. Sehr seltsam.
Darüber hinaus wirst du const-correctness für VCL-Klassen kaum erwarten können, da Delphi das Konzept überhaupt nicht kennt.
asc schrieb:
Obwohl verbessert könnte die Stabilität noch besser sein (u.a. Fehlermeldungen bei Codevervollständigung)
Bei mir (C++Builder 2009) taucht hin und wieder eine Zugriffsverletzung in bcbide*.bpl in der Funktion GetSymRec() auf, die aber nach erneutem Aufruf von Code Completion nicht mehr auftritt. Meinst du das?
asc schrieb:
Performanceprobleme bei Codevervollständigung
Die gibt es nur, wenn du PCH nicht richtig verwendest. C++Builder 2009 hat einen Wizard, der einen entsprechenden PCH automatisch generieren kann. In einem korrekt konfigurierten Projekt sind die CC-Verzögerungen gewöhnlich deutlich unter einer Sekunde.
asc schrieb:
Behandlung einiger Fehler maximal als Warnungen (wie z.B. fehlende Rückgaben etc.)
Wäre vielleicht einen QC-Report wert. Ansonsten:
-w!
rudiM schrieb:
den der doofe Debugger macht nach jedem Step oder Breakpoint, alle mühsam aufgeklappten Strukturen wieder zu. Das sollte er doch besser den User überlassen.
Sehe ich ebenso; das Problem wurde in QC #67560 berichtet.
-
audacia schrieb:
asc schrieb:
Fehlende const-correctness in Bezug mit VCL-Klassen (const Objekte die ohne Probleme geändert werden können - so wie die Datumsklassen).
Das (QC #67988) scheint ein Compiler-Problem mit einigen DELPHIRETURN-Typen zu sein. Sehr seltsam.
Darüber hinaus wirst du const-correctness für VCL-Klassen kaum erwarten können, da Delphi das Konzept überhaupt nicht kennt.
Ich kenne den Eintrag (Schau mal wer die Nachricht eingetragen hat, und beachte den ersten Buchstaben vom Vor- und die zwei ersten vom Nachnamen ;p).
Davon abgesehen funktioniert const mit vielen anderen VCL-Typen, bislang ist mir dieses "Phänomen" nur bei TDateTime aufgefallen.
audacia schrieb:
asc schrieb:
Obwohl verbessert könnte die Stabilität noch besser sein (u.a. Fehlermeldungen bei Codevervollständigung)
Bei mir (C++Builder 2009) taucht hin und wieder eine Zugriffsverletzung in bcbide*.bpl in der Funktion GetSymRec() auf, die aber nach erneutem Aufruf von Code Completion nicht mehr auftritt. Meinst du das?
Ich kann dir gerade nicht die genaue Fehlermeldung sagen, aber es ist auf jedenfall eine Zugriffsverletzung die immer wieder beim ersten Versuch einer CC (nach einer gewissen Arbeitszeit) auftritt. Der zweite Versuch funktioniert in der Regel wieder, ganz selten (ich glaube 3 mal bislang) hat mir dieser oder ein ähnlicher Fehler aber auch das ganze RAD-Studio abrauchen lassen...
audacia schrieb:
asc schrieb:
Performanceprobleme bei Codevervollständigung
Die gibt es nur, wenn du PCH nicht richtig verwendest. C++Builder 2009 hat einen Wizard, der einen entsprechenden PCH automatisch generieren kann. In einem korrekt konfigurierten Projekt sind die CC-Verzögerungen gewöhnlich deutlich unter einer Sekunde.
Wir arbeiten (aus Grund mangelnder Controlunterstützung von Komponenten die wir nicht so schnell austauschen können) noch mit dem 2007, und werden wohl den 2009 [vielleicht auch noch seinen Nachfolger] überspringen. Die PCH ist nach meiner Meinung eh eine Hölle in dem Projekt (Liegt wohl an den vielen Projektportierungen, da scheinen die Projekteinstellungen nicht unbedingt wie bei einem Neuprojekt zu sein).
cu André
-
asc schrieb:
Ich kenne den Eintrag (Schau mal wer die Nachricht eingetragen hat, und beachte den ersten Buchstaben vom Vor- und die zwei ersten vom Nachnamen ;p).
Schon klar
Ich erwähnte den Bericht aus dokumentarischen Gründen.
asc schrieb:
Die PCH ist nach meiner Meinung eh eine Hölle in dem Projekt
Hier kann ich dir nicht folgen. Was verhindert den Einsatz eines PCH bei dem Projekt?
(Wenn du Probleme mit den Projektdateien hast, könntest du versuchen, einfach eine neue zu erstellen und die alten Dateien hinzuzufügen, anstatt den Projekt-Importer zu benutzen.)
Aber das wird doch wohl noch nicht alles gewesen sein?
Ich bin sicher, DocShoe, akari, Braunstein, Kolumbus und einige andere haben auch eine Meinung dazu
-
audacia schrieb:
(Wenn du Probleme mit den Projektdateien hast, könntest du versuchen, einfach eine neue zu erstellen und die alten Dateien hinzuzufügen, anstatt den Projekt-Importer zu benutzen.)
Das habe ich beizeiten auch vor, wobei es vielleicht sinnvoll ist dies zu tun, wenn wir tatsächlich auf einen neueren C++ Builder migriert haben (Die Art und Weise wie die PCH bei uns eingesetzt werden, entspricht jedenfalls nicht dem Projektstandard unter dem 2007, und ist wohl noch ein Relikt aus dem 6er BCB)...
-
Klar habe ich ne Meinung dazu, aber ich setze im Moment immer noch den BCB6 ein, ich weiss also nicht, ob der CG2009 100%ig absturzkompatibel zu dem Fossil ist.
Nach einigen Erfahrungen, die andere User hier gepostet haben, glaube ich, dass der BCB6 wohl ein Ausreisser nach unten ist, was die Qualität angeht, daher schreibe ich nichts über fehlende Features oder Bugs.- native COFF Unterstützung statt Konvertierung per COFF2OMF oder implib.
- Benutzerdefinierte einklappbare Regionen, so wie es in Visual C# zum Beispiel möglich ist (#region/#endregion). Damit liessen sich dann logische Codeblöcke gruppieren statt nur Methoden/Schleifen.
- Unterstützung von Versionierungstools (zB. Subversion) aus der IDE. (Funktioniert wahrscheinlich jetzt schon, muss man nur manuell einrichten?)
- Unterstützung von mehreren Kernen beim Übersetzen (siehe TwineCompile)
Von der VCL kommt man sicher nicht mehr weg, die Mixtur aus Delphi und C++ stösst mir immer wieder übel auf. Oft fehlen mir so Kleinigkeiten wie der Aufruf von Methoden eines VCL GUI Objektes aus einem nativen Win32 Thread.
Ich überlege mal weiter, vielleicht fällt mir noch etwas ein.
-
DocShoe schrieb:
- native COFF Unterstützung statt Konvertierung per COFF2OMF oder implib.
Für DLL ist IMPLIB eigentlich wunderbar unkompliziert; ich nehme an, du möchtest C-Libraries, die mit MSVC kompiliert wurden, direkt einbinden können, oder? Für C++-Libraries steht das eher nicht in Aussicht infolge der doch sehr unterschiedlichen ABIs von Borland und Microsoft, aber gegen einen Linker, der COFF akzeptiert, spricht eigentlich nichts.
(Mit ULink ist das, soweit ich weiß, bereits möglich.)
DocShoe schrieb:
- Benutzerdefinierte einklappbare Regionen, so wie es in Visual C# zum Beispiel möglich ist (#region/#endregion). Damit liessen sich dann logische Codeblöcke gruppieren statt nur Methoden/Schleifen.
Wird unterstützt ab C++Builder 2006.
DocShoe schrieb:
- Unterstützung von Versionierungstools (zB. Subversion) aus der IDE. (Funktioniert wahrscheinlich jetzt schon, muss man nur manuell einrichten?)
Ja, z.B. mit DelphiSVN, und auch in der JCL gibt es, wenn ich mich recht erinnere, eine IDE-Integration. Ich verwende gewöhnlich externe Tools (TortoiseSVN), aber eine OOTB-Integration wäre ganz nett. Gerade mit dem History-View in den neueren IDEs ließen sich interessante Dinge anstellen.
DocShoe schrieb:
Unterstützung von mehreren Kernen beim Übersetzen (siehe TwineCompile)
Das wäre überfällig, zumal es infolge der unterschiedlichen Modularisierungsansätze für C++ signifikant einfacher zu realisieren ist als für Delphi. (Dafür braucht man für Delphi-Projekte eigentlich gar keine Build-Parallelisierung :p) Einstweilen tut es TwineCompile recht gut.
DocShoe schrieb:
Oft fehlen mir so Kleinigkeiten wie der Aufruf von Methoden eines VCL GUI Objektes aus einem nativen Win32 Thread.
Wie sollte das denn anders sein? Implizites Locking für alle Zugriffe auf UI-Komponenten? Oder fehlt dir aus einem Nicht-VCL-Thread der Zugriff auf TThread::Synchronize()?
DocShoe schrieb:
Ich überlege mal weiter, vielleicht fällt mir noch etwas ein.
-
Ich habe mich bisher nicht gemeldet, da ich auch bisher nur den 2007er einsetze. Desweiteren sind wir bei uns im Institut gerade dabei auf Qt umzustellen, so dass ich den Builder in nächster Zeit nicht mehr so oft nutzen werde.
Gerade im Vergleich zu Qt ist mir aufgefallen, dass die Internationalisierung beim CB doch arg umständlich ist. Das ist dort einfacher gelöst.
Die Debuggerprobleme mit Templateklassen (std::string etc.) haben mich auch immer gestört.
Die Einbindung der Reportkomponenten könnte auch verbessert werden und ich hoffe, dass jetzt mal bei einem Anbieter geblieben wird (meinetwegen Rave). Oder kommt da was Eigenes dazu?
Wenn ich den Qt-Creator nutze, fällt mir auf, dass dort die Codevervollständigung eine Geschwindigkeit erreicht hat, die sie für mich nutz bar macht. Beim CB habe ich das immer abgeschaltet, da es mir zu lange gedauert hat.
Kann man im 2009er jetzt im Projektmanager endlich die Dateien alphabetisch sortieren? Das ging im 2007er nicht (oder ich war zu blöd dazu was zu finden).
Das wars erstmal
Ciao
-
Braunstein schrieb:
Gerade im Vergleich zu Qt ist mir aufgefallen, dass die Internationalisierung beim CB doch arg umständlich ist. Das ist dort einfacher gelöst.
Hm, Qt verwendet doch auch nur so eine gettext-Variante, oder?
Braunstein schrieb:
Kann man im 2009er jetzt im Projektmanager endlich die Dateien alphabetisch sortieren? Das ging im 2007er nicht (oder ich war zu blöd dazu was zu finden).
Das macht er, glaube ich, automatisch.
-
audacia schrieb:
Hm, Qt verwendet doch auch nur so eine gettext-Variante, oder?
Das kann ich nicht beurteilen da ich gettext nur ganz kurz angeschaut habe. Ich empfand das Handling beim damaligen Test aber als unschön, so dass ich gettext nicht weiter vertieft habe. Mit der Qt-variante kam ich auf Anhieb sehr gut zurecht.
audacia schrieb:
Das macht er, glaube ich, automatisch.
Beim 2007er jedenfalls nicht.
-
audacia schrieb:
DocShoe schrieb:
- Benutzerdefinierte einklappbare Regionen, so wie es in Visual C# zum Beispiel möglich ist (#region/#endregion). Damit liessen sich dann logische Codeblöcke gruppieren statt nur Methoden/Schleifen.
Wird unterstützt ab C++Builder 2006.
Aha. Und wie heissen die Schlüsselwörter? Ich habe in der Hilfe nichts gefunden.
-
DocShoe schrieb:
Aha. Und wie heissen die Schlüsselwörter? Ich habe in der Hilfe nichts gefunden.
-
Funktioniert tatsächlich, danke!
-
Funktioniert, ist aber praktisch nicht zu gebrauchen.Die IDE klappt bei jeder Änderung des Quelltextes alle Regionen wieder auf, selbst die Regionen, die von der Änderung nicht betroffen sind. Da besteht eindeutig Verbesserungsbedarf. Oder ist das ein Feature, das man irgendwo ein- und ausschalten kann? Habe natürlich wieder nichts gefunden, weder in der Hilfe, noch in den Editoroptionen.
Zum Thema Debugging ist mir noch was eingefallen, ich hätte gerne Debug Makros, mit denen man etwas in die Debugkonsole schreiben kann. Es gibt zwar die Funktion OutputDebugString, aber die gibt nur eine ganze Zeile aus, die man sich vorher zusammenbauen muss. Ausserdem weiss ich nicht, ob der OutputDebugString Funktionsaufruf nur beim Debug Build gemacht wird, im Release sollte der nicht auftauchen. Im Viusal Studio gibt es verschiedene TRACE Makros, die ähnlich wie printf Formatierungen und Parameter entgegenehmen und in der Debugkonsole ausgeben.Zwei neue Vorschläge:
- Code folding praxistauglich machen
- Debug Makros, z.B. wie im Visual Studio, zumindest vergleichbare Funktionalität
-
DocShoe schrieb:
Funktioniert, ist aber praktisch nicht zu gebrauchen.Die IDE klappt bei jeder Änderung des Quelltextes alle Regionen wieder auf, selbst die Regionen, die von der Änderung nicht betroffen sind. Da besteht eindeutig Verbesserungsbedarf. Oder ist das ein Feature, das man irgendwo ein- und ausschalten kann? Habe natürlich wieder nichts gefunden, weder in der Hilfe, noch in den Editoroptionen.
Nein, ich glaube, das ist ein Bug; etwas ähnliches steht in QC #23373.
DocShoe schrieb:
Zum Thema Debugging ist mir noch was eingefallen, ich hätte gerne Debug Makros, mit denen man etwas in die Debugkonsole schreiben kann. Es gibt zwar die Funktion OutputDebugString, aber die gibt nur eine ganze Zeile aus, die man sich vorher zusammenbauen muss. Ausserdem weiss ich nicht, ob der OutputDebugString Funktionsaufruf nur beim Debug Build gemacht wird, im Release sollte der nicht auftauchen. Im Viusal Studio gibt es verschiedene TRACE Makros, die ähnlich wie printf Formatierungen und Parameter entgegenehmen und in der Debugkonsole ausgeben.
So etwas gibt es:
#include <utilcls.h> int main (void) { OLETRACE ("%s, %d", "foo", 42); // wenn TCHAR-Setting auf "char" OLETRACE (L"%s, %d", L"foo", 42); // wenn TCHAR-Setting auf "wchar_t" }
-
Danke, das OLETRACE ist genau das, was ich gesucht habe. Woher zum Geier hast du das? In der Online Hilfe (weder BCB6 noch CG2007) findet man irgendetwas; google spuckt auch nur eineinhalb Seiten Treffer mit Quelltexten aus, von denen 75% russisch sind.
Wie lautet denn das Formatsymbol für floating point? %f ist es jedenfalls nicht.
-
DocShoe schrieb:
Danke, das OLETRACE ist genau das, was ich gesucht habe. Woher zum Geier hast du das?
Ich hatte einmal das Vergnügen, die Automation-Schnittstelle von Microsoft Office benutzen zu dürfen; da landet man hin und wieder in utilcls.h.
Allerdings werden die OLE-Makros, soweit ich weiß, im Release-Build standardmäßig nicht deaktiviert. Die Definition sieht wie folgt aus:
#if !defined(OLETRACE) #define OLETRACE TDebugHlpr<TCHAR>::TRACE_HLPR #endif
Entsprechend müßtest du vor der Einbindung von utilcls.h noch
#ifndef _DEBUG #define OLETRACE(...) #endif
verwenden, um die Traces loszuwerden.
DocShoe schrieb:
Wie lautet denn das Formatsymbol für floating point? %f ist es jedenfalls nicht.
TRACE_HLPR() verwendet die WinAPI-Funktion wvsprintf(), deren Syntax ein wenig von der C-Formatsyntax abweicht. Aus irgendeinem Grunde unterstützt diese Funktion jedoch keine Gleitkommazahlen - der Workaround wäre
String (theFloat).c_str ()
.Es dürfte deutlich sichtbar sein, daß es sich um eine nicht ganz ausgegorene Lösung handelt
Aber wenn das Einbinden eines zusätzlichen Headers dir nichts ausmacht, kannst du dir ja problemlos dein eigenes TRACE-Makro schreiben, das auf die C-RTL zurückgreift und außerdem standardmäßig im Release-Build nicht aktiv ist.
-
Ich habe mir schon selbst was zusammengestrickt, und da OLETRACE mit floating point überhaupt nichts anfangen kann werde ich wohl dabei bleiben. Trotzdem danke für den Hinweis.
PS: Bleibt ein neuer Vorschlag:
- Debug Makros, z.B. wie im Visual Studio, zumindest vergleichbare Funktionalität
- Debug Makros, z.B. wie im Visual Studio, zumindest vergleichbare Funktionalität
-
WAs noch zu wünschen wäre: eine (wenn auch vielleicht einfache) Klassenvervollständigung wie bei Delphi. Damit spart man sich viel Tipparbeit.
Ich habe mir mal vor einiger Zeit so ein kleines Tool programmiert, dass zumindest bei sehr einfachen Klassendeklaration in der Lage ist, die entsprechenden Definitionsrümpfe zu generieren.Leider geht das im CB2009 nicht mehr, weil da beim Aufruf von externen Tools so wichtige Parameter wie "Wort unter Cursor" und "Dateiname" weggelassen werden, wenn die .h-Datei im Editor sichtbar ist.
-
Burkhi schrieb:
WAs noch zu wünschen wäre: eine (wenn auch vielleicht einfache) Klassenvervollständigung wie bei Delphi. Damit spart man sich viel Tipparbeit.
Ganz meine Meinung - deshalb hatte ich das auch bereits im Eröffnungspost erwähnt
Burkhi schrieb:
Ich habe mir mal vor einiger Zeit so ein kleines Tool programmiert, dass zumindest bei sehr einfachen Klassendeklaration in der Lage ist, die entsprechenden Definitionsrümpfe zu generieren.
Interessant. Ich hatte auch schon darüber nachgedacht, einen rudimentären Parser für Deklarationen zu schreiben. Damit könnte man viele interessante Dinge implementieren, z.B. Class Completion, die Scope-Comboboxen aus Visual C++, einen Hotkey zum Wechseln zwischen Deklaration und Definition (Ctrl+Shift+Up/Down in Delphi), verbesserte Codevervollständigung und sogar einige Refactorings.
Burkhi schrieb:
Leider geht das im CB2009 nicht mehr, weil da beim Aufruf von externen Tools so wichtige Parameter wie "Wort unter Cursor" und "Dateiname" weggelassen werden, wenn die .h-Datei im Editor sichtbar ist.
Das wäre zwar ein Fall für einen QC-Report, allerdings glaube ich, daß derartige Tools ohnehin besser über die ToolsAPI in die IDE integriert werden sollten. Da kann man direkt auf Editor-Buffer zugreifen, hat über die Code-Completion-Interfaces Zugriff auf die Symboltabelle des Compilers etc.
-
audacia schrieb:
Das wäre zwar ein Fall für einen QC-Report, allerdings glaube ich, daß derartige Tools ohnehin besser über die ToolsAPI in die IDE integriert werden sollten. Da kann man direkt auf Editor-Buffer zugreifen, hat über die Code-Completion-Interfaces Zugriff auf die Symboltabelle des Compilers etc.
Das habe ich schon Reportet, ab CB5 z.B. gibts keine $COL und $ROW Angaben bei den H-Dateien. Ab CB2009 hat sich das geändert, jetzt gibts auch die Parameter $CURTOKEN und $EDNAME nicht mehr.
Bis zum CB2006 hab ich mein kleines Tool noch nutzen können, ich brauchte EDNAME und CURTOKEN dafür.
Die Integration in die IDE wäre m.E. auch besser, hab mich nur noch nicht genauer damit beschäftigt.@Audacia:
Sehr gute Artikel auf deine Seite.