Fehlende Features in C++Builder

audacia

DocShoe schrieb:

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

DocShoe

Funktioniert tatsächlich, danke!

DocShoe

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

audacia

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"
}

DocShoe

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.

audacia

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.

DocShoe

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

Burkhi

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.

audacia

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.

Burkhi

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.

audacia

Nachdem mittlerweile C++Builder 2010 sowie die ersten Updates dafür veröffentlicht wurden, will ich diesen Thread mal etwas aktualisieren:

Maverick schrieb:

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

Ein konfigurierbarer Code-Formatierer ist Bestandteil von C++Builder 2010.

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.

Das ist in C++Builder 2010 endlich über die Debugger-Visualizer möglich. Standardmäßig gibt es bereits welche für std::string/std::wstring und TDateTime/TDate/TTime, weitere können über das OpenTools-API eingebunden werden.

Linnea schrieb:

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

Ein Class-Explorer ist nun endlich Bestandteil von C++Builder 2010. Allerdings hat er mit dem aus C++Builder 6 ungefähr nichts zu tun: er wurde von Grund auf neu entwickelt und greift auf den Compiler zurück, ist also sehr zuverlässig. Details unter http://blogs.embarcadero.com/ddean/2009/08/04/34822.

asc schrieb:

[*]Fehlende (zudem realistisch funktionierende) Refactoringwerkzeuge.

Gibt es zwar immer noch nicht, aber der Class Explorer kann auch Referenzen suchen, und das weitaus zuverlässiger als der bisherige Mechanismus.

audacia schrieb:

Es gibt zwar "Go to declaration", aber nicht "Go to definition".

Auch das gibt es zwar im Editor noch immer nicht, aber aus dem Class Explorer heraus ist "Go to definition" möglich.

rudiM schrieb:

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.

Das ist in C++Builder 2010 behoben.

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.

Sollte im aktuellen Update für C++Builder 2010 behoben sein.

Falls es noch weiteres gibt, was an C++Builder verbesserungswürdig erscheint, so wäre ich interessiert, davon zu lesen.

DocShoe

Danke für´s Update

Hallo,

für mich ist eines der grössten negativen Mankos im Builder 2010 die lausige Hilfe.
Wie soll man die Verbesserungen eines Produktes bzw. die Neuerungen kennen lernen, wenn beim Druck auf F1 keine oder eine leere Hilfeseite erscheint.
Das Hilfe-update 1 hat nicht wirklich eine Verbesserung gebracht.
Da es keine Sekundärliteratur zu dem C++ Builder2010 wäre die Hilfe die einzige Informationsgrundlage. So aber bleibt das Gefühl, dass man die Features nutzt, welche auch schon im Builder 5 vorhanden waren, denn dort waren diese wenigstens dokumentiert.

Ich bin mit Embarcadero schon seit einiger Zeit in Kontakt, aber was da bisher gekommen ist, kann man vergessen. Zunächst wird ein Problem als nicht existent klassifiziert, obwohl dies bei anderen Entwicklern ebenfalls auftritt und man keinen findet bei dem es überhaupt funktioniert.

Gruss

rudiM

Obiges kann ich nur unterstreichen.

Als ich mir den 2009er zulegte, war das meiste in der Hilfe Schwachsinn wie dieser:

Classtyp: Dies ist ein Typ der Klasse.

Ich vermute, die haben einfach keine Zeit um eine Hilfe zu schreiben, Hauptsache ist, das Ding wird verkauft, auch wenn es nur halbfertig ist.
Gruß Rudi

audacia

TWBuilder schrieb:

für mich ist eines der grössten negativen Mankos im Builder 2010 die lausige Hilfe.

Sehe ich auch so. Das Problem ist durchaus bekannt, und es gibt sogar ein paar technische Gründe für den Rückschritt nach der bereits recht ordentlichen Dokumentation in C++Builder 2009, aber das rechtfertigt den status quo natürlich nicht im geringsten.

Ich weiß nicht, wie da weiter vorgegangen werden wird, aber ich kann versichern: dieses Problems ist man sich zur Genüge bewußt.

rudiM schrieb:

Ich vermute, die haben einfach keine Zeit um eine Hilfe zu schreiben

Doch, durchaus. Tatsächlich ist meiner Meinung nach der Inhalt der Hilfe das geringste Problem; an Material mangelt es eigentlich nicht (von ganz neuen Komponenten abgesehen, die oft erst mit dem ersten Help Update dokumentiert werden). Die eigentliche Schwierigkeit sehe ich in der mangelhaften Organisation, der Unübersichtlichkeit und dem unzureichenden Register. Man findet allzu oft nicht, was man sucht: das war in den meisten bisherigen Versionen besser.

Edit: Die Dokumentation ist übrigens auch online unter docwiki.embarcadero.com verfügbar.

asc

audacia schrieb:

...und es gibt sogar ein paar technische Gründe für den Rückschritt nach der bereits recht ordentlichen Dokumentation in C++Builder 2009, aber das rechtfertigt den status quo natürlich nicht im geringsten.

Ich befürchte nur das es Embaccadero ziemlich egal ist (Der C++ Builder scheint nach ein paar kleinen Belebungen weiterhin nur ein "Abfallprodukt" von Delphi zu sein). Und ganz ehrlich: Ich sehe derzeit keinen wirklichen Grund für Neukunden (Bestehende Projekte unter dem C++ Builder weiterzuführen ist etwas anderes, oder wenn das Hintergrundwissen ohnehin im Hause vorhanden ist).

Solange der C++ Builder so stiefmütterlich gepflegt wird (die kleinen Änderungen sind für mich nur ein Tropfen auf den heißen Stein), sehe ich weiterhin keine Zukunft für ihn.

audacia

asc schrieb:

Ich befürchte nur das es Embaccadero ziemlich egal ist

Ist es nicht, das kann ich dir versichern.

asc schrieb:

(Der C++ Builder scheint nach ein paar kleinen Belebungen weiterhin nur ein "Abfallprodukt" von Delphi zu sein).

Schon mal den Class Explorer angeschaut? Für Delphi gibt es nichts Vergleichbares. C++Builder wird durchaus aktiv entwickelt.

asc schrieb:

Und ganz ehrlich: Ich sehe derzeit keinen wirklichen Grund für Neukunden

Ich schon.
Im Übrigen wird sich die Situation mit der kommenden Version, die da ja auch den Mac unterstützen soll, vielleicht wieder ändern

asc schrieb:

(die kleinen Änderungen sind für mich nur ein Tropfen auf den heißen Stein)

Den heißen Stein beziffere bitte genauer. (Und Features wie der Class Explorer sind beileibe keine Kleinigkeiten.)

VergissEs

audacia schrieb:

asc schrieb:

(die kleinen Änderungen sind für mich nur ein Tropfen auf den heißen Stein)

Den heißen Stein beziffere bitte genauer. (Und Features wie der Class Explorer sind beileibe keine Kleinigkeiten.)

Na dann hoffen wir mal das der Class Explorer nicht wiedermal in einer zukünfigen Version verschwindet.

Der Resourcen-DLL-Experten (Translation-Manager) gab es ja auch schon mal in
früheren Versionen (bis BDS2006) und beim RAD2009 wurde dieser wieder als neues "feature" beigepackt.
Die damals durch migrieren auf die neue Version Ihre Code umschreiben mussten
werden mit Sicherheit einen weiten Bogen um den Resourcen-DLL-Experten machen.

Auf die Mac Unterstützung bin ich schon gespannt... hoffe mit besseren Ende als Kylix, BuilderX usw.

audacia

VergissEs schrieb:

Na dann hoffen wir mal das der Class Explorer nicht wiedermal in einer zukünfigen Version verschwindet.

Der alte Class-Explorer war ein 3rd-party-Produkt; dieser ist eine Eigenentwicklung. Es würde mich doch sehr wundern, wenn der einfach so wieder verschwände.

VergissEs schrieb:

Der Resourcen-DLL-Experten (Translation-Manager) gab es ja auch schon mal in
früheren Versionen (bis BDS2006) und beim RAD2009 wurde dieser wieder als neues "feature" beigepackt.

Das Feature ist nie verschwunden: man mußte nur ein externes Tool, den ETM, dafür benutzen. Was in C++Builder 2006 verschwand und in C++Builder 2009 wieder auftauchte, war nur die IDE-Integration.

VergissEs

audacia schrieb:

Das Feature ist nie verschwunden: man mußte nur ein externes Tool, den ETM, dafür benutzen. Was in C++Builder 2006 verschwand und in C++Builder 2009 wieder auftauchte, war nur die IDE-Integration.

Bei meiner alten BDS2006 installation ist nur die Hilfedatei d7etm.hlp vorhanden das externe Tool wie in der Hilfeddatei beschrieben etm60.exe ist nicht vorhanden evtl. liegt es ja auch daran das ich immer die Prof. Version kaufe.