C++ Builder 10.3.2 - Eine Frage zur IDE
-
Die Probleme fangen ja nicht erst bei großen Projekten an. Ich habe scherzhalber mal ein komplett neues VCL-Projekt angefangen und mit Ausnahme der benennung der Dateien und des Ablageorts exakt so belassen, wie das Template es generiert. Sprich ein Winz-Projekt mit einer Form. Bereits da stieg mir regelmäßig das ein oder andere Feature aus.
Was würde ich für einen neuen Kollegen geben, damit wir endlich anfangen können wirklich über eine Portierung nachzudenken...
-
@asc OT:
Wir denken gerade auch ernsthaft über eine Portierung auf´s Visual Studio nach, wie weit sind denn da eure Erkenntnisse? Ich beschäftige mich jetzt seit knapp 2 Wochen sporadisch mit dem Visual Studio und bin da eigentlich nur auf drei sinnvolle Ansätze gekommen:
-
C++ und Qt
Die (fast) rundherum sorglos Lösung. Qt integriert sich in´s Visual Studio und bringt kaum eigene Schlüsselwörter mit. Wenn man GUI und Programmlogik sauber trennt kann man Standard-C++ programmieren. Einziger Wermutstropfen sind die eingeschränkten Qt-Widgets. Wenn man die DevExpress und Steema TeeCharts Komponenten für VCL verwendet ist man schon sehr verwöhnt, was man als GUI so alles zaubern kann, und das fehlt mir bei Qt einfach. -
Managed C++ und .NET Forms
Vorteil ist, dass man .NET Komponentensammlungen von Drittanbietern nutzen kann (DevExpress und Steema bieten ihre Produkte auch für .NET an). Nachteil ist aber der Managed-Code und Microsoft-eigene Spracherweiterungen (gcnew, Zeiger mit ^, etc.). Außerdem gibt es eine RTL mit Garbage Collector, die bei Echtzeitbildbearbeitung (machen wir) schon mal stören kann. -
C#, C/C++ und .NET Forms
Die Überlegung ist, alles Zeitkritische in C/C++ zu erledigen und die Visualisierung in C# zu machen. Das hätte die Vorteile, dass man Standard-C++ machen kann und bei der Visualisierung eine Sprache ohne Rumflickerei wie bei managed C++ benutzen zu können. Dazu gibt´s wieder die schicken Komponenten von DevExpress und Steema. Allerdings ist das Marshalling von C/C++ nach C# besch...., und das ist für mich im Moment ein KO Kriterium für diesen Ansatz.
-
-
@Smitty sagte in C++ Builder 10.3.2 - Eine Frage zur IDE:
Also mit dem C++Builder kannst du Recht haben, aber die VCL war - ist - und wird immer - besser sein als die MFC. Fakt.
Wahrscheinlich. Sehr sicher sogar. Mag ich aber nicht zu 100% bestätigen
Die MFC hab ich noch nie gemocht. Ist total umständlich, kein gutes C++ usw.
Die VCL hab ich gemocht, als ich Delphi programmiert habe. Das passt nicht zu C++, vermittelt auch einen schlechten Stil (keine Ahnung, was sich in den letzten Jahren getan hat). Das macht die MFC natürlich noch nicht besser, aber irgendwie scheidet damit der C++ Builder und die VCL als ernsthafte C++ Plattform aus.Was man halt nehmen kann, ist Qt oder GTK. Ich kenn mich mit Qt besser aus, arbeite schon viele Jahre intensiv damit. So wirklich mögen tu ich das auch nicht. Es ist gut genug, wenn man anspruchslos ist. Will da auch nicht ins Detail gehen, egal. Aber ich kenn halt nichts besseres.
@DocShoe Ich würde dir pauschal zu 1 raten. Kann man ohne weitere Infos nicht abschließend beurteilen, aber was ich mir dabei denke. 2 fällt im Endeffekt weg, ist aus meiner Sicht gar keine Lösung. 3 ist relativ umständlich. Kommt auf das konkrete Projekt drauf an, aber ich denke, mir wäre das bei jedem größeren Projekt irgendwann zu umständlich. Und wenns "noch" komplexer wird, will man einfach eher "schnell" was machen, ohne sich zu überlegen, wie man das überhaupt marshallen kann usw. Deswegen würde ich 1 bevorzugen.
Und für komplexere Visualisierung dann evtl. eher ein Webfrontend (evtl. einfach im lokalen Browser). Bei sowas wie Charts findet man mittlerweile einfach viel mehr ausgereifte JS Komponenten, als etwas für andere Sprachen.
-
Allerdings ist das Marshalling von C/C++ nach C# besch...., und das ist für mich im Moment ein KO Kriterium für diesen Ansatz.
Wo genau drückt denn der Schuh? xD
Weil: meiner Erfahrung nach ist das nicht so ein Problem. Ich hab mal die Streaming-Player für eine CCTV Software geschrieben. Da gab's 32+ gleichzeitige Streams auf bis zu 3 Monitoren. Auf "middle-of-the-road" Hardware von vor ~10 Jahren. Die erste Variante wurde mit WinForms gebaut und die zweite mit WPF. Beides lief am Ende sehr gut. Mit WPF war es einiges an Fummelei dem System auszureden dauernd out-of-memory zu gehen, weil die D3D/WPF Interop es nicht ermöglicht die Interop-Texturen zu disposen. Nachdem das über mitzählen und selbst GC.Collect aufrufen work-arounded war, lief es dann aber recht gut. Und WinForms war sowieso kein Thema.
Der GC kann natürlich zum Problem werden. Kommt halt drauf an wie zeitkritisch "realtime" wirklich ist. Wenn du kein einziges Frame droppen darfst, dann kannst du es natürlich vergessen. Damit scheiden dann aber 2 und 3 gleichermassen aus, und es bleibt eh nur noch 1 und "1-Derivate".
-
@Smitty sagte in C++ Builder 10.3.2 - Eine Frage zur IDE:
(...) aber die VCL war - ist - und wird immer - besser sein als die MFC. Fakt.
Und wenn du wissen willst was ich meine hier ein kleines Beispiel: Nimm einen BCB 6 und ein VS 6. (...)Echt jetzt? Das Argument mit dem du dein "war - ist - und wird immer - besser sein" bekräftigst ist ein Vergleich zweier ~20 Jahre alter IDEs?
Also nicht falsch verstehen. Ich bin garantiert kein MFC Fanboy und ich kenne die VCL nicht und kann es daher nicht vergleichen. Was ich aber schon weiss ist dass sich in den letzten 20 Jahren sowohl bei VS als auch bei der MFC einiges getan hat.
-
@hustbaer sagte in C++ Builder 10.3.2 - Eine Frage zur IDE:
@Smitty sagte in C++ Builder 10.3.2 - Eine Frage zur IDE:
(...) aber die VCL war - ist - und wird immer - besser sein als die MFC. Fakt.
Und wenn du wissen willst was ich meine hier ein kleines Beispiel: Nimm einen BCB 6 und ein VS 6. (...)Echt jetzt? Das Argument mit dem du dein "war - ist - und wird immer - besser sein" bekräftigst ist ein Vergleich zweier ~20 Jahre alter IDEs?
Habe damals( 2005 - 2006 ) beruflich mit dem VS 6 gearbeitet und hatte privat den BCB 6 im Einsatz. Glaube es oder nicht, ich kann mich noch sehr gut daran erinnern dass das 6er Studio deutlich öfters Probleme bis hin zu Abstürzen gebracht hat.
Also nicht falsch verstehen. Ich bin garantiert kein MFC Fanboy und ich kenne die VCL nicht und kann es daher nicht vergleichen. Was ich aber schon weiss ist dass sich in den letzten 20 Jahren sowohl bei VS als auch bei der MFC einiges getan hat.
Nö, laut einem Bericht von M$ vor einigen Jahren ist die MFC nur noch geduldet. Voller Focus auf .NET. Ist auch nicht schwer zu glauben.
Mit VS muss ich dir aber Recht geben. Das gefällt selbst mir mittlerweile richtig gut.
Gehe auch deswegen immer mehr in Richtung C# .NET.p.s.:
Echt jetzt? Das Argument mit dem du dein "war - ist - und wird immer - besser sein" bekräftigst ist ein Vergleich zweier ~20 Jahre alter IDEs?
-> und wenn ich sowas lese, weiss ich doch gleich wie alt ich bin
-
@Smitty sagte in C++ Builder 10.3.2 - Eine Frage zur IDE:
Habe damals( 2005 - 2006 ) beruflich mit dem VS 6 gearbeitet und hatte privat den BCB 6 im Einsatz. Glaube es oder nicht, ich kann mich noch sehr gut daran erinnern dass das 6er Studio deutlich öfters Probleme bis hin zu Abstürzen gebracht hat.
Das glaube ich dir schon dass du das damals gemacht hast und dich noch erinnern kannst. Es hat nur keine Aussagekraft bezüglich aktuellen Versionen.
Nö, laut einem Bericht von M$ vor einigen Jahren ist die MFC nur noch geduldet. Voller Focus auf .NET. Ist auch nicht schwer zu glauben.
Jain. Zwischen 1998 (VC6) und 2008 ist garantiert noch einiges passiert. Danach vielleicht weniger, aber selbst Support für Ribbons wurde z.B. noch eingebaut. Klar hat MFC jetzt keinen Fokus mehr. Heisst aber trotzdem nicht dass sich seit VC6 nix mehr getan hätte. Und ist auch nicht so.
Mit VS muss ich dir aber Recht geben. Das gefällt selbst mir mittlerweile richtig gut.
Naja und der von dir kritisierte Designer ist Teil der IDE, nicht Teil der Library. Wobei ich aktuelle Versionen da auch nicht mehr verwendet habe. Ich weiss nicht wie viel sich wirklich getan hat. Ich meine nur: Du weisst es vermutlich genau so wenig
Und damit ist das "Fakt." in deinem Beitrag mMn. etwas ... naja sagen wir so, es passt gut zum Zeitgeist 
-> und wenn ich sowas lese, weiss ich doch gleich wie alt ich bin
Ich hab es bisher noch halbwegs erfolgreich geschafft mein inneres Bild/Verständnis von "alt" stetig fliessend anzupassen. Ich bin nicht alt. Nur die anderen sind so schrecklich jung
-
Wo genau drückt denn der Schuh? xD
Hab grad wenig Zeit, ich schreib nächste Woche ein paar Sätze dazu.
-
@hustbaer
Ich habe letztens in VS2017 mit der MFC arbeiten müssen, und glaub mir, die MFC kommt (immer noch) nicht mal ansatzweise an die Leistungsfähigkeit der VCL bzw. Firemonkey heran. Selbst "Kleinigkeiten" wie das Ändern der Hintergrundfarbe eines Controls oder des Fonts muss da immer noch selbst programmiert werden.Es ist aber auch echt zum K...n:
- Embarcadero hat ein super Framework, aber eine "bescheidene" IDE.
- Microsoft hat eine super IDE, aber eine bescheidenes Framework, zumindest was die MFC angeht.
Mönsch, könnt ihr euch nicht mal zusammentun?
-
@DocShoe sagte in C++ Builder 10.3.2 - Eine Frage zur IDE:
@asc OT:
Wir denken gerade auch ernsthaft über eine Portierung auf´s Visual Studio nach, wie weit sind denn da eure Erkenntnisse?
Wir überlegen garnicht den C++ Code in irgendeiner Weise zu retten und inzwischen besteht auch die Einigkeit uns von Desktopanwendungen zu trennen. Für uns kommen derzeit zwei Alternativen in den Sinn: Entweder Java oder C#. Aufgrund fehlender Entwicklerkapazitäten liegt die Entscheidung aber seit längeren auf dem Eis. Bevor wir nicht mindestens einen weiteren Entwickler bekommen, brauchen wir über eine Portierung nicht nachzudenken (und je nach Kenntnissen kann ein weiterer Entwickler den Ausschlag für die ein oder andere Richtung geben).
C++ mag zwar in performancekritischen Anwendungen nicht unwichtig sein, meine Erfahrung ist aber, das Performance zwar nicht ganz vernachlässigt werden sollte, aber in 90% der Businessanwendungen auch nicht das Hauptkriterium ist. Zudem hat sich bei uns als Flaschenhals in der Anwendung, auch bedingt durch spezielle Anwendungsszenarien, nicht die Sprache/Codebasis als solche, sondern der allgemeine Umgang mit den Daten herausgestellt (auch wenn schon recht lange von mir gesagt, wurde das erst nach diversen Optimierungen auf DB-Seite inkl. DB-Seitiger Datenaufbereitung als Fakt akzeptiert).
Wir haben aber auch keine grafisch extrem aufwendigen Darstellungen, oder viele zeitlich hochkritische Berechnungen (und in den Bereichen wo so etwas vielleicht mal am Rande relevant werden würde, muss es nicht auf dem Client laufen - den es ist nicht die schnelle Darstellung, sondern wenn die schnelle Datenanalyse/-zusammenstellung relevant, das kann als Webservice oder vergleichbares außerhalb der eigentlichen Kernanwendung laufen, Sprache ist dann auch egal).
- C++ und Qt
Die (fast) rundherum sorglos Lösung. Qt integriert sich in´s Visual Studio und bringt kaum eigene Schlüsselwörter mit. Wenn man GUI und Programmlogik sauber trennt kann man Standard-C++ programmieren. Einziger Wermutstropfen sind die eingeschränkten Qt-Widgets. Wenn man die DevExpress und Steema TeeCharts Komponenten für VCL verwendet ist man schon sehr verwöhnt, was man als GUI so alles zaubern kann, und das fehlt mir bei Qt einfach.
Haben wir aufgrund mehrerer Faktoren ausgeschlossen:
- Für unseren Anwendungsfall ist C++ schlicht nicht die Sprache der Wahl, da kann man in anderen Sprachen mit weniger Aufwand schneller zum Ziel kommen.
- Hohe Lizenzkosten wenn man nicht rein dynamisch baut oder Support haben will.
- Der immer größere Wunsch von Kunden und Interessenten auf Webtechniken umzustellen, hat dem ein Ende bereitet.
Die anderen Alternativen können wir aus dem gleichen Grund für uns selbst ausschließen. Ich favorisiere aktuell .Net Core, da gibt es auch gute Komponenten (u.a. von Devexpress) die nach den bisherigen Erkenntnissen alles können was wir brauchen (an der ein oder anderen Stelle mag die Bedienung leicht anders sein, das liegt aber auch daran das unser Projekt eine selbstgebaute Komponente verwendet (wovon in der Firma aber auch nur einer wirklich überzeugt ist, ich [und nicht nur ich] präferieren da die Kalender/Scheduler-Controls diverser Hersteller).
Aber wie gesagt: Bei uns ist die Performance nicht das Hauptkritierium, zumal die Anforderungen/Wünsche von Kundenseite eh für eine Webanwendung sprechen. Dort wo Performance relevant ist, geht es nicht um Echtzeitdarstellung und um jede Milisekunde, sondern um die Vorverarbeitung/-analyse von Daten und später ggf. noch um automatische Ressourcenplanung. Aspekte die in unseren Fall in einen eigenständigen Service ausgelagert werden können (auch C++ wäre hier denkbar).
Und viele der Aspekte die von Anwenderseite aktuell zu einem "hängen" im Arbeitsprozess führen (und als Performanceproblem gesehen werden), sind weniger der eigentlichen Performance sondern den Umständen wie dieses Programm entwickelt wurde (Singlethreading, modale Fenster...) und wie es mit Fenstern umgeht geschuldet. Nur an einer Stelle ist wirklich die Reaktion das Problem (was aber der Art und Weise geschuldet ist wie die Daten verwendet werden; Unnötiges einlesen großer Datenmengen wo nur ein Bruchteil wirklich relevant ist, für Abfragen/Prüfungen ungünstig strukturierte Daten in der Datenbank die anders abgelegt/aufbereitet oder vorberechnet werden sollten...).
- C++ und Qt
-
@asc
Dann kenne ich auch einen "ganz besonderen" Fall:
Bei meinen ehemaligen AG wurde eine Software entwickelt, die alle 15 Sekunden Daten aus einer Datenbank gelesen und dann dargestellt hat, das Problem war nur, das diese Abfrage 12-13 Sekunden lang dauerte und in dieser Zeit dann das Programm nicht bedienbar war.
Mein Vorschlag, das ganze einen Hintergrundthread auszulagern, wurde energisch zurückgewiesen, da die SW. Spezifikation nicht verändert werden sollte, ebenso wurden meine Optimierungen seitens der DB wieder verworfen, da sie ebenso nicht in die SW- Spec passten.Letzendlich ist dann der Großkunde mit Regressforderungen abgesprungen, da sie es nicht hinbekommen hatten.
-
@Burkhi
Zum Glück wird hier nicht über Verbesserungen, Refactorings und DB-Optimierungen gestritten. Bei uns liegt das Problem nicht an Vorgaben, sondern rein an mangelnder Entwicklungskapazität.Aber bei uns bewerben sich zum einen nur seht selten welche und dann sind das entweder meist Personen die nicht selten schon beim Mini-Programmiertest scheitern (Simple Funktion mit einer 1-Zeilen Berechnung wo auch die Formel genannt wird schreiben - in einer nahezu beliebigen Programmiersprache), oder die ausschließlich von zu Hause remote arbeiten wollen (Wir lehnen zwar Home Office nicht gänzlich ab - wenn es auch in der Anfangsphase nicht gerne gesehen wird, aber ebenso erwartet man zumindest eine gewisse Überschneidung auch vor Ort). Und der einzige Neue (und technisch wirklich gute) schied leider aus gesundheitlichen Gründen nach wenigen Monaten wieder aus.
