Hallo. Habe damals viel Basic und weniger Delphi programmiert. Zuhause bin ich eher in C womit ich meine Mikrocontroller Projekte auch schreibe. Ab und an nutze ich AutoIT für kleinere Scripte. Nun bräuchte ich aber ab und an eine GUI am PC für meine Platinen. Möchte auf jeden Fall Crossplatform sein und habe mich daher von QT und Lazarus hin und her reissen lassen. Leider kenne ich mich aber in C++ nicht aus. Es sollen keine riesen Programme werden, sondern nur Auswertungs-Software und Hardware-Konfiguations-Programme. Zumeist nutze ich den FTDI-Chip für die PC-Ankopplung, daher habe ich in Verbindung mit QT einmal danach gesucht. Leider war ich etwas über die Ergebnisse geschockt. Selbst Leute, die mit der Umgebung schon so einiges Angestellt haben, kamen da an ihre Grenzen. Ich habe leider nicht die Zeit mich so extrem in eine Programmiersprache einzuarbeiten da andere Projekte Prio haben. Könnt Ihr hier irgendwie mir einen Tip geben wie ich mich am besten endscheiden sollte? Grüße Tim
kopfkratz Ja also was soll's denn werden ? In C++ einsteigen dürfte die sinnvollste Entscheidung sein. JAVA ist wegen dem ORACLE disaster ja nicht mehr uneingeschränkt empfehlenswert m( Und JAVA ist rein objektorientiert :-P Was Du brauchst ist einfach ein QT widget um Deine einkommenden Daten zu visualisieren, da einfach mal in die Doku schaun: http://qt-project.org/doc/qt-5.0/qtwidgets/qtwidgets-index.html Ist es eigentlich immer soooo schwierig eine Metasuchmaschine zu nehmen und nach den konkreten Anforderungen zu suchen ? Du brauchst also zwei Klassen, eine die Dir die Daten am PC abnimmt und eine die Dir selbige Daten visualisiert. Und es gibt gute online C++ Tutorials ...
@Dr. Sommer & Team: Java finde ich wegen der Hardwarenahen Geschichten nicht so passend. Hatte mir einmal NetBeans angeschaut und war nicht so von überzeugt... @Kopf-Kratzer: Doch doch, Suchen kann ich schon bedienen, nur finden die wie gesagt bei QT viele Probleme wenn es um USB-Anbindungen geht. Ich lasse mich aber gerne eines besseren belehren ;) Wie ich das mit den Klassen an sich händeln würde habe ich ja im Kopf. Die Frage war darauf abgezielt, ob es denn Sinn macht ohne nun fünf Wochen Einarbeitungsphase auch schon im Vorhinein was brauchbares hin zu bekommen. ...oder ob da Lazarus doch evtl. die bessere Entscheidung wäre. Bin aber ja eigentlich ohnehin eher zu C gerissen; Pascal Dialekte mag ich nicht so sehr.
Oh, stimmt. Die frage nach gewerblicher Nutzungsmöglichkeit gibt es ja auch noch -> http://www.heise.de/forum/heise-Developer/Kommentare/Programmentwicklung-mit-Qt-auf-Windows-7/kommerzielle-QT-Nutzung-tatsaechlich-ohne-kostenpflichtige-Lizenz/posting-442170/show/ Gleich mal einlesen.
Tim schrieb: > @Dr. Sommer & Team: Java finde ich wegen der Hardwarenahen > Geschichten Hä? Wo ist denn die GUI-Entwicklung am PC hardwarenah? > @Kopf-Kratzer: Doch doch, Suchen kann ich schon bedienen, nur finden die > wie gesagt bei QT viele Probleme wenn es um USB-Anbindungen geht. Was hat Qt mit USB zu tun? libusb oder direkt Serialport-Zugriff geht davon völlig unabhängig; genau wie in Java... > Ich lasse mich aber gerne eines besseren belehren ;) > Wie ich das mit den Klassen an sich händeln würde habe ich ja im Kopf. > Die Frage war darauf abgezielt, ob es denn Sinn macht ohne nun fünf > Wochen Einarbeitungsphase auch schon im Vorhinein was brauchbares hin zu > bekommen. Fünf Wochen in C++ könnte vielleicht hinkommen. Wenns schneller gehen darf würde ich zu was einfacherem wie eben Java raten. > Bin aber ja eigentlich ohnehin eher zu C gerissen; Pascal Dialekte mag > ich nicht so sehr. Kannst ja Gtk+ verwenden, aber GUI's ohne OOP zu programmieren ist irgendwie doof. kopfkratzer schrieb: > In C++ einsteigen dürfte die sinnvollste Entscheidung sein. C++ lernen ist auf jeden Fall sinnvoll, aber eben auch nicht so ganz einfach... > JAVA ist wegen dem ORACLE disaster ja nicht mehr uneingeschränkt > empfehlenswert m( Java hat 1000 Gründe es nicht zu verwenden (auch ohne Oracle), aber um mal eben schnell eine GUI zu bastlen ist es durchaus zu gebrauchen.
Dr. Sommer schrieb: >> JAVA ist wegen dem ORACLE disaster ja nicht mehr uneingeschränkt >> empfehlenswert m( > Java hat 1000 Gründe es nicht zu verwenden (auch ohne Oracle), aber um > mal eben schnell eine GUI zu bastlen ist es durchaus zu gebrauchen. ftp://ftp.heanet.ie/disk1/trolltech/pub/qt/pdf/qt-vs-java-whitepaper.pdf Die Schlussfolgerung stimmt auch heute noch, selbst wenn Swing durch SWT ersetzt wird "Java/Swing may be appropriate for certain projects, especially those without GUIs or with limited GUI functionality. C++/Qt is an overall superior solution, particularly for GUI applications."
Arc Net schrieb: > Dr. Sommer schrieb: >>> JAVA ist wegen dem ORACLE disaster ja nicht mehr uneingeschränkt >>> empfehlenswert m( >> Java hat 1000 Gründe es nicht zu verwenden (auch ohne Oracle), aber um >> mal eben schnell eine GUI zu bastlen ist es durchaus zu gebrauchen. > > ftp://ftp.heanet.ie/disk1/trolltech/pub/qt/pdf/qt-vs-java-whitepaper.pdf > Die Schlussfolgerung stimmt auch heute noch, selbst wenn Swing durch SWT > ersetzt wird > "Java/Swing may be appropriate for certain projects, especially those > without GUIs or with limited GUI functionality. C++/Qt is an overall > superior solution, particularly for GUI applications." Bitte lies noch einmal das komplette Dokument. Besonders im ersten Abschnitt wird hervor gehoben, dass Java erst bei Profis weniger effizient ist. Die Frage ist immer noch, dass ein Anfaenger versucht leicht eine GUI zu bauen, ohne sich im Detail mit OO zu beschaeftigen! Zwar zweifel ich Dr. Sommers Aussage an, dass es 1000 Gruende gibt nicht Java zu verwenden (ich wuerde fast sagen, dass es 1500 Gruende sind), jedoch ist die Aussage mit der schnellen GUI einfach nur richtig. Wenn man einfach nur schnell eine funktionierende GUI haben moechte, die keinen besonderen Elemente enthaelt, dann erreicht man mit Java einfach am schnellsten sein Ziel (oder natuerlich C#).
Wenn es nur um Oberflächenprogrammierung ginge, könnte man durchaus Java verwenden. Da lässt sich schon vieles schickes recht schnell zusammenbauen. Schwierig bis sehr schwierig wird es aber, wenn mit betriebssystemspezifischen Dingen zusammengearbeitet werden soll, sei es der Aufruf einer Win32-API-Funktion, das Verwenden von DLLs, von (D)COM oder gar die Integration von in C bzw. C++ geschriebenem Code. Wenn mit so etwas wie libusb oder Microsofts WinUSB gearbeitet werden soll, wenn die FTDI-eigenen DLLs genutzt werden soll, wird das mit Java aufwendiger als in C bzw. C++. Natürlich ist dann die eingangs gewünschte Portabilität auch nicht mehr gegeben - die FTDI-DLLs sind halt windows-spezifisch, und damit unter Linux so nicht nutzbar. Andererseits lassen sich die betriebssystemabhängigen Dinge auch so kapseln, daß die GUI unverändert übernommen werden kann, und nur die gekapselten Dinge angepasst werden müssen. Hier ist Qt als GUI-Toolkit keine schlechte Wahl; wxWidgets wäre ein alternativer Kandidat.
Ich könnte noch C# mit WinForms ins Rennen werfen. Das ist recht komfortabel in der Entwicklung, und wirklich cross-platform. D.h. das Programm läuft ohne Recompile auf Windows, Mac, Linux und sogar ARM (Rasperry Pi etc.).
Boris B. schrieb: > Ich könnte noch C# mit WinForms ins Rennen werfen. > > Das ist recht komfortabel in der Entwicklung, und wirklich > cross-platform. D.h. das Programm läuft ohne Recompile auf Windows, Mac, > Linux und sogar ARM (Rasperry Pi etc.). Echt jetzt? Ich dachte C# ist nur Windows? Kannst Du mehr schreiben? Gibt es eine kostenlose Entwicklungsumgebung um Erfahrungen zu machen?
Interessant schrieb: > Boris B. schrieb: >> Ich könnte noch C# mit WinForms ins Rennen werfen. >> >> Das ist recht komfortabel in der Entwicklung, und wirklich >> cross-platform. D.h. das Programm läuft ohne Recompile auf Windows, Mac, >> Linux und sogar ARM (Rasperry Pi etc.). > > Echt jetzt? Ich dachte C# ist nur Windows? Kannst Du mehr schreiben? > Gibt es eine kostenlose Entwicklungsumgebung um Erfahrungen zu machen? Die Sprache an sich ist ja erst mal nicht Platform-spezifisch. Spannender wird es dann beim Framework: Unter Windows gibt es das .NET Framework, unter Linux/Mac/Android gibt es Mono. Die beiden sind aber so weit kompatibel, dass ein für .NET geschriebenes Programm genauso auf Mono läuft und umgekehrt. Du kannst also die .exe Datei einfach von einem System auf's andere kopieren und dort sofort starten. Als Entwicklungsumgebungen gibt es z.B. Visual Studio Express (Windows), Xamarin Studio (Mac) oder MonoDevelop (Linux).
Danke für die Antwort! Kann ich auch XCode auf Mac verwenden? (Jaja, googeln kann ich :-) Dann wird das doch direkt versucht.
Ok, XCode ist nicht. Damit kann man aber leben. Nochmals danke für den Tipp.
Interessant schrieb: > Kann ich auch XCode auf Mac verwenden? Nicht dass ich wüsste. XCode beherrscht nur C++ und objC. Ich verwende auf dem Mac Xamarin Studio, das ist ganz brauchbar ;-) Schau mal auf der Mono-Homepage vorbei, da findest du alles was du brauchst (Runtime, IDEs, Sourcen, usw.)
finde schade das python noch nicht ins rennen geschickt wurde :) für einfache GUI sachen ist es auch sehr praktisch ansonsten würde ich mir wohl auch die mühe machen und C# + Mono mal genauer anschauen. C# + .NET ist dem Java Framework schon lange weit davon gelaufen und lässt sich kaum noch vergleichen Mit Mono hab ich leider keine Erfahrungen habe aber bisher fast nur gutes gehört.
Einfach. Hardwarenah + GUI + gute Verbreitung und Lernmöglichkeiten = C++. Für die GUI z.B. Qt (unterstützt die drei relevanten Desktop-Systeme). C# ist etwas "narrensicherer" und ich mag es auch, aber hier wäre es nicht meine erste Wahl.
Python + QT funktioniert einwandfrei plattformübergreifend. Habe da noch nie etwas editieren müssen. Die Sprache ist übersichtlich und es gibt einen Haufen praktischer Module. Bevor ich mir Java antun würde, würde ich lieber versuchen C++ plattformübergreifend zu schreiben.
C++/Qt oder Python/PyQt Letzeres ist vermutlich leichter zu lernen und viele Dinge, die in C++ relativ kompliziert sind, sind mit Python schnell hingehackt. Soo schlimm ist das mit der FTDI API unter C++ übrigens auch nicht...
Tim schrieb: > Habe damals viel Basic und weniger Delphi programmiert. > Zuhause bin ich eher in C womit ich meine Mikrocontroller Projekte auch > schreibe. > Ab und an nutze ich AutoIT für kleinere Scripte. > > Nun bräuchte ich aber ab und an eine GUI am PC für meine Platinen. Habe es zwar noch nie benutzt, nur etwas herumgeschnuppert: PureBasic könnte was für Dich sein. http://www.purebasic.com
Mein Tipp: Lern C++. So schwierig ist es nun auch wieder nicht, vor allem weil du nicht alles können musst um damit produktiv zu arbeiten. Kauf dir ein gutes Buch zu dem Thema (z.B. "Der C++ Programmierer" sowie "Effektiv C++ programmieren") und dann wird das schon! Als Entwicklungsumgebung für reines C++ kann ich dir Codeblocks empfehlen. Dort ist bereits das GUI Toolkit wxWidgets dabei, mit dem man plattformunabhängige GUIs basteln kann. Wenn du mit Qt arbeitest, dann nimm eben Qt Creator. Von C# kann ich nur abraten: es ist im Prinzip nur für Windows verfügbar. Klar gibt es auch unter Linux die Mono VM, aber erwarte dir davon nicht zuviel. Diese ist Jahre hinter der Windows .NET VM hinterher, somit bist du damit nicht plattformunabhängig. Mal abgesehen davon sind hardwarespezifische Details immer betriebssystemabhängig. Nicht zuletzt ist Microsoft unter Linux Freaks nicht sehr beliebt, dementsprechend wenig Hilfe wirst du im Internet finden, ganz einfach weil damit eben nicht besonders viele Leute Erfahrung haben. Hingegen kannst du davon ausgehen, dass du mit C oder C++ garantiert Hilfe finden wirst im Internet.
dsdasdasd (Gast) schrieb: > Von C# kann ich nur abraten .. > .. Nicht zuletzt ist Microsoft unter Linux Freaks nicht sehr beliebt, Na das ist ja mal ein Grund der "Gewicht" hat. Nur weil der Mainstream-Foren-Mob das pöse C# nicht mag (weil von MS) soll man die Finger davon lassen? Was für ein ideologischer Hirnkrampf! > dementsprechend wenig Hilfe wirst du im Internet finden, Eine glatte Lüge. Es gibt genügend Foren, die sich mit C# beschäftigen, ganz ähnlich wie denen, die sich mit Delphi beschäftigen, was ja auch nicht sonderlich gepuscht wird auf Linux Plattformen.
dsdasdasd schrieb: > on C# kann ich nur abraten: es ist im Prinzip nur für Windows > verfügbar. > Klar gibt es auch unter Linux die Mono VM, aber erwarte dir davon nicht > zuviel. Diese ist Jahre hinter der Windows .NET VM hinterher Stimmt garnicht. Mono ist momentan auf dem Stand von .NET 4.5. Das nennst du "Jahre hinter"??? dsdasdasd schrieb: > es ist im Prinzip nur für Windows verfügbar. Kann es sein dass du überhaupt keinen Plan hast und hier nur rumstänkern willst?
Oh mann wenn hier jetzt C# und Delphi als Alternativen auftauchen... Plattforumübergreifend und dann zu C# greifen ist so richtig dämlich, davon abgesehen ist C# überflüssig wie ein Kropf. Müll für den ganzen Programmiersprachen-Müllberg.
baham schrieb: > Müll für den ganzen Programmiersprachen-Müllberg. Richtig, alles was man braucht ist Maschinencode, damit kann man schließlich alles machen. Mehr Programmiersprachen sind überflüssig.
baham (Gast) schrieb: > Oh mann wenn hier jetzt C# und Delphi als Alternativen auftauchen... > Plattforumübergreifend und dann zu C# greifen ist so richtig dämlich, Dämlich ist dein Einlass hier. Delphi ist 100% plattforumübergreifend. C# hat seine Stärken im enormen Ausbau des Frameworks wird künftig auch für Systemprogrammierung eine Rolle spielen. http://www.heise.de/newsticker/meldung/C-fuer-Systemprogrammierung-2073618.html
Könnt ihr MS-Fans nicht einfach mal ruhig sein? In JEDEM Thread in dem es um Programmierung geht, kommt einer daher und will mit irgendeiner .NET-"Programmiersprache" nerven. C# ist eine Windowssprache, man weiß nie wann MS vielleicht gegen Mono vor geht (Patente). Wenn MS .NET einstellt, dann wars das mit den Programmen die darauf aufbauen. Wird nie passieren? Ich sage nur Silverlight, DAS Plugin was Flash in Wochen vom Markt verdrängt... Oder für die Entwicklungsumgebung werden Gebühren verlangt, ach Halt das passiert ja jetzt auch schon. Wird eben die kostenlose Version eingestellt. :) Man sollte sich bei der Programmierung niemals auf einen einzigen Hersteller fixieren. Gerade in Zeiten von Android und Co. ist das wichtiger denn je.
Ein Gast schrieb: > Könnt ihr MS-Fans nicht einfach mal ruhig sein? Wieso MS-Fan? Ich hab mit dem Verein garnix am Hut (benutze ausschließlich Linux, OSX und Android). Ein Gast schrieb: > Man sollte sich bei der Programmierung niemals auf einen einzigen > Hersteller fixieren. Gerade in Zeiten von Android und Co. ist das > wichtiger denn je. C# läuft mit Xamarin ganz hervorragend auf Android :-)
:
Bearbeitet durch User
Tim schrieb: > Habe damals viel Basic und weniger Delphi programmiert. > Zuhause bin ich eher in C womit ich meine Mikrocontroller Projekte auch > schreibe. > Ab und an nutze ich AutoIT für kleinere Scripte. > Nun bräuchte ich aber ab und an eine GUI am PC für meine Platinen. > Möchte auf jeden Fall Crossplatform sein und habe mich daher von QT und > Lazarus hin und her reissen lassen. BASIC: RealBasic PureBASIC Beides Platformübergreifend, allerdings kommerziell. Oder halt Lazarus wenn du schon Delphi kannst. > Leider kenne ich mich aber in C++ nicht aus. Für ein bischen GUI-Geklöppel würde ich eine Scriptsprache verwenden, Bindings für die üblichen GUIs haben die alle an Bord. Tk reicht vermutlich schon, dazu Python oder Perl, mittlerweile sieht es auch nicht mehr so altbacken aus sondern wie native Widgets und ist wirklich sehr einfach zu scripten, einfacher als die nativen GUIs die angebunden sind. > Es sollen keine riesen Programme werden, sondern nur > Auswertungs-Software und Hardware-Konfiguations-Programme. Dafür reicht obiges dicke.
Ein Gast schrieb: > C# ist eine Windowssprache, C# ist bei ECMA und ISO als Standard registriert. Java ist übrigens auch keine Orakelsprache. > man weiß nie wann MS vielleicht gegen Mono > vor geht (Patente). Oh, mal wieder ein Verschwörungs-Fanboy. > Wenn MS .NET einstellt, dann wars das Und wenn du morgen an der Ampel überrollt wirst, brauchst du auch keine Programmiersprach mehr .. > Oder > für die Entwicklungsumgebung werden Gebühren verlangt, Kommerzielle Lizenzen sind Usus in der Softwarewelt (gestern wie heute). Auch Qt bietet kommerzielle Lizenzmodelle an oder beispielsweise Embarcadero. Viele Softwarefirmen leben davon. Borland hat früher sein Turbo C und und Turbo Pascal auch nicht verschenkt. > Man sollte sich bei der Programmierung niemals auf einen einzigen > Hersteller fixieren. Quark. Wenn mich Linux nur peripher tangiert interessiert mich das ewige Genöle der Linuxfanboys nicht, die immer Angst haben zu kurz zu kommen, aber bei jeder Gelegenheit damit prahlen, jede WindowsApp unter Wine starten zu können.
Neues aus der Anstalt schrieb: >> Von C# kann ich nur abraten .. > >> .. Nicht zuletzt ist Microsoft unter Linux Freaks nicht sehr beliebt, > > Na das ist ja mal ein Grund der "Gewicht" hat. Nur weil der > Mainstream-Foren-Mob das pöse C# nicht mag (weil von MS) soll man die > Finger davon lassen? > > Was für ein ideologischer Hirnkrampf! doch, das hat gewicht. wenn ich mit einem bash script, einem c oder c++ programm unter linux probleme habe, so bekomme ich garantiert hilfe. bei c# unter linux sieht das nun mal anders aus. ich habe c# bereits in der arbeit verwendet, für windows ist das echt eine tolle programmiersprache. aber auf embedded plattformen oder generell auf linux mache ich einen großen bogen herum. mal abgesehen davon wird c# nie die performance von c oder c++ erreichen. in zeiten, wo es für c++ wirklich tolle frameworks wie Qt gibt, sehe ich für c# nicht viel grund. gerade wo mobile plattformen immer häufiger eingesetzt werden, ist "going native" wieder gefragt, und da ist c# nun mal suboptimal. c# ist für mich die typische sprache, um irgendwelche business software zu erstellen. wer technisch anspruchsvolle software erstellen möchte und nur c# kennt tut sich wohl etwas schwer am arbeitsmarkt. also kurz zusammengefasst: c++ ist beim lernen etwas schwieriger, aber längerfristig hast du damit weit mehr möglichkeiten. ich kann jedem nur c++ ans herz legen, damit habt ihr ein schweizer taschenmesser in der hand! c# ist eher wie ein kreuzschraubenzieher, damit kann man gewisse aufgaben gut erledigen, aber bei anderen aufgaben hat man damit keine chance. oder schon mal ein OS, einen treiber, o.ä. in c# gesehen?
dsadasdad schrieb: > gerade wo mobile plattformen immer häufiger eingesetzt werden, ist > "going native" wieder gefragt, und da ist c# nun mal suboptimal. Wie kommst du darauf das C# nicht "nativ" wäre? Von der Performance her tun sich C++ und C# übrigens nicht besonders viel...
:
Bearbeitet durch User
Boris B. schrieb: > dsadasdad schrieb: >> gerade wo mobile plattformen immer häufiger eingesetzt werden, ist >> "going native" wieder gefragt, und da ist c# nun mal suboptimal. > > Wie kommst du darauf das C# nicht "nativ" wäre? > Von der Performance her tun sich C++ und C# übrigens nicht besonders > viel... ich würde sagen, das kommt drauf an. wenn du SW schreibst, die "IO bound" (z.B. GUI Anwendung) ist, dann ist C# schon ok. Aber sobald du "CPU bound" SW erstellst, hat C++ die Nase vorn. Und zwar teilweise deutlich. Ich hab mir einige C++ vs. C# Vergleiche im Internet angesehen. Dabei musste ich aber feststellen, das meist Leute geschrieben haben, die wenig Plan von C++ hatten. Wenn man Objekte per value und nicht per reference übergibt, und Konzepte wie RAII nicht kennt, bringt es nicht viel, einen Performancevergleich anzustellen. Und mit native meine ich, dass C# nicht in x86 Maschinencode übersetzt wird, sondern in einer VM läuft. C++ hingegen wird direkt ausgeführt. Alleine schon deshalb ist C++ Code schneller - wenn man denn weiß wie man damit umgeht.
45redfdf schrieb: > Und mit native meine ich, dass C# nicht in x86 Maschinencode übersetzt > wird, sondern in einer VM läuft. Das ist nicht richtig. Erst wird zwar IL-Code erzeugt, dann aber auf der Zielmaschine (durch die CLR) nativer Maschinencode.
Tant-Al schrieb: > Das ist nicht richtig. Erst wird zwar IL-Code erzeugt, dann aber auf der > Zielmaschine (durch die CLR) nativer Maschinencode. und in der Zeit ist mein C++ Programm mit der Berechnung schon durch...
sdadasda schrieb: > und in der Zeit ist mein C++ Programm mit der Berechnung schon durch... Sinnloses Statement. Ich bevorzuge aus verschiedenen Gründen auch C++ (u.a. wegen des mehr oder weniger deterministischen Verhaltens bei der Speicherfreigabe), aber der Geschwindigkeitsunterschied ist nur bei sehr rechen- und speicherintentiven Anwendungen spürbar.
sdadasda schrieb: > und in der Zeit ist mein C++ Programm mit der Berechnung schon durch... Dann ist die Berechnung ja nicht gerade Zeit intensiv und die C# Version ist 1ms (Umwandlung zu Maschinencode) danach auch fertig. Das geile an C# ist doch die enorme Produktivität, man kümmert sich um das eigentliche Problem und nicht so sehr um die technische Umsetzung. Außerdem reicht die Performance bis auf wenige rechenintensive Dinge völlig aus. C++ ist eine tolle Sprache, aber wer kann von sich behaupten in ihr ein Profi zu sein?
45redfdf schrieb: > Wenn man Objekte per value und nicht per reference übergibt Tja, und wenn man ganz schlau ist übergibt man Objekte dann doch per Value, um einen Performance-Gewinn ggü. CLR / JVM zu erhalten: Wenn man nämlich z.B. eine Klasse hat die nur einen Integer enthält, ist die Übergabe by Value genauso schnell, aber das Anlegen auf dem Heap und die Dereferenzierung entfällt. Gut dass man in C++ die Wahl hat... sdadasda schrieb: > und in der Zeit ist mein C++ Programm mit der Berechnung schon durch... Dafür kann die Just-in-Time-Compilation den Code exakt für die Ziel-CPU optimieren, im Gegensatz zu C/C++ was bei PC's typischerweise für i386 "optimiert" wird...
sdadasda schrieb: > und in der Zeit ist mein C++ Programm mit der Berechnung schon durch... Ihr habt immer Probleme mit eurer Performance. Man könnte denken, dass manche Leute bei ihrer GUI im Hintergrund jeden Pixel einzeln setzen oder 2D FFTs in Echtzeit berechnen wollen. Eine Möglichkeit für simple GUIs ist Processing ( http://processing.org/ ). Das basiert auf Java. Das wird beispielsweise in Verbindung mit dem Arduino eingesetzt (hmpf... jetzt breche ich damit wieder eine Grundsatzdiskussion vom Zaun). Zu C#: 1. mit M$ .net Framework bist du auf Windoofs festgelegt ABER: 2. es gibt Mono, das nahezu genauso benutzbar ist wie der M$-Kram (was fehlt sind sehr spzielle Sachen wie Linq, was du am Anfang eh nicht brauchst), somit ist auch C# systemunabhängig. Prinzipiell sind in Mono jedoch keine GUI-Sachen implementiert ABER: 3. http://www.mono-project.com/Gui_Toolkits da wird sich sicherlich etwas passendes finden. Sogar QT Bindings sind verfügbar. Ich mache seit einigen Jahren C/C++ und ein Jahr lang mal C# gemacht. Parallel zur Arbeit mache ich (kleine) Projekte weiterhin lieber in C# als in C++, da ein umfangreiches Framework das Programmieren sehr sehr vereinfacht. Außerdem lassen (zumindest mit .net unter Windoofs) sich die GUIs sehr schnell realisieren, ohne dass viele kryptische Dateien generiert werden und das Projekt aufblähen (das Aufblähen geschieht bei manchen GUI-Toolkits in Verbindung mit C++). Um hier mal einige Leute zum Nachdenken anzuregen (und um ein wenig rumzutrollen/rumzustänkern): so viele Leute schreien über mangelnde Performance, programmieren aber gleichzeitig schlecht durchdachten & mangelhaft dokumentierten Spaghetti-Code. Dieser Code wird von ganz allein langsam, da bestimmte Fallstricke irgendwann übersehen werden. Tim schrieb: > @Dr. Sommer & Team: Java finde ich wegen der Hardwarenahen Geschichten > nicht so passend. Hatte mir einmal NetBeans angeschaut und war nicht so > von überzeugt... Zum Thema hardwarenah: falls du damit beispielsweise die Kommunikation zu RS232 meinst: diese Kommunikation kann man auch unabhängig von der GUI bzw. einer GUI-Anwendung lösen. Beispielsweise könnte man die RS232-Kommunikation auf eine lokale TCP-Verbindung übersetzen und das GUI-Programm hängt sich an die TCP-Verbindung (was bei Java kein Problem sein sollte). Zum Thema Netbeans: fande das damals sehr aufgebläht und hat ohne Ende Festplattenplatz benötigt... Elipse ftw!
Dr. Sommer schrieb: >> Wenn man Objekte per value und nicht per reference übergibt > Tja, und wenn man ganz schlau ist übergibt man Objekte dann doch per > Value, um einen Performance-Gewinn ggü. CLR / JVM zu erhalten: Wenn man > nämlich z.B. eine Klasse hat die nur einen Integer enthält, ist die > Übergabe by Value genauso schnell, aber das Anlegen auf dem Heap und die > Dereferenzierung entfällt. Gut dass man in C++ die Wahl hat... Heap braucht man in dem Fall sowieso nicht. Ich leg die Variable am Stack an, und übergeb an die Funktion einfach die Referenz darauf. Man hat in C++ also folgende Vorteile: ->Übergabe per Referenz, also im Hintergrund per Adresse, ohne das man aber auf !=0 abfragen muss ->Kein Heap nötig ->vorhersehbarer Löschzeitpunkt des Objekts, ohne irgendeine GC Magic void bar(const string& str) { // tu irgendwas mit dem String } void foo() { string s("irgendein text..."); // Variable liegt am Stack bar(s); // Übergabe per Referenz } // und hier wird der string wieder automatisch zerstört (~string() aufgerufen) Natürlich bringt es bei einem Integer nicht viel, dort übergeb ich einfach per copy. Wir haben in der Firma mal eine bestehende Java SW in C++ neu geschrieben, und man merkte einen deutlichen Performance Boost. Gerade bei rechenintensiven Dingen kann man es einfach nicht leugnen, dass C++ spitze ist. Ich versteh nicht ganz, warum das die .NET Fraktion nicht akzeptieren kann, dass es eben Sprachen gibt, die eine flottere Programmausführung ermöglichen. Ich behaupte ja auch nicht, dass das .NET Framework schlecht ist, oder man mit C# nicht produktiv ist. Interessanterweise heulen aber alle rum, wenn man sagt, dass guter C++ Code schneller ist wie guter C# Code.
ein c++ nutzer schrieb: > Wir haben in der Firma mal eine bestehende Java SW in C++ neu > geschrieben, und man merkte einen deutlichen Performance Boost. Gerade > bei rechenintensiven Dingen kann man es einfach nicht leugnen, dass C++ > spitze ist. > > Ich versteh nicht ganz, warum das die .NET Fraktion nicht akzeptieren > kann, dass es eben Sprachen gibt, die eine flottere Programmausführung > ermöglichen. > Ich behaupte ja auch nicht, dass das .NET Framework schlecht ist, oder > man mit C# nicht produktiv ist. > Interessanterweise heulen aber alle rum, wenn man sagt, dass guter C++ > Code schneller ist wie guter C# Code. Ich verstehe nicht ganz, warum Äpfel mit Haselnüssen verglichen werden. C++ erzeugt überlicherweise native Code. Überführt man Java oder C# in native Code, ist die gleiche Perfomance zu erwarten. Eine schnellere Abarbeitung hat also nix mit der Sprache zu tun, sondern mit der Umsetzung durch den Compiler. Du musst als das Kit vergleichen. Rein sprachlich gesehen ist C++ ein Relikt im Vergleich zu Java oder C#.
ein c++ nutzer schrieb: > Dr. Sommer schrieb: > Heap braucht man in dem Fall sowieso nicht. Eben - aber in den CLR/JVM Sprachen eben schon. > Ich leg die Variable am Stack an, und übergeb an die Funktion einfach > die Referenz darauf. Ja oder halt direkt per Value. > Man hat in C++ also folgende Vorteile: > ->Übergabe per Referenz, also im Hintergrund per Adresse, ohne das man > aber auf !=0 abfragen muss > ->Kein Heap nötig > ->vorhersehbarer Löschzeitpunkt des Objekts, ohne irgendeine GC Magic Ganz genau... Bei deinem String-Beispiel könnte man vermutlich sogar effizient by-Value übergeben, falls die String-Implementation ein Copy-on-Write implementiert... > Natürlich bringt es bei einem Integer nicht viel, dort übergeb ich > einfach per copy. Ja und bei Klassen die nur ein Integer sind eben auch:
1 | class MyClass { |
2 | public:
|
3 | inline MyClass (int i) : m_index (i) {} |
4 | // 9000 Funktionen
|
5 | private:
|
6 | int m_index; |
7 | };
|
8 | void fun1 (MyClass obj) { |
9 | }
|
10 | void fun2 () { |
11 | MyClass obj (42); |
12 | fun1 (obj); |
13 | }
|
Hier kann ich eine schöne Klasse mit tollem API und allem drum und dran haben (=> Abstraktion), aber dennoch by-Value übergeben was dann so effizient ist wie direkt einen Integer zu übergeben. Das geht in CLR/JVM gerade eben nicht. > Wir haben in der Firma mal eine bestehende Java SW in C++ neu > geschrieben, und man merkte einen deutlichen Performance Boost. Gerade > bei rechenintensiven Dingen kann man es einfach nicht leugnen, dass C++ > spitze ist. Auch wenn der rechenintensive Teil nur ein Algorithmus ganz ohne Speicherverwaltung ist? Weil einfach nur rechnen lässt sich ja wunderbar JIT-compilen. > Interessanterweise heulen aber alle rum, wenn man sagt, dass guter C++ > Code schneller ist wie guter C# Code. Sie wollen halt kein C++ lernen :o) ... wobei, wenn man weiß wie man CLR/JVM Code gut schreibt, man den auch schon ziemlich schnell kriegen kann. nativ schrieb: > Eine schnellere > Abarbeitung hat also nix mit der Sprache zu tun, sondern mit der > Umsetzung durch den Compiler. Naja bei normaler Ausführung auf PC's wird ja JIT-compiled, und somit nativer Code ausgeführt. nativ schrieb: > Rein > sprachlich gesehen ist C++ ein Relikt im Vergleich zu Java oder C#. C++ hat zwar alte Wurzeln, wird aber immer noch weiterentwickelt (letzte Version von 2011) und kann sprachlich jedenfalls eine ganze Menge mehr Dinge als Java (C# weiß ich nicht) - von Relikt würde ich hier nicht reden! Und bei Java war man ja auch so schlau die dann doch etwas angestaubte Syntax zu übernehmen.
da kommt ja noch einiges dazu: Index Überprüfungen zur Laufzeit, Objekte werden am Heap angelegt, GC läuft im Hintergrund, usw... Alleine schon deshalb ist C# Code langsamer. Und dann kommt ja noch die Übersetzung zur Laufzeit dazu. Jedenfalls bei Java kann ichs sagen, da ist C++ weit voraus, und bei C# wirds wohl ähnlich sein. C++ gibts jetzt in der Version C++11, da hat man alles was man von modernen Sprachen erwartet. Und gewisse Dinge kann C++ bei weitem besser als Java und C#, nämlich die generische Programmierung. Templates hab ich sonst noch nirgends so mächtig umgesetzt gesehen wie in C++.
Dr. Sommer schrieb: > Hier kann ich eine schöne Klasse mit tollem API und allem drum und dran > haben (=> Abstraktion), aber dennoch by-Value übergeben was dann so > effizient ist wie direkt einen Integer zu übergeben. Das geht in CLR/JVM > gerade eben nicht. Bei C# geht sowas schon nur leider nicht mit Klassen, aber mit Strukturen. Diese werden auf dem Stack angelegt (also nix mit GC) und wird generell als value übergeben (außer man will es nicht dann als Referenz). Das größte Ärgernis von C++ ist, wie ich finde, das absolut veraltete Forward-Declaration Headersystem, einfach grauenhaft.
Dr. Sommer schrieb: > Sie wollen halt kein C++ lernen :o) ... wobei, wenn man weiß wie man > CLR/JVM Code gut schreibt, man den auch schon ziemlich schnell kriegen > kann. das stimmt wohl teilweise ;-) Ich hab letztens jemanden in der Firma eingeschult, der davor nur C# und Java gekannt hat. Als ich ihm gezeigt habe, wie Smart Pointer in C++ funktionieren, war er ganz erstaunt. Was, das geht? Wow... Wie geht denn das? C++ gilt ja als "anfällig" für Speicherlecks, doch wenn die Leute erstmal sehen, wie sauber man das mit Smart Pointer implementieren kann, sind sie immer erstaunt. Und das ohne den Overhead eines GC!
> Ich versteh nicht ganz, warum das die .NET Fraktion nicht akzeptieren > kann, dass es eben Sprachen gibt, die eine flottere Programmausführung > ermöglichen. Das Erfinden solcher "Tatsachen" zeugt nicht gerade von Diskussionsfähigkeit. > Interessanterweise heulen aber alle rum, wenn man sagt, dass guter C++ > Code schneller ist wie guter C# Code. Hast Du das geträumt? Niemand hier hat dem widersprochen; es wurde sogar explizit erwähnt, dass es bei rechenintensiven Programmen durchaus eine Rolle spielt. Abgesehen davon meinst Du wohl, dass das Endergebnis "schneller" ist; das hat nichts mit der Programmiersprache zu tun. Theoretisch könnte man aus C#-Code die gleiche Binary wie aus einem äquivalenten Stück C++-Code machen. Jedenfalls sind meine Erfahrungen ganz andere: Ein Teil (ja, es geht auch ohne fantasievolle Verallgemeinerung) der C++-Fraktion dreht mit Schaum vor dem Mund durch, wenn man sagt, dass die Differenz bei einem guten Teil aller Anwendungen völlig egal ist, man aber einiges schneller und produktiver in C# implementieren kann. Um mal einen alten Spruch zu strapazieren: Wenn man nur einen Hammer zur Verfügung hat, sieht jedes Problem aus wie ein Nagel. BTW: Ich mag und verwende beides.
ein c++ nutzer schrieb: > Als ich ihm gezeigt habe, wie Smart Pointer in C++ funktionieren, war er > ganz erstaunt. Was, das geht? Wow... Wie geht denn das? > C++ gilt ja als "anfällig" für Speicherlecks, doch wenn die Leute > erstmal sehen, wie sauber man das mit Smart Pointer implementieren kann, > sind sie immer erstaunt. Und das ohne den Overhead eines GC! RAII ist schon ziemlich geil und nach meiner Meinung besser als ein GC. Aber wie lange hat es nun gedauert bis man in C++ SmartPointer erfunden hat? Und wie lange wird es noch dauern bis diese endlich überall genutzt werden?
Warum zur Hölle wird C# bzw .Net überhaupt genannt, wenn es definitiv um plattformübergreifende Programmierung geht? Es geht mit z.B. QT + C++ oder Python problemlos plattformübergreifend, ohne zusätzliche Programme und Gefriemel. .Net auf Linux zu betreiben macht doch gar keinen Sinn, wenn man sich auch einfach eine andere Sprache wählen kann.
baham schrieb: > Warum zur Hölle wird C# bzw .Net überhaupt genannt, wenn es definitiv um > plattformübergreifende Programmierung geht? Weil C# plattformunabhängig (mit Mono) ist? Und weil C# eine tolle Sprache ist. baham schrieb: > Es geht mit z.B. QT + C++ oder Python problemlos plattformübergreifend, > ohne zusätzliche Programme und Gefriemel. Qt Programme können auch nicht ausgeführt werden, wenn auf dem System die Qt Bibliotheken fehlen. Python ebenso. Um Mono zu installieren genügt ein: sudo apt-get install mono. Und du kannst das Binary, was auf Windows kompiliert wurde auf Linux ausführen. Also nix Gefriemel. Nicht mal ausprobiert, aber seinen Senf dazu geben.
ptr schrieb: > Um Mono zu installieren genügt ein: sudo apt-get install mono. Und du > kannst das Binary, was auf Windows kompiliert wurde auf Linux ausführen. > Also nix Gefriemel. Nicht mal ausprobiert, aber seinen Senf dazu geben. So isses. Funktioniert wirklich tadellos. Ich z.B. entwickel ganz komfortabel auf einem WIndows-Rechner, und kopiere die .exe dann einfach auf meinen Raspberry Pi, wo das Programm dann läuft. Gaanz easy :-)
ptr schrieb: > Weil C# plattformunabhängig (mit Mono) ist? Und weil C# eine tolle > Sprache ist. Nein. Und Nein. C# ist das PHP der Systemsprachen. Ein paar wenige können damit wirklich Programme schreiben, aber der große Rest macht Programme wie (früher) die tausend "Mach deinen PC schneller".
Ein Gast schrieb: > C# ist das PHP der Systemsprachen. Ein paar wenige können damit wirklich > Programme schreiben, aber der große Rest macht Programme wie (früher) > die tausend "Mach deinen PC schneller". Entweder verwechselst du C# mit irgendeiner anderen Sprache oder du bist einfach ein echt schlechter Troll.
Auch du ptr, wirst die Wahrheit irgendwann erkennen. Bis dahin, sei glücklich in deiner C#-Welt.
>Qt Programme können auch nicht ausgeführt werden, wenn auf dem System >die Qt Bibliotheken fehlen. Python ebenso. >Um Mono zu installieren genügt ein: sudo apt-get install mono. Und du >kannst das Binary, was auf Windows kompiliert wurde auf Linux ausführen. >Also nix Gefriemel. Nicht mal ausprobiert, aber seinen Senf dazu geben. Dann nimm halt wxWidgets, dann brauchst du nicht mal mehr die QT-Biblibothek. Ich kann nicht nachvollziehen, dass man bei gezielt plattformunabhängigen Programmen den Weg über C# geht. Aber bitte, jedem Tierchen sein Plaisierchen. Bescheuert ist es weiterhin.
kann wxWidgets auch sehr empfehlen! eine wirklich sauber durchdachte und einfach verwendende gui. wer glaubt er muss c# auf linux verwenden, soll es tun, ist halt wie wenn man nach deutschland zieht und nur englisch sprechen kann. ja es geht, aber viel kann man sich davon nicht erwarten.
wxWidgets schrieb: > aber viel kann man sich davon nicht erwarten. Wieso nicht? Habe bis jetzt keinerlei Einschränkungen finden können. wxWidgets schrieb: > ist halt wie > wenn man nach deutschland zieht und nur englisch sprechen kann Jetzt unstellst du, dass ich nur eine Programmiersprache "spreche"? Keine Angst, es sind deutlich mehr (incl. C und C++). Aber warum sollte ich zu C/C++ greifen wenn C# so viel besser funktioniert und die gleichen Ergebnisse liefert?
:
Bearbeitet durch User
ein c++ nutzer schrieb: > C++ gibts jetzt in der Version C++11, da hat man alles was man von > modernen Sprachen erwartet. Ein Hindley-Milner-artiges Typsystem? eg
Ich möchte hier auch nochmal Lazarus in die Waagschale werfen. Wer Delphi kennt, muß sich nicht umstellen, plattformübergreifend ist es auch, die Programmentwicklung so effizient wie in C#, GUI kein Problem, die FTDI-Bibliotheken kann man auch einbinden, oder SynaSer für Com-Port-Zugriff benutzen, und der wichtigste Unterschied ist, daß monolithische .exe-Dateien entstehen, die kein in Hintergrund installiertes Framework benötigen, statisch gelinkt läuft überall. Für mich persönlich der entscheidende Grund, Lazarus gegenüber C# den Vorzug zu geben.
>Bleibt für mich auch nur QT und Lazarus >“(Das ist natürlich eine völlig sachliche und professionelle Tatsache >und keine persönliche Meinung ;-)“ Kein Java zu nutzen ist ja schonmal die richtige Entscheidung ;) Aber warum eigentlich kein Python? Imho auch die am einfachsten zu lesende Sprache von allen genannten und problemlos (Ohne Gefrickel und irgendwelche "Wir versuchen Microsoft Produkte auch unter Linux laufen zu lassen"-Pakete) plattformübergreifend. + Undendlicher Vorrat an gut funktionierenden Modulen für zig Anwendungen.
xarm schrieb: > Aber warum eigentlich kein Python? Das einzige was gegen Python spricht, ist die Performance, da ja interpretiert wird. Wenn das nicht stört, ist Python eine super Sache. (Mal ehrlich, in wie viel prozent aller Fälle kommt es wirklich auf die Performance an?) Was mich persönlich an Python nervt ist höchstens die Einrückungs-Syntax ;-)
Die Einrückungssyntax ist Gewöhnungssache, ich finde nach einiger Zeit
erhöht das die Lesbarkeit enorm. (Besser als {} ist sowieso fast alles
;) )
Klickibunti kann man z.B. mit QT-Creator haben. Da kann man sich eine
Klickbunti Gui zusammenklicken und die kann man dann wirklich
komfortabel mit Python nutzen.
Pyside und PyQT funktionieren beide gut und sind auch fast
Syntax-identisch.
http://qt-project.org/wiki/PySide
http://qt-project.org/wiki/QtCreator_and_PySide
http://zetcode.com/gui/pyqt4/german/ <-- ist ohne klickibunti Gui Aufbau
aber zeigt schnell die elementare Benutzung.
Für Performancekritische Sachen ist Python natürlich nicht die richtige
Wahl, aber C++/C Module lassen sich sehr einfach einbinden und nutzen.
(Swig & Ctypes) Große Berechnungen o.ä. kann man dann auch mit C++
erledigen.
Und z.B. die serielle Schnittstelle ansprechen geht in zwei eindeutigen
Zeilen, einfacher geht es glaub ich nicht.
Möglicherweise spricht gegen Python die dynamische Typisierung, nicht jedermanns Sache. Mir gefällt sie jedenfalls nicht. xarm schrieb: > Imho auch die am einfachsten zu lesende Sprache von allen genannten und > problemlos (Ohne Gefrickel und irgendwelche "Wir versuchen Microsoft > Produkte auch unter Linux laufen zu lassen"-Pakete) > plattformübergreifend. Ich mach fast kein C# mehr, sondern eigentlich nur noch C/C++. Ich bin kein Fanboy, aber C# ist und bleibt eine Alternative. Es funktioniert und macht keine Probleme, da einheitliches und umfangreiches Framework. Die Sprache hat ein tolles Design und vereint Erfahrungen aus C, C++, Java etc., aber es gibt natürlich auch Dinge die Umstritten sind bzw. nicht jedem gefallen, wie z.B. der GC. Diese fanatische Abneigung in der Linuxwelt gegen C# ist doch zum Teil ein Resultat der radikalen Einstellung gegen Microsoft und allen nicht-OpenSource/FreeSoftware Unternehmen. Außerdem da gibt es noch eine Menge Leute die sich strikt weigern etwas anderes als C und GTK+ zu machen. Versteht mich nicht falsch ich will hier Niemanden C# aufquatschen. Aber hier wird der Programmiersprache C# einfach unrecht getan.
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.