Hallihallo! Ich entwickle eine Wuchtmaschine für kleine bis mittelgroße Rotoren. Die mechanischen Komponenten und die Datenerfassung stehen soweit schon, die Daten werden mit einem µC per Ethernet an einen PC mit Windows 7 bzw. Windows 10 gesendet. Meine ersten Programmiererfahrungen waren vor etwa 2 Jahren mit Matlab, hier habe ich meine erste Anwendung für die Datenauswertung entwickelt. Vor einem Jahr habe ich dann das Programm, was noch längst nicht fertig ist, auf C (WinAPI) umgeschrieben. Vor etwa einem halben Jahr bin ich dann auf C++ (MFC) umgestiegen. Da die Auswerte-Software am PC noch einige Zeit in Anspruch nehmen wird, stellt sich mir die Frage ob sich ein erneuter Umstieg, auf z.B. C# lohnt. Als Programmierumgebung möchte ich bei VisualStudio bleiben. Was mir an C# (WPF) gefällt, ist die XAML-Markupsprache für die GUI-Programmierung. Was mir an C++ (MFC) nicht gefällt ist die Kompilierungsdauer. Auch sieht es auf den ersten Blick mit VisualStudio so aus, als ob WPF Zukunftsträchtiger ist als MFC? Das Umschreiben meines bisherigen Codes würde kein Problem für mich darstellen. Die Plattform auf der meine Anwendung läuft kann ich selber auswählen, deshalb sehe ich die benötigten .Net Frameworks nicht als Nachteil. Bis auf das Ethernet-Gedöns, muss ich noch auf OpenGL bzw. DirectX Zugriff haben. Ethernet sollte kein Problem darstellen, zumindest nach dem was ich gelesen habe. Wie schaut es hier bezüglich OpenGL/DirectX aus? Welche Vorteile bzw. Nachteile hätte ich noch bezüglich C++ / C#? Eignet sich C# für Industrieanwendungen genauso gut wie C++? Danke schonmal! Grüße Reggie
Aus IT-Betriebssicht kann ich dir sagen, dass .Net Frameworks keinen Spaß machen und schwierig zu pflegen sind. Es gibt leider oft Spezial-Anwendungen die bestimmte .Net Versionen voraussetzen und mit anderen inkompatibel werden. Die Probleme sind natürlich alle lösbar, verursachen aber unnötigen Aufwand.
JJ schrieb: > Aus IT-Betriebssicht kann ich dir sagen, dass .Net Frameworks keinen > Spaß machen und schwierig zu pflegen sind. > Es gibt leider oft Spezial-Anwendungen die bestimmte .Net Versionen > voraussetzen und mit anderen inkompatibel werden. Die Probleme sind > natürlich alle lösbar, verursachen aber unnötigen Aufwand. Danke für den Gedanken. Habe erst vor einigen Tagen mit C# angefangen. Hättest du da ein konkretes Beispiel für mich?
Hallo, für solche Industrieanwendungen wäre es immer am besten, wenn sie so installiert würden, dass sie GARNICHTS weiter brauchen, also keine Version x.yz von Net-Libraries und möglichst wenig sonstiges Runtimezeugs, es sei denn, man liefert es selbst mit. Natürlich widerspricht das der Microsoft-Philosophie, die haben es am liebsten wenn du unrettbar abhängig bist, am besten speicherst du gleich deine Parameter bei denen in der Cloud, und alle Kunden brauchen ein Konto bei MS. Georg
Georg schrieb: > für solche Industrieanwendungen wäre es immer am besten, wenn sie so > installiert würden, dass sie GARNICHTS weiter brauchen, also keine > Version x.yz von Net-Libraries und möglichst wenig sonstiges > Runtimezeugs, es sei denn, man liefert es selbst mit. Natürlich wäre mir eine absolut eigenständige Plattform am liebsten. Auf dem µC ist eine marginale GUI vorhanden, da ich aber nicht Unsummen an Geld ausgeben kann bietet sich mir ein Windows-PC prima an. Dort kann die weiterführende Auswertung erfolgen, händische Kalkulationen oder Ausdrücke. Ich verstehe die Problematik die du meinst aber ich bin hier absolut flexibel, was die PC-Software angeht, sprich ich habe das Sagen über die Plattform. Diese Problematik hätte ich aber wohl mit MFC auch? Dort benötige ich schließlich auch so einige Windows Bibliotheken.
Reginald L. schrieb: 1. > da ich aber nicht Unsummen an Geld ausgeben kann 2. >bietet sich mir ein Windows-PC prima an Finde den Logikfehler... Bleib bei C/C++, damit hast du was vernünftiges. C# und der .NET-Mist sind so ein ekliges Geraffel.
Horst schrieb: > 1. >> da ich aber nicht Unsummen an Geld ausgeben kann > 2. >>bietet sich mir ein Windows-PC prima an > > Finde den Logikfehler... Auf den ersten Blick sieht das tatsächlich so aus. Auf den Zweiten nicht mehr: Einen für das Projekt tauglichen Windows-PC gibt es komplett für ein paar hundert Euro, hier muss nur noch die eigentliche Anwendung entwickelt werden. Möchte man so eine Anwendung auf einem autarken, selbst entwickeltem System zum Laufen bekommen wird man allein für die Hardware inklusive Gehäuse und Bildschirm schon mehr los, geschweige denn in Hinsicht auf die Entwicklungsarbeit. Horst schrieb: > Bleib bei C/C++, damit hast du was vernünftiges. C# und der .NET-Mist > sind so ein ekliges Geraffel. Was meinst du mit "Geraffel"? Was mir gerade auffällt, ist, dass man viel mit "PInvoke" schaffen muss, zumindest in meinem Fall.
Ein Windows PC ist gut und passend zur Visualisierung und Parametrisierung eines Prozessen auf externen Hardware. Die Kommunikation waere daher seriell genuegend. zB per USB UART. Weshalb? Ein PC kriegt nie ein vernuenftiges Timing hin. Auch keine Echtzeit Verarbeitung. Das muss alles auf externer Hardware passieren. zB auf einem Arduino.
Uli, der Wilde schrieb: > Ein Windows PC ist gut und passend zur Visualisierung und > Parametrisierung eines Prozessen auf externen Hardware. Deshalb ja der PC, weil mein Projekt wirtschaftlicher und schneller zu entwickeln ist. Uli, der Wilde schrieb: > Die > Kommunikation waere daher seriell genuegend. zB per USB UART. > Weshalb? Ein PC kriegt nie ein vernuenftiges Timing hin. Auch keine > Echtzeit Verarbeitung. Das muss alles auf externer Hardware passieren. > zB auf einem Arduino. UART war mein erster Anlauf, mit steigenden Anforderungen bin ich auf USB gewechselt. Nach einiger Zeit bin ich schlussendlich bei Ethernet gelandet. Ausschlaggebend war die Übertragungsrate und der Ausschluss von USB3.0. Die Verarbeitung geschieht komplett auf dem PC da hier einfach die Performance und der Speicher vorhanden ist. Und naja, ein Arduino ist es nun wirklich nicht. Wobei ich schon an einen baremetal-Arduino gedachte hatte...
Hi, C# ist nix für Industriesteuerungen. Für Front-Ends kann man sich den Krampf antun, aber portabel ist das nicht, geschweige denn robust, da macht einem ein Windows OS schon einen Strich durch die Rechnung. Besser beraten ist man mit Linux-Kenntnissen, C++, C, ev. noch etwas Python fürs Testen. Wenn man embedded/realtime gehen muss, erleichtert man sich da schon mal viel Portierungsarbeit. MFC ist IMHO "Broken by design", es gibt da deutlich besseres wie Qt oder auch wxWidgets. Generell würde ich mich an die "Keep it Simple"-Formel halten. Darunter fällt das .NET/C#-Geschmodder schon mal nicht, schon bei C++ gehen da oft die Meinungen auseinander. Nichtsdestotrotz würde ich erst mal das machen, womit du dich am wohlsten fühlst und deine Prototypen am schnellsten umgesetzt kriegst. Alles andere muss man an Erfahrung so nach und nach sowieso sammeln.
Wenn du die Wahl zwischen C++ und C# hast und die Applikation mehr GUI als Numbercruncher wird: ganz klar C#. Gründe: - C# ist eine deutlich modernere Sprache als C++. Viel der Komplexität aus C++ gibt es in C# so nicht. Getrennte Header- und Implementierungsdateien, die z.T. unterschiedliche Semantik von static, volatile, virtual in beiden, Pointer**. Das muss alles kein Problem sein, es geht aber halt auch ohne. - Die Doku der .Net-Klassenbibliothek ist sehr gut. - Microsoft pflegt das .Net-Framework schon lange und .Net ist für MS wichtig, plötzlich abgekündigt wird es also vermutlich nicht. (C++ natürlich auch nicht) - C# ist potentiell sicherer als C++. C# wird zu Bytecode compiliert (Intermediate Language, IL) und interpretiert. C++ ist Maschinencode. Remote Code Execution oder Out-of-Bounds-Speicherzugriffe sind in IL, wenn überhaupt, nur viel schwieriger durchführbar. - Garbage-Collection. Ja, das kann man auch in C++ haben, soweit ich das verstanden habe muss man aber aufpassen nichts zu vergessen. In C# ist es umgekehrt, man muss sich Mühe geben damit sie versagt. Größter Nachteil von C#: es ist deutlich langsamer als C++.
Fitzebutze schrieb: > C# ist nix für Industriesteuerungen. Ich merke auch immer mehr, dass ich hier immer öfter auf die WinAPI-Funktionen zugreifen muss. Fitzebutze schrieb: > MFC ist IMHO "Broken by design", es > gibt da deutlich besseres wie Qt oder auch wxWidgets. Was meinst du damit genau? Was mich hier stört sind die Verrenkungen um eine akzeptable GUI aufzubauen. Das finde ich bei C# eben auch so toll. Ich glaube das ist wohl auch das hauptsächliche Problem, dass ich mit MFC zur Zeit habe und deshalb wechseln möchte. Hast du da einen Tipp, mit was ich am besten die GUI designen könnte? Unter MFC habe ich es ja mit dem Ressource-Editor gemacht, ein Witz gegen den Designer unter C#.
Tilo R. schrieb: > Wenn du die Wahl zwischen C++ und C# hast und die Applikation mehr GUI > als Numbercruncher wird: ganz klar C#. Das ist es eben: Die Anwendung soll ganz klar eine komfortable und zeitgerechte GUI haben. Sie soll nicht wie eine typisch-graue-alt-Industrieanwendung aussehen, warum Industrieanwendungen so aussehen ist mir dabei schon klar. Andererseits werden eben noch Modalanalysen durchgeführt als auch anspruchsvolle 2D-Plots. Tilo R. schrieb: > - C# ist eine deutlich modernere Sprache als C++. Das ist es auch noch, was mich zu C# treibt... Tilo R. schrieb: > Größter Nachteil von C#: es ist deutlich langsamer als C++. Hab ich auch schon gelesen, allerdings nichts von "deutlich" sondern eher im einstelligen %-Bereich. Wie dem auch sei: Spielt für meine Anwendung keine Rolle.
@Fitzebutze & Co: Schon mal auch nur fünf Minuten für industrielle Anwendungen entwickelt? Da laufen tausende Apps 24*7 ohne Probleme. Schonmal einen Instandhalter gesehen der ein Update auf eine neue Linuxversion hinbekommen hat? Werdet erwachsen und kricht erstmal aus der Schule bevor ihr so einen unbelegten Unfug schreibt!
Experte schrieb: > Schonmal einen Instandhalter > gesehen der ein Update auf eine neue Linuxversion hinbekommen hat? > Werdet erwachsen und kricht erstmal aus der Schule bevor ihr so einen > unbelegten Unfug schreibt! Fragt sich wer hier Müll schreibt. Windows ist doch so schrottig, dass Industrieanlagen bei Upgrades reihenweise ausfallen würden. Nicht umsonst laufen deswegen noch hunderttausende Maschinen mit Win 95, 98, 2000.
C# sowie Java, jeder kann sich den Sourcecode ansehen.
Willst Du das Programm nutzen oder verkaufen? Im ersteren Fall ist Matlab gar nicht so schlecht. GUIs sind schnell gebaut, und Zahlen kann Matlab auch schnell verarbeiten. Nicht so gut ist die Reaktionsgeschwindigkeit von Matlab-GUIs und die Lizenzpolitik.
Reginald L. schrieb: > Meine ersten Programmiererfahrungen waren vor etwa 2 Jahren mit Matlab, > hier habe ich meine erste Anwendung für die Datenauswertung entwickelt. > Vor einem Jahr habe ich dann das Programm, was noch längst nicht fertig > ist, auf C (WinAPI) umgeschrieben. Vor etwa einem halben Jahr bin ich > dann auf C++ (MFC) umgestiegen. > > Da die Auswerte-Software am PC noch einige Zeit in Anspruch nehmen wird, > stellt sich mir die Frage ob sich ein erneuter Umstieg, auf z.B. C# > lohnt. Das heisst du werkelst schon 2 Jahre an einer Software für dein Produkt, hast nach einem Jahr die Programmiersprache gewechselt und quasi neue angefangen und denkst jetzt wieder darüber nach die Programmiersprache zu wechseln? Dein Produkt wird nie fertig werden, und wenn doch ist es bis dahin völlig veraltet. Wenn man eine Software für ein Produkt entwickelt, dann legt man die Funktionalität fest, die Rahmenbedingungen, wählt danach die Hardware, notwendige 3rd Party Software und Progammiersprache aus und legt los. Es ist klar dass sich immer wieder Änderungen ergeben, so ein Projekt ist dynamisch, aber man muss einen Zeithorizont haben und zum Ziel kommen. Eine andere Programmiersprache ist höchstens für Version 2.0. Der ganze Thread klingt sehr nach Troll.
also SO geht das schonmal garnicht.. nur EINE Programmiersprache? den µC macht man natürlich in C dann bracht man aber auf jeden Fall eine Multi-Tier Anwendung die Datenbankanbindung in JAVA, wildem SQL, trigger (PL/SQL), den AppServer mit C#, Daten per XSL ausliefern (und ganz fest mit XSLT verwurstet), am Client natürlich CSS/HTML5/Javascript und auf jeden Fall ein Silverlight Plugin.. hab ich was vergessen? achso, die IPAd app in ObjectivC
Walter T. schrieb: > Nicht so gut ist die Reaktionsgeschwindigkeit von Matlab-GUIs und die > Lizenzpolitik. Reaktionsgeschwindigkeit stimmt. Was ist das Problem mit der Lizenzpolitik? Matlab-'Compiler' kaufen und fertig, oder nicht?
Horst schrieb: > Nicht > umsonst laufen deswegen noch hunderttausende Maschinen mit Win 95, 98, > 2000. Das stimmt nur teilweise. Der Grund dafür ist eben, dass die Maschinen "alt" sind und eben solche Maschinen nicht unbedingt alle 10 Jahre neu gekauft werden. Wenn eine Maschine eine hohe Ausfallsicherheit aufweisen soll, läuft da eh kein Windows drauf. Pic T. schrieb: > C# sowie Java, jeder kann sich den Sourcecode ansehen. Das ist ein Interessanter Punkt! Wie das? Walter T. schrieb: > Willst Du das Programm nutzen oder verkaufen? Im ersteren Fall ist > Matlab gar nicht so schlecht. GUIs sind schnell gebaut, und Zahlen kann > Matlab auch schnell verarbeiten. Ich will mir den Weg noch offen halten, Potenzial für den Verkauf ist vorhanden, deshalb bin ich von Matlab weggegangen. Der Andere schrieb: > Das heisst du werkelst schon 2 Jahre an einer Software für dein Produkt, > hast nach einem Jahr die Programmiersprache gewechselt und quasi neue > angefangen und denkst jetzt wieder darüber nach die Programmiersprache > zu wechseln? Nä. Vor etwa anderthalb Jahren habe ich mit der Entwicklung der Maschine begonnen. Die Entwicklung der Anwendung zählt dazu auch, ja. Der Andere schrieb: > Der ganze Thread klingt sehr nach Troll. Hier klingt nur einer nach Troll.
Reginald L. schrieb: > Pic T. schrieb: >> C# sowie Java, jeder kann sich den Sourcecode ansehen. > Das ist ein Interessanter Punkt! Wie das? https://msdn.microsoft.com/de-de/library/bb979397.aspx
Fitzebutze schrieb: > Hi, > > C# ist nix für Industriesteuerungen. Für Front-Ends kann man sich den > Krampf antun, aber portabel ist das nicht, geschweige denn robust, da > macht einem ein Windows OS schon einen Strich durch die Rechnung. Von welchem Windows reden wir hier? Windows 95? Solche Visualisierungen/Steuerungen unter Windows zu machen ist absolut üblich (und danach klingt OpenGL, DirectX) Wenn es um harte Echtzeit geht ist die Plattform weder (nur) ein normaler PC/Server noch ein OS wie Linux oder Windows, die so komplex sind, dass die geforderten Eigenschaften nicht mit realistischem Aufwand bewiesen werden können. Portabel wird das ganze sowieso nicht und muss es auch nicht sein, da niemand den Aufwand betreiben wird mal eben zwischendurch die (Betriebs-)Systeme auszutauschen. Ob man mittel-/langfristig über andere Systeme nachdenkt, ist dagegen was anderes und durchaus sinnvoll. > Generell würde ich > mich an die "Keep it Simple"-Formel halten. Darunter fällt das > .NET/C#-Geschmodder schon mal nicht, schon bei C++ gehen da oft die > Meinungen auseinander. Ohne Begründung ist das einfach nur Polemik Reginald L. schrieb: > Was meinst du mit "Geraffel"? Was mir gerade auffällt, ist, dass man > viel mit "PInvoke" schaffen muss, zumindest in meinem Fall. Für was genau? Georg schrieb: > Hallo, > > für solche Industrieanwendungen wäre es immer am besten, wenn sie so > installiert würden, dass sie GARNICHTS weiter brauchen, also keine > Version x.yz von Net-Libraries und möglichst wenig sonstiges > Runtimezeugs, es sei denn, man liefert es selbst mit. Natürlich > widerspricht das der Microsoft-Philosophie, die haben es am liebsten > wenn du unrettbar abhängig bist, am besten speicherst du gleich deine > Parameter bei denen in der Cloud, und alle Kunden brauchen ein Konto bei > MS. Pic T. schrieb: > C# sowie Java, jeder kann sich den Sourcecode ansehen. .NET Native... "During precompilation, required portions of the .NET Framework are statically linked into your app. This allows the app to run with app-local libraries of the .NET Framework..." https://msdn.microsoft.com/en-us/library/dn584397.aspx
:
Bearbeitet durch User
Arc N. schrieb: > Für was genau? Ich habe gestern Abend/Nacht mal in C# reingeschnuppert und wollte beispielsweise eine Console im Hintergrund, als Debugging-Hilfe, laufen lassen. Um dieses Fenster auf meine Wünsche anzupassen musste ich schon fünf WinAPI-Funktionen importieren (AllocConsole(),SetWindowLong(),...) Arc N. schrieb: > .NET Native... > "During precompilation, required portions of the .NET Framework are > statically linked into your app. This allows the app to run with > app-local libraries of the .NET Framework..." > https://msdn.microsoft.com/en-us/library/dn584397.aspx Das ist natürlich auch sehr interessant, hab ich auch nicht gewusst.
Reginald L. schrieb: > eine Console im Hintergrund, als Debugging-Hilfe, laufen > lassen Nimmt man dafür nicht üblicherweise das VisualStudio Output Fenster? Also "Debug.WriteLine(...)"? Hat den Vorteil, dass es im Release-Build automatisch entfernt wird.
:
Bearbeitet durch User
Boris P. schrieb: > Nimmt man dafür nicht üblicherweise das VisualStudio Output Fenster? > Also "Debug.WriteLine(...)"? Ich benutze im entfernten Sinne Console.WriteLine(). Ich dachte hier an ein Debugging ohne VisualStudio. Ist auch nur im "Admin-Modus" zu sehen. Ich spiele immer noch mit C# herum. Sehe ich das richtig, dass ich mit C++ kleine Bibliotheken schreiben kann und darin enthaltene Funktionen in C# benutzen kann?
Reginald L. schrieb: > Ich spiele immer noch mit C# herum. Sehe ich das richtig, dass ich mit > C++ kleine Bibliotheken schreiben kann und darin enthaltene Funktionen > in C# benutzen kann? Ja, das geht. Entweder ein rein native DLL schreiben und die per PInvoke verwenden, oder noch einen C++/CLI Wrapper mit in die DLL packen, dann lässt sie sich wie eine ganz normale .NET Assembly als Referenz in C# verwenden.
Boris P. schrieb: > Ja, das geht. Entweder ein rein native DLL schreiben und die per PInvoke > verwenden, oder noch einen C++/CLI Wrapper mit in die DLL packen, dann > lässt sie sich wie eine ganz normale .NET Assembly als Referenz in C# > verwenden. Super, danke!
Kann es sein, dass du Programmiersprache zu sehr mit GUI-Toolkit assozierst? Beides hat in meinen Augen nur bedingt etwas miteinander zu tun. Wenn du C/C++ beherrschst, dann bleib doch einfach dabei und such dir ein genehmes GUI Toolkit. MFC kommt mit Visual Studio mit, das ist bequem. Aber MFC hat auch mir nie so richtig Spaß gemacht. Hast du dir mal Qt oder wxWidgets angesehen? Ist in meinen Augen deutlich moderner. Qt ist super, wenn portierbarkeit wichtig ist. Es ist extrem umfangreich und sieht am besten aus, wenn es um die Erstellung eigener UI Elemente geht. wxWidgets ist dagegen ein Leichtgewicht, super wenn einem die fertigen Widgets ausreichen (man kann aber natürlich auch eigene erstellen) und einfach nicht so überwältigend. Und das sind nur die zwei, die ich verwende. Da gibt es noch deutlich mehr. Vielleicht ist auch was für dich dabei: https://de.wikipedia.org/wiki/Liste_von_GUI-Bibliotheken#C.2B.2B
Angehängte Dateien:
Stephan W. schrieb: > Kann es sein, dass du Programmiersprache zu sehr mit GUI-Toolkit > assozierst? Beides hat in meinen Augen nur bedingt etwas miteinander zu > tun. Ich glaube du bringst es auf den Punkt! Stephan W. schrieb: > Wenn du C/C++ beherrschst, dann bleib doch einfach dabei und such dir > ein genehmes GUI Toolkit. > MFC kommt mit Visual Studio mit, das ist bequem. Aber MFC hat auch mir > nie so richtig Spaß gemacht. Hast du dir mal Qt oder wxWidgets > angesehen? Ist in meinen Augen deutlich moderner. > Qt ist super, wenn portierbarkeit wichtig ist. Es ist extrem umfangreich > und sieht am besten aus, wenn es um die Erstellung eigener UI Elemente > geht. wxWidgets ist dagegen ein Leichtgewicht, super wenn einem die > fertigen Widgets ausreichen (man kann aber natürlich auch eigene > erstellen) und einfach nicht so überwältigend. Genau das ist es, mit MFC wird der ganze Code so langsam sehr unübersichtlich. Auf der Qt-Homepage war ich schon, weißt du da wie es mit der OpenSource-"Lizenz" aussieht? Muss ich hier den kompletten Code offenlegen oder nur den der GUI? Stephan W. schrieb: > Und das sind nur die zwei, die ich verwende. Da gibt es noch deutlich > mehr. Vielleicht ist auch was für dich dabei: > https://de.wikipedia.org/wiki/Liste_von_GUI-Bibliotheken#C.2B.2B Auch diese Seite habe ich mir schon angesehen...und wurde mit Informationen erschlagen. Ich würde gerne etwas in Richtung angehängtes Bild erstellen, mit Freigabe des GUI-Codes habe ich absolut kein Problem. Nur den restlichen Code würde ich gerne vorerst für mich behalten wollen. Könntest du mir da Qt empfehlen? Vielen Dank für diesen Stups in die richtige Richtung!
Arc N. schrieb: >> Generell würde ich >> mich an die "Keep it Simple"-Formel halten. Darunter fällt das >> .NET/C#-Geschmodder schon mal nicht, schon bei C++ gehen da oft die >> Meinungen auseinander. > > Ohne Begründung ist das einfach nur Polemik Die Begründung kann ich gerne zusammenfassend liefern - es gibt aber eine Menge Threads dazu. Das Framework ist mit Konstrukten aufgebläht, die ein vernünftiges Memory-Management sehr schwierig machen. Das endet dann darin, dass ein etwas aufwendigerer Prozess, der öfters Objekte alloziert/freigibt, nach einigen 100 Betriebstunden plötzlich keinen Speicher mehr kriegt, obwohl genügend da ist. Siehe Memory-Fragmentierung. Das Problem ist allerdings nicht OS-spezifisch, obwohl die Linux-SLAB-Allocation etwas besser performt als das Windows-Speichermanagement. Auf einem Embedded-Target oder Schaltschrankelement ist das ein Albtraum. Die Chancen, ein C#-Programm für eine robuste Steuerung zertifiziert zu kriegen, sind somit deutlich geringer als bei einer sauber programmierten State-Machine in C mit strengen Regeln was malloc() betrifft. Mit den Runtime-Strukturen von .net kann man sich richtig elegant ins Knie schiessen. Wer sowas zertifiziert oder als robust erklärt, ist meines Erachtens nicht seriös. Das ist schon bei C++-Sachen knifflig, aus dem Grund ist auch kein einziges stabiles OS in C++ geschrieben. Wenn man diesen Ansatz verfolgen will, muss man eine Menge C++-Features schon mal verbieten, da kann mans auch gleich in besser verifizierbarem C machen. Wie ich ja schon sagte: Für Visualisierung ist das kein Problem, da sind Betriebszeiten von einigen 1000 Stunden am Stück auch nicht gefordert. Was nun Industriesteuerungen und die Fragen des TO angeht: Wenn man mit der Zeit gehen will, ist man mit Kenntnis in Linux/QNX o.ä. und QT nicht schlecht beraten. Nicht umsonst stecken solche Entwicklungen bevorzugt in medizinischen Diagnosegeräten. Ist aber immer wieder bezeichnend, dass bei dem Thema die Troll-Unken wieder aus ihren Löchern unken :-) Wenn man bei grossen, schwerfälligen Firmen arbeiten will, kann man mit Klickibunti aus der Microsoft- oder Apple-Welt nach wie vor punkten, da man es dort oft nicht anders kennt und 90% der Entwicklung für die Fehlersuche durch externe Spezialisten finanzieren kann :-) Und für Prototyping ist Klickibunti auch völlig ok, darum: macht ruhig C#, wenn es industriell wird und Geld abwirft, kann man es immer nochmal neu und robust machen (lassen). Typischerweise muss Klickibunti auch nicht 24/7 laufen und nicht unbedingt in 10 Jahren wiederverwertbar sein. Reginald L. schrieb: > Was meinst du damit genau? Was mich hier stört sind die Verrenkungen um > eine akzeptable GUI aufzubauen. Das finde ich bei C# eben auch so toll. > Ich glaube das ist wohl auch das hauptsächliche Problem, dass ich mit > MFC zur Zeit habe und deshalb wechseln möchte. Hast du da einen Tipp, > mit was ich am besten die GUI designen könnte? Unter MFC habe ich es ja > mit dem Ressource-Editor gemacht, ein Witz gegen den Designer unter C#. MFC ist ein Dinosaurier, da stecken Altlasten drin, die man heute einfach nicht mehr so machen würde. So manche Callback-Konzepte sind da von hinten durch die Brust und sorgen nicht für robuste GUIs. Ich habe ganz gute Erfahrungen mit wxWidgets bzw. wxDesigner gemacht, letzterer wird allerdings nicht mehr gewartet. Ich würde mir mal die QT-Sachen anschauen, die sind von der Wartung her nicht schlecht. Wenn es nur um die GUI geht, haben auch andere Mütter schöne Kinder (Java, Delphi, ...). Für Rapid Prototyping ist sogar Labview oder myopenlab (Labview in Java für Arme oder Coder) legitim. Generell ist der Ansatz, eine vernünftige Library (DLL) zu entwickeln und entsprechend aus einer anderen Hochsprache zu nutzen, schon mal gut für die Wartbartkeit/Wiederverwertung. Aber dem C#-Framework sollte man die mainloop der Steuerung nicht überlassen :-)
Reginald L. schrieb: > Ich würde gerne etwas in Richtung angehängtes Bild erstellen, mit > Freigabe des GUI-Codes habe ich absolut kein Problem. Nur den restlichen > Code würde ich gerne vorerst für mich behalten wollen. Könntest du mir > da Qt empfehlen? Solange du dich vor Codelizenzen, die mit dem Wort "GPL" infiziert sind, hütest, musst du deinen Code nicht offenlegen. Bei "LGPL" auch nur den Code der Bibliothek, wenn du was dran veränderst. Und abgesehen davon: Eine Menge kleiner Firmen halten sich nicht an die GPL und regeln das später. Nur die grossen Firmen tauchen ab und an bei gplviolations.org auf...
Klingt zwar erstmal dumm, klappt aber überraschend gut: Python und Gtk mit https://sourceforge.net/projects/pygobjectwin32/ Mit cx_freeze kann man Python, Gtk und alle andere Abhängigkeiten in einen Ordner zusammenschnüren, der dann ohne weitere Abhängigkeiten auf jedem Windows läuft. Nen MSI-Installer kann man ohne Mehraufwand auch erzeugen. Allerdings wird das Programm, weil es Python und ein halbes GNOME mitbringt, gleich mehrere Megabyte groß und Gtk schert sich recht wenig darum, auf Windows nativ auszusehen.
Man kann den dynamischen Speicher auch umgehen indem man alle Objekte statisch alloziert ... Dann aendern sich nur die Werte und ein paar Flags.
Win User schrieb im Beitrag #4525602: > Das stimmt einfach nicht. Wenn ein Programm Speicher frisst hat der > Programmierer einen Fehler gemacht. In C++ muss new/delete ausbalanciert > sein, in C# muss man dem GarbageCollector in zeitkritischen Anwendungen > helfen. > Ha ha. Genau das ist das Problem. Garbage Collection im Userspace hat in robusten Anwedungen nix zu suchen. Mit Programmierfehlern hat das nichts zu tun, sondern damit, dass manche OS nur bedingt ihren Speicher reorganisieren können, wenn er zu sehr fragmentiert ist (lesen!). Trotzdem zeigt dir die Prozesskontrolle immer noch denselben "free heap" an. > Fitzebutze schrieb: >> Für Visualisierung ist das kein Problem, da sind >> Betriebszeiten von einigen 1000 Stunden am Stück auch nicht gefordert. > > Das erzahle mal den Usern die WinCC, InTouch usw. in der Produktion > einsetzen. Die führen ja auch regelmässig Freudentänze ob der stabilen Systeme auf...[har har]. > > Fitzebutze schrieb: >> Nicht umsonst stecken solche Entwicklungen bevorzugt in medizinischen >> Diagnosegeräten. > > Schonmal die Lizenzbedingungen von QNX gelesen? Auch die schliessen jede > Haftung für den Einsatz in medizinischen Geräten aus. Ich spreche von Diagnosegeräten. Der Marktführer in Rotkreuz setzt auf Linux, andere Marktführer im Bereich Robotik (ja, auch definitiv sicherheitsrelevant) auf QNX. > > Schonmal eine moderne Pruduktionsstätte, ein Schalthaus, eine > Steuerbühne von innen gesehen? Und schon wieder unken sie... Da sehe ich allerdings regelmässig SPS. Oh D. schrieb: > Man kann den dynamischen Speicher auch umgehen indem man alle Objekte > statisch alloziert ... Dann aendern sich nur die Werte und ein paar > Flags. Genau so macht man's, oder implementiert eigene memory pools. Aber typischerweise in Sprachen, die keinen bescheuerten Laufzeitballast mitbringen. Also z.B. C/C++. Das Problem hat man bei Python auch, aber man kriegt es besser in den Griff. Manche Kollegen würden sagen, dass C und Python ".NET done right" ist...
Fitzebutze schrieb: > Genau so macht man's, oder implementiert eigene memory pools. Aber > typischerweise in Sprachen, die keinen bescheuerten Laufzeitballast > mitbringen. Also z.B. C/C++. Das Problem hat man bei Python auch, aber > man kriegt es besser in den Griff. Manche Kollegen würden sagen, dass C > und Python ".NET done right" ist... Also ich würde in so einem Umfeld auf eine Sprache setzten, die es mir einfach macht robusten und sicheren Code zu schreiben. Und da sehe ich C# meilenweit vor C++. In C++ kann einfach zu viel schief gehen und einem dann um die Ohren fliegen, wenn man es am wenigsten erwartet. Auch in Sachen Multithreading ist das Leben mit C# um ein vielfaches einfacher. Von der Entwicklungseffizienz mal ganz zu schweigen... (PS: Und man bekommt echtes, natives Cross-Platform, was einem andere Sprachen/Frameworks wie z.B. Qt so nicht bieten können.)
:
Bearbeitet durch User
Habe jetzt ne Weile lang Qt ausprobiert, da gefällt mir der dauernde Wechsel zwischen Qt und MFC nicht so sehr. Ansonsten finde ich den GUI Builder allerdings spitze. Bleibe jetzt erst mal bei C#. Es ist schon ein deutlicher Unterschied zu MFC, vor allem zeitlich. Mit dem GUI Builder bin ich hier recht zufrieden. Boris P. schrieb: > In C++ kann einfach zu viel schief gehen und > einem dann um die Ohren fliegen, wenn man es am wenigsten erwartet. Bin mal gespannt wie es mit Sockets bei C# ausschaut. Mit MFC habe ich hier kleinere Probleme gehabt die ich nicht zufriedenstellend lösen musste. Boris P. schrieb: > Auch in Sachen Multithreading ist das Leben mit C# um ein vielfaches > einfacher Da bin ich auch gespannt. Bei MFC muss man schon schöne Verrenkungen anstellen.
Boris P. schrieb: > (PS: Und man bekommt echtes, natives Cross-Platform, was einem andere > Sprachen/Frameworks wie z.B. Qt so nicht bieten können.) Jetzt hast du meinen Trolldetektor kaputt gemacht. Soviel Schrott habe ich schon lange nicht mehr gelesen. QT das auf zig Plattformen läuft mit C#/.NET vergleichen, das nur auf Windows läuft und dann ernsthaft behaupten, C#/.NET wäre natives Cross-Plattform. Willst du uns verarschen?
Reginald L. schrieb: > Habe jetzt ne Weile lang Qt ausprobiert, da gefällt mir der dauernde > Wechsel zwischen Qt und MFC nicht so sehr. Hä? Was für ein dauernder Wechsel? > Bleibe jetzt erst mal bei C#. Es ist schon ein deutlicher Unterschied zu > MFC, vor allem zeitlich. Und wie machst du das da mit dem "dauernden Wechsel"? > Bin mal gespannt wie es mit Sockets bei C# ausschaut. Mit MFC habe ich > hier kleinere Probleme gehabt die ich nicht zufriedenstellend lösen > musste. Qt hat auch eigene komfortable Socketklassen. > Boris P. schrieb: >> Auch in Sachen Multithreading ist das Leben mit C# um ein vielfaches >> einfacher > Da bin ich auch gespannt. Bei MFC muss man schon schöne Verrenkungen > anstellen. Auch da hat Qt so einiges zu bieten. Reginald L. schrieb: > Auf der Qt-Homepage war ich schon, weißt du da wie es mit der > OpenSource-"Lizenz" aussieht? Warum "Lizenz" in Anführungszeichen? > Muss ich hier den kompletten Code offenlegen oder nur den der GUI? Wenn du für die kommerzielle Qt-Lizenz nicht bezahlen willst, kannst du Qt under der LGPL nutzen. Dann musst du Änderungen, die du an Qt selbst machst, offenlegen. Und es muss dem Benutzer möglich sein, die von dir gelieferte Qt gegen eine eigene Version auszutauschen, was im Wesentlichen darauf hinausläuft, dynamisch zu linken. Von deinen Programm selbst musst du keinerlei Code offenlegen. Reginald L. schrieb: > Ich würde gerne etwas in Richtung angehängtes Bild erstellen Dann könnte vielleicht Qt mit qwt ganz interessant sein. Fitzebutze schrieb: > Und abgesehen davon: Eine Menge kleiner Firmen halten sich nicht an die > GPL und regeln das später. Nur die grossen Firmen tauchen ab und an bei > gplviolations.org auf... Das soll jetzt hoffentlich keine Empfehlung sein, gegen Lizenzbedingungen zu verstoßen nach dem Motto: Interessiert ja eh keinen. Wer bei der Entwicklung einer kommerziellen Software so vorgeht, verdient es nicht anders, als in Grund und Boden geklagt zu werden.
Rolf M. schrieb: > Reginald L. schrieb: >> Habe jetzt ne Weile lang Qt ausprobiert, da gefällt mir der dauernde >> Wechsel zwischen Qt und MFC nicht so sehr. > > Hä? Was für ein dauernder Wechsel? > >> Bleibe jetzt erst mal bei C#. Es ist schon ein deutlicher Unterschied zu >> MFC, vor allem zeitlich. > > Und wie machst du das da mit dem "dauernden Wechsel"? > >> Bin mal gespannt wie es mit Sockets bei C# ausschaut. Mit MFC habe ich >> hier kleinere Probleme gehabt die ich nicht zufriedenstellend lösen >> musste. > > Qt hat auch eigene komfortable Socketklassen. Ich bin davon ausgegangen, dass ich Qt ausschließlich für die GUI benutze. Mit dem Qt-Editor möchte ich nur ungern arbeiten. Kann ich von Qt aus auch direkt WinAPI Funktionen nutzen? Rolf M. schrieb: > Das soll jetzt hoffentlich keine Empfehlung sein, gegen > Lizenzbedingungen zu verstoßen nach dem Motto: Interessiert ja eh > keinen. > Wer bei der Entwicklung einer kommerziellen Software so vorgeht, > verdient es nicht anders, als in Grund und Boden geklagt zu werden. Wer keine 300 Dollar monatlich für eine Lizenz ausgeben kann, der hat es auch nicht verdient zu programmieren!
Reginald L. schrieb: > Ich bin davon ausgegangen, dass ich Qt ausschließlich für die GUI > benutze. Mit dem Qt-Editor möchte ich nur ungern arbeiten. Kann ich von > Qt aus auch direkt WinAPI Funktionen nutzen? Qt ist nur eine Library, und da man in c(++) winapi funktionen aufrufen kann, kann man das auch aus von qt aufgerufenen callbacks. Das ist aber definitiv der falsche Ansatz. Wenn du die WinAPI funktionen nutzen willst, um das Fenster zu manipulieren, dann bleib gleich bei plain WinAPI. Entweder man nutzt das GUI Framework ganz oder garnicht, halbe Sachen sind murks. Wenn du WinAPI für andere zwecke benötigst, dan überlege dir eine Abstraktion mit einem sinvollen Interface. Ausserdem sollte man GUI und Logik trennen. Wenn du es richtig machst kannst du am ende das GUI, die Logik oder das Platformspezifische WinAPI geraffel austauschen, ohne den rest ändern zu müssen. Beffasse dich auch mit der Schichtarchitektur: https://de.m.wikipedia.org/wiki/Schichtenarchitektur (Die im Artikel verschiedenen aufgelisteten Schichten kann man ignorieren, man muss diese einfach sinnvoll wählen) Nun noch zum QT-Editor, den muss man natürlich nicht nutzen, wenn man nicht will. Ich finde QML cool, schau dir dass doch noch an. Reginald L. schrieb: > Wer keine 300 Dollar monatlich für eine Lizenz ausgeben kann, der hat es > auch nicht verdient zu programmieren! Dummes gelaber! Ich bin immer bestrebt, sowenige Fremdquellen wie möglich zu verwenden, und wenn ich etwas in seltenen fällen nicht selber schreibe, dann kommen mir nur Libraries mit MIT Lizenz oder vergleichbarem rein. Alles, was ich nicht für mich behalten will (80%), stell ich mit MIT Lizenz in die Wildnis. Dadurch muss ich mich nicht mit Lizenzproblemen herumschlagen, habe keine Kosten, bin Unabhängig, und Profitiere von den Profitören meiner Open Source teile. Es geht also nicht darum, keine 300$ ausgeben zu können, sondern dass das meistens total überflüssig ist.
Daniel A. schrieb: > Entweder man nutzt das > GUI Framework ganz oder garnicht, halbe Sachen sind murks. Sehe ich, insofern die Libraries auch das können was die WinAPI kann, auch so. Daniel A. schrieb: > Ausserdem sollte man GUI und > Logik trennen. Das werde ich jetzt versuchen noch weiter zu trennen als bisher. Ich programmiere ja noch nicht so lange...Übung, Übung, Übung... Daniel A. schrieb: > Dummes gelaber! Ich bin immer bestrebt, sowenige Fremdquellen wie > möglich zu verwenden, und wenn ich etwas in seltenen fällen nicht selber > schreibe, dann kommen mir nur Libraries mit MIT Lizenz oder > vergleichbarem rein. Alles, was ich nicht für mich behalten will (80%), > stell ich mit MIT Lizenz in die Wildnis. Dadurch muss ich mich nicht mit > Lizenzproblemen herumschlagen, habe keine Kosten, bin Unabhängig, und > Profitiere von den Profitören meiner Open Source teile. Es geht also > nicht darum, keine 300$ ausgeben zu können, sondern dass das meistens > total überflüssig ist. Naja, das war Sarkasmus. Ich versuche möglichst viel selber zu machen, sonst hätte ich auch nicht mit diesem Projekt begonnen. Mit Lizenzen und Urheberrechten sehe ich das privat sehr gelassen. Da ich noch nicht weiss, wo dieses Projekt endet, muss ich hier eben ein Auge darauf werfen.
Tilo R. schrieb: > Wenn du die Wahl zwischen C++ und C# hast und die Applikation mehr GUI > als Numbercruncher wird: ganz klar C#. Verzeih', aber ich finde das gar nicht so klar. > Gründe: > - C# ist eine deutlich modernere Sprache als C++. Viel der Komplexität > aus C++ gibt es in C# so nicht. Getrennte Header- und > Implementierungsdateien, die z.T. unterschiedliche Semantik von static, > volatile, virtual in beiden, Pointer**. Das muss alles kein Problem > sein, es geht aber halt auch ohne. Das stimmt, aber dafür hat man weniger Kontrolle über den genauen Ablauf. Das kann bei Echtzeitanwendungen zu erheblichen Problemen führen. > - Die Doku der .Net-Klassenbibliothek ist sehr gut. Die von beispielsweise Qt ebenfalls. > - Microsoft pflegt das .Net-Framework schon lange und .Net ist für MS > wichtig, plötzlich abgekündigt wird es also vermutlich nicht. (C++ > natürlich auch nicht) Qt gibt es noch länger als .NET und es wird vermutlich ebenfalls nicht morgen abgekündigt. > - C# ist potentiell sicherer als C++. C# wird zu Bytecode compiliert > (Intermediate Language, IL) und interpretiert. C++ ist Maschinencode. > Remote Code Execution oder Out-of-Bounds-Speicherzugriffe sind in IL, > wenn überhaupt, nur viel schwieriger durchführbar. Das behaupten die Java-Leute auch gerne... Die Erfahrung zeigt jedoch, daß es auch mit C# und Java möglich ist, unsichere Programme zu schreiben. Letztlich erhöht die Runtime Engine die Komplexität des Softwaresystems -- das ist einer der Gründe dafür, warum C# und Java meist langsamer sind als C++ -- und eine höhere Komplexität führt eben leider auch zu einer höheren Wahrscheinlichkeit von Fehlern und Sicherheitsproblemen, zu einem höheren Ressourcenverbrauch und zu einer geringeren Performanz. Das mag bei GUI-Anwendungen meistens keine größeren Probleme bereiten, im Echtzeit-Umfeld muß man aber genau auf solche Dinge achten. > - Garbage-Collection. Ja, das kann man auch in C++ haben, soweit ich das > verstanden habe muss man aber aufpassen nichts zu vergessen. In C# ist > es umgekehrt, man muss sich Mühe geben damit sie versagt. Garbage Collection ist bei Echtzeitanwendungen leider oft problematisch, weil sie nämlich gerne ausgerechnet dann zuschlägt, wenn gerade größere Datenmengen zur Verarbeitung anstehen. Das führt regelmäßig zu Problemen, welche nur in Abhängigkeit vom Laufzeitzustand auftreten und daher schwer zu debuggen und noch viel schwerer zu beheben sind. In modernem C++ mit RAII ist die Speicherverwaltung auch kein so großes Thema mehr, weil sich da schon der Compiler um viele Dinge kümmern kann. > Größter Nachteil von C#: es ist deutlich langsamer als C++. Richtig. Insofern: wenn die Echtzeit-Anforderungen nicht allzu hoch sind, keine hochgenaue Kontrolle über den Programmlauf notwendig und es kein Problem ist, sich von einem Hersteller und seiner Plattform abhängig zu machen, dann kann man jederzeit C# und .NET benutzen. Wenn irgend eines dieser Dinge Kopfschmerzen bereitet oder ohnehin man bereits C++ kann, dürfte hingegen dieses die bessere Wahl sein. Letztlich erkauft man sich etwas Komfort bei der Entwicklung zum Preis von Kontrolle, Ressourcenverbrauch und Performanz.
Reginald L. schrieb: > Fitzebutze schrieb: >> C# ist nix für Industriesteuerungen. > Ich merke auch immer mehr, dass ich hier immer öfter auf die > WinAPI-Funktionen zugreifen muss. > > Fitzebutze schrieb: >> MFC ist IMHO "Broken by design", es >> gibt da deutlich besseres wie Qt oder auch wxWidgets. > Was meinst du damit genau? Was mich hier stört sind die Verrenkungen um > eine akzeptable GUI aufzubauen. Das finde ich bei C# eben auch so toll. Mir scheint, Du hast Deine Wahl bereits getroffen. Wenn nicht, dann schau Dir mal Qt an -- und sag mir dann bitte, wo Du da Verrenkungen siehst. > Ich glaube das ist wohl auch das hauptsächliche Problem, dass ich mit > MFC zur Zeit habe und deshalb wechseln möchte. Hast du da einen Tipp, > mit was ich am besten die GUI designen könnte? Unter MFC habe ich es ja > mit dem Ressource-Editor gemacht, ein Witz gegen den Designer unter C#. Für Qt gibt es den Qt Designer, um einzelne GUI-Komponenten zu designen, oder eine komplette IDE namens QT Creator. Da Du oben erwähnst, daß Dir XAML gefällt: etwas ganz Ähnliches bietet Qt mit QML beziehungsweise der Qt Designer, der XML-Beschreibungen der mit ihm gebauten GUI-Komponenten erzeugt.
Reginald L. schrieb: > Auf der Qt-Homepage war ich schon, weißt du da wie es mit der > OpenSource-"Lizenz" aussieht? Warum Lizenz in Anführungszeichen? > Muss ich hier den kompletten Code offenlegen oder nur den der GUI? Weder, noch. Du mußt den Code ohnehin nicht "offenlegen" im Sinne von "frei verfügbar machen" oder "veröffentlichen", das ist ein beliebter Denkfehler in Bezug auf die GPL. Die verlangt aber nur, daß Du den Code und zugehörige Rechte an jene weiter zu geben, denen Du Deine Binärprogramme weitergibst -- also zum Beispiel einem Kunden, der Dein Programm gekauft hat. Kurz gesagt: Du bist nicht verpflichtet, Deinen Code oder Deine Binaries für jedermann zugänglich zu machen. Du bist nicht verpflichtet, Deinen Code oder Deine Binaries kostenlos weiterzugeben. Die GPL hindert Dich auch nicht daran, Deine Binaries zu verkaufen. Darüber hinaus steht die Qt-Library aber nicht (nur) unter der GPL, sondern auch unter der LGPL. Die wiederum sagt, daß Du die Bibliothek auch in Deiner proprietären Software benutzen darfst und nicht verpflichtet bist, den Code Deiner Software weiterzugeben -- auch nicht, wenn Du die Binaries verkaufst. Nur wenn Du etwas an Qt selbst veränderst, bist Du dazu verpflichtet, Deine Änderungen zugänglich zu machen -- und auch hier wieder nur denen, denen Du Deine Binaries gegeben bzw. verkauft hast.
Karl Käfer schrieb: > Die verlangt aber nur, daß Du den Code > und zugehörige Rechte an jene weiter zu geben, denen Du Deine > Binärprogramme weitergibst -- also zum Beispiel einem Kunden, der Dein > Programm gekauft hat. Und der (der Kunde) darf dann den Code in Internet hochladen und an alle verteilen, oder?
Sheeva P. schrieb: > Mir scheint, Du hast Deine Wahl bereits getroffen. Wenn nicht, dann > schau Dir mal Qt an -- und sag mir dann bitte, wo Du da Verrenkungen > siehst. Ja, so ziemlich, aber noch nicht ganz :) Mit Verrenkungen bei MFC meine ich, bei vielen Dingen das Rad neu erfinden zu müssen. Meine µC programmiere ich so ziemlich ohne Libs. Hier brauche ich die Echtzeit. Bei Windows ist das für meinen Fall absolut unnötig, allein schon aufgrund der Rechenleistung, es erspart mir jede Menge Arbeit bestimmte Problemstellungen mit einer Funktion lösen zu können, und wird dazu auch noch übersichtlicher. Sheeva P. schrieb: > Für Qt gibt es den Qt Designer, um einzelne GUI-Komponenten zu designen, > oder eine komplette IDE namens QT Creator. > > Da Du oben erwähnst, daß Dir XAML gefällt: etwas ganz Ähnliches bietet > Qt mit QML beziehungsweise der Qt Designer, der XML-Beschreibungen der > mit ihm gebauten GUI-Komponenten erzeugt. Den Designer finde ich ja spitze, was mir nicht gefällt ist der Editor, da würde ich gerne bei VisualStudio bleiben. Mir stellt sich jetzt auch die Frage, warum C++ (in meinem Fall)? Möchte ich bestimmte Sachen mit C machen, dann kann ich diese notfalls als Libs einbinden. Danke auch an Karl, für die Ausführung zur GPL, das klingt interessant, werde ich mir genauer anschauen.
Mir scheint hier wird sehr viel vermischt. Mal wird von der (Industrie)Steuerung an sich geredet, dann wieder von Applikationssoftware... Also das Szenario ist ja folgendes: Die Steuerung der Wuchtmaschine ist bereits implementiert (wie auch immer) und die Daten werden per Ethernet übertragen. Die Auswertesoftware soll also wahrscheinlich ausrechnen und anzeigen, welches Wuchtgewicht man anbringen muss oder ähnliches. Also meiner Erfahrung nach: Wenn es um so Sachen wie die angesprochene Auswertesoftware geht, dann ganz klar C#/.net. Mit C++ handelt man sich da nur Ärger ein, mit C# lassen sich schneller schönere und bessere Ergebnisse produzieren. Meiner Erfahrung nach, lassen sich außerdem nach mehreren Monaten mit C# leichter wieder Änderungen durchführen, als mit C++. Außerdem kann man sich mit reinem C++ relativ schnell auch unsaubere Memoryleaks einhandeln, die dann nach einer gewissen Zeit zu Abstürzen führen. C++ bürdet dem Programmierer sehr viel Verantwortung auf, eine Verantwortung die man idR bei der Entwicklung von Applikationssoftware abstrahieren möchte.
> Also meiner Erfahrung nach: Wenn es um so Sachen wie die angesprochene > Auswertesoftware geht, dann ganz klar C#/.net. Mit C++ handelt man sich > da nur Ärger ein, mit C# lassen sich schneller schönere und bessere > Ergebnisse produzieren. Meiner Erfahrung nach, lassen sich außerdem nach > mehreren Monaten mit C# leichter wieder Änderungen durchführen, als mit > C++. > > Außerdem kann man sich mit reinem C++ relativ schnell auch unsaubere > Memoryleaks einhandeln, die dann nach einer gewissen Zeit zu Abstürzen > führen. C++ bürdet dem Programmierer sehr viel Verantwortung auf, eine > Verantwortung die man idR bei der Entwicklung von Applikationssoftware > abstrahieren möchte. Der Vorteil von .Net ist also, dass man sich keine Mühe geben muss. Wenn das der Anspruch ist -- ok.
adcap schrieb: > Also das Szenario ist ja folgendes: Die Steuerung der Wuchtmaschine ist > bereits implementiert (wie auch immer) und die Daten werden per Ethernet > übertragen. Die Auswertesoftware soll also wahrscheinlich ausrechnen und > anzeigen, welches Wuchtgewicht man anbringen muss oder ähnliches. Ganz genau, es geht lediglich darum, die im Stream ankommenden Daten zu ordnen, analysieren und auszuwerten. adcap schrieb: > mit C# lassen sich schneller schönere und bessere > Ergebnisse produzieren. Das ist eben meine Anforderung, mit C++ wird der Code im gegensatz zu C# ellenlang und unübersichtlich. Für kleinere und kritischere Programme wird da C++ klar im Vorteil sein, weil man mehr Freiheiten hat. adcap schrieb: > C++ bürdet dem Programmierer sehr viel Verantwortung auf, eine > Verantwortung die man idR bei der Entwicklung von Applikationssoftware > abstrahieren möchte. Auch wieder ein entscheidender Faktor in meinem Fall: Ich programmiere noch nicht so lange. JJ schrieb: > Der Vorteil von .Net ist also, dass man sich keine Mühe geben muss. Polemik.
Reginald L. schrieb: > Welche Vorteile bzw. Nachteile hätte ich noch bezüglich C++ / C#? Eignet > sich C# für Industrieanwendungen genauso gut wie C++? Falls sich das in den letzten 10 Jahren nicht geändert hat ist Remote-Debuggen von .net-Applikationen ein riesiger Krampf, vor allem wenn man mit einem Notebook einen Leitrechner in einer fremden Domäne untersuchen muss. So weit ich mich erinnere ginge das nur, wenn die Domäne des Leitrechners und die des Notebooks eine Vertrauensstellung zueinander haben, das kann man eigentlich im Fall eines Industriebetriebs generell ausschliessen. Ergo nichts remote-debuggen, im Fall des Falles dann entweder eigenen Leitrechner mitnehmen, der aber mit der Aussenwelt dann nicht reden kann/darf/will, Entwicklungsumgebung am Leitrechner installieren (sehr böse, macht u.U. auch einiges kaputt) und oder nicht debuggen. Ach ja, keine Breakpoints in GUI-Delegates setzen. MFC ist auch ein Krampf, ein anderer halt.
Reginald L. schrieb: > Polemik. Nein da hat er schon recht. Reginald L. schrieb: > Den Designer finde ich ja spitze, was mir nicht gefällt ist der Editor, > da würde ich gerne bei VisualStudio bleiben. Wenn das dein einziges Problem ist: Es ist eine Unterstützung für diesen Basteleditor vorhanden.
nanana schrieb: > Karl Käfer schrieb: >> Die verlangt aber nur, daß Du den Code >> und zugehörige Rechte an jene weiter zu geben, denen Du Deine >> Binärprogramme weitergibst -- also zum Beispiel einem Kunden, der Dein >> Programm gekauft hat. > > Und der (der Kunde) darf dann den Code in Internet hochladen und an alle > verteilen, oder? Natürlich, das Recht -- und unter bestimmten Umständen eben auch die Pflicht -- zur Weitergabe gehören dazu. Die meisten Kunden sind allerdings nicht so blöd, Code zu veröffentlichen, den sie selbst teuer bezahlt haben. Immerhin würden sie dadurch die Investition in ihren Wettbewerbsvorteil invalidieren. Ich gebe meinen Code regelmäßig unter GPL an meine Kunden weiter, und bisher ist noch keiner auf die Idee gekommen, etwas zu veröffentlichen. Aber selbst wenn es einer tun würde, wäre mir das herzlich egal, denn ich habe mein Geld ja schon bekommen und der Kunde hat ein Recht auf das, was er bezahlt hat.
Reginald L. schrieb: >> Qt hat auch eigene komfortable Socketklassen. > Ich bin davon ausgegangen, dass ich Qt ausschließlich für die GUI > benutze. Mit dem Qt-Editor möchte ich nur ungern arbeiten. Kann ich von > Qt aus auch direkt WinAPI Funktionen nutzen? Ja kann man problemlos - braucht man aber eigentlich meist gar nicht. Qt zwingt dich nicht dazu, irgendeinen bestimmten Editor zu benutzen. Da kannst du nehmen, was du willst. > Rolf M. schrieb: >> Das soll jetzt hoffentlich keine Empfehlung sein, gegen >> Lizenzbedingungen zu verstoßen nach dem Motto: Interessiert ja eh >> keinen. >> Wer bei der Entwicklung einer kommerziellen Software so vorgeht, >> verdient es nicht anders, als in Grund und Boden geklagt zu werden. > Wer keine 300 Dollar monatlich für eine Lizenz ausgeben kann, der hat es > auch nicht verdient zu programmieren! Du meinst nicht, dass was falsch läuft, wenn jemand Geld mit Software-Entwicklung verdient und das auf Basis von geklauter Software tut? Reginald L. schrieb: > Den Designer finde ich ja spitze, was mir nicht gefällt ist der Editor, > da würde ich gerne bei VisualStudio bleiben. Dann tu das doch. Qt kann man auch in VisualStudio integrieren. http://doc.qt.io/vs-addin/
Sheeva P. schrieb: > Das stimmt, aber dafür hat man weniger Kontrolle über den genauen > Ablauf. Das kann bei Echtzeitanwendungen zu erheblichen Problemen > führen. Nicht bzw. nur zum Teil vorhersehbar ist die GC. Ab 4.6 gibt es GC.TryStartNoGCRegion https://msdn.microsoft.com/de-de/library/dn906201%28v=vs.110%29.aspx Der Rest ist genauso vorhersehbar wie in C++ auch: Von sehr gut bis gar nicht. > Das behaupten die Java-Leute auch gerne... Die Erfahrung zeigt jedoch, > daß es auch mit C# und Java möglich ist, unsichere Programme zu > schreiben. Anzahl der Sandbox-Ausbrüche bei .NET vs. Java? Und das obwohl die Quelltexte seit Jahren unter http://referencesource.microsoft.com/ liegen. > Letztlich erhöht die Runtime Engine die Komplexität des Softwaresystems > -- das ist einer der Gründe dafür, warum C# und Java meist langsamer > sind als C++ -- und eine höhere Komplexität führt eben leider auch zu > einer höheren Wahrscheinlichkeit von Fehlern und Sicherheitsproblemen, > zu einem höheren Ressourcenverbrauch und zu einer geringeren Performanz. Sprachs und nannte weiter oben Qt... Quelltext .NET 4.6.1 ~338 MB, QT 5.6 ~1418 MB > Garbage Collection ist bei Echtzeitanwendungen leider oft problematisch, > weil sie nämlich gerne ausgerechnet dann zuschlägt, wenn gerade größere > Datenmengen zur Verarbeitung anstehen. Da könnte noch lange OT über die verschiedenen GC-Ansätze für harte Echtzeit diskutiert werden... JamaicaVM wäre ein Stichwort > In modernem C++ mit RAII ist die Speicherverwaltung auch kein so großes > Thema mehr, weil sich da schon der Compiler um viele Dinge kümmern kann. Da oben schon von unsicheren Programmen die Rede war: Das sieht man bei C++ täglich in div. Browsern... > Letztlich erkauft man sich etwas > Komfort bei der Entwicklung zum Preis von Kontrolle, Ressourcenverbrauch > und Performanz. Etwas Komfort? Wenn Komfort auch Lesbarkeit, Wartbarkeit und Kleinigkeiten wie REPL etc. einschließt war C# gegenüber C++ z.T. schon recht deutlich besser und erst mit C++11/14 wurde letzteres etwas komfortabler. C++ gegenüber anderen GC-Sprachen insb. auch guten, funktionalen Sprachen: Da wird C++ immer sehr deutlich hinterherhinken... Robert S. schrieb: > So weit ich mich erinnere ginge das nur, wenn die Domäne des > Leitrechners und die des Notebooks eine Vertrauensstellung zueinander > haben, das kann man eigentlich im Fall eines Industriebetriebs generell > ausschliessen. Ergo nichts remote-debuggen, im Fall des Falles dann > entweder eigenen Leitrechner mitnehmen, der aber mit der Aussenwelt dann > nicht reden kann/darf/will, Entwicklungsumgebung am Leitrechner > installieren (sehr böse, macht u.U. auch einiges kaputt) und oder nicht > debuggen. Wie man's macht, so ist's verkehrt... Hätte MS das einfach zugelassen, hätten sie von allen Seiten - zu Recht - einen auf den Deckel bekommen, ist es etwas komplizierter, gibt's auch einen auf den Deckel.. https://msdn.microsoft.com/en-us/library/9y5b4b4f%28v=vs.100%29.aspx http://www.codeproject.com/Tips/618804/Remote-debugging-for-Visual-Studio-from-different
Rolf M. schrieb: > Du meinst nicht, dass was falsch läuft, wenn jemand Geld mit > Software-Entwicklung verdient und das auf Basis von geklauter Software > tut? Machen die Chinesen jeden Tag, nicht nur im Softwarebereich, und das ist auch gut so.
Was soll Qt mit Echtzeit zu tun haben ? Qt ist GUI, und Echtzeit ist was ganz anderes. Das GUI laeuft in einem Prozess(Thread) mit niedriger Prioritaet, und dann ist die Ausfuehrungszeit des Qt egal. Der Echtzeit Teil muss einfach deterministisch sein, mit jeder Variablen statisch alloziert ...
Reginald L. schrieb: > Das ist eben meine Anforderung, mit C++ wird der Code im gegensatz zu C# > ellenlang und unübersichtlich. Man kann in jeder Sprache sauber und übersichtlich oder unsauber und beschissen programmieren. Ein neues Tool oder eine andere Programmiersprache hilft dir gar nichts wenn du einfach nur wurstelst. Im Gegenteil, jede neue Sprache heisst erst mal Lernaufwand und ein Rückschritt in der Effizienz und der fehlerquote weil man die Tücken und Fallstricke nicht kennt. Das ist genauso wie ein schlechter Läufer, der meint mit neuen Laufschuhen jetzt die 5000m 4 Minuten schneller laufen zu können. Oder der schlechte Heimwerker, der meint für 1000de von Euros teuerstes Profiwerkzeug kaufen zu müssen. Es wird dadurch nicht besser!
Der Andere schrieb: > Man kann in jeder Sprache sauber und übersichtlich oder unsauber und > beschissen programmieren. Das ist schon klar. Andererseits brauchst du für eine Problemstellung mit einer Programmiersprache mehr Zeilen (somit unübersichtlicher) als mit einer anderen, um diese zu lösen. Beispiel Netzwerkadapter:
1 | // MFC
|
2 | PIP_ADAPTER_ADDRESSES h_adapters = 0; |
3 | ULONG adapters_size = 0; |
4 | GetAdaptersAddresses(AF_INET, NULL, NULL, NULL, &adapters_size); |
5 | h_adapters = (IP_ADAPTER_ADDRESSES*)MALLOC(adapters_size); |
6 | GetAdaptersAddresses(AF_INET, NULL, NULL, h_adapters, &adapters_size); |
7 | |
8 | // WPF
|
9 | NetworkInterface[] alladapters = NetworkInterface.GetAllNetworkInterfaces(); |
Und das zieht sich so durchs ganze Programm, mit wenigen Ausnahmen. Der Code wird länger und unübersichtlicher. Vielleicht nicht unbedingt sicherer, da ich aber Anfänger bin, kommt mir das schon zu Gute.
das ist doch nicht die MFC sondern die WinAPI https://msdn.microsoft.com/en-us/library/windows/desktop/aa365915%28v=vs.85%29.aspx
Robert L. schrieb: > das ist doch nicht die MFC > > sondern die WinAPI Weil MFC hierfür keinen Wrapper hat. Mir ging es lediglich darum, aufzuzeigen, dass Codeschnipsel für eine Problemstellung mit MFC generell länger werden als mit C# (zumindest für das, was ich bisher mit C# gemacht habe). Ich finde es schon praktisch, wenn mir die Programmiersprache simple Problemstellungen erleichtert, anstatt, dass ich eine ellenlange Funktion hierfür schreiben muss. So einfach wie möglich, so kompliziert wie nötig.
Reginald L. schrieb: > Ich finde es schon praktisch, wenn mir die > Programmiersprache simple Problemstellungen erleichtert, anstatt, dass > ich eine ellenlange Funktion hierfür schreiben muss. Das macht nicht die Sprache, sondern die API. Bei C++ (mit Qt) sieht der Code z.B. so aus:
1 | auto interfaces = QNetworkInterface::allInterfaces(); |
Rolf M. schrieb: > Das macht nicht die Sprache, sondern die API. Ja klar, hast recht. Ich denke, was mich auch so bei Microsoft hält, ist der Umstand, dass ich ausschließlich bei Windows bleibe. Habe inzwischen jetzt meine Klassen die in eigenen Threads laufen umgeschrieben. Das ist ein Unterschied wie Tag und Nacht im Vergleich zu MFC. Was ich auch prima finde, ist, dass sich .Net um eine Schar von Kleinigkeiten kümmert. Für meine Zwecke bin ich bisher absolut zufrieden mit dem Wechsel zu C#. Danke nochmals an alle für die hilfreichen Infos und Tipps!
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.