Fehlende Features in C++Builder

audacia

Mich würde interessieren, welche Features ihr beim täglichen Arbeiten mit C++Builder vermißt, was ihr als lästig empfindet, und was andere IDEs können, C++Builder aber nicht.

Ich beginne mal:

Mich stört, daß der Debugger bei der Einzelschrittausführung ständig in System-Headerdateien abschweift. Beispiel:

#include <string>
void foo (const std::string& s) {}
int main (void)
{
    foo ("bar"); // <--
}

Ein "Step-into" aus der markierten Zeile führt nicht in die Funktion foo(), sondern zunächst nach xstring, wo std::basic_string<>::basic_string(const char*) deklariert ist.
(QC #1962)

Der Debugger zeigt den tatsächlichen Typen eines polymorphen Objektes nicht an (hier ausführlicher besprochen). Ein Beispiel wäre ein generischer Event-Handler:

void __fastcall TFrmMain::BtnFooClick(TObject *Sender)
{
    ...
}

Als Sender wird hier BtnFoo vom Typ TButton übergeben; der Debugger zeigt aber nicht die TButton-Members von Sender an, sondern behandelt es einfach als TObject.
(QC #73567)

Es gibt zwar "Go to declaration", aber nicht "Go to definition".
Class Completion, wie in Delphi verfügbar. Man stelle sich vor, die folgende Klassendeklaration zu tippen:

unit Foo;

interface

type
  TFoo = class
  public
    destructor Destroy; override;
  published
    property Bar: Integer;
    property Baz: Integer read FBaz write FBaz;
  end;

Sodann wähle man Ctrl+Shift+C, und die IDE ergänzt den Code folgendermaßen:

type
  TFoo = class
  private
    FBaz: Integer;
    FBar: Integer;
    procedure SetBar(const Value: Integer);
  published
  public
    destructor Destroy; override;
  published
    property Bar: Integer read FBar write SetBar;
    property Baz: Integer read FBaz write FBaz;
  end;

implementation

{ TFoo }

destructor TFoo.Destroy;
begin

  inherited;
end;

procedure TFoo.SetBar(const Value: Integer);
begin
  FBar := Value;
end;

end.

Ich bin sicher, ihr habt der Liste einiges hinzuzufügen - und gespannt auf die Antworten

Maverick

Ich arbeite zwar nicht täglich damit, aber was ich vermisse ist automatische Codeformatierung wie z.b. bei Visual C++. Finde das ziemlich nützlich wenn man geschweifte Klammern macht und die Tabs automatisch angepasst werden. Gibt es zwar bei BCB auch aber nicht "so ausgereift" wie bei VC++.

Vor allem finde es auch praktisch, wenn man wie bei VC++ den kompletten Code markiert und dann nochmal formatieren lässt - so ist alles schön einheitlich.

Und ein IDE Addin dafür gibt es scheinbar nicht (habe zumindest keins gefunden).

Linnea

am BCB2009 stört mich momentan:

- 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.

- der ClassExplorer mit den dazugehörigen Funktionen aus dem BCB6 fehlt (z.B. "neue Eigenschaft", "neue Funktion" usw.)

@Maverick
Formatierung und diverse Feature findest in diesem Addon:
http://www.cnpack.org/index.php?lang=en

kpeter

~Breaker schrieb:

@Maverick
Formatierung und diverse Feature findest in diesem Addon:
http://www.cnpack.org/index.php?lang=en

About CnPack schrieb:

CnPack Team is made up of Chinese Programmers and Delphi / C++ Builder fans across the Internet. Our products include CnWizards, CnVCL, CVSTracNT and etc.

Sind das die Guten oder die Bösen ?

asc

audacia schrieb:

Mich würde interessieren, welche Features ihr beim täglichen Arbeiten mit C++Builder vermißt,...

Ich kann nur vom 2007 ausgehen:

Diverse Mängel im Debugger (zum Großteil schon angegeben)
Diverse kleine Probleme mit der Verwendung von Namensräumen, u.a.:
"Zwangs"-using namespace in den Componentenheadern
Includeguards können nicht ohne negative Konsequenzen umbenannt werden (z.B. wenn man mit Namensräumen etc. arbeitet und dennoch eine Eindeutigkeit haben will).
Fehlende (zudem realistisch funktionierende) Refactoringwerkzeuge.
Fehlende const-correctness in Bezug mit VCL-Klassen (const Objekte die ohne Probleme geändert werden können - so wie die Datumsklassen).
Obwohl verbessert könnte die Stabilität noch besser sein (u.a. Fehlermeldungen bei Codevervollständigung)
Performanceprobleme bei Codevervollständigung
Behandlung einiger Fehler maximal als Warnungen (wie z.B. fehlende Rückgaben etc.)

-**xXx**-

Refactoring und Codevervollständigung wie in Java / Eclipse das wär toll *träum*

mfg
xXx

rudiM

Hallo audacia,

Ich hab mich echt auf den Builder 2009 gefreud. Der BCB 5.0 hatte nicht soviele Möglichkeiten beim Debuggen, Variablen anzuzeigen. Im Prinzip ist BCB 2009 schon besser, aber nicht gut genug.

Variablen wie Strukturen, Arrays oder Klassen werden nur mit einem + vor dem Bezeichner aufgelistet. Zwar kann man durch Klick aufs + die Datenstruktur öffen, uU. tauchen weitere + Unterstrukturen auf, die man durchklicken kann, bis man dort ist, wo man was sehen will. Soweit, so gut. ABER wenn man mit Singelstep die Entwicklung einer solchen Variablen beobachten will, ist man gelackmeiert - 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.
Vielleicht gibt es ja auche Option, die das verhindert, hab ich aber noch nicht gefunden.

Gruß Rudi

Maverick

~Breaker schrieb:

@Maverick
Formatierung und diverse Feature findest in diesem Addon:
http://www.cnpack.org/index.php?lang=en

Danke, habe aber gerade gesehen das man beim Turbo 2006 Explorer keine Addins installieren kann. Keine Komponenten, damit kann ich leben, aber Addin... nicht gut.

audacia

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.

asc

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é

audacia

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

asc

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)...

DocShoe

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.

audacia

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.

Braunstein

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

audacia

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.

Braunstein

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.

DocShoe

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.

audacia

DocShoe schrieb:

Aha. Und wie heissen die Schlüsselwörter? Ich habe in der Hilfe nichts gefunden.

#pragma region und #pragma end_region.