Ausrichtung: Welche entwicklungsumgebung?
-
Hallo zusammen,
ich entwickle und pflege ein paar Projekte, die als Client/Server im Windowsumfeld laufen. Als Serversystem ist der MS SQL Server (2008-2012) im Rennen, die Clientprogramme sinds nativ in C++ geschrieben.
Als Entwicklungsumgebung verwende ich den C++ Builder XE2 sowie hauptsächlich DevArt, TMS und DevExpress Komponenten. Etliche Codeteile der Businesslogik sind (zum Glück) rein C++, also die Haustypen und STL und deren Strings.
Wie jedes Jahr ärgere ich mich über die Informationspolitik von Emba und Co, und vor allem über die nicht eingehaltenen Versprechen, was denn alles kommen sollte, wie 64bit C+11 etc oder auch die laaaaaame CodeInsight Funktion bei größeren Projekten. ich habe erst gestern nochmals alle Header optimiert, und wo es geht Forward Deklarationen eingebaut... Und Jetzt gerade die Aufregung bezgl. einer eventuellen Änderung der EULA, ... Langsam habe ich darauf keine Lust mehr.
Meine Frage halt hier in das Forum, was gibt es denn für Alternativen?
Ich will der C++ Sprache treu bleiben, ich mags halt, und auch will ich nativ bleiben (bei einem Projekt ist dies Voraussetzung). Also alles .net fällt im Grunde aus.Was bleibt noch? Ok, Visual C++ mit derm MFC. Ich habe früher mal damit gearbeitet und dies war lange nicht so flüssig wie mit der VCL, auch der Designer hat nicht diese Qualitäten wie der des RAD Studios... Es gibt zwar auch Fremdkomponenten, aber deren Qualität kenne ich nicht. Wie ist es denn mit der MFC im Moment bestellt, ist das was mit Zukunft, wie siehts mit Drittkomponenten aus? Auf der anderen Seite ist die C++ Unterstützung auch nicht 100%ig... Was hat Microsoft für eine Strategie in diesem Umfeld?
Ich hab im Moment keinen Plan, bin aber gerade dabei ein neues Projekt aus zu tüfteln, was jetzt nicht gerade zeitkritisch ist. Ob ich die Alten portieren würde, weiss ich auch nicht, nur für was Neues sollte ich mich jetzt mal festlegen...
Daher mal so die Frage in die große Runde, was denkt Ihr, wie geht es weiter, was ist sinnvoll? Und was ist Eure Strategie?
Verwirrt...
Pixfreak
-
Was aktuell der Trend ist: .NET
Du schreibst den Backend Code in C++ und klatscht eine C# GUI mit WinForms oder WPF drueber. Ist halt insofern unpraktisch, als dass du 2 Sprachen hast statt einer. Dafure ist das GUI schreiben in C# auch viel bequemer als mit C++.
MFC wuerde ich nicht wirklich verwenden - ich habe noch ein MFC Projekt zu warten und es geht zwar ganz OK, aber MS setzt aktuell dauernd auf neue GUI techniken, so dass man nicht wirklich weiss wie die Zukunft aussieht. MFC wird zwar sicher nicht wegfallen, aber der support wird immer geringer.
Persoenlich wuerde ich Qt nehmen wenn ich jetzt ein neues Projekt mit C++ machen wuerde.
Vielleicht hilft dir dieser Thread aber auch weiter: http://www.c-plusplus.net/forum/p2247616#2247616
-
der aktuelle Trend ist HTML 5.
-
pixfreak schrieb:
Meine Frage halt hier in das Forum, was gibt es denn für Alternativen?
Realistisch betrachtet wohl nur Qt oder .net. Ich kenne eine Reihe von Firmen, die früher den C++ Builder eingesetzt haben aus geschäftlichen Kontakten, alle sind zu einer dieser beiden Alternativen gewechselt.
pixfreak schrieb:
Was bleibt noch? Ok, Visual C++ mit derm MFC. Ich habe früher mal damit gearbeitet und dies war lange nicht so flüssig wie mit der VCL, auch der Designer hat nicht diese Qualitäten wie der des RAD Studios...
Das gilt wohl noch immer so. MS pflegt die MFC weiter, wird da aber wohl nicht mehr viel neues bringen.
http://blogs.msdn.com/b/vcblog/archive/2012/06/14/10320171.aspxpixfreak schrieb:
Also alles .net fällt im Grunde aus.
Die Arbeit in C# kommt von allen Alternativen den gewohnten Abläufen im C++ Builder am nächsten. Angesichts der mäßigen Optimierungen des Borland Compilers ist C# auch meist die schnellere Alternative. Es sollte also gute Gründe für den Verzicht auf .net geben, man muss es mittlerweile als integralen Bestandteil von Windows betrachten.
Shade Of Mine schrieb:
Du schreibst den Backend Code in C++ und klatscht eine C# GUI mit WinForms oder WPF drueber. Ist halt insofern unpraktisch, als dass du 2 Sprachen hast statt einer.
Nach mehrjähriger Erfahrung mit solchen Projekten, sehe ich eigentlich keine Nachteile mehr in dieser Zweisprachigkeit, verglichen mit dem C++ Builder. Dort hat man ja eigentlich mit Delphi auch eine zweite Sprache. C# und C++ ergänzen sich durchaus ganz gut.
Shade Of Mine schrieb:
aber MS setzt aktuell dauernd auf neue GUI techniken, so dass man nicht wirklich weiss wie die Zukunft aussieht. MFC wird zwar sicher
Im Moment ist da wirklich nicht zu sehen, wohin die Reise geht. Das könnte sich allerdings bald ändern, eventuell schon zur Build Konferenz Ende Oktober. Klar ist die Entwicklungen um C++/CX und Metro haben in letzter Zeit viele Resourcen gebunden und auch die C++11 Unterstützung für VC++ verzögert. Aber klar ist, einmal haben sie wohl in letzter Zeit personelle Verstärkung bekommen und die für Metro gebundenen Resourcen werden jetzt anderweitig verwendet.
http://blogs.msdn.com/b/vcblog/archive/2012/08/29/cxxcxpart00anintroduction.aspx
http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-10-Welcome-Ale-Contenti-VC11-and-Beyond-with-Steve-Teixeira-and-Tarek-Madkour
-
also von Microsoft würd ich nix mehr anpacken, die schmeißen regelmässig alles über den Haufen. Sauladen!
-
Hallo, und danke für Eure Infos bzw. den Hinweis auf den obigen Thread.
Im Grunde bringt mich das irgendwie nicht weiter... Ich glaube im Moment ist es besser die Entwicklung einfach mal zu verfolgen und eine Entscheidung für später aufheben...
Sprachlich ist der Builder XE3 nicht wirklich weiter gekommen, in Anbetracht der großen Ankündigungen im Frühjahr eine Enttäuschung, habe ich mir aber schon fast gedacht... FM2 und irgend ein iOS oder so brauche ich halt nicht. Mal sehen, was vielleicht als Update später geliefert wird...
Zu MFC buw QT: Mit der MFC habe ich im aktuellen Visual Studio mal gespielt, der Designer ist da ja fast noch genau so wie früher bei VC++ 5... Schon alleine das positionieren der Steuerelemente ist schon tricky...
QT kenne ich noch aus der KDE2/3 Zeit. War recht ordentlich,ist halt aber mit Lizenz auch ein ganz schöner Kostentreiber...
Was gibt es denn für MFC bzw. für QT denn brauchbare Komponenten für einen Zeitplaner (tageweise für Resourcen) oder Reporting Tools ala Fast Report?
VG Pixfreak
-
Wenn du keine Probleme mit dem Compiler und der Einbindung von Bibliotheken oder modernem C++ hast, ist es für dich sicher besser, bei C++ Builder zu bleiben.
Es bleibt immer noch der in dem anderen Thread beschriebene Weg, Teile des Programms in VC++ als C-DLL oder COM-Komponente zu implementieren. Das macht aber wohl nur bei sehr GUI-lastigen Projekten Sinn, wenn der Anteil dieser externen Teile klein bleibt.
Welche Probleme aber mit bestehenden C++ Builder Projekten auftreten, wenn sie mal wirklich einen neuen Compiler rausbringen, kann im Moment noch keiner absehen.
-
Wie beruhigend, daß auch andere diese Probleme haben
Was den neuen C++Builder-Compiler angeht, mache ich mir keine großen Sorgen wegen der Kompatibilität. Das Ziel ist, Clang - also eine überaus solide Basis - um die C++Builder-Spracherweiterungen zu bereichern; wir werden eher darüber stolpern, daß Clang beim Implementieren des Sprachstandards akribischer ist als BCC (z.B. implementiert Clang Two-phase name lookup) und viele Dinge, die BCC durchgehen läßt, als Fehler markiert.
Das eigentliche Problem mit Delphi/C++Builder ist, daß die VCL völlig vernachlässigt wird, seit irgendjemand auf diese Cross-Platform-Geschichte verfallen ist; desweiteren wird die IDE kaum gepflegt, alte Bugs werden nur schleppend behoben und stattdessen zu den jährlichen Releases immer neue Features rausgehauen. In der Übergangszeit zwischen Borland zu Embarcadero schien mir das in die richtige Richtung zu gehen - Bugfixes nahmen einen viel höheren Stellenwert ein, die IDE wurde spürbar besser, Delphi wurde endlich eine moderne Sprache -, aber dieser Geist ist, vielleicht auch im Zuge der Personalumstrukturierungen (Verlagerung vieler mit erfahrenen Leuten besetztem Arbeitsplätze aus Scotts Valley/CA nach Rumänien, Rußland, Spanien, wo stattdessen jüngere und unerfahrenere, daher günstigere Mitarbeiter beschäftigt werden), mittlerweile flötengegangen.
Ich bin noch nicht entschieden, wie ich weiter verfahre. Zurzeit überlege ich, ob man nicht den Übergang zwischen plain C++ und irgendeiner (UI-freundlichen) Hochsprache wie C# oder eben auch Delphi vereinfachen könnte, indem man für das C++-Interface mehr oder weniger automatisch einen Wrapper generiert. Mit libclang wäre es sicher möglich, den C++-Code zu parsen; dann bräuchte man noch Interpretationshilfen, um zwischen Value-Types und Reference-Types zu entscheiden sowie das präferierte Speichermodell (Zeiger, intrinsische/extrinsische Referenzzählung, Pooling) zu erkennen, so daß man entscheiden kann, wie der Typ in anderen Sprachen zu repräsentieren wäre. Könnte ein spannendes Projekt sein.
-
pixfreak schrieb:
Meine Frage halt hier in das Forum, was gibt es denn für Alternativen?
Ich will der C++ Sprache treu bleiben, ich mags halt, und auch will ich nativ bleiben (bei einem Projekt ist dies Voraussetzung). Also alles .net fällt im Grunde aus.Nativ C++ würde ich vermutlich trotz einiger Punkte die mir nicht ganz gefallen wohl Qt wählen. Eine weitere native Möglichkeit, wenn gleich erst ab Windows 8 (inkl. WP8-Smartphones...) wäre WinRT (C++/CX) [Im wesentlichen eine native Rückportierung von .Net Ansätzen nach COM]. Oder du lebst weiterhin mit den Mankos von dem C++ Builder...
Das gleiche Problem hättest du aber auch aktuell mit .net, da MS seine Ankündigungen aktuell sehr schlecht gestaltet, und mit seiner aktuellen Art auch hier einigen Entwicklern an das Bein pisst... Wobei ich da inzwischen die Sache etwas besser sehe, da man doch mit geschickter Codetrennung recht gut verschiedene Wege gehen kann.
Welchen Weg du auch gehst: Die Gefahr auf das falsche Pferd zu setzen scheint mit aktuell Recht hoch. Ohne Glaskugel wie z.B. Windows 8 (und vielleicht 9) ankommen wird, wird die Zukunft recht schwer zu deuten sein.
@kenner der trends: HTML 5 sehe ich als keine Option für größere Anwendungen (Wenn überhaupt in einer Mischform, wo die Logik weitgehend ausgelagert ist).
-
audacia schrieb:
Zurzeit überlege ich, ob man nicht den Übergang zwischen plain C++ und irgendeiner (UI-freundlichen) Hochsprache wie C# oder eben auch Delphi vereinfachen könnte, indem man für das C++-Interface mehr oder weniger automatisch einen Wrapper generiert. Mit libclang wäre es sicher möglich, den C++-Code zu parsen; dann bräuchte man noch Interpretationshilfen, um zwischen Value-Types und Reference-Types zu entscheiden sowie das präferierte Speichermodell (Zeiger, intrinsische/extrinsische Referenzzählung, Pooling) zu erkennen, so daß man entscheiden kann, wie der Typ in anderen Sprachen zu repräsentieren wäre. Könnte ein spannendes Projekt sein.
Ja, klingt spannend. Eventuell sollten wir mal in einem separaten Thread unsere Erkenntnisse dazu sammeln.
Appropos Wrapper, hast du dir diese "Projektion" mal angesehen, die MS in Form von C++/CX zwischen Standard C++ und der Metro Version von COM geschaffen hat ?
-
nn schrieb:
Ja, klingt spannend. Eventuell sollten wir mal in einem separaten Thread unsere Erkenntnisse dazu sammeln.
Bist du auch aktiv interessiert an sowas? Ich werde mich damit eingehend beschäftigen, sobald ich dafür Zeit habe (so richtig erst ab Januar, wenn die Arbeit an meinem nächsten größeren Projekt - das mit dem Win32-UI - beginnt), vorher bekomme ich höchstens kleine Machbarkeitsstudien hin. Aber das braucht uns nicht vom Experimentieren und Brainstormen abhalten
Machst du einen auf?
nn schrieb:
Appropos Wrapper, hast du dir diese "Projektion" mal angesehen, die MS in Form von C++/CX zwischen Standard C++ und der Metro Version von COM geschaffen hat ?
Ja, hab ich. Das ist nett gemacht: COM, das sich wie .NET anfühlt, schöne Idee eigentlich. Aber die Implementierung von WinRT verzichtet wohl großenteils auf die Projektion und verwendet die WRL (die als "ATL on steroids" vielleicht nicht falsch beschrieben ist); und nach MC++ und C++/CLI bin ich ein wenig zurückhaltend, mich gleich auf den nächsten ever-so-slightly-different-but-incompatible C++-Dialekt zu stürzen, den Microsoft produziert hat.
-
audacia schrieb:
Machst du einen auf?
Gerne, sobald ich etwas mehr Zeit habe, meine Gedanken auszuformulieren. Kann etwas dauern.
Einmal beschäftigt mich die Automatisierung des Weges von C++ über C++/CLI (und die Marshalling Library) nach C#.
Dann wäre da noch die Nutzung von VC++ im C++ Builder, z.B. über COM. Ob und wann ich mich damit beschäftige, wird auch davon abhängen, ob ich mir XE3 leiste. Ist zwar im Budget, aber im Moment hält sich meine Begeisterung in Grenzen. Wenn es mal einen neuen Compiler gibt, wäre der auf jeden Fall einen Vergleich mit VC wert. Im Moment glaube ich aber, die fahren die selbe Taktik wie bei FireMonkey und wollen für etwas unfertiges kassieren, dass in der nächsten Version eh wieder umgekrempelt wird.
audacia schrieb:
Ja, hab ich. Das ist nett gemacht: COM, das sich wie .NET anfühlt, schöne Idee eigentlich. [...] und nach MC++ und C++/CLI bin ich ein wenig zurückhaltend, mich gleich auf den nächsten ever-so-slightly-different-but-incompatible C++-Dialekt zu stürzen, den Microsoft produziert hat.
Ich hoffe auch mehr darauf, dass sich das normale COM unter zukünftigem Windows dahin entwickeln könnte ...
audacia schrieb:
Aber die Implementierung von WinRT verzichtet wohl großenteils auf die Projektion und verwendet die WRL
In einem Interview auf Channel 9 hieß es, dass sei so, weil die WRL zuerst fertig war. C++/CX stand noch nicht zur Verfügung, als diese Arbeiten begannen.
-
nn schrieb:
In einem Interview auf Channel 9 hieß es, dass sei so, weil die WRL zuerst fertig war. C++/CX stand noch nicht zur Verfügung, als diese Arbeiten begannen.
Ah, das Bootstrapping-Problem. Leuchtet mir ein.
nn schrieb:
Einmal beschäftigt mich die Automatisierung des Weges von C++ über C++/CLI (und die Marshalling Library) nach C#.
Dann wäre da noch die Nutzung von VC++ im C++ Builder, z.B. über COM.
Dabei wäre festzuhalten, daß es andersherum jeweils recht einfach ist. Wenn du C#, Delphi oder Delphi-kompatibles C++ in C++Builder schreibst, bekommst du ja vollwertige RTTI, aus der du eine Projektion der Schnittstelle mitsamt Wrapper-Code generieren könntest. In C++ geht das ja leider nicht.
Überhaupt besteht die Frage, ob man vielleicht den Spieß umdrehen könnte und anstatt für den C++-Code, der die Arbeit macht, eine für C# oder Delphi verdauliche Schnittstelle zu generieren, umgekehrt aus dem UI eine C++-kompatible Schnittstelle extrahiert. Ich bin mir noch nicht ganz sicher, was die Konsequenzen eines solchen Ansatzes angeht, aber vermutlich würde das voraussetzen, daß man die Logik des Programmablaufes in C++ schreiben will, was im allgemeinen fraglich ist, wenn die andere Sprache (etwa C# oder sogar sowas wie Python) für Highlevel-Code viel besser geeignet ist, oder wenn man viele Kleinigkeiten im UI auch direkt im Event-Handler implementieren könnte, ohne die Steuerung wieder an die Programmlogik zu übergeben. Andererseits ist das vielleicht sogar gewünscht, weil man so konsequent eine Model/View-Trennung erzwingen kann. Fragen über Fragen...
Aber wir kommen schon arg vom Thema ab. Wäre es einem der Moderatoren, die hier mitlesen, vielleicht möglich, die letzten paar Postings in einen eigenen Thread zu verschieben, damit wir den Thread von pixfreak nicht völlig verunstalten? Eine sinnvolle Trennung wäre etwa nach diesem Posting.