Ich suche eine Programmiersprache plus Programmierumgebung, mit der ich plattformübergreifend programmieren kann, und zwar: - für Windows und unter Windows - für Android unter Windows - für Raspberry Pi unter Windows und auf dem Pi - tendenziell unter Linux für Linux, Android und Pi Es soll eine Compilersprache sein für kleine Programme zur Meßwerterfassung über RS232 (USB, Bluetooth), Speicherung und grafischen Darstellung und so Kram. Z.B. ein serielles Terminal. Es soll definitiv keine Interpretersprache wie Java oder Python sein. Bisher habe ich Qt und den Qt-Creator gefunden, aber der braucht wohl einige zusätzliche Pakete wie das VisualStudio mit VisualC++, welches dann wieder auf MS zurücklenkt. Außerdem wxWidgets, oder MingW, die wohl mit Qt und auch mit Codeblocks gehen. Da weiß ich aber nicht, ob die auch für Android nutzbar sind. Das läuft dann alles auf C++ hinaus. Alternativ wäre noch Lazarus mit FreePascal, welches anscheinend alle gewünschten Plattformen unterstützt. Hat damit jemand Erfahrung? Und es wäre schön, wenn die IDE schlank und nicht so überfrachtet wäre.
Was hälst du denn von Qt mit dem QtCreator - der eigenen IDE? Finde sie sehr übersichtlich und bedient sich gut. Kann aber alles nötige und ist für M$, Apfel und unix verfügbar.
Timm T. schrieb: > Bisher habe ich Qt und den Qt-Creator gefunden, Das ist keine Sprache, sondern eine Klassenbibliothek (und darauf angepasste Entwicklungsumgebung) für eine Sprache. Nämlich für C++. > Außerdem wxWidgets, oder MingW Das eine ist eine Klassenbibliothek, das andere eine Entwicklungsumgebung. wxWidgets "geht" nicht mit Qt, sondern ist eine Alternative dazu.
Timm T. schrieb: > Ich suche eine Programmiersprache plus Programmierumgebung, mit der ich > plattformübergreifend programmieren kann, > - für Windows und unter Windows C#, C, C++, Java, Delphi, (Visual) BASIC (.NET), usw. > - für Android unter Windows Java > - für Raspberry Pi unter Windows und auf dem Pi C, C++, ein Haufen Scripting Sprachen, Java > - tendenziell unter Linux für Linux, Android und Pi Läuft auf dem Pi nicht Linux? Also was soll das? C, C++, Java > Es soll definitiv keine Interpretersprache wie Java oder Python sein. Pech gehabt. Z.B. auch wenn es C für Android gibt, Java ist die Sprache der Wahl auf Android. > Bisher habe ich Qt Eine GUI-Bibliothek. Was soll das mit einer Programmiersprache zu tun haben? Du wirst wohl aus deiner Komfort-Ecke rauskommen müssen. Das ist so wie im richtigen Leben: Wie nennt man jemanden, der drei Sprachen spricht? Trilingual. Wie nennt man jemanden, der zwei Sprachen spricht? Bilingual. Wie nennt man jemanden, der eine Sprache spricht? Einen Amerikaner. Als Amerikaner der Programmiersprachen wirst du nicht weit kommen. Nicht über dein virtuelles Texas hinaus.
Timm T. schrieb: > Es soll definitiv keine Interpretersprache wie Java oder Python sein. Java ist keine Interpretersprache. Java ist hier definitiv das Mittel der Wahl. Aber dennoch wirst du wahrscheinlich kein Programm schreiben können, das unter Android und auf PC läuft, dazu sind die Plattformen zu verschieden.
Hannes J. schrieb: > Eine GUI-Bibliothek. Was soll das mit einer Programmiersprache zu tun > haben? QT ist nicht einfach nur eine GUI-Bibliothek. Es enthaelt eine komplette Abstraktionslayer, so dass eine Entwicklung fuer alle Plattformen moeglich ist. Im Prinzip ist QT genau dass, was der TE sucht. Die Wahl der Programmiersprache ist fuer Multi-Plattform Entwicklung unerheblich. Die richtige Wahl der Schnittstellen ist wichtig. Die bietet QT in grosser Vielzahl, vor allem in Verbindung mit QML. Verfuegbare Plattformen: https://de.wikipedia.org/wiki/Qt_%28Bibliothek%29#Unterst.C3.BCtzte_Plattformen
:
Bearbeitet durch User
Timm T. schrieb: > Es soll definitiv keine Interpretersprache wie Java oder Python sein. Dann schau dir Cython an: flexibilität von Python, mit C-Elementen. Oder anders gesagt: Python-Like-Code mit C ähnlicher geschwindigkeit da statisch compiliert.
1 | About Cython |
2 | |
3 | Cython is an optimising static compiler for both the Python programming |
4 | language and the extended Cython programming language (based on Pyrex). |
5 | It makes writing C extensions for Python as easy as Python itself. |
6 | |
7 | Cython gives you the combined power of Python and C to let you |
8 | write Python code that calls back and forth from and to C or |
9 | C++ code natively at any point. |
10 | |
11 | easily tune readable Python code into plain C performance by |
12 | adding static type declarations. |
13 | |
14 | use combined source code level debugging to find bugs in your |
15 | Python, Cython and C code. |
16 | |
17 | interact efficiently with large data sets, e.g. using multi- |
18 | dimensional NumPy arrays. |
19 | |
20 | quickly build your applications within the large, mature and |
21 | widely used CPython ecosystem. |
22 | |
23 | integrate natively with existing code and data from legacy, |
24 | low-level or high-performance libraries and applications. |
Cython Projekt: http://cython.org/ Buch zu Cython: http://www.amazon.de/Cython-Kurt-W-Smith/dp/1491901551/ref=sr_1_1?ie=UTF8&qid=1458377885&sr=8-1&keywords=Cython Timm T. schrieb: > Es soll definitiv keine Interpretersprache wie Java oder Python sein. Warum nicht? Angst das Python 'zu langsam' ist? Das bezweifel ich ganz stark. Ja, natürlich ist pure Python langsamer als z.B. gut geschriebener C-Code. Aber das interessiert gar nicht wenn du eh auf Daten einer Schnittstelle (RS232, Netzwerk, what ever) warten musst. Wenn man natürlich die Resourcen nicht nutzt, und alles Old-School in einer riesiegen main-Loop abfeiert, und die anderen drölf Kerne seiner CPU ungenutzt lässt, ja, dann kann das Tatsächlich zu einem Problem werden... Aber in Zeiten, wo es gar kein Problem ist multi-threading/multi-processing Anwendungne zu schreiben, ist die Sprache das kleinste Problem. Schlechten Code kann man in jeder Sprache schreiben, auch in C oder Assembler... Bei einer Script-Sprache sehe ich sogar den Vorteil das man das ganze eben nicht bei jeder änderung für X Platformen neu compilieren muss (Windows (x86), Linux(x86), Linux(ARM), Android,...). Einfach rüberkopieren und gut. Und ja, das sehe ich als einen entscheidenen Vorteil. Denn spätestens, wenn dein Compiler auf einer Platform nicht alle Compiler-Flags unterstützt wie auf einer anderen Platform, dann ist das ganze schon scheiße. (Ja, dieses Problem hatte ich mit CLang auf dem RPi. Da unterstütze der Compiler das sanitize-flag nicht.) Und mit Python hast du auch Qt. Und Qt ist ein wirklich sehr gutes Framework. Ganz viele Möglichkeiten hast du nicht zur Auswahl: - Java - C/C++ mit Qt - Python mit Qt - Eine Mischung aus C/C++ mit Python/Cython und Qt Wenn du Java und Python aber vornherin ausschleißt, ist die Sache klar. Dann nimm Qt und den Qt-Creator als IDE, C/C++ als Sprache und dann hau in die Tasten.
Rufus Τ. F. schrieb: > Das ist keine Sprache, sondern eine Klassenbibliothek (und darauf > angepasste Entwicklungsumgebung) für eine Sprache. Nämlich für C++. Deswegen steht da drunter: Timm T. schrieb: > Das läuft dann alles auf C++ hinaus. Hannes J. schrieb: > Läuft auf dem Pi nicht Linux? Also was soll das? C, C++, Java Jaja, und auf dem Pi läuft auch Win10. Trotzdem können nicht alle Umgebungen für Linux (auf x86) auch auf dem Pi (ARM) genutzt werden.
Kaj schrieb: > Warum nicht? Angst das Python 'zu langsam' ist? > Das bezweifel ich ganz stark. Nun, zumindest gibt es Leute, denen Fhem welches in Pyhton geschrieben ist, zu langsam ist. Und dabei ist Fhem "nur" eine Oberfläche, um ein paar Meßwerte darzustellen, welche auf einem 1GHz Prozessor läuft. Nicht daß ich jetzt Fhem nachbasteln möchte...
Timm T. schrieb: > Nun, zumindest gibt es Leute, denen Fhem welches in Pyhton geschrieben > ist, zu langsam ist. Das muss aber nicht zwingend an der Sprache liegen. Man kann in jeder Sprache schlechten, schnarlangsamen Code schreiben. Ebenso kann man aber mit Python ebenfalls Code schreiben der mehr als schnell genug ist. Und Fhem selber ist nicht in Python geschrieben. Fhem ist in Perl geschrieben: http://fhem.de/fhem_DE.html
1 | FHEM (eingetragene Marke) ist ein in perl geschriebener, |
2 | GPL lizensierter Server für die Heimautomatisierung. |
Es mag aber durchaus ein Frontend dazu geben, welches in Python geschrieben ist. Das sind aber 2 paar Schuhe. Und gerade bei der Auswertung/Aufbereitung/Darstellung/Sortierung von Daten kann man viel falsch machen, so das Code wirklich langsam wird, so wie in jeder Sprache. Gutes Beispiel dazu: Beitrag "Re: Python 3: neue Werte in einer Liste finden" Man muss es nur "richtig" machen. Timm T. schrieb: > Nun, zumindest gibt es Leute, denen Fhem [...] zu langsam ist. Ja, mir ist ein frisch installiertes Windows auf einer nagelneuen SSD mit 8 Kern Prozessor auch zu langsam... Mein 50Mbit internet ist mir auch zu langsam... Gibt auch Leute denen ist Tempo 220 auf der Autobahn zu langsam... Das empfinden von Geschwindigkeit ist subjektiv, eben so von Lautstärke. In einem Auto empfindest du 25km/h als schnarchlangsam. Fahr aber mal 25km/h auf einem alten Traktor, ohne Kabine und ohne Windschutzscheibe, da wird dir das ganz schön schnell vorkommen. Das selbe hast du bei Software. Wenn man natürlich nur einen Desktop gewöhnt ist, der 4 bis 8 Kerne und 3 bis 4 GHz hat, dann kommt einem der RPi natürlich ultra langsam vor. Nimm einen RPi (egal ob welcher) und versuch mal damit im Internet zu surfen... Das finde ich ebenfalls mega langsam. Aber am Browser kanns ja nicht liegen, der ist ja in C++ geschrieben... So, liegt es jetzt an der Verwendeten Sprache, in der der Browser geschrieben ist? Oder liegt es daran, das der Browser einfach schlecht programmiert ist? Oder liegt es vielleicht doch an der Hardware? (Ja, ein Browser ist hier ein schlechtes Beispiel, weil ein Browser natürlich noch viel viel mehr macht!) Spontan zu sagen: "Da sind Leute, die sagen das Anwendung X zu langsam ist, weil es in Sprache Y geschrieben ist", und deswegen eine Sprache auszuschließen, ohne es mal selbst probiert zu haben, ist, meiner Meinung nach, einfach dumm. Denn dann drüfte es keine Anwendungen geben die in C++ geschrieben sind, weil C++ ja soooooo einen Overhead im vergleich zu C hat. Ebenso dürfte es keine Programme geben die in C geschrieben sind, weil C ja sooooooo einen Overhead im gegensatz zu Assembler hat... Gibt immerhin Leute die das behaupten, auch noch im Jahre 2016, auch wenn das alles schon tausendfach widerlegt wurde. Man muss eine Sprache nur richtig anwenden.
Kaj schrieb: > Das muss aber nicht zwingend an der Sprache liegen. Man kann in jeder > Sprache schlechten, schnarlangsamen Code schreiben. Sicher. > Ebenso kann man aber > mit Python ebenfalls Code schreiben der mehr als schnell genug ist. Was ist schon schnell genug? Python als Bytecode, der auf einer VM ausgeführt wird, ist etwa 10 bis 50 mal langsamer als compilierter Maschienencode. (Gleichfalls für Ruby.) Cython oder PyPy mögern die Sache womöglichg etwas verbessern. Oder man versucht die kritischen Teile in C zu schreiben. Das wahre ist das aber alles nicht. Python mag für viele Sachen OK sein, wahrscheinlich auch für den Herrn Thaler. Erst recht, wenn im Wesentlichen nur Bibliotheksroutinen aufgerufen werden, die ja meist in C geschrieben sind. Aber von Seiten der Sprachen gibt es jetzt ja genügend (bessere) Alternativen -- bei cross plattform GUI, Tools, Bibliotheken und Support leider nicht.
Stefan Salewski schrieb: > Python als Bytecode, der auf einer VM > ausgeführt wird, ist etwa 10 bis 50 mal langsamer als compilierter > Maschienencode 1. wird es von einem Interpreter ausgefürt, nicht einer VM, und 2. kann man so pauschal nicht sagen. Ein guter Interpreter kann genauso schnell oder sogar schneller als nativer code sein. Das hat mich mal bei einem meiner Benchmarks von asmjs vs js erstaunt, damals erhöte ich eine Variable in einer Schleife bis sie wieder bei 0 ankahm. Getestet habe ich das Erhöhen in asmjs direkt (1s), in einer modulfunktion (5s) und in einer modulfunktion eines anderen Moduls (6min). Der js code hat die Variable in einer anderen Funktion hochgezählt, brauchte aber nur 1s. Die uhrsache wird wohl gewesen sein das der JS Interpreter zur runtime den Funktionsaufruf wegoptimieren konnte, der compilierte asmjs code aber nicht.
Daniel A. schrieb: > uhrsache Haha, dieser Verschreiber hätte in keinem besseren Kontext stehen können :D
Daniel A. schrieb: > 1. wird es von einem Interpreter ausgefürt, nicht einer VM, und 2. kann > man so pauschal nicht sagen. Ein guter Interpreter kann genauso schnell > oder sogar schneller als nativer code sein. Na Du weisst es sicher besser als Wikipedia und andere Quellen im Netz: https://en.wikipedia.org/wiki/Python_(programming_language) "The main Python implementation, named CPython, is written in C meeting the C89 standard.[78] It compiles Python programs into intermediate bytecode,[79] which is executed by the virtual machine." Und ich kann es so pauschal sagen -- meine Aussage war auf Python (oder Ruby) bezogen. Insbesondere auf das übliche CPython von Guido. Dazu habe ich noch keinen Benchmark gesehen, wo der Python Code nicht wenigstens 10 mal langsamer als entsprechender Code in C oder einer ähnlich gut in Maschienencode compilierten Sprache wäre. Dümmliche Benchmarks, wo lediglich eine C-Bibliothek von Python aus aufgerufen wird zählen natürlich nicht.) Dass Java Code in einigen Benchmarks schneller ist als vergleichbarer C Code ist mir bekannt -- was mich auch tatsächlich etwas verwundert. Aber in Java ist in den letzten 20 Jahren eben auch extrem viel Manpower investiert worden.
Daniel A. schrieb: > 1. wird es von einem Interpreter ausgefürt, nicht einer VM, und 2. kann > man so pauschal nicht sagen. Ein guter Interpreter kann genauso schnell > oder sogar schneller als nativer code sein. Ein echter Interpreter wird das nur dann sein, wenn der native Code schlechtere Algorithmen verwendet, oder wenn die Einzelbefehle des interpretierten Codes komplexe optimierte Operationen sind und der Interpretationsaufwand darin verschwindet. Möglicherweise beziehst du dich auch auf just-in-time Compiler mit ausgeprägter Hotspot-Optimierung, wie sie bei Java existieren. Aber das sind Compiler, keine Interpreter, nur eben teilweise zur Laufzeit.
:
Bearbeitet durch User
@ Stefan Salewski (Gast) Ups, ich hatte den Context des Satzteils > Python als Bytecode, der auf einer VM ausgeführt wird Falsch Interpretiert. Ich dachte es würde aussagen, dass Python immer als Bytecode auf einer VM ausgeführt wird, was nicht der Fall ist, da ein Programm das ein Script analysiert & ausführt per Definition ein Interpreter ist. https://de.wikipedia.org/wiki/Interpreter: > Ein Interpreter (im Sinne der Softwaretechnik) ist ein Computerprogramm, > das einen Programm-Quellcode im Gegensatz zu Assemblern > oder Compilern nicht in eine auf dem System direkt ausführbare > Datei übersetzt, sondern den Quellcode einliest, analysiert und ausführt. Ich hätte bemerken müssen, das "Python als Bytecode, der auf einer VM ausgeführt wird", eine spezifische Implementationsmöglichkeit eines Python Interpreters ist, auf welche hier Bezug genommen wurde. Mein Fehler.
Uninteressant! Python hatte ich schon ausgeschlossen. Ich möchte nach dem Kompilieren eine ausführbare Datei erhalten, die auf dem System läuft. Ohne das noch irgendwelche Interpreter oder VMs dazwischenhängen, egal ob die Textzeilen oder Bytecode ausführen. Was ist mit Lazarus bzw. Freepascal? Scheint auf allen vier Plattformen zu gehen. Die Syntax von Pascal sagt mir jedenfalls mehr zu als die von C(++).
Timm T. schrieb: > - für Windows und unter Windows > - für Android unter Windows > - für Raspberry Pi unter Windows und auf dem Pi > - tendenziell unter Linux für Linux, Android und Pi > > Es soll eine Compilersprache sein für kleine Programme zur > Meßwerterfassung über RS232 (USB, Bluetooth), Speicherung und grafischen > Darstellung und so Kram. Z.B. ein serielles Terminal. Ich habe seinerzeit EcmSpy - im Prinzip auch nichts anderes als die Anzeige seriell erfasster Daten - unter Linux mit C# und Gtk# und Mono entwickelt, das lief unter Windows sowohl mit einer Mono Runtime als auch .Net, wenn Gtk# nachinstalliert wurde. Als IDE konnte MonoDevelop (jetzt Xamarin irgendwas) oder unter Windows zusätzlich Visual Studio benutzt werden. Android fällt dann natürlich als Plattform aus, aber um Linux und Windows zu versorgen fand ich es damals den einfachsten Weg, um den Preis, dass es auf beiden Plattformen nicht voll nativ ist.
Timm T. schrieb: > Was ist mit Lazarus bzw. Freepascal? Scheint auf allen vier Plattformen > zu gehen. Sehr empfehlenswert, wird meistens ignoriert, weil "unsexy". Wenn du zu den Leuten gehörst, die bereits genug gesehen haben, um zu wissen, daß "unsexy" eine Stärke ist, dann greif zu!
Timm T. schrieb: > Ich suche eine Programmiersprache plus Programmierumgebung, .. > Es soll eine Compilersprache sein für kleine Programme zur > Meßwerterfassung über RS232 (USB, Bluetooth), Speicherung und grafischen > Darstellung und so Kram. Z.B. ein serielles Terminal. > Es soll definitiv keine Interpretersprache wie Java oder Python sein. Damit schiesst Du dir bezüglich: > plattformübergreifend programmieren kann selbst ins Bein. Eine Programmiersprache allein taugt nicht mehr als Assemblercode. Den Komfort/Nutzen macht die runtime-Umgebung und die Programmbibliotheken resp der Zugang zur API des OS. Das alles bringt eine VM resp. scriptsprache mit. Eine gute scriptsprache/VM liefert auch eine vernünftige Debug-schnittstelle (Single step/variable dump/watchpoint) mit so dass als Programmierumgebung ein Editor mit syntax highlight komplett aussreicht. MfG,
Da kommt eigentlich nur C# in Frage. Damit kannst du - für Windows entwickeln (Visual Studio, .NET oder .NET Core). - für Linux/Pi entwickeln (Mono Develop oder Xamarin Studio, Mono oder .NET Core). - für Android entwickeln (Visual Studio oder Xmarain). - für Mac entwickeln (Mono Develop oder Xamarin Studio, Mono oder .NET Core). - ... Unter Windows, Mac und Linux musst du den Code oft nicht mal neu kompilieren, da eine solche .exe direkt unter allen Systemen lauffähig ist. IDEs (alle kostenlos): - Visual Studio Community - Visual Studio Code - MonoDevelop - Xamarin Studio Frameworks: - .NET (Windows) - .NET Core (Alle Platformen) - Mono (Mac, Linux, ...) - Xamarin (Mobile Platformen: Android, iOS usw.)
:
Bearbeitet durch User
Boris P. schrieb: > Da kommt eigentlich nur C# in Frage. HAHAHA. Das kommt natürlich nicht in Frage. MS behauptet da zwar manchmal was, aber wie üblich geht da nichts richtig. Schau dir mal die großen OSS-Projekte an, wie die das machen. Firefox, Thunderbird, LibreOffice, usw. laufen auf allen Plattformen ohne Probleme und haben überall den gleichen Code. Ein paar kleine Eigenheiten müssen über Dateien für die jeweilige Plattform geregelt werden. PS: Timm T. schrieb: > - für Raspberry Pi unter Windows und auf dem Pi Windows hat auf einem RPi nichts zu suchen...
Go wäre u.U. noch eine Option z.B. mit Qt-Bindings 1) 2) oder Sciter 3) Android/iOS: https://github.com/golang/go/wiki/Mobile Allerdings ist das z.Z. nicht so integriert und aufeinander abgestimmt wie bspw. bei C++ und Qt-Creator 1) https://github.com/visualfc/goqt 2) https://github.com/go-qml/qml 3) http://sciter.com/ (ist ein HTML-GUI-Framework, deutlich schlanker als ChromiumEmbedded oder Electron) bzw. https://github.com/oskca/sciter für die Go-Bindings
Nimm Purebasic. https://de.wikipedia.org/wiki/PureBasic http://www.purebasic.com/german/index.php Ich habe es nur unter Windows benutzt, weiß aber von Anderen, daß die erzeugten Programme auch für Linux übersetzt werden können. Für Windows kommt eine .exe raus, die nichts weiter benötigt (kein .net und andere Rattenschwänze) Es gibt eine kostenlose Probierversion davon. mfG Paul
Horst schrieb: > HAHAHA. Das kommt natürlich nicht in Frage. MS behauptet da zwar > manchmal was, aber wie üblich geht da nichts richtig. Ach Horst... Ich habe hier einige Tools, die ich sowohl auf Windows als auch auf dem Mac laufen lasse. Auch diverse Server habe ich unter Windows/Mac erstellt, und lasse sie momentan auf einem Raspberry Pi laufen. Und meine erste Android App in Xamarin habe ich auch die Tage geschrieben. Mein Fazit: Das funktioniert alles ganz wunderbar. Also, wenn man keine Ahnung hat einfach mal den Mund halten... (oder hast du gegenteilige Erfahrungen gemacht? Wie genau sehen die aus?)
Einmal gesucht und schon gibt's C++ für Android: https://developer.android.com/tools/sdk/ndk/index.html http://stackoverflow.com/questions/4764557/android-c-development-with-visual-studio https://sites.google.com/site/lapndaandroid/home/using-eclipse-for-android-c-c-development https://www.visualstudio.com/en-us/features/cplusplus-mdd-vs.aspx Und nun stellt Euch mal vor was bei der Suche nach QT gefunden wird: http://doc.qt.io/qt-5/androidgs.html Da JAVA der Standard für Smartphones ist kommt man da zwar herum nur muß man sicher einiges verbiegen wenn man QT mit C++ nehmen will, geht aber. http://www.developer.com/ws/android/development-tools/android-vs.-qt-a-mobile-developers-comparative-review.html http://wiki.qt.io/How_to_Create_and_Run_Qt_Application_for_Android Es spricht also nichts dagegen C++ mit QT für Android zu nehmen. Da es keinen echten Windowmanager bei Android gibt kann es natürlich passieren das Dinge die in Windows und X11 funktionieren bei Android nicht das tun was erwünscht ist, aber dafür kann man ja eine Klasse schreiben die erbt und entsprechend die Funktionen implementiert.
Marc schrieb: > Sehr empfehlenswert, wird meistens ignoriert, weil "unsexy". Hab mal ein bißchem damit rumprobiert und finde es schonmal angenehmer als C. Hast Du Erfahrungen, wie gut das für Raspberry Pi und Android funktioniert? Horst schrieb: >> - für Raspberry Pi unter Windows und auf dem Pi > Windows hat auf einem RPi nichts zu suchen... Ich meinte damit auch "unter Windows das Programm für den Pi schreiben und auf dem Pi verfeinern und kompilieren". Paul B. schrieb: > Nimm Purebasic. Ich arbeite seit einigen Jahren mit PB, es ist wunderbar um schnell zu einem Ergebnis zu kommen. Mein größtest Projekt - gerade mal geschaut - waren 12000 Zeilen PB-Code*. Leider kann PB zwar für Linux auf PC-Architektur, aber nicht für Linux auf ARM kompilieren. Damit fällt es für den Raspberry Pi leider aus, und leider wird das nach Freds Aussage auch noch eine Weile so bleiben. Ich bedauere das sehr, sonst wäre das meine erste Wahl gewesen. *) Und nein, es gibt in den 12000 Zeile keine einzige Goto-Anweisung.
cppler schrieb: > Und nun stellt Euch mal vor was bei der Suche nach QT gefunden wird: Gefunden habe ich auch viel. Ich würde nur gern ein bißchen Feedback haben, was davon brauchbar ist. Ich würde mich ja auch durchaus auf die C/C++ Schiene einlassen, wenn es sinnvoll ist. Obwohl meine Ausflüge in C auf dem AVR meine Vorurteile bezüglich dieser Sprache eher bestätigt haben. Ich würde nur ungern viel Zeit in eine Richtung investieren, um dann in ein paar Monaten festzustellen, daß ich nicht weiterkomme: Hätteste mal lieber das Andere genommen. Besonders geht es mir hier um Schnittstellen zu Datenerfassung, z.B. eine RS232 über Bluetooth oder USB-Seriell-Wandler am Tablet. Das ist immer noch was anders als ein Hello World zum Laufen zu bringen, das hab ich auch schon mit Scratch geschafft.
Timm T. schrieb: > cppler schrieb: >> Und nun stellt Euch mal vor was bei der Suche nach QT gefunden wird: > > Gefunden habe ich auch viel. Ich würde nur gern ein bißchen Feedback > haben, was davon brauchbar ist. > Dazu müßtest Du erstmal passendes "Waswillicheigentlichwirklich" angeben. > Ich würde mich ja auch durchaus auf die C/C++ Schiene einlassen, wenn es > sinnvoll ist. Obwohl meine Ausflüge in C auf dem AVR meine Vorurteile > bezüglich dieser Sprache eher bestätigt haben. Ich würde nur ungern viel > Zeit in eine Richtung investieren, um dann in ein paar Monaten > festzustellen, daß ich nicht weiterkomme: Hätteste mal lieber das Andere > genommen. Also C/C++ bei µC bringt keine Nachteile, außer man will auf'm Tiny10 alle Bits ausnutzen und kann Assembler oder besser gleich Opcode aus dem FF. Was machst Du dann mit Deinem optimiertem Code wenn ein anderer Controller notwendig wird ? Sobald Du es in einer Hochsprache implementiert hast braucht es idR nur eine Anpassung an die neue Hardware (I/O, Timer usw.) da kommt man aber niemals drum herum. Dafür bleibt aber der Programmablauf identisch und man muß sich nicht darum kümmern ob nun jmp o.ä. vorher einen push o.ä. braucht, denn das übernimmt der Compiler. > > Besonders geht es mir hier um Schnittstellen zu Datenerfassung, z.B. > eine RS232 über Bluetooth oder USB-Seriell-Wandler am Tablet. Das ist > immer noch was anders als ein Hello World zum Laufen zu bringen, das hab > ich auch schon mit Scratch geschafft. QT ist eine sehr mächtige Klassenbibliothek ursprünglich plattform übergreifend für grafische Ausgaben und Standardeingaben (Tastatur, Maus usw.). Für Deine spezifische Hardware mußt Du selber Hand anlegen, das kannst Du aber einfach tun indem Du von bestehenden Klassen erbst und dort dann die Funktionen in Deiner Klasse an Deine Anforderungen anpaßt. Wenn Du über USB, Bluetooth o.ä. kommunizieren willst schaue nach ob und wo das implementiert ist und wenn Du einen passenden Treiber brauchst mußt Du entweder eine weit verbreitete Hardware nehmen oder selber hardwarenah programmieren. Die Kunst besteht darin Deine Anpassungen so zu implementieren das sie transparent im Code sind und das Interface sich nicht ändert. Sehr mächtig ist z.B. Operatoren Überladung, da kannst Du dann einfach
1 | <<
|
und
1 | >>
|
für Dein I/O nehmen und Deine Klasse kümmert sich darum ob das stdIO ist oder Bluetooth oder Seriell oder CAN oder was auch immer benötigt wird. QT für Oberfläche, C++11 für Programmablauf und eigene angepaßte Klassen für spezifische Hardware würde ich persönlich empfehlen. Eierlegendewollmilchsäue die tun was man will ohne selber Hirnschmalz einzusetzen geht nicht, auch wenn das die Rapid-Vertriebler behaupten. Erstelle erstmal eine Klasse die für Dein I/O in C++ transparent ist, dann erbst Du davon und paßt sie an die aktuelle Hardware an.
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.