Hallo Leute, Grundannahmen: - Codevervollständigung zum Code-Schreiben ist bequem. - Debugging ist essentiell. - C++17 hat seine Daseinsberechtigung. Im Moment finde ich keine IDE, die mich bei allen Grundannahmen Unterstützt. Mein letztes Projekt habe ich mit Eclipse durchgezogen. Aber Codan von Eclipse ist wohl bei C++14 stehengeblieben. Kennt ihr Alternativen?
Ja Codan is defakto tot. VSCode und dessen language-server Implementierung hat gezeigt wohin der Weg geht. Aktuell benutz ich auch hauptsächlich VSCode in Kombination mit dem Cortex-Debug Plugin zur Entwicklung... Problematisch is das ganze nur wenn man sich den Assembler anschaun muss, dann schaut man in VSCode momentan nämlich durch die Finger.
Die IAR Embedded Workbench für Arm unterstützt in den neuesten Versionen C++17. Ist aber ein kommerzielles Tool, bei dem nur eine auf 32kB limitierte Version kostenlos ist. Dafür bekommt man einen recht leistungsfähigen Debugger (ordentliche Probe vorausgesetzt) inklusive Simulator.
Redest du da nur vom Compiler oder wirklich von der von der Code-Completion? Mich wundert es etwas, dass die nicht generell den neusten GCC einsetzen. Der GCC9.1 hat ja nun schon Anfänge von C++20.
Aber wer tut sich denn den IAR freiwillig an? Der war in v7 schon komplett grottenschlecht und in v8 habenses echt noch schlimmer gemacht. Ich dacht echt das geht nicht mehr... VSCode wollt ich auch mal ausprobieren, aber als ich las, dass das in JavaScript geschrieben ist dachte ich: NEIN! einfach NEIN! Daher häng ich mich hier mal ran, mal gucken was für IDE/Edeitoren hier vorgeschlagen werden. Privat Code ich in Notepad++. Debuggt wird mit Segger Ozone.
Bzgl Eclipse und C++17 ist hier nochmal ein schöner Artikel: https://www.eclipse.org/community/eclipse_newsletter/2017/april/article5.php ...aus 2017. Aber da haben es welche eingesehen, dass es beim Fortschritt von C++ (alle 3 Jahre eine neue Version) mit Eigenbauten nicht weitergehen kann. Wenn Codan tot ist, ist das ja gut. Aber ich hätte da gehofft, dass man in 2 Jahren schon irgendwie auf Clang umgestiegen ist. hmmmh.
VS Code, cpp mode, language/debug server, jlink zum debuggen. Cmake oder Makefile zum bauen!
Mw E. schrieb: > VSCode wollt ich auch mal ausprobieren, aber als ich las, dass das in > JavaScript geschrieben ist dachte ich: > NEIN! einfach NEIN! Die Befürchtung hatte ich erst auch aber was MS da auf Electron Basis gezimmert hat ist richtig flott und fühlt sich immer responsive an.
Vincent H. schrieb: > Mw E. schrieb: >> VSCode wollt ich auch mal ausprobieren, aber als ich las, dass das in >> JavaScript geschrieben ist dachte ich: >> NEIN! einfach NEIN! > > Die Befürchtung hatte ich erst auch aber was MS da auf Electron Basis > gezimmert hat ist richtig flott und fühlt sich immer responsive an. VSCode ist in TypeScript geschrieben, nicht JavaScript. Am Ende kommt JavaScript raus, ja, aber man hat mit TypeScript viel mehr Möglichkeiten. Zustimmen kann ich aber, es ist verdammt flott, hatte noch nie Probleme damit. Warum man es nicht nutzen möchte, nur weil es auf einer bestimmten Programmiersprache basiert, will mir nicht in den Kopf.
Weil JS einfach zu einem Krebsgeschwür wird (oder schon lange ist). JS wurde als Gluecode für HTML Seiten erfunden um Intraktionen zu ermöglichen ohne jedesmal die Seite vom Server neuladen zu müssen. Selbst da wird mit Megabytes großen Frameworks, die einfach nur die CPU sinnlos belasten total übertrieben. Inzwischen schreiben die Webhipster ja schon das Serverbackend mit JS (NodeJS), wofür es NIE gedacht war! Also ihr meint VSScode ist nicht so schlimm, ich habs mal in meiner VM installiert und sofort beim installer fliegen nicht nur .js Dateien durch die Gegend, sondern auch .node Das ist ja noch mehr ein nogo als js. Bei node und seinem aketmanager npm hat ja nun jeder jeglichen Überblick verloren und dadurch wurde schon oft genug bösartiger Code eingeschleust. https://www.heise.de/developer/meldung/JavaScript-Sicherheitsluecke-im-Node-js-Paketmanager-NPM-3152199.html https://www.zdnet.de/88348273/hacker-manipuliert-javascript-bibliothek-und-stiehlt-bitcoins/ (und weitere lassen sich leicht finden) Inzwischen blendet npm ja auch schon Werbung ein, mal gucken ab wann die von externen Servern kommt und was nachladen kann ;) Sowas will ich einfach nicht auf meinem Rechner haben! Welchen Grund gibts denn eine Desktopawendung mit einer Websprache zu bauen?
Programmierer schrieb: > Kennt ihr Alternativen? Embedded Studio: https://www.segger.com/products/development-tools/embedded-studio/
Vincent H. schrieb: > Die Befürchtung hatte ich erst auch aber was MS da auf Electron Basis > gezimmert hat ist richtig flott und fühlt sich immer responsive an. Microsoft hat es geschafft sowohl den schlechtesten Editor des Universums (notepad.exe) als auch den mit weitem Abstand besten der Menschheit momentan bekannten Editor (code) herauszubringen, das ist schon ein recht bemerkenswerter Umstand welches Spektrum da mit nur 2 Produkten aufgespannt wird. Wenn sie nur in allen anderen Bereichen ebensolche Fortschritte machen würden...
:
Bearbeitet durch User
hat jemand von euch mal das mbed studio ausprobiert? bin gerade erst darüber gestolpert (https://os.mbed.com/studio/) es sieht aus wie das VS Code, soll wohl den ARM Compiler 6 mitbringen, da er auf llvm+clang basiert dürfte er auch ganz gut C++17 unterstützen.
ja, aber noch nicht sehr ausgiebig. Wenn man ein unterstütztes Board hat ist alles sehr einfach, es muss nicht wie VSCode PlugIns zusammengesucht werden und es ist fertig konfiguriert. Bezüglich Fehler- und Warnmeldungen hat sich der ARM Compiler etwas anders verhalten als der gcc, aber das war schnell zu korrigieren. Leider werden im Moment noch nicht viele Boards vom Debugger unterstützt und auch für das ältere mbed2 ist es nicht gemacht. Aber gerade da wäre es interessant, der ARM compiler erzeugt für die Cortex-M0 wesentlich kompakteren Code.
Da hat sich ja eine interessante Anzahl an Minussen eingefunden. Aber ich würde gerne mal Argumente FÜR Javascript als Desktop Progamme Programmiersprache hören. Aber bitte welche die nicht auf Java selbst zutreffen wie Multi OS, da kannste dann auch das geringere Übel nehmen, nämlich Java ;)
Mw E. schrieb: > FÜR Javascript als Desktop Progamme > Programmiersprache hören. > Aber bitte welche die nicht auf Java selbst Was hat das eine mit dem anderen zu tun?
Bei dem anti JS rant da oben fühlen sich wohl ein paar JS Kiddies gekränkt. Für Argumente bin ich ja immer zu haben, aber ich sehe keine pro JS als Desktopprogrammiersprache. Oder willste darauf hinaus wieso ich Java erwähne? Naja falls das Hauptargument "läuft auf jedem OS" ist. Das kann Java auch und ist dafür entwickelt um Programme zu schreiben und nicht nur um am HTML DOM etwas rumzuspielen.
Mw E. schrieb: > Bei dem anti JS rant da oben fühlen sich wohl ein paar JS Kiddies > gekränkt. > Für Argumente bin ich ja immer zu haben, aber ich sehe keine pro JS als > Desktopprogrammiersprache. Ich sehe js mittlerweile auch als gefährlich an. Das liegt aber nicht an js selbst sondern an dem was daraus gemacht wird. Mal nur ein Beispiel. Man nehme eine aktuelle nodejs Version und will damit ein paar Byte über UART austauschen. Also mal schnell: "npm install serialport" getippt. Geht ja so einfach. Leider landen dann sofort 616 Dateien in 133 Verzeichnissen auf der Platte die ab sofort zum Projekt gehören. Das wird von den node-Jüngern dann so einfach unkommentiert hingenommen. Mir wird davon schlecht. Eine kleine App unter cordova für iOS und Android bringt es auf 1965 Dateien in 822 Verzeichnissen mit Code aus allen Herren Ländern dessen Abhängigkeiten niemand verifiziert. Glaubt denn wirklich jemand, dass da noch einer durchsteigt und dass das in 2 Jahren auch noch läuft? Wie will man da verhindern dass beim automatischen Zusammenschaufeln von Code aus tausenden Projekten nicht doch irgendwann mal ein faules Ei darunter ist? Schöne neue Welt.
Mw E. schrieb: > aber ich sehe keine pro JS als Desktopprogrammiersprache Viele Programmierer können es, damit wird die Entwicklung billiger. Mit welcher Sprache sonst kann man so komfortabel (und damit billig) Web Apps, Smartphone Apps, Server Backends und Desktop Apps schreiben? Es gibt eine Riesen Menge an Tools und Bibliotheken, was die Entwicklung weiter vereinfacht & verbilligt. Oder würdest du lieber extra zahlen für eine IDE die in deiner Lieblingssprache geschrieben ist...? Was interessiert dich die Sprache einer Anwendung, die du nicht selbst modifizieren musst? Einfach nicht nach schauen und benutzen. Ich kann dir verraten dass im Backend mancher Web Apps sogar noch Fortran werkelt... temp schrieb: > Leider landen dann sofort 616 Dateien in 133 Verzeichnissen auf der > Platte die ab sofort zum Projekt gehören. Das wird von den node-Jüngern > dann so einfach unkommentiert hingenommen. Mir wird davon schlecht Dir wird von Dateien schlecht? Dann schau besser mal nicht in die Verzeichnisse z.B. vom GCC oder den üblichen C Libraries wie HAL oder SPL, oder dem unsäglichen TI PDK Monstrum. Was man in modernen Sprachen wie JS in 3 Zeilen macht braucht in C 100, das sorgt allein schon für geringe Code Density...
https://www.st.com/en/development-tools/stm32cubeide.html Hab ich allerdings noch nicht getestet und bzgl. C++17 hab ich auch nix gefunden.
und zum Vergleich mit Java: hat hier schonmal jemande versucht durchzusteigen wie die Eclipse Erweiterungen funktionieren? Da sind erstmal zig Verwaltungsdateien, der Code liegt irgendwo kompiliert vor. Bei VS Code sind die Erweiterungen natürlich auch in JS/TS, da kann man bei Bedarf sogar mit VSCode direkt rein debuggen und Sachen korrigieren/ändern. Das Persistenzformat der Einstellungen in .cproject bei Eclipse ist eklig und obwohl fast jeder µC Hersteller eine Eclipse Variante anbietet sind die Projekte in keiner Weise kompatibel. Bei VSCode ist alles gut lesbar in JSON gespeichert und leicht per Code zu bearbeiten. Eclipse ist ein extrem gewachsener Moloch, das kann sehr sehr viel aber die Realisierung ist viel zu kompliziert. Ich habe Kollegen die wollen von C++ nichts mehr wissen und machen alles nur noch in JS/TS. Neulinge von der Uni zaubern in wenigen Wochen Sachen da hätten die C++ Leute ein Jahr und länger dran gesessen.
Dr. Sommer schrieb: > Dir wird von Dateien schlecht? Dann schau besser mal nicht in die > Verzeichnisse z.B. vom GCC Wie war das doch gleich mit Äpfeln und Birnen? Der GCC ist ein Projekt in sich. Sicher kein kleines aber von einer Community in sich gepflegt. Da wird nicht wie beim npm alles erst zusammengetragen. Und ja mir wird vor dem Wildwuchs schlecht. > oder den üblichen C Libraries wie HAL oder > SPL, oder dem unsäglichen TI PDK Monstrum. Meine Meinung darüber habe ich auch schon oft geäußert. Selber schuld wer das verwendet. > Was man in modernen Sprachen > wie JS in 3 Zeilen macht braucht in C 100, das sorgt allein schon für > geringe Code Density... aber nicht wenn für diese 3 Zeilen 20 verschiedene Module mit ein paar 100 Dateien nötig sind, die zusammenhanglos von irgendwo her ins Projekt installiert werden. Das ist leider bei python genauso wie bei nodejs die Regel. Johannes S. schrieb: > Ich habe Kollegen die wollen von C++ nichts mehr wissen und machen alles > nur noch in JS/TS. Neulinge von der Uni zaubern in wenigen Wochen Sachen > da hätten die C++ Leute ein Jahr und länger dran gesessen. Zaubern ist hier wirklich das Schlüsselwort. Nichts dagegen wenn man sich für ein paar schnelle Sachen für den schnellen Weg entscheidet. Trotzdem kommt am Ende nur ein Müllhaufen aus wenig eigenem und viel fremden Code raus der eventuell heute funktioniert, aber keiner weiß wie und warum. Wie gesagt ich habe nichts gegen js. Wir embedden die V8 selbst in eigenen Produkten. Auch nodejs an sich will ich nicht schlecht machen. Aber die Art und Wiese wie es am Ende zu fertigen Applikationen kommt und wie die Codebestandteile zusammengetragen werden ist einfach nur krank.
temp schrieb: > Sicher kein kleines aber von einer Community in sich gepflegt. Nur dass der GCC alleine eben nicht zu gebrauchen ist. Da kommen dann noch binutils und diverse andere Bibliotheken wie newlib zu. temp schrieb: > Da wird nicht wie beim npm alles erst zusammengetragen. Nur weil ARM das freundlicherweise alles in ein großes ZIP packt. Wären das einzelne Pakete in einem Paketmanager à la npm könnte man die auch einzeln aktualisieren - schön wär's! temp schrieb: > aber nicht wenn für diese 3 Zeilen 20 verschiedene Module mit ein paar > 100 Dateien nötig sind, die zusammenhanglos von irgendwo her ins Projekt > installiert werden. Die meisten Programmierer haben zum Glück keine Modul-Allergie. Ich find's super einfach ein paar Pakete zu importieren und komplexe Aufgaben im Nu umzusetzen. Im Embedded-Bereich ist diese Mentalität auch vorhanden, aber kurioserweise disjunkt von textbasierter Programmierung: Das Hauptargument von Simulink und Konsorten ist es, dass es bereits viele Komponenten wie PID-Regler oder Verzögerungsglieder usw. integriert hat - das grafische Zusammenklicken selbiger kommt erst an 2. Stelle. Wie schön es wäre, in C(++) entsprechende Module kombinieren zu können! Aber die wären dann wieder in vielen Dateien abgelegt... temp schrieb: > Trotzdem kommt am Ende nur ein Müllhaufen aus wenig eigenem und viel > fremden Code raus der eventuell heute funktioniert, aber keiner weiß wie > und warum. Es weiß auch kein einzelner Mensch wie ein Computer oder der Linux-Kernel funktioniert. Code, der sich auf fremde Komponenten stützt, ist noch lange kein "Müllhaufen". Das ist absolut gang und gäbe - jedes Rad für jedes Projekt in jeder Firma neu zu erfinden ist ziemlich irre! Nur Embedded-C-Programmierer haben da irgendwie Probleme mit.
Dr. Sommer schrieb: > Es weiß auch kein einzelner Mensch wie ein Computer oder der > Linux-Kernel funktioniert. Code, der sich auf fremde Komponenten stützt, > ist noch lange kein "Müllhaufen". Das ist absolut gang und gäbe - jedes > Rad für jedes Projekt in jeder Firma neu zu erfinden ist ziemlich irre! > Nur Embedded-C-Programmierer haben da irgendwie Probleme mit. Im Fall von nodejs aber schon. Bei einer normalen Applikationsentwicklung verwendet man natürlich Libs da wo es angebracht ist. Und versteht auch nicht den gesamten Code. Soweit so gut. Trotzdem nimmt man eine bestimmte Version dieser Lib, die auch nicht immer die neueste sein muss, und hat unter Kontrolle welche Bestandteile man in welcher Version benutzt und woher sie kommen. Man kann auch gezielt Updates einzelner Bestandteile machen und behält auch die Kontrolle. Um beim Beispiel mit nodejs zu bleiben. Ein "npm install serialport" installiert aber Unmengen von modulen unbekannter Versionsstände auf die man damit keinen Einfluss hat. Mache ich das gleiche in 2 Wochen oder Jahren oder nur auf einer anderen Maschine landet nie der gleiche Code auf der Platte. Und keiner hat eine Übersicht darüber oder kann es beeinflussen. Das dich das nicht interessiert ist mir klar. Der Satz sagt alles: Dr. Sommer schrieb: > Einfach nicht nach schauen und benutzen. Dr. Sommer schrieb: > Die meisten Programmierer haben zum Glück keine Modul-Allergie. Das habe ich auch nicht. Jedenfalls solange ich die Kontrolle darüber habe welche Module und in welchen Versionen. Wenn dich das nicht interessiert ist es grob Fahrlässig und ich bin froh dass du nicht auf Flugzeuge oder der gleichen los gelassen wirst.
Das Thema der vielen verteilten Komponenten kommt aber aus der massiv eingesetzten OpenSource Software. Da gibt es nicht den einen der alles am Stück liefert, es hat sich ein Sammelsurium an guten Komponenten etabliert und die werden von verschiedenen Leuten gepflegt. Den Software Dinosaurieren wie MS und Co. war das auch nicht recht, die hätten die Fäden lieber selber alle in der Hand und möchten nur das Interface, nicht aber die Implementierung liefern. Viele Programmierer wollen das aber nicht und dieses Geflecht an Komponenten hat sich entwickelt. Bei JS Anwendungen ist aber ein einfach durchschauberes System der Paketverwaltung dahinter und Pakete sind üblicherweise alle als Quellcode vorhanden. Das es teilweise viel ist kommt auch von dem Komfort den diese bieten. Ein einfaches OS API hat im Hintergrund üblicherweise auch viele verzahnte Komponenten. Ein OS unabhängiges Paket muss nun vieles wieder neu erfinden wenn es sich nicht auf Features eines OS verlassen will. Und das funktioniert bei NodeJS auch erstaunlich gut, selbst grosse Dinger wie NodeRed laufen unter Windows genauso wie auf dem RPi. Und Alternativ muss man ja nicht grosse Frameworks benutzen, gerade mit NodeJS hat man eine gute Basis für einfache eigene Anwendungen.
temp schrieb: > Das ist leider bei python genauso wie bei nodejs die > Regel. Da sind mindestens zwei Größenordnungen dazwischen. Wofür man bei node 600 Pakete braucht reichen bei Python vielleicht 6 und dann ist es schon vergleichsweise viel und bei 4 von den 6 kann man sich mindestens dunkel an deren Namen erinnern weil es halbwegs bekannt ist und oft erwähnt wird. Ja, node ist vollkommener Wahnsinn. JavaScript ist ok aber Node ist die Manifestation des blanken Irrsinns. Den ganzen Scheiß müsste man um den Faktor 100 verringern und zusammenfassen um es auf das Level von Python zu bringen und wieder halbwegs beherrschbar zu machen.
:
Bearbeitet durch User
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.