Praxisnahe IDE
-
Wer den Emacs nicht kennt hat das Coden verpennt
Mal im ernst C++ Snippets und VisualStudio ist schon sehr peinlich oder? *duck
-
@audacia: Mit "die neuesten GUI-Objekte von Windows 7" meinte ich Sachen wie Aero-Glass-Support, Ribbon-Steuerelemente und Touch-Support ja. Welche IDE benutzt du denn?
@__cpp: Du rätst mir von Visual Studio ab. Warum?
-
DarkBug schrieb:
@__cpp: Du rätst mir von Visual Studio ab. Warum?
Das war nur ein Troll.
-
DarkBug schrieb:
Mit "die neuesten GUI-Objekte von Windows 7" meinte ich Sachen wie Aero-Glass-Support, Ribbon-Steuerelemente und Touch-Support ja.
Ribbons sind nur eine neue Art von Steuerelementen. Der einzige Grund, warum man sie in anderen Frameworks eher selten findet dürfte die Lizenzpolitik von MS sein.
Die anderen beiden Punkte setzen lediglich Windows voraus, kein spezifisches Framework
-
DarkBug schrieb:
@audacia: Mit "die neuesten GUI-Objekte von Windows 7" meinte ich Sachen wie Aero-Glass-Support, Ribbon-Steuerelemente und Touch-Support ja. Welche IDE benutzt du denn?
C++Builder 2010.
zwutz schrieb:
Die anderen beiden Punkte setzen lediglich Windows voraus, kein spezifisches Framework
Das Framework kann dir aber den Umgang damit entschieden vereinfachen.
-
audacia schrieb:
Das Framework kann dir aber den Umgang damit entschieden vereinfachen.
das ist klar, aber nicht nur das MS-Framework bietet die Unterstützung. Wobei Glass eh nur ein Dreizeiler ist
-
zwutz schrieb:
das ist klar, aber nicht nur das MS-Framework bietet die Unterstützung.
Ich spreche auch von der VCL.
-
Ist jetzt wirklich von Visual Studio abzuraten im Gegensatz zum C++ Builder 2010? Ich mein warum sollte __cpp das sonst schreiben, oder kann ich diesen Beitrag als Spam betrachten?
-
Nicht ernst nehmen. Wenn er es ernst meinen würde, würde er den Mumm haben sich wenigstens zu registrieren.
-
DarkBug schrieb:
Ist jetzt wirklich von Visual Studio abzuraten im Gegensatz zum C++ Builder 2010? Ich mein warum sollte __cpp das sonst schreiben, oder kann ich diesen Beitrag als Spam betrachten?
Das ist reiner Spam, wie es sich leider in einigen Threads befindet, bei der es um "Glaubensfragen" geht.
Für reines C++, erst einmal losgelöst vom Framework ist imho Visual Studio dem C++ Builder vorzuziehen. Wenn man Oberflächen schnell zusammenklicken will, ist der C++ Builder die bessere Wahl. Grundsätzlich bin ich aber vorsichtig bei der Aussage zur Zukunft (Viele Komponentenentwickler haben ihre VCL-Entwicklung eingestellt - sicherlich gibt es noch viel, aber bei weiten nicht mehr so viel wie ursprünglich).
-
asc schrieb:
Für reines C++, erst einmal losgelöst vom Framework ist imho Visual Studio dem C++ Builder vorzuziehen.
Ja. Wenn's nur um C++-Code geht, also ohne nennenswertes UI, dann dürfte der bessere Compiler von VC den Ausschlag geben.
asc schrieb:
Wenn man Oberflächen schnell zusammenklicken will, ist der C++ Builder die bessere Wahl.
"Schnell zusammenklicken"? Sicher, das ist auch ein nettes Feature. Aber die VCL ist viel mehr als "schnell zusammenklicken".
Ich würde sagen, wenn du Anwendungen mit anspruchsvollem UI für Windows entwickeln willst, ist die VCL mit Abstand die beste Lösung. Am besten mit Delphi, aber wenn es C++ sein soll, dann ist C++Builder das Mittel der Wahl.
asc schrieb:
(Viele Komponentenentwickler haben ihre VCL-Entwicklung eingestellt - sicherlich gibt es noch viel, aber bei weiten nicht mehr so viel wie ursprünglich).
Ja, der große Trend weg von Delphi, C++Builder und VCL begann etwa 2002, als alle glaubten, .NET werde über kurze Sicht das neue Windows-API restlos ersetzen, und infolgedessen Borland nicht so recht weiterwußte, etwas verzweifelt Delphi nach .NET portierte und gleichzeitig versuchte, C++Builder durch den platformunabhängigen, jedoch für Borland selbst unvorteilhaft egalitären C++BuilderX zu ersetzen. In dieser Zeit stiegen nicht wenige Drittanbieter aus. (Man wird retrospektiv sagen können, daß das Borland-Management in durchaus nennenswertem Ausmaß für die Misere mitverantwortlich war. Glücklicherweise wurde das IDE-Business vor ein paar Jahren an Embarcadero verkauft, bevor Borland, nach dem der Aktienkurs asymptotisch gegen 0 zu gehen begann, schlußendlich von MicroFocus geschluckt wurde.)
Der Trend hat sich aber zwischenzeitlich mehr als relativiert. Ich bin nicht sicher, ob es dazu wirklich brauchbare Statistiken gibt - TIOBE wohl eher nicht -, aber die Präsenz von Delphi und C++Builder im Netz, etwa bei StackOverflow, nimmt wieder zu.
-
Auf jeden Fall bin ich gespannt, was Embarcadero aus Delphi macht, soll ja in Richtung Funktionale Programmiersprache, Cross-Platform und 64-Bit Computing gehen
-
audacia schrieb:
asc schrieb:
Für reines C++, erst einmal losgelöst vom Framework ist imho Visual Studio dem C++ Builder vorzuziehen.
Ja. Wenn's nur um C++-Code geht, also ohne nennenswertes UI, dann dürfte der bessere Compiler von VC den Ausschlag geben.
Oh, für den VC gibt es einige UI-Frameworks, und auch einige Plugins für entsprechende Designer (zum Beispiel, aber nicht ausschließlich QT).
audacia schrieb:
asc schrieb:
Wenn man Oberflächen schnell zusammenklicken will, ist der C++ Builder die bessere Wahl.
"Schnell zusammenklicken"? Sicher, das ist auch ein nettes Feature. Aber die VCL ist viel mehr als "schnell zusammenklicken".
Ja, aber sie kann auch einiges was gänzlich der üblichen C++ Entwicklung wiederspricht [Und Schwierigkeiten beim Umgang mit STL-Algorithmen etc. verursachen kann; Beispiel: __fastcall Konvention, keine saubere const Unterstützung bei ein paar VCL-Datentypen...] - ist halt die Frage, in wie weit man sich an die VCL binden möchte.
audacia schrieb:
Ich würde sagen, wenn du Anwendungen mit anspruchsvollem UI für Windows entwickeln willst, ist die VCL mit Abstand die beste Lösung.
Ich behaupte das einige andere UI-Frameworks mit der VCL gleichziehen (Seien es die beiden UI-Frameworks von .Net, sei es QT...), und ob ich mich nun an die Compilerspezifischen Erweiterungen von dem C++ Builder, oder an .Net oder dem Makrokrimskrams von QT binde, ist glaube ich durchaus vergleichbar.
audacia schrieb:
asc schrieb:
(Viele Komponentenentwickler haben ihre VCL-Entwicklung eingestellt - sicherlich gibt es noch viel, aber bei weiten nicht mehr so viel wie ursprünglich).
Ja, der große Trend weg von Delphi, C++Builder und VCL begann etwa 2002, als alle glaubten, .NET werde über kurze Sicht das neue Windows-API restlos ersetzen,...
Und auch derzeit gibt es noch immer den Trend von der VCL weg (Es sind auch in den letzten paar Jahren noch weitere Komponentenhersteller abgesprungen). Das hat natürlich auch die Überlebenswahrscheinlichkeiten der Restlichen etwas erhöht (Wo weniger Konkurrenz herrscht, ist die Suche nach alternativen Herstellern schwierig). Nenn mir bitte beispielsweise einen gescheiten HTML-Viewer, den man nicht mittels COM ansteuern muss, und der aktuell noch gut gepflegt wird.
Zeus schrieb:
Auf jeden Fall bin ich gespannt, was Embarcadero aus Delphi macht...
Mir wäre es mal lieber, zu wissen wie die Zukunft vom C++ Builder aussieht. Und der C++ Builder wird und wurde lange Zeit nur minimal gepflegt (und im Gegensatz zum VS gibt es auch so gut wie keine Addins, die mangelnde Fähigkeiten der IDE ausbügeln).
Die Zeit, in der ich von der VCL überzeugt war, liegen jedenfalls schon etliche Jahre zurück. Und ich stoße immer wieder an Stellen, die mir negativ bei der VCL in Zusammenhang mit C++ auffallen.
-
asc schrieb:
Oh, für den VC gibt es einige UI-Frameworks, und auch einige Plugins für entsprechende Designer (zum Beispiel, aber nicht ausschließlich QT).
Qt ist ja ganz nett, wenn man plattformunabhängig bleiben will. Aber UIs für Windows würde ich nicht mit Qt erstellen. Qt versucht zwar, den Windows-Look zu imitieren, verwendet aber keine nativen Windows-Controls, was im Vergleich zu "richtigen" Windows-Anwendungen (VCL, MFC, WTL, WinForms) durchaus auffällt; andauernd stimmen irgendwelche subtilen Details im Aussehen, Bedienung oder Funktionalität nicht. Aus demselben Grunde übrigens würde ich einen weiten Bogen um AWT oder Swing machen.
Abgesehen davon ist die Unterstützung für Windows-spezifische Eigenheiten in C++Builder einfach deutlich besser (bzw. überhaupt vorhanden); man denke nur an den umfangreichen ActiveX-Support, oder einfach an die Vista-spezifischen Neuerungen in den Common Controls.
Auch die Ribbon-Steuerelemente sind ein passendes Beispiel: für C++Builder sind sie gleich mitgeliefert, mir fallen spontan zwie weitere 3rd-party-Komponenten dazu ein, und es gibt, glaube ich, noch ein paar mehr. Aber für Qt? Niente.
Und Qt ist in dieser Hinsicht noch die beste Option. wxWidgets, GTK und all die anderen Toolkits können das durchaus anerkennenswerte Niveau von Qt nicht halten.
asc schrieb:
Ich behaupte das einige andere UI-Frameworks mit der VCL gleichziehen (Seien es die beiden UI-Frameworks von .Net, sei es QT...)
Die VCL ist vielleicht etwas umfangreicher und mehr "up-to-date", aber sonst ist WinForms sicherlich sehr konkurrenzfähig. Allerdings bevorzuge ich aus verschiedenen Gründen den ressourcenbasierten VCL-Designer (die DFM-Dateien) gegenüber dem WinForms-Designer, der Quelltext generiert. Etwa vereinfachen UI-Ressourcen die Internationalisierung. Und bei der Arbeit mit Versionskontrollsystemen ist
object LvwDataItems: TListView Left = 8 Top = 143 Width = 353 Height = 150 Columns = < item Caption = 'First column' Width = 200 end item Caption = 'Second column' Width = 100 end> TabOrder = 2 ViewStyle = vsReport endeinfach übersichtlicher als
// // lvwDataItems // this.lvwDataItems.Columns.AddRange(new System.Windows.Forms.ColumnHeader[] { this.firstColumn, this.secondColumn}); this.lvwDataItems.Location = new System.Drawing.Point(8, 143); this.lvwDataItems.Name = "lvwDataItems"; this.lvwDataItems.Size = new System.Drawing.Size(353, 150); this.lvwDataItems.TabIndex = 0; this.lvwDataItems.UseCompatibleStateImageBehavior = false; this.lvwDataItems.View = System.Windows.Forms.View.Details; // // firstColumn // this.firstColumn.Text = "First column"; this.firstColumn.Width = 200; // // secondColumn // this.secondColumn.Text = "Second column"; this.secondColumn.Width = 100;Es gibt natürlich durchaus auch Aspekte, die bei WinForms besser gelöst sind; etwa die Datenbindung. Aber alles Hin und Her wird zu unwichtigen Details, wenn auf das eigentliche Problem von WinForms stößt: für alles außer C# und VB.NET ist die IDE-Unterstützung einfach miserabel. Ich denke, Jochen Kalmbach hat das hier gut ausgeführt - von C++/CLI, speziell in Verbindung mit WinForms, sollte man tunlichst die Finger lassen.
Zurzeit arbeite ich an einem C++/CLI-Projekt, das C++-Code für ein mit C#/WinForms erstelltes UI zugänglich machen soll, und ich find's nicht lustig. VS 2010 unterstützt für C++/CLI nicht einmal IntelliSense; die Verbindung von Managed und Unmanaged Code ist (obzwar viel besser als nackte P/Invoke-Aufrufe) insgesamt recht unschön. (__clrcall ist kein Stück besser als __fastcall, und das Herumhantieren mit Handles macht die Arbeit mit STL und dergleichen auch nicht einfacher. Außerdem füge mal einer TForm-Klasse einen Member vom Typ
std::vector<>hinzu - und dann versuche das mal in C++/CLI
)Zwar steht diese Deutung diametral zur chronologischen Abfolge der Ereignisse, aber ich bei der Arbeit mit C++/CLI drängt sich mir sehr oft der Gedanke auf "C++Builder ist, was C++/CLI hätte sein sollen".
Mit WPF ist das ohnehin etwas anders. WPF ist für neuartige Anwendungsfälle sicherlich hochattraktiv, aber es ist selbst in der .NET-Welt kein Ersatz für WinForms. Und die IDE-Unterstützung für C++ mit WPF ist nicht einmal miserabel, sie ist überhaupt nicht existent.
asc schrieb:
Nenn mir bitte beispielsweise einen gescheiten HTML-Viewer, den man nicht mittels COM ansteuern muss, und der aktuell noch gut gepflegt wird.
Ich kenne weder für die VCL noch für WinForms einen, der nicht auf dem Internet Explorer basieren würde. (Das Gecko-basierte Browser-Widget in Qt ist vielleicht eine interessante Alternative.) Und offen gesagt halte ich es für ziemlich sinnfrei, an dieser Stelle das Rad neu zu erfinden, anstatt ein Steuerelement einzubinden, das auf einem etablierten Browser basiert.
asc schrieb:
und im Gegensatz zum VS gibt es auch so gut wie keine Addins, die mangelnde Fähigkeiten der IDE ausbügeln
Nein, da gibt es absolut gar keine, außer TwineCompile, GExperts, den CNWizards oder den DDevExtensions
Sicher, es gibt kein Visual Assist X oder CodeRush für C++Builder. Aber vielleicht tut sich da ja etwas?
asc schrieb:
Mir wäre es mal lieber, zu wissen wie die Zukunft vom C++ Builder aussieht.
Sie wird sehr eng verbunden sein mit der Zukunft von Delphi. Das nächste Release wird beispielsweise auch Mac-Anwendungen erstellen können.
asc schrieb:
Und der C++ Builder wird und wurde lange Zeit nur minimal gepflegt
Das ist, mit Verlaub, Blödsinn. C++Builder litt natürlich unter der C++BuilderX-Eskapade um 2003-2005. Aber die Ressourcen in der Entwicklung von Delphi und C++Builder sind seit 2007 wieder ziemlich gut ausbalanciert. Das C++-Compiler-Team dürfte sogar etwas besser besetzt sein als das Delphi-Compiler-Team.
-
audacia schrieb:
asc schrieb:
Oh, für den VC gibt es einige UI-Frameworks, und auch einige Plugins für entsprechende Designer (zum Beispiel, aber nicht ausschließlich QT).
Qt ist ja ganz nett, wenn man plattformunabhängig bleiben will. Aber UIs für Windows würde ich nicht mit Qt erstellen...
Unabhängig davon was ich selbst von QT halte, verstehst du hoffentlich das "zum Beispiel, aber nicht ausschließlich QT". Es ist einer von mehreren Designern die man beim VS nachrüsten kann (so wie es für wxWidgets auch eines für den C++ Builder gibt).
audacia schrieb:
Abgesehen davon ist die Unterstützung für Windows-spezifische Eigenheiten in C++Builder einfach deutlich besser...
Was bei jedem Framework das für eine Plattform ausgelegt ist, logisch ist.
audacia schrieb:
asc schrieb:
Ich behaupte das einige andere UI-Frameworks mit der VCL gleichziehen (Seien es die beiden UI-Frameworks von .Net, sei es QT...)
Die VCL ist vielleicht etwas umfangreicher und mehr "up-to-date",
Ich würde sagen das sowohl WinForms als auch die VCL sich kaum etwas in der Aktualität tun, und WPF/Silverlight gibt es ebenso noch. Und auch wenn WPF gewisse Umstellungen erfordert, kann man damit sehr viel machen (und es sowohl für WPF wie auch für WindowsForms einen riesigen, aktuellen Komponentenmarkt).
audacia schrieb:
aber sonst ist WinForms sicherlich sehr konkurrenzfähig. Allerdings bevorzuge ich aus verschiedenen Gründen den ressourcenbasierten VCL-Designer (die DFM-Dateien) gegenüber dem WinForms-Designer, der Quelltext generiert.
Mir persönlich ist der Quellcode lieber, als die dfm-Dateien (unabhängig von der Lesbarkeit sieht man eher was da gemacht wird). Zudem krankt diese dfm extrem stark wenn bei der UI auch Ableitungen etc. verwendet werden (Eine Änderung an einer Basisform, und mit etwas Pech gibt es Laufzeitfehler wenn man nicht alle direkt oder indirekt abgeleiteten Forms einmal öffnet und neu speichert - Leider kenne ich dies zu genüge, auch wenn ich die Vererbung von Forms selbst nicht gutheiße).
audacia schrieb:
Aber alles Hin und Her wird zu unwichtigen Details, wenn auf das eigentliche Problem von WinForms stößt: für alles außer C# und VB.NET ist die IDE-Unterstützung einfach miserabel.
Und? Bei der VCL hat man auch nur die Auswahl zwischen Delphi und C++, das halte ich persönlich nicht als KO-Kriterium (Davon abgesehen bin ich von C++/CLI auch nicht begeistert, unabhängig von der UI-Unterstützung).
audacia schrieb:
"C++Builder ist, was C++/CLI hätte sein sollen".
Eine ebenso propritäre Lösung, die sich ebenso nicht vollständig in die Sprache einbindet?
audacia schrieb:
Und die IDE-Unterstützung für C++ mit WPF ist nicht einmal miserabel, sie ist überhaupt nicht existent.
Das ist Unsinn. Die IDE-Unterstützung mag noch immer nicht auf dem Niveau wie bei WinForms sein, aber auch nicht viel schlechter (Visual Studio 2010).
audacia schrieb:
Nenn mir bitte beispielsweise einen gescheiten HTML-Viewer, den man nicht mittels COM ansteuern muss, und der aktuell noch gut gepflegt wird.
Ich kenne weder für die VCL noch für WinForms einen, der nicht auf dem Internet Explorer basieren würde.[/quote]
Das würde mich nicht stören, wenn man sich nicht durch COM-Interfaces hangeln müsste (und diesem eine sinnvolle Schnittstelle verpasst). Es gab einen durchaus akzeptablen unter der VCL, der hängt aber inzwischen weit hinter dem HTML/CSS-Standard zurück und wird nur noch von wenigen aktualisiert.
audacia schrieb:
asc schrieb:
und im Gegensatz zum VS gibt es auch so gut wie keine Addins, die mangelnde Fähigkeiten der IDE ausbügeln
Nein, da gibt es absolut gar keine, außer TwineCompile, GExperts, den CNWizards oder den DDevExtensions
Sicher, es gibt kein Visual Assist X oder CodeRush für C++Builder. Aber vielleicht tut sich da ja etwas?
Daran zweifel ich, nachdem selbst das einfachste Refactoring bis heute nicht funktioniert, und ich auch nirgends Firmen sehe, die in dieser Richtung irgendetwas ankündigen. Und auch wenn du meinst, das der C++ Builder inzwischen wieder besser supportet wird, ich sehe davon recht wenig. Ja, es gibt ein paar Verbesserungen, aber keine die bei mir den Eindruck hinterlassen das sich viel tut.
Zudem hat sich Embaccadero imho ins eigene Fleisch geschnitten, nachdem nun keinerlei kostenlose Version mehr existiert. Eine IDE die für möglichst viele zugänglich ist unterstützt die Verbreitung eines Frameworks massiv.
-
asc schrieb:
audacia schrieb:
Und die IDE-Unterstützung für C++ mit WPF ist nicht einmal miserabel, sie ist überhaupt nicht existent.
Das ist Unsinn. Die IDE-Unterstützung mag noch immer nicht auf dem Niveau wie bei WinForms sein, aber auch nicht viel schlechter (Visual Studio 2010).
Du kannst WPF Visual C++/CLI Projekte erstelle?
-
asc schrieb:
Unabhängig davon was ich selbst von QT halte, verstehst du hoffentlich das "zum Beispiel, aber nicht ausschließlich QT". Es ist einer von mehreren Designern die man beim VS nachrüsten kann (so wie es für wxWidgets auch eines für den C++ Builder gibt).
->
audacia schrieb:
Und Qt ist in dieser Hinsicht noch die beste Option. wxWidgets, GTK und all die anderen Toolkits können das durchaus anerkennenswerte Niveau von Qt nicht halten.
asc schrieb:
audacia schrieb:
Abgesehen davon ist die Unterstützung für Windows-spezifische Eigenheiten in C++Builder einfach deutlich besser...
Was bei jedem Framework das für eine Plattform ausgelegt ist, logisch ist.
Und da hier nach einer C++-IDE für Windows gefragt wurde, dürfte das durchaus relevant sein, oder?
asc schrieb:
Und? Bei der VCL hat man auch nur die Auswahl zwischen Delphi und C++, das halte ich persönlich nicht als KO-Kriterium
Man kann mit C++ und der VCL gut arbeiten, im Gegensatz zu C++/CLI und WinForms. Da die Frage - ich betone es nocheinmal - nach einer C++-IDE für Windows gestellt wurde, ist das ein nicht ganz unwichtiger Aspekt. WinForms ist natürlich ebenso okay, wenn man nicht irgendwelchen C++-Code hat, den man im Projekt benutzen will, sondern alles komplett neu schreibt - dann kann man ja C# benutzen. Aber sobald irgendwie Interoperabilität mit bestehendem C++-Code ins Spiel kommt, wird's unschön.
asc schrieb:
Daran zweifel ich, nachdem selbst das einfachste Refactoring bis heute nicht funktioniert
Dann solltest du dir vielleicht den Class Explorer nocheinmal genauer ansehen.
Daß "Rename" meist nicht funktioniert, liegt daran, daß es, als es seinerzeit für C++Builder 2006 entwickelt wurde, auf die Basis eines damals völlig neuen, auf die Schnelle implementierten und daher reichlich unausgereiften Compiler-Features gestellt wurde. Die technischen Details sind hier vielleicht nicht von Interesse, aber so viel sei gesagt: der in C++Builder 2010 hinzugekommene Class Explorer ist ebenfalls mithilfe des Compilers implementiert, benutzt allerdings für die Referenzsuche einen wesentlich älteren, seit Borland C++ 4 oder 5 existierenden und zwischenzeitlich an die Anforderungen angepassten Mechanismus. Das hat unter anderem zur Folge, daß die Symbolreferenzsuche im Class Explorer perfekt (!) funktioniert. Der mittelfristige Plan ist, wenn ich das richtig mitbekommen habe, auf der technologischen Basis des Class Explorer eine persistente Symboldatenbank zu erstellen, mit deren Hilfe man allerhand neue Features (das Rename-Refactoring, eine Symbolsuche, Aufrufgraphen etc.) implementieren kann. Der Class Explorer und die XML-Unterstützung des Compilers (ich hatte das andernorts schon erwähnt; seit C++Builder 2010 kann der C++-Compiler seine gesamte Symboltabelle, einschließlich aller Referenzinformationen zu jedem einzelnen Symbol, als XML ausgeben) waren die ersten Schritte in diese Richtung. Der nächste Schritt wird eher nicht in der kommenden Version vollzogen, da momentan der Mac die höchste Priorität zu haben scheint - aber danach wird hier sicherlich etwas passieren.
asc schrieb:
Zudem hat sich Embaccadero imho ins eigene Fleisch geschnitten, nachdem nun keinerlei kostenlose Version mehr existiert. Eine IDE die für möglichst viele zugänglich ist unterstützt die Verbreitung eines Frameworks massiv.
Da allerdings muß ich zustimmen.
-
Zeus schrieb:
Du kannst WPF Visual C++/CLI Projekte erstelle?
Ja, theoretisch sogar das (es ist umständlich, aber ich habe in einen Buch sogar dazu entsprechendes gefunden).
audacia schrieb:
Und da hier nach einer C++-IDE für Windows gefragt wurde, dürfte das durchaus relevant sein, oder?
Hast recht, ich bin etwas "ausgeglitten", habe aber auch unter der VCL schon einiges "erlitten". Nicht das die VCL grundsätzlich schlecht ist, sie integriert sich aber nicht wirklich schön in C++ (und hat imho, wie die alle Frameworks ihre Macken).
audacia schrieb:
Der mittelfristige Plan ist, wenn ich das richtig mitbekommen habe, auf der technologischen Basis des Class Explorer eine persistente Symboldatenbank zu erstellen, mit deren Hilfe man allerhand neue Features (das Rename-Refactoring, eine Symbolsuche, Aufrufgraphen etc.) implementieren kann.
Tut mir leid, ich glaube es inzwischen erst, wenn ich eine Umsetzung wirklich sehe. Und tut mir leid, das ich alle Versionen nach 2007 nur kurz antesten konnte - wir haben noch keinen Ersatz für alle Komponenten gefunden, und die DB-Umstellung verzögert sich immer weiter (Auch weil immer wieder zurück gerudert wird). Ich befürchte das in unserer Firma erst der Sprung gemacht wird, wenn der C++ Builder wesentlich mehr als nur den Class Explorer dazu erhalten hat (und damit rechne ich persönlich, nach bisherigen Erfahrungen, nicht allzu schnell).