Hallo wir diskutieren gerade in der Arbeit, mit welcher Software wir zukünftig PC-Steuerungen programmieren wollen. Aktuell wird C# und der Borland C++ Builder verwendet. Wer programmiert Messsoftware/ Steuerungen in Microsoft C++/C# (2010) und kann Vor- und Nachteile von Visual C++ (.net) und C# nennen ? (Es steht auch nur genanntes zur Diskussion, also kein HP VEE oder LabView oder Konsorten :-) ) Gruß Gerhard
Gerhard schrieb: > Wer programmiert Messsoftware/ Steuerungen in > Microsoft C++/C# (2010) und kann Vor- und Nachteile von Visual C++ > (.net) und C# nenne ? Ich mach' sowas in C#. Das Borland kenn' ich nicht. Aber verglichen mit der letzten .Net-freien Version in Visual Studio 6.0 ist C++.Net einfach eine Krücke. Ich denke, daß Microsoft das auch nur noch solange pflegt, bis die letzten MFC-Programmierer in Rente gegangen sind. DIE .Net-Sprache ist m.E. eindeutig C#. mfg.
Das ist eine interessante Fragestellung. Ich habe ebenfalls mit technischer PC-Software zu tun, die im Dauerbetrieb funktionieren muß. Bisher bin ich dabei sehr konservativ und verwende nur natives C++/MFC und sehr gut ausgeteste Bibliotheken. Erste Erfahrungen mit VC10 für kleinere Teilprojekte sind bisher vielversprechend, aber ich bin bezüglich des UI noch unentschlossen. Bitte schreibe doch mal über eure Erfahrung mit C# und .net in einer technischen Umgebung, insbesondere über den 24/7-Einsatz.
24/7 schrieb: > Das ist eine interessante Fragestellung. > > Ich habe ebenfalls mit technischer PC-Software zu tun, die im > Dauerbetrieb funktionieren muß. Bisher bin ich dabei sehr konservativ > und verwende nur natives C++/MFC und sehr gut ausgeteste Bibliotheken. 99% genauso bei uns Für Programmteile, bei denen es auf Performance ankommt, wird es auch noch lange so bleiben. Da die MFC nur ein dünner Wrapper um die Winapi ist, gibt es auch keine Geheimnisse oder unerklärlichen Phänomene denen man nicht Herr werden könnte. ...auch wenn die MFC seit mindestens 10 Jahren schon totgesagt wurde. Solange man keine Teletubbi-Schickimickifrontend braucht, spricht auch dabei nichts gegen die MFC. My 2 cent
Ich weiß nicht, ob man marktführende Produkte in dieser Fragestellung einfach so kategorisch (ideologisch?!?) ausschließen sollte. Auch halte ich z.B. Diagramme oder Anzeigen, die während der Messung auf einfache Art und Weise den aktuellen Zustand visualisieren nicht für "Teletubbi-Schickimickifrontend". Mag ja mächtig wichtig erscheinen, alles in möglichst kryptographischer Art in einer Shell darzustellen. Ob dies jedoch einer professionellen Prüfstandssoftware (um die es hier jawohl geht) gerecht wird, sollte jeder für sich selbst entscheiden. [Um den Wind aus den Segeln zu nehmen: Ja, ich bin auch in der Lage in einer Shell zu arbeiten!] Aber zum Thema: Wenn ihr tatsächlich für eine der beiden Sprachen entscheiden müsst, würde ich sagen, nehmt dass, das für eure eingesetzte Hardware die bessere Treiberunterstützung DLLs Programmierbeispiele bietet. Und das wäre bei unseren Produkten eher C++.
Hi, wir benutzen ebenfalls VS2010 mit C# und auch noch den "guten" alten C++-Builder 5. Mit beiden Entwicklungsumgebungen arbeiten wir jetzt schon recht lange, so dass ich mir mal ein Urteil erlaube: C++-Builder: Eigentlich ein gutes Konzept. Ich mag die VCL, da sie leicht zu verstehen ist und viele wichtige und sinnvolle Windowselemente kapselt und auch einheitlich darstellt. Leider hat es Borland geschafft, durch nicht vorhandenen Service und wirklich haarsträubender Fehler im Compiler und in der IDE den Großteil seiner Kunden zu vergraulen. Gerade bei großen Projekten stößt der C++-Builder schnell an seine Grenzen und man programmiert um bestimmte Fehler herum. Für heutige Verhältnisse kann man aber kleine kompakte Programme erstellen, die auch auf älterer Hardware ohne Probleme läuft. Für meine privaten kleineren Softwareprojekte benutze ich den Builder immer noch, denn man kommt damit schnell zum Ziel. Was von diesen Aussagen für die neueren Versionen noch gilt kann ich nicht sagen, wir sind aus bestimmten Gründen (kaputte Internationalisierungstools in Version 6) bei dieser Version geblieben. VS2010: Machst Du .NET, dann nimm um Himmels Willen auch C#. C++ mit den .NET-Erweiterungen ist wirklich eine Krücke und kommt bei uns nur in managed/unmanaged-Wrapper-Dlls zum Einsatz. Hat man sich mit C# erst einmal angefreundet, dann bietet es eine Fülle von neuen Möglichkeiten (z.B. Reflection, LINQ), die Probleme auf recht elegante Weise mit wenig Code lösen lassen. Auch die Unterstützung durch die IDE ist hervorragend und macht nach kurzer Zeit richtig Spaß. Kennt man die Borland-VCL, dann kommt man auch schnell mit WinForms zurecht. Möchte man WPF benutzen, dann steht man erst einmal wie der Ochs vorm Scheunentor, denn die Lernkurve ist wirklich extrem steil und viele bekannte Konzepte und Vorgehensweisen nützen einem hier nichts mehr. Verabschieden kann man sich z.B. von einem visuellen Editor zur Dialogerzeugung. Den gibt es zwar unter WPF auch noch, nur funktioniert Klickie-Klackie dort konzeptbedingt einfach nicht. Also schreibt man seine Dialoge direkt in XAML und das muss man erst einmal erlernen und verstehen. Die Möglichkeiten sind dann allerdings fast unbegrenzt und die Oberflächenlogik läßt sich zum Großteil implizit in XAML beschreiben und man muss sich in der Applikation nicht mehr darum kümmern. Mit heutigen Rechnern sehe ich auch bei den aufwendigen WPF-Oberflächen keine Performanceprobleme. Bei der Ansteuerung von spezieller Hardware kann es dagegen schon etwas aufwändiger werden, vor allem dann, wenn mit C-Frameworks der Hersteller interagiert werden muss. Wir haben in solchen Fällen .NET-C++-Wrapper benutzt, um von der managed- zur unmanaged-Welt zu gelangen. In einfachen Fällen mögen aber auch ein paar P-Invoke-Funktionen reichen. Mein Fazit: Ich würde C#.NET benutzen, da die Sprache und die IDE tolle Möglichkeiten bietet. Was man für die Oberfläche nimmt muss jeder selbst entscheiden, hier mögen auch Kundenwünsche ausschlaggebend sein. Gruß, Oliver
Hallo danke für die Posts. Ich habe ja gehofft, dass VC++ als Empfehlung rauskommt. Bisher habe ich nur mit dem C++ Builder gearbeitet, und da kann nach herzenslust alte Traditionen wie globale Variablen usw genutzt werden, was aber bei C# nicht geht (oder doch?). Alte Vorlieben wirft man ungern über Bord. Muss ich mich also doch noch mal mit C# beschäftigen. Gruß Gerhard
Gerhard schrieb: > Hallo > > danke für die Posts. Ich habe ja gehofft, dass VC++ als Empfehlung > rauskommt. Bisher habe ich nur mit dem C++ Builder gearbeitet, und da > kann nach herzenslust alte Traditionen wie globale Variablen usw genutzt > werden, was aber bei C# nicht geht (oder doch?). Wie in C++ auch. Klasse mit öffentlichen, statischen Methoden, Membern oder Eigenschaften > Alte Vorlieben wirft > man ungern über Bord. Muss ich mich also doch noch mal mit C# > beschäftigen. Zum einen ist, wie schon erwähnt wurde, der Übergang von VCL zu WinForms bzw. dem .NET-Framework relativ "weich" (man sieht deutlich die Handschrift von Anders Hejlsberg (TP, VCL, C#, .NET)), andererseits ist das Framework wesentlich umfangreicher d.h. die Eingewöhnung in C# 2) dürfte, je nach Vorkenntnissen/Motivation nur einen Bruchteil der Zeit ausmachen den man braucht, um das gesamte Framework zu überblicken und voll nutzen zu können. Wenn man sich auf WinForms "beschränkt" 1), kann man mit C# und .NET auch portable Sachen entwickeln. > Gruß > Gerhard 1) http://www.mono-project.com/Compatibility "Everything in .NET 4.0 except WPF, EntityFramework and WF, limited WCF." 2) Preview der neueren Funktionen u.a. CaaS und den guten alten Read Evaluate Print Loop http://msdn.microsoft.com/en-us/roslyn
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.