Hallo, auf der Suche nach Erfahrungen zu C++ auf (deeply) Embedded Systemen bin ich auf den folgenden Artikel gestoßen: https://www.embedded-software-engineering.de/c-in-deeply-embedded-systemen-a-927854/ Beruflich programmiere ich Cortex-M controller bisher nur in C und auch die driver, HALs, middleware und Beispiel Applikationen der Controller Hersteller sind (überwiegend) nur in C. Falls Zeit zur Verfügung steht, dann schreibe ich grundsätzlich die driver für die Controller Peripherie auf die Applikation zugeschnitten selbst. Driver für externe Hardware wie z.B. transceiver nutze ich vom Hersteller. Für komplexe middleware nutze ich fertige Komponenten in C (z.B. Stacks, RTOS). Die App entwickle ich dann auch in C. 1. Wer von euch verwendet weiterhin C bei Neuprojekten? Wer von euch ist auf C++ umgestiegen? 2. Falls ihr auf C++ umgestiegen seid, in welchen layer (driver, middleware, app) setzt ihr C++ ein? 3. Entwickelt ihr alleine oder in einem Team? Ich könnte mir vorstellen, dass es schwieriger ist C++ in einem Team durchzusetzen. Viele meiner embedded Software Kollegen können gar kein C++. 4. Was ist euer Resümee zum Umstieg auf C++? Hat sich die Wartbarkeit des Codes erhöht? Ist die Produktivität gestiegen? Macht ihr nun weniger Fehler beim Programmieren? Das soll auf keinen Fall eine Diskussion zu C VS. C++ werden. Es geht hier alleine um Erfahrungen.
:
Gesperrt durch Moderator
In privaten Projekten benutze ich so gut wie nur C++, die professionellen Kollegen C. Ich habe Einsicht in den Profi Code, halte meinen aber für etwas professioneller :) Für C++ muss man auf die C Basics eine Schüppe drauflegen was das Lernen angeht, mit der Abstraktion und Zerlegung eines Projektes in Komponenten kommen aber nicht alle klar. Schon in einem früheren Ansatz war niemand bei uns für C++ zu begeistern bzw. hat es das verstanden. Mit Arduino ändert sich das vielleicht das etwas in Zukunft, die Benutzung von Komponenten und OO ist da im System drin. Nimmt ein Anfänger sicher nicht so wahr und programmiert erstmal linear drauf los, aber es gibt sicher auch einige die verstehen lernen was Klassen sind und warum man die einsetzt. Ja, der Stil und die Qualität der Arduino Libs sind sehr unterschiedlich, aber das mMn bessere Mbed mit sauberem C++ API hat nie gegen Arduino anstinken können.
MMn. muss man bei Verwendung von C++ auf µC etwas mehr aufpassen, da man nicht wild auf dem Heap herumwerkeln darf. Durch C++ eröffnen sich aber auch auf dem µC neue Möglichkeiten der Kapsulierung und Strukturierung. In meinem Spielprojekt habe ich zum Beispiel - das CMSIS-RTOS in C++ verpackt, man erbt einfach von einer Klasse "Thread", implementiert einen (nicht statischen) Member aus dem IF und hat einen Thread in C++ Umgebung, zusätzlich zum Rest der eigenen Klasse - den SYS-Layer (Open, Close, R, W, etc) mittels eigenem VFS in einhängbare C++ Device Treiber implementiert. - nutze stellenweise sogar STL Container (z.B. list) Gibt viele interessante Spielereien. Ob da C oder C++ mehr Sinn macht, hängt stark von der Anwendung, der Wartbarkeit und vor allem vom Wissen des Projektstarters (Architektur) ab. CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” https://www.youtube.com/watch?v=zBkNBP00wJE
:
Bearbeitet durch User
@jojos @thorstendb Vielen Dank für eure Beiträge. Ihr scheint beide C++ eher privat zu verwenden, aber mit privaten Spielereien kann man nicht seine Miete bezahlen ;). Viel interessanter wird es natürlich im kommerziellen und industriellen Umfeld.
BobDerBaumeister schrieb: > Ihr scheint beide C++ eher privat zu verwenden, C/C++ beruflich/privat Windows, Multiplatform, Microcontroller :-)
:
Bearbeitet durch User
Hier kommt nur noch C++ zum Einsatz, von AVR 8Bit bis ARM32-Bit. Resumee: Alles in allem schneller Entwicklung und viel weniger Fehler. Allerdings: Grundlage für den Erfolg / Verbesserung ist die extrem starke Nutzung von Compile-Time-Features und generischem Code. Das verlangt dem average-C++-Entwickler einiges ab. Schau auch mal hier: Beitrag "Informationen zu C vs C++ / aka Futter für die Diskussion"
Da man die guten Dinge von Standard C++ in Embedded-Systemen kaum nutzen kann, die ganzen Standard-Bibliotheken passen nicht, degeneriert C++ dort häufig zu C mit syntaktischem Zucker. Und das brauche ich nicht. So, und ab dem Punkt wird die Diskussion wieder ausarten. Es werden C++ Beispiele gebracht werden, die den Vorteil von C++ zeigen sollen, aber nur syntaktischen Zucker zeigen. Beispiele die missratene Abstraktionen zeigen werden, Beispiele die gegen jegliche Grundlagen von OOP verstoßen, aber cool sein wollen. Beispiele mit unwartbarem Zeug, usw. Ich bin dann schon mal raus. Ach halt, für's Weitertrollen wenn ihr mit C vs. C++ durch seit: Emacs oder vi?
BobDerBaumeister schrieb: > Ihr scheint beide C++ eher privat zu > verwenden, Es geht schon um kommerziell, nur hat sich da C++ für µC nicht durchsetzen können, auch weil in den letzten 30 Jahren sehr viele verschiedene Plattformen zum Einsatz kamen. Da ist die Historie der Klotz am Bein. Und das war ja die Frage Nr. 1.
> 1. Wer von euch verwendet weiterhin C bei Neuprojekten? Wer von euch ist > auf C++ umgestiegen? Ich würde davon abraten. Der einzige Grund kein C++ zu verwenden ist wenn es für die Zielplatform keinen Compiler gibt. Das sollte aber 2022 eher selten sein. > 2. Falls ihr auf C++ umgestiegen seid, in welchen layer (driver, > middleware, app) setzt ihr C++ ein? In allen. Umso weiter unten im "Layer" umso lohnenswerter ist es für das Produkt an dem ich entwickle. Grad Hardware Abstraktionen lassen sich in C++ viel besser und wartbarer abbilden als in C. > 3. Entwickelt ihr alleine oder in einem Team? Ich könnte mir vorstellen, > dass es schwieriger ist C++ in einem Team durchzusetzen. Viele meiner > embedded Software Kollegen können gar kein C++. "Team" (aus Mangel eines besseren Wortes). Leider ist die Einstiegshürde vor allem für Entwickler die ausschließlich prozedurale Sprachen beherrschen immens und ein Einlernen meines Erachtens nicht wirtschaftlich. > 4. Was ist euer Resümee zum Umstieg auf C++? Hat sich die Wartbarkeit > des Codes erhöht? Ist die Produktivität gestiegen? Macht ihr nun weniger > Fehler beim Programmieren? Wartbarkeit -> ja Produktivität -> vermutlich ja, lässt sich in der Pfuscherbude nicht eruieren Fehler -> nein
:
Bearbeitet durch User
Hannes J. schrieb: > So, und ab dem Punkt wird die Diskussion wieder ausarten. Es werden C++ > Beispiele gebracht werden, die den Vorteil von C++ zeigen sollen, aber > nur syntaktischen Zucker zeigen. Beispiele die missratene Abstraktionen > zeigen werden, Beispiele die gegen jegliche Grundlagen von OOP > verstoßen, aber cool sein wollen. Beispiele mit unwartbarem Zeug, usw. > Ich bin dann schon mal raus. Bitte, bloß nicht. Das nervt total, wenn jemand anfängt seine Code Schnippsel zu posten. Es soll einfach eine sachliche Diskussion bleiben. Wer nutzt es im industriellen / kommerziellen Umfeld. Welche Vorteile haben sich ergeben oder welche Stolpersteine gab es. Kam das Team damit klar. Halt die Fragen von oben.
Da der µC mit seiner Software ein eher statisches System darstellt, und man eben eine bessere Kontrolle über den Speicher hat, bleiben die meissten bei C auf diesen Systemen. Die Programme sind ja idR. überschaubar "klein". Für ein (privates) Projekt "NetLase LC" bin ich ebenfalls bei C geblieben, habe aber von Beginn an auf ein RTOS gesetzt. Daten werden angenommen, verarbeitet, ausgegeben. Da ändert sich nichts am Speicherlayout, auch nicht bei der Vielzahl an verarbeiteten Daten und Datenkanälen. Auf dem PC schaut das wesentlich dynamischer aus, z.B. beim SystemAnalyzer vom MDK-ARM. Mein Fazit: In C auf dem µC ist es einfacher, den Überblick über den Speicher zu behalten. In C++ auf dem PC ebenfalls, denn dort hat man den Vorteil des Speichermanagements (und etwas mehr Speicher :-) ) sowie die Kapselung über die Klassen / Templates. Beide Fälle schützen einen jedoch nicht davor, sauberen Code (bzw. Abstraktion) schreiben und vor allem mit den vorhandenen Ressourcen haushalten zu müssen!
:
Bearbeitet durch User
BobDerBaumeister schrieb: Ich programmiere als Hobby Mikrocontroller in C und C++. Früher habe ich beruflich Desktop Anwendungen und mobile Apps in C++ entwickelt. Heute programmiere ich beruflich völlig andere Sachen in Java und Go, manchmal auch Python. > 1. Wer von euch verwendet weiterhin C bei Neuprojekten? Wer von euch ist > auf C++ umgestiegen? Ich benutze beide Programmiersprachen, je nach Laune. > 2. Falls ihr auf C++ umgestiegen seid, in welchen layer (driver, > middleware, app) setzt ihr C++ ein? Alle, wo es geht. Wenn schon, dann auch richtig. > 3. Entwickelt ihr alleine oder in einem Team? Ich könnte mir vorstellen, > dass es schwieriger ist C++ in einem Team durchzusetzen. Viele meiner > embedded Software Kollegen können gar kein C++. Im Team sollte man so etwas nur gemeinsam entscheiden. In der Firma wo ich beruflich (nicht embedded) entwickle, benutzen wir einige Teile der Programmiersprachen/Frameworks nicht, weil sie nicht jeder beherrscht bzw. nicht leiden kann. Es ist wichtig, dass sich alle mit dem Code und den Tools wohl fühlen. Klar erwarten wir, dass sich die Entwickler weiter entwickeln, aber das braucht Zeit und Lust. > 4. Was ist euer Resümee zum Umstieg auf C++? Hat sich die Wartbarkeit > des Codes erhöht? Ist die Produktivität gestiegen? Macht ihr nun weniger > Fehler beim Programmieren? Ich denke, dass C++ hilfreich ist, um große Projekte sauber zu strukturieren. Ich würde alte Projekte jedoch nicht umschreiben. Davon wird man weder schöner noch reicher.
C++ ist durch seine unbegrenzten Möglichkeiten schneller, sicherer und effektiver als C. Leider verführt es anscheinend viele dazu, Klassen, Vererbung und Mehrfachinstanziierung zu nutzen, wo es weniger sinn macht. Und am Ende kannst Du den Code nur noch im Debugger lesen, weil 100 Funktionen write heißen und die IDE beim Namespace durcheinander kommt. Ganz Böse gesagt ist C++ sowas wie C + Hochsprache + Assembler. Sinnvoll eingesetzt sind beide Erweiterungen gut, sonst öffnen sie die Büchse der Pandora.
A. S. schrieb: > nd am Ende > kannst Du den Code nur noch im Debugger lesen, weil 100 Funktionen write > heißen und die IDE beim Namespace durcheinander kommt. Das ist ein Problem deiner nicht genannten IDE und nicht von C++.
A. S. schrieb: > C++ ist durch seine unbegrenzten Möglichkeiten schneller, sicherer und > effektiver als C. Sorry, aber "unbegrenzt" gibt es nicht und es ist auch nicht immer schneller als C, meistens sogar langsamer z.B. weil virtuelle Methoden von Objekten indirekt aufgerufen werden. Sicherer? Das bezweifle ich. Wenn ein Programmierer in C erfahren ist aber von C++ noch wenig Ahnung hat, macht er in C++ wahrscheinlich mehr Fehler als in C. Zum Beispiel vergisst er vielleicht, den Destruktor als virtual zu markieren. Unter bestimmten Bedingungen werden die Destruktoren dann in der falschen Reihenfolge ausgeführt. Als Anfänger weiss man das eventuell nicht. > effektiver als C Kommt wohl auch sehr darauf an, wie man C++ nutzt und ob man es beherrscht. > ist C++ sowas wie C + Hochsprache + Assembler Mit Assembler hat das nichts zu tun und C ist auch schon eine Hochsprache.
BobDerBaumeister schrieb: > 2. Falls ihr auf C++ umgestiegen seid, in welchen layer (driver, > middleware, app) setzt ihr C++ ein? Bin voll auf Arduino, und damit auf der C++ Schiene. Layer? Auf jedem.
Ich/wir verwenden C nur noch, wo es "behindertengerecht" sein muß. Ansonsten von C++ jeweils soviel, wie sinnvoll. Es gibt viele Dinge in C++, die in einfach besser sind und nichts kosten. Da gibt es als Ablehnungsgrund höchstens "kenne ich nicht, will ich auch nicht kennen" bei manchen.
BobDerBaumeister schrieb: > 1. Wer von euch verwendet weiterhin C bei Neuprojekten? Wer von euch ist > auf C++ umgestiegen? Ich nehme nur C++. > > 2. Falls ihr auf C++ umgestiegen seid, in welchen layer (driver, > middleware, app) setzt ihr C++ ein? Ich benutze das C++ sehr restriktiv. Alles was auf new/delete hinauslaufen könnte, das wird vermieden. Habe teilweise nur 32KByte Ram, da kann ich mir kein Trashing erlauben. New gibt es nur beim Programmstart. std::vector, std::string fällt schon alles weg. Vererbt wird wenig. Aber alleine das Strukturieren des Code in Klassen erhöht die Wartbarkeit. > > 3. Entwickelt ihr alleine oder in einem Team? Ich könnte mir vorstellen, > dass es schwieriger ist C++ in einem Team durchzusetzen. Viele meiner > embedded Software Kollegen können gar kein C++. Ich habe Kollegen. An meinem Code bin ich aber alleine dran. > > 4. Was ist euer Resümee zum Umstieg auf C++? Hat sich die Wartbarkeit > des Codes erhöht? Ist die Produktivität gestiegen? Macht ihr nun weniger > Fehler beim Programmieren? Das Benutzen von Objekte mit Member-Variablen (public/private) erhöht die Portablität ungemein. Ich benutze manche Klassen teilweise auf verschiedenen Prozessoren.
Stefan ⛄ F. schrieb: > Mit Assembler hat das nichts zu tun und C ist auch schon eine > Hochsprache. Stefan, Du kannst genügend gut C++ um meine Aussagen zu verstehen. C++ saugt praktisch alle Paradigmen. Natürlich nicht unbegrenzt, aber doch nehezu. Und ja, C++ hat einfach mehr Möglichkeiten, Code zu optimieren, auch wenn gcc vieles auch in C umsetzt. Und ja, auch mehr Zusicherungen etc. sind möglich. Dass (fast) unendliche Möglichkeiten auch (fast) unendliche Fehler und Missverständnisse provozieren kann, ist die kehrseite. Und der Grund, warum es noch nicht flächendeckend im Kernel oder autosar verwendet wird. Und ja, C++ ist deutlich mehr Hochsprache als C. Und trotzdem sehen viele Konstrukte für Dich und mich oft aus wie Assembler. Und sind ähnlich fragil.
c++ für uController erfordert eine Art Dialekt von c++. Um diesen Dialekt von c++ zu verstehen, muss man bereit sein, sich ohne Vorurteile von der üblichen c++ Implementationen zu lösen. Die 'member functions' einer 'struct' oder einer 'class' werden in der Regel 'static' definiert. Es werden keine Objekte deklariert, sondern man nutzt nur den Typ der 'struct' oder der 'class'. Deshalb können 'templates' sehr universell verwendet werden und deshalb kann die Implementation 'header-only' realisiert werden. Mit dieser kurzen Zusammenfassung sind genau die Themen aufgelistet, die hier im Forum in der Regel für intensive Diskussionen sorgen. Was ich oben skizziert habe, hat mit Arduino-c++ nichts gemein. Arduino-c++ verwendet c++ konventionell als eine sprachliche Erweiterung von c mit deklarierten Objekten und mit den üblichen header-(.h) und source-(.cc) Dateien. Falls sich jemand wirklich für diese Art von uC++Dialekt interessiert: Eine ältere Implementation eines vollständigen Frameworks für uController in c++ basierend auf c++03 mit Ergänzungen c++17 findet sich unter: https://github.com/KonstantinChizhov/Mcucpp
Beitrag #7139725 wurde vom Autor gelöscht.
Beitrag #7139727 wurde vom Autor gelöscht.
Beitrag #7139730 wurde vom Autor gelöscht.
Das haben wir hier schon x-mal durch und dazu gibt einen Thread: Beitrag "Informationen zu C vs C++ / aka Futter für die Diskussion"
MitLeserin schrieb: > c++ für uController erfordert eine Art Dialekt von c++. Um diesen > Dialekt von c++ zu verstehen, muss man bereit sein, sich ohne Vorurteile > von der üblichen c++ Implementationen zu lösen. Das findet hier leider nicht statt, ich habe es (fast) aufgegeben, das hier zu propagieren ;-) > Was ich oben skizziert habe, hat mit Arduino-c++ nichts gemein. > Arduino-c++ verwendet c++ konventionell als eine sprachliche Erweiterung > von c mit deklarierten Objekten und mit den üblichen header-(.h) und > source-(.cc) Dateien. Arduino ist broken-by-design > Falls sich jemand wirklich für diese Art von uC++Dialekt interessiert: > Eine ältere Implementation eines vollständigen Frameworks für > uController in c++ basierend auf c++03 mit Ergänzungen c++17 findet sich > unter: > https://github.com/KonstantinChizhov/Mcucpp Das ist eigentlich auch schon wieder überholt, weil mit C++20 bessere Möglichkeiten offen stehen, allen voran concepts (ermöglicht quasi ein Überladen von Meta-Funktionen (Achtung: ich schrieb Meta ...).
Wilhelm M. schrieb: > Das haben wir hier schon x-mal durch Nicht wirklich. Die Frage "Vor- und Nachteile von C++" wurde schon etliche Male durchgekaut. Die Frage "Wer benutzt zum aktuellen Stand 2022 C++ für embedded-Projekte professionell?" nicht. Mich interessiert das auch, inhaltlich kann ich dazu allerdings nichts beitragen, weil mein Metier weit, weit weg von Softwareentwicklung liegt.
Walter T. schrieb: > Wilhelm M. schrieb: >> Das haben wir hier schon x-mal durch > > Nicht wirklich. Die Frage "Vor- und Nachteile von C++" wurde schon > etliche Male durchgekaut. Die Frage "Wer benutzt zum aktuellen Stand > 2022 C++ für embedded-Projekte professionell?" nicht. Man kennt mich ja hier im Forum als einer der stärksten Verfechter von C++ (statt C) im uC Umfeld. Zwar haben wir vielleicht nur wenige Threads mit explizit dieser Überschrift, doch taucht genau diese Diskussion hier sehr oft auf.
Wilhelm M. schrieb: > ... doch taucht genau diese Diskussion hier > sehr oft auf. Leider geführt von denjenigen, die es gerade nicht nutzen.
Walter T. schrieb: > Wilhelm M. schrieb: >> ... doch taucht genau diese Diskussion hier >> sehr oft auf. > > Leider geführt von denjenigen, die es gerade nicht nutzen. Das kann ich nicht beurteilen, aber jeder hat ein Meinung dazu ;-)
Eines der Probleme ist, dass viele bei C++ an OOP denken. Und verkennen dabei, dasS C++ eine Multiparadigmen-Sprache (prozedural, OOP / OOB, generisch, meta-programmatisch, funktional, ...) ist. Meine Empfehlung bei bestehenden C-Projekten ist es, mit den "kleinen Goodies" von C++ bei der Umstellung zu beginnen. Damit erreicht man auch die alten Hasen. Am besten gepaart mit internen Mini-Schulungen aka "Goodie of the week". Danach kann man dann schrittweise tiefer einsteigen, beispielsweise erste HW-Abstraktionen mit statischer Polymorphie / concepts einzuführen. Das führt dann zu Code, bei dem zur Compilezeit sehr viele Fehler schon auftauschen (können).
Wilhelm M. schrieb: > Das ist eigentlich auch schon wieder überholt, weil mit C++20 bessere > Möglichkeiten offen stehen ... Das ist korrekt, aber ohne nutzbares c++20-Framework ist die Diskussion darüber rein akademisch. Normale Anwender, und da nehme ich mich nicht aus, verfügen nicht über das fundierte Wissen und den tiefen Einblick in die Sprache c++xx, um so ein Framework selber zu schreiben. Aber ein bestehendes c++20-Framework zu studieren und anhand von Beispielen zu verstehen und dann selber anzuwenden ist möglich. Ein funktionierendes c++20-Framework für uController ist ein erstklassiges Werkzeug um 'templates', 'concepts' und andere moderne Möglichkeiten der Sprache c++ zu studieren, zu verstehen und dann selber anzuwenden. Besser als jedes Lehrbuch.
Random .. schrieb: > Da der µC mit seiner Software ein eher statisches System darstellt, und > man eben eine bessere Kontrolle über den Speicher hat, bleiben die > meissten bei C auf diesen Systemen. Die Programme sind ja idR. > überschaubar "klein". Du kannst dein C Programm auch einfach ähnlich in C++ schreiben. Du musst kein tolles C++ Feature verwenden. Du hast aber die Option diese zu verwenden. Und gerade wenn ich an Strings denke sollte man das auch. Sehe ehrlich gesagt keinen Grund wieso man annehmen sollte, dass man schlauer als der Compiler sei und bei C irgendwas noch aktiv selbst optimieren könnte. Wenn ich einen modernen Clang/G++ verwende optimiert der echt viel. Mit Godbolt zu spielen kann eine wahre Offenbarung sein. Und moderne uC haben >100MHz und weit über 100kB RAM. Da hätte ich echt keine Bauchschmerzen dabei std:vector usw. zu benutzen. Siehe Pi Pico: "Hauptprozessor (CPU): 32-Bit RP2040 Cortex-M0+ Dual-Core-Prozessor mit 133 MHz Taktfrequenz Arbeitsspeicher (RAM): 264 kByte SRAM Programmspeicher: 2 MByte Q-SPI-Flash" Diese "aber wir nehmen den 2ct billigeren Controller mit 1kB RAM bei 1000 Stück im Jahr, denk Mal an die BOM" Denke ist da vielen aber wohl noch im Weg. So lange ihr keine hohen Stückzahlen habt ist es eigentlich immer billiger wenn man die Software und Wartung einrechnet eine der größten Varianten des uC zu verwenden. Diese kleinen 8bit Kisten sollte man tunlichst vermeiden außer man hat bestehenden Code und selbst dann kann man über eine Portierung nachdenken.
hehe ich durfte zu einem ähnlichen Thema einen Talk bei der buliding IoT halten (https://vimeo.com/ondemand/buildingiot2021/ Nr.3 Quo vadis, Embedded-Firmware-Entwicklung?) Also ich würde zu 100% ein neues Projekt mit modern C++ statt C starten. Wenn man die HAL des Chipherstellers verwendet, dann kann man diese zur Not auch noch von C++ aus aufrufen. Allerdings ist es dann ein etwas eingeschränktes C++, kein Heap, also kein new/delete. Mein absolutes lieblingsfeature ist constexpr/consteval, Gerne nutze ich auch std::array und damit dann eine "for each" schleife. Da heap nicht erlaubt ist, bin ich für std::allocator dankbar. mit std::variant lässt sich eine gute Alternative zu Exceptions aufbauen. nullptr ist auch deutlich hilfreicher als NULL enum class ist etwas besser gekapselt Wenn Interesse besteht kann ich den Talk auch gerne kostenlos in einer kleinen Gruppe über MS Teams halten :)
benwilliam schrieb: > Also ich würde zu 100% ein neues Projekt mit modern C++ statt C starten. "Würde" ist aber zur Beantwortung der Frage des TO nicht ausreichend. Oliver
benwilliam schrieb: > Allerdings ist es dann ein etwas eingeschränktes C++, kein Heap, also > kein new/delete. für die Angst vor dem Heap auch noch Geld bezahlen? Das Problem lässt sich z.B. mit Memory Pools umgehen.
J. S. schrieb: > für die Angst vor dem Heap auch noch Geld bezahlen? Das Problem lässt > sich z.B. mit Memory Pools umgehen. genau siehe std::allocator :)
was wieder zu dem Punkt führt das der C++ Werkzeugkasten sehr gut gefüllt ist, aber man deutlich mehr lernen muss um das alles unfallfrei einsetzen zu können. Damit sehe ich das eben mehr als Personalproblem. Erfahrene C-Programmierer lehnen das ab, die Frischlinge von der Uni wollen JavaScript...
Naja, in manchen Firmen ist es wie hier im Forum da kommen die gleichen Argumente wie hier ... haben wir schon immer mit der Sprache X gemacht usw. Obwohl ich sehr lange Zeit mit klassischem C++ auf PC programmiert habe, hat es bei mir bis zu Rente gebraucht, das ich mich wieder mit MC und ihrer Programmierung beschäftigen durfte. Dachte am Anfang auch C89 mit Klassen und Vererbung reicht dafür aus. Templates und CRTP kannte ich von der Windows Template Libray (WTL) mit ich privat meine PC Anwendungen programmiere. Im Laufe der Zeit habe ich immer mehr Features bei neueren C++ Versionen gefunden die das Leben Erleichtern. Meine Zutaten zur embedded Programmierung sind im Moment: templates, scoped enums, meta programming, type_traits, requires, concepts also C++20. Da bin ich mit Wilhelm M. einer Meinung. Ich kann das gerne auch näher erklären warum .. nur in welchem Thread hier ?
Ich benutze beruflich C++ seit 14 Jahren, zunächst 2 Jahre für Windows/MFC, dann ~7 Jahre für WindowsCE auf ARM-uCs (Embedded), 15 Monate ANSI-C99 für SPARC/Embedded (Safety) und seit 4 Jahren wieder für normale Windows-Kisten. Meiner Meinung nach kannst du mit C99 auch guten Code schreiben, unter der Voraussetzung, dass TDD gemacht wird (siehe Grenning: TDD for EmbeddedC). Sind da alle mit dabei, spricht nix dagegen, ANSI-C weiter zu verwenden. Soll wirklich auf C++ gewechselt werden, bei uCs unbedingt sinnvolle Einschränkungen bezüglich Sprachumfang festlegen (bzw. ausknobeln lassen). Guter Ansatzpunkt hierfür, z.B. MISRA-C++ und vielleicht einen Analyzer wie Lint dafür. Schrittweise steigender Compilerwarnlevel kann aber auch helfen. Die Magie entfaltet C++ eigentlich dann, wenn OOP gemacht wird und Objekte sinnvoll gemäß gekapselt sind, Demeter eingehalten wird und Composition anstelle Inheritance gemacht wird. Kann aber ein weiter Weg dahin sein, gerade wenn OOP noch Neuland ist. Google C++ Style Guide hilft vielleicht dabei.
Falk S. schrieb: > Die Magie entfaltet C++ eigentlich dann, wenn OOP gemacht wird wie bitte? OOP ist Magie??? > und > Objekte sinnvoll gemäß gekapselt sind, Objekte? Du meinst Klassen. Und die sind auch nicht gekapselt, sondern sie kapseln. > Demeter eingehalten wird und > Composition anstelle Inheritance gemacht wird. Hört sich so an, als ob Du gerade mit OOP angefangen hast ;-) > Kann aber ein weiter Weg dahin sein, gerade wenn OOP noch Neuland ist. > Google C++ Style Guide hilft vielleicht dabei. OOP in C++ hat zwar auch auf µC seine Bedeutung, ist aber einfach Standard. C++ hat viel mehr zu bieten als OOP, denn C++ ist eben eine Multiparadigmen-Sprache. Und gerade die weiteren Zutaten wie compile-time-computation, Meta-Funktionen und TMP, generische Programmierung mit constraints / requirements sind die Dinge, die es im µC-Bereich interessant macht.
Falk S. schrieb: > Ich benutze beruflich C++ seit 14 Jahren, zunächst 2 Jahre für > Windows/MFC, dann ~7 Jahre für WindowsCE auf ARM-uCs (Embedded), 15 > Monate ANSI-C99 für SPARC/Embedded (Safety) und seit 4 Jahren wieder für > normale Windows-Kisten. > > Meiner Meinung nach kannst du mit C99 auch guten Code schreiben, unter > der Voraussetzung, dass TDD gemacht wird (siehe Grenning: TDD for > EmbeddedC). > Sind da alle mit dabei, spricht nix dagegen, ANSI-C weiter zu verwenden. > Die Frage ist doch eher : Was bieten mir die neuen Features etwas besser zu machen oder mir die Arbeit zu erleichtern ? > Soll wirklich auf C++ gewechselt werden, bei uCs unbedingt sinnvolle > Einschränkungen bezüglich Sprachumfang festlegen (bzw. ausknobeln > lassen). Guter Ansatzpunkt hierfür, z.B. MISRA-C++ und vielleicht einen > Analyzer wie Lint dafür. Schrittweise steigender Compilerwarnlevel kann > aber auch helfen. > Wenn dein Umfeld Misra verlangt bleibt dir nichts anderes übrig ;-) > Die Magie entfaltet C++ eigentlich dann, wenn OOP gemacht wird und > Objekte sinnvoll gemäß gekapselt sind, Demeter eingehalten wird und > Composition anstelle Inheritance gemacht wird. > C++ bietet viel mehr als OOP ;-) > Kann aber ein weiter Weg dahin sein, gerade wenn OOP noch Neuland ist. > Google C++ Style Guide hilft vielleicht dabei. Style Guides helfen dir nicht Probleme zu lösen werden aber wichtig wenn ein anderer dein Code lesen und verstehen muss. Zu einem code review mit unleserlichem Spaghetti code auf zu tauchen ist keine so gute Idee ;-)
Wilhelm M. schrieb: > Objekte? Du meinst Klassen. Verschwende deine Energie nicht mit Begriffen, solange klar ist, was gemeint war. Jede Programmiersprache hat ein etwas anderes Wording.
Genau! Jedoch war es hier eindeutig und deswegen falsch.
BobDerBaumeister schrieb: > 1. Wer von euch verwendet weiterhin C bei Neuprojekten? Wer von euch ist > auf C++ umgestiegen? Ich verwende C, wenn der Kunde das ausdrücklich wünscht, oder anzunehmen ist, dass C-Programmierer den Code später warten müssen. Ansonsten verwende ich immer C++ (wenn Compiler vorhanden ist). > 2. Falls ihr auf C++ umgestiegen seid, in welchen layer (driver, > middleware, app) setzt ihr C++ ein? Musste den Umstieg C->C++ nie machen. Ich setze C++ auf allen Ebenen ein. > 3. Entwickelt ihr alleine oder in einem Team? Ich könnte mir vorstellen, > dass es schwieriger ist C++ in einem Team durchzusetzen. Viele meiner > embedded Software Kollegen können gar kein C++. Unterschiedlich. C++ ist eine sehr umfangreiche Sprache. Wenn die Komplexität der Projekte relativ gering ist und die damit beauftragen Entwickler E-Techniker sind, die die Software-Entwicklung nur nebenbei betreiben, würde ich denen raten, bei C zu bleiben. > 4. Was ist euer Resümee zum Umstieg auf C++? Hat sich die Wartbarkeit > des Codes erhöht? Ist die Produktivität gestiegen? Macht ihr nun weniger > Fehler beim Programmieren? Ich merke immer, dass ich in C einiges mehr an Code schreiben muss, um das selbe zu erreichen. Fehlende Abstraktionsmöglichkeiten von C behindern die Testbarkeit und damit verbringt man dann später deutlich mehr Zeit, die vorhandenen Fehler zur Laufzeit im Debugger zu finden.
Wilhelm M. schrieb: > OOP ist Magie??? Ja! Die mir bekannte Definition von dem Begriff "Magie": > Magie ist, wenn man die Technik dahinter, > den Sinn und die Verfahren nicht verstanden hat. Das heißt: Was für dich normal ist, ist für andere durchaus magisch. Mit dem Wechsel von C zu C++ geht ein Paradigmenwechsel einher. Das führt zwangsläufig dazu, dass heißgeliebte und geübte Verfahren in den Hintergrund rücken und andere Denkweisen sich breit machen. Ein recht wichtiger Punkt scheint mir dabei der Kontrollfluss im Programm zu sein. Da sehe ich die größte OOP Einsteiger Hürde. Der C Programmierer wird ein Kontrollflussdiagram(Programmlaufplan) malen, und im Idealfall findet sich das 1:1 im fertigen Programm wieder. Der OOPler dagegen baut Kapseln(Klassen). Versieht diese mit Schnittstellen. Oder anders herum, entwirft Schnittstellen und füllt diese mit Fleisch(Code+Daten). Ein traditioneller Kontrollfluss ist dann quasi nur innerhalb der einzelnen Methoden sichtbar. Der OOPler wird eher UML Diagramme o.ä. malen, in dem sich die einzelnen Komponenten Nachrichten über ihre Schnittstellen senden (Methoden aufrufen). Der resultierende Kontrollfluss ist so nicht mehr übersichtlich ausgebreitet vor einem liegend, sondern zerfasert in dutzende/hunderte Klassen und Dateien. Natürlich geht es nicht ohne Kontrollfluss... In der OOP ergibt sich der Kontrollfluss automatisch durch die Kommunikation zwischen den Komponenten. Dadurch steht dieser nicht mehr im Fokus, wie es z.B. bei einem C oder ASM Geübten der Fall ist. Dieses "loslassen", des Kontrollflusses, da klemmt es. Die entstehende Empfindung: Kontrollverlust Magie! Es funktioniert, ohne offensichtlichen/ausgebreiteten Kontrollfluss,
:
Bearbeitet durch User
Naja, zuerst solltest du "Embedded-Systeme" mal definieren ;) das kann von 8-Bit Controller bis zu einem Multi-Core Systeme mit Linux heute alles bedeuten. Wir haben im beruflichen Umfeld seit dem Umstieg auf die ARM-Welt (mit und ohne OS) vor ~15 Jahren eigentlich ausschliesslich C++ verwendet (wobei hier wohl stark limitiertes C++ gemeint ist). Das machte die Wiederverwendbarkeit von Bibliotheken um einiges einfacher mit wesentlich weniger Fehlerquellen. Seit rund 3 Jahren gehen setzen wir verstärkt auch automatisierte Tests (direkt in den Build-Pipelines integriert) im Firmware-Bereich ein -> denke mit C ist das etwas schwieriger zu machen (wobei ich das ehrlich nie ausprobiert habe). Folgende Punkte müssen halt im beruflichen Umfeld auch betrachtet werden: - Heutzutage sollten C++ Compiler für alle relevanten Zielsysteme verfügbar sein, und oftmals sind sie zudem noch so performant, dass sie an reines C ohne Probleme herankommen. - Tool-Chain & Infrastruktur (nicht jeder Betrieb möchte 100 verschiedene Tools und Lizenzverträge haben) - Wenn beispielsweise im Büro nebenan ein C++ Team sitzt, können die einem bei Ressourcenmangel unter die Arme greifen. Ich denke nicht, dass irgendwo noch jemand Desktop- oder Web-Applikationen in C entwickelt.
Patrick B. schrieb: > - Heutzutage sollten C++ Compiler für alle relevanten Zielsysteme > verfügbar sein, und oftmals sind sie zudem noch so performant, dass sie > an reines C ohne Probleme herankommen. Die Performance ist mindestens gleich, denn alle heutigen Compiler setzen die Sprache mit nur wenigen Optimierungen auf Sprachebene in eine IL um, auf der dann der Optimizer hauptsächlich arbeitet.
Arduino F. schrieb: > Der resultierende Kontrollfluss ist so nicht mehr übersichtlich > ausgebreitet vor einem liegend, sondern zerfasert in dutzende/hunderte > Klassen und Dateien. Was die Wartbarkeit und Testbarkeit sicher UNHEIMLICH erhöht. > Natürlich geht es nicht ohne Kontrollfluss... > In der OOP ergibt sich der Kontrollfluss automatisch durch die > Kommunikation zwischen den Komponenten. Dadurch steht dieser nicht mehr In der Tat. Und nur allzu oft hat keiner einen WIRKLICH guten Durchblick wie, wo und wann passiert. Bravo! > im Fokus, wie es z.B. bei einem C oder ASM Geübten der Fall ist. > > Dieses "loslassen", des Kontrollflusses, da klemmt es. > Die entstehende Empfindung: Kontrollverlust Das ist keine Empfindung, das ist REAL! Ich will ja nicht immer wieder die alte Leier anfangen, aber meine, wenn gleich sehr begrenzte Wahrnehmung ist, daß viele dieser Dinge nur allzu oft zu Bloatware führen! Wahnsinnige, aufgeschwemmt, lahmarschige Software! Nein, ich würde das Problem sicher NICHT mit Assembler lösen wollen. Das geht schon in C++. Aber eben nicht mit der Einstellung der meisten (einiger?) Softwareentwickler, die sämtliche Verantwortung für Leistung auf Frameworks und Hardware abschieben.
Mahlzeit, Nun bin ich ja einer von den tumben Elektrolurchen, die's grad mal so bis zu C geschafft haben, aber bislang den hoheren Weihen von C++ und noch viel besseren Sprachen nicht so recht was abgewinnen konnten. Mich wuerden jetzt mal konkrete Beispiele und konkrete Vorteile interessieren, also z.B.: Guckt mal das olle VU-Meter hier an: Beitrag "VU-Meter mit Attiny13a statt LM3916" Sprich: Ich hab einen µC mit einem ADC Eingang und 4 I/Os, an denen 12 gecharlieplexte LEDs haengen, die dann in Abhaengigkeit von den Daten des ADCs gar lustig und sinnvoll leuchten sollen. Wie realisiert der Informatiker sowas popeliges in C++ oder hoeher? Also was wird da zu Klassen, was wird da von wem abgeleitet, templatisiert oder was weiss ich, welche Art der "schwarzen Magie" da jetzt gerade hip ist? Gruss WK
Dergute W. schrieb: > Beitrag "VU-Meter mit Attiny13a statt LM3916" > Sprich: Ich hab einen µC mit einem ADC Eingang und 4 I/Os, an denen 12 > gecharlieplexte LEDs haengen, die dann in Abhaengigkeit von den Daten > des ADCs gar lustig und sinnvoll leuchten sollen. > Wie realisiert der Informatiker sowas popeliges in C++ oder hoeher? Man kann es immer mit der Abstraktion übertreiben, davon wird auch REICHLICH Gebrauch gemacht. Aber dein Beispiel taugt nicht für die Fragestellung, denn dabei geht es eher um größere und komplexere Projekte. Je einfacher die sind, umso weniger macht Abstraktion Sinn und bringt auch wenig Vorteile. Das Projekt oben kann man auch locker in Assembler machen.
Dergute W. schrieb: > Sprich: Ich hab einen µC mit einem ADC Eingang und 4 I/Os, an denen 12 > gecharlieplexte LEDs haengen, die dann in Abhaengigkeit von den Daten > des ADCs gar lustig und sinnvoll leuchten sollen. > Wie realisiert der Informatiker sowas popeliges in C++ oder hoeher? Also > was wird da zu Klassen, was wird da von wem abgeleitet, templatisiert > oder was weiss ich, welche Art der "schwarzen Magie" da jetzt gerade hip > ist? Man kann deine Frage auch anders drehen: wie möchtest du ein Embedded-Gerät mit 10" Grafik Touch-Display, Netzwerkkommunikation, Filesystem, Firewall und "Cloud-Kommunikation" über MQTT... in C realisieren? Zumal wenn der Code dann Komponenten (Bibliotheken, Business-Logik) enthält, die sich über mehrere Projekte mit unterschiedlichen Zielplattformen erstrecken und ständig weiterentwickelt werden? => Deswegen ja auch mein Einwand: Patrick B. schrieb: > Naja, zuerst solltest du "Embedded-Systeme" mal definieren ;) das kann > von 8-Bit Controller bis zu einem Multi-Core Systeme mit Linux heute > alles bedeuten. Embedded bedeutet heute nicht mehr 8Pin & 8-Bit Controller! Dein Motorsteuergerät oder Entertainment- & Navisystem im Auto sind auch Embedded;) Nutzt die für euch (und vor allem im Sinne der Firma) richtigen Tools!
Falk B. schrieb: > Was die Wartbarkeit und Testbarkeit sicher UNHEIMLICH erhöht. Erstaunlicher weise, ja. Die Einzelkomponenten lassen sich viel einfacher und vollständiger warten und testen. Die Kapselung(Spracheigenschaften) unterbindet versehentliches/beabsichtigtes unterlaufen dieses Schutzes. C++ bietet an der Stelle alles, was auch C kann, und geht weit darüber hinaus. Falk B. schrieb: > In der Tat. Und nur allzu oft hat keiner einen WIRKLICH guten Durchblick > wie, wo und wann passiert. Wie schon gesagt: Was wie wo und wann passiert, wird im inneren der Kapseln entschieden. Das Innere ist jederzeit auswechselbar. Im Idealfall, ohne dass sich die Schnittstelle ändert. Merke: Man programmiert immer nur gegen die Schnittstelle, nie gegen die Implementierung. Falk B. schrieb: > Das ist keine Empfindung, das ist REAL Die Empfindung ist real, ja. Aber diese Empfindung ist in der OOP Welt nicht nötig. Denn der Kontrollfluss findet statt, egal ob man den Fokus darauf richtet, oder auch nicht. Der Kontrollfluss wird auf etwas andere Art hergestellt, als es der C Programmierer gewohnt ist. Die Frage ist, kann er sich an die etwas andere Sichtweise gewöhnen? Wenn nein, sollte er es lassen. Anfänger haben es da viel leichter. Die brauchen nicht die liebgewonnenen Sichtweisen los zu lassen. Gesetzte Prozedural Entwickler haben es schwerer, die müssen das beiseite drängen, was bisher ihre Erfolge ihr Überleben, gesichert hat. Niemand weicht ohne Grund von eingetretenen, als sicher empfundenen, Pfaden ab. Das betreten von Neuland ist wohl immer mit Unsicherheiten/Furcht verbunden. Ob dies rational oder irrational ist, wird die individuelle Erfahrung zeigen. Falk B. schrieb: > Ich will ja nicht immer wieder die alte Leier anfangen, Dann lass es doch..... Wer dagegen ist, wird immer negative Beispiele finden. Das ist Psychologie, hat mit C++ oder OOP nix zu tun.
Dergute W. schrieb: > Wie realisiert der Informatiker sowas popeliges in C++ oder hoeher? Wahrscheinlich wäre meine Lösung sehr ähnlich Deiner Lösung in C. Ausser, dass die Lösung dann mit einem C++ compiler übersetzt worden wäre. C++ ist halt ein Werkzeug, um die wachsende Komplexität, die sich auch immer weiter in die embedded Welt einschleicht, in den Griff zu bekommen. In Deinem Beispiel, kann man evtl. die Umsetzung eines analogen Eingangs auf auf 12 digitale Ausgänge testen. Wie groß ist die Chance, dass Du in der endgültigen Software dabei einen Fehler hast, den Du nicht sofort findest? Nimm auf der anderen Seite mal Bluetooth. Die Spezifikation der Core-Components ist auf 3112 Seiten beschrieben. Wir groß ist die Chance, dass Du da eine robuste und flexible Implementierung hin bekommst, wenn Du die mit den selben Mitteln entwickelst, wie Dein Beispiel oben?
Moin, Falk B. schrieb: > Das Projekt oben kann man auch locker in > Assembler machen. Ach. Achwas. Achnee. Waer' ich nicht draufgekommen. > Aber dein Beispiel taugt nicht für die > Fragestellung, denn dabei geht es eher um größere und komplexere > Projekte. Hm - mir war so, als ginge es hier um (deeply) embedded Geruempel. Im ersten Post ist ein Artikel verlinkt, wo es um Hoergeraete geht. Und nicht um: Patrick B. schrieb: > ein > Embedded-Gerät mit 10" Grafik Touch-Display, Netzwerkkommunikation, > Filesystem, Firewall und "Cloud-Kommunikation" über MQTT... Und dann stell ich mir natuerlich die Frage: Ab wann (wieviele LEDs, wieviele von welchem anderen Gedoens) ist denn dann C++ angesagt? Gruss WK
Nur mal so als Beispiel eines einfachen, entkernten Projekts mit einem avr128db64 auf einem Testboard mit vielen externen Geräten. Die meisten Treiber dafür habe ich in dem Beispiel entfernt, denn compilieren könnt Ihr das eh nicht, weil zuviele weitere Header-Files (header-only) nötig wären. Es soll nur mal die Struktur zeigen, die bei solchen einfachen Projekten immer gleich ist. Die generische Klasse Devices deklariert die vorhandenen Geräte für unterschiedlicher HW-Revisionen des Boards, in diesem Beispiel fehlt aber viel. Die gen. Klasse GlobalFSM realisiert eine globale FSM (ebenfalls viel entfernt). Sie läuft in zwei Loops, einmal max. Geschwindigkeit und einmal mit 1kHz. Viel anders würde das VU-Meter auch nicht aussehen, natürlich weniger Deklarationen für Geräte.
Sorry, aber der Code über mir ist doch total unlesbar. Diese ganzen Scopes stören doch beim lesen. Da bleibe ich lieber bei "einfacherem" C++, welches sehr nahe an C ist. Nur weil C++ so viel Werkzeug bietet, muss ich es nicht komplett ausnutzen. Es verkompliziert alles. Man sollte auf dem Level bleiben, auf denen die meisten Kollegen im Team zurecht kommen. Wenn man Alleingänge macht, dann hilft das keinem weiter.
Moin, Merci fuer's Beispiel. Bleibt also im Endeffekt bei Statemachines. Also eher nix mit "Kontrollfluss loslassen" - aber das klingt fuer mich eh eher wie die Werbung mit den 2 Ommas beim Yoga. Gruss WK
Mir sind noch zu C-Plas-Plas 2 Fragen eingefallen. Wie ist die Nutzung von C-Plas-Plas in Zusammenhang mit Fusi geregelt? Gibt es da Einschränkungen? Und Misra?
Dergute W. schrieb: > Ach. Achwas. Achnee. Waer' ich nicht draufgekommen. > [...] > Und dann stell ich mir natuerlich die Frage: > Ab wann (wieviele LEDs, wieviele von welchem anderen Gedoens) ist denn > dann C++ angesagt? Bis jetzt war das eine konstruktive und angenehme Diskussion, warum mußt Du polemisch werden? Welchen Teil von Wilhelms Hinweis, daß OOP ein Werkzeug ist, um die zunehmende Komplexität besser beherrschen zu können, hast Du denn nicht verstanden?
Dergute W. schrieb: > Bleibt also im Endeffekt bei Statemachines. Jedes Programm und auch imperativ geschriebene Programme in C sind immer Zustandsautomaten. Und auch OO ist das, allerdings haben wir hier geschachtelte Automaten, denn die meisten Klassen realisieren Automaten. Und genau das ist das Wesen von OOP: wir haben viele Objekte, also Automaten, die miteinander agieren. Die Idee von OOP ist, möglichst kleine Automaten zu haben, die für sich abgeschlossen sind, damit einfach wiederverwendbar und testbar. Insofern ja: es bleibt immer bei Zustandsautomaten: in manchen Fällen sind sie explizit codiert (in dem obigen simplen Beispiel als switch/case, man kann aber genauso auch z.B. SML nehmen), in anderen Fällen implizit durch die Zustände der Objekte.
Dergute W. schrieb: > Mich wuerden jetzt mal konkrete Beispiele und konkrete Vorteile > interessieren, also z.B.: Guckt mal das olle VU-Meter hier an: > Beitrag "VU-Meter mit Attiny13a statt LM3916" Hab mir das mal angeschaut, das ist ja reiner Spaghetti-Code ohne auch nur einen Funktionsaufruf. Und entsprechend mühsam ist es, zumindest die grobe Funktion des Programms zu erfassen.
Thorsten M. schrieb: >> Mich wuerden jetzt mal konkrete Beispiele und konkrete Vorteile >> interessieren, also z.B.: Guckt mal das olle VU-Meter hier an: >> Beitrag "VU-Meter mit Attiny13a statt LM3916" > > Hab mir das mal angeschaut, das ist ja reiner Spaghetti-Code ohne auch > nur einen Funktionsaufruf. Stimmt nicht. Das Ding besteht halt nur aus einer Funktion, welche im ADC-Interrupt aufgerufen wird. > Und entsprechend mühsam ist es, zumindest die > grobe Funktion des Programms zu erfassen. Naja, man hätte den Quelltext besser strukturieren können, auch ein paar Leerzeilen hätten nicht geschadet. Aber der Rest ist OK, weil halt linear. Es gibt kurze Interrupts und lange, wo die LEDs neu berechnet und per Multiplex angesteuert werden.
Konkreter, ich würde das Display in eine Klasse packen, und grob die folgenden funktionen definieren (Pseudocode):
1 | Display.Init; |
2 | Display.SetLEDs(Leds...); //nur zum Testen |
3 | Display.SetLevel(EffValue...); //Angabe über Effektivwert, ruft dann SetLEDs |
4 | Display.TestPeakLED; |
5 | Display.DoMultiplexing; |
Natürlich kann man das auch einfach über Funktionen umsetzen, durch eine Klasse bleiben aber die internen Variablen (wie z.B. der Countdown-Zähler für die Peak-LED) eindeutig vom Übrigen abgetrennt. Es ist dann klarer, wo die Variable dazugehört und man ist weniger versucht, von außen zu manipulieren. Man könnte es auch in eine eigene Datei packen, die Klasse macht das halt ordentlicher. Im Grunde ist die Klasse wie die Linien auf einem Parkplatz, es passen dadurch rechnerisch auch nicht mehr Autos drauf, aber es vereinfacht das saubere Abstellen vom Auto bzw. Code.
Habe mir den Code auch mal angesehen. Dabei fällt einem natürlich sofort die manuell / extern erzeugte Quadrierungstabelle auf. Sowas macht man in C++ mit einer IIFE, also einem Funktionsaufruf (am besten als Closure) zur Compilezeit. Da wird dann auch jedem Sofort klar, was der Inhalt der Tabelle ist, und Kapselt das ganze in einer Klasse. Der Rest ist natürlich unspektakulär, man würde das Display kapseln und vllt sogar mit den Led-Pins parametrieren, so dass man das Ganze leicht auf mehr als 12 Leds erweitern kann. Auch den Inhalt der LUT kann man zur Compilezeit erzeugen lassen. Im Übrigen ist natürlich eine naked-ISR übel. Ich hätte komplett auf Interrupts verzichtet und den ADC ge-polled. Wäre wohl auch nicht langsamer, dafür aber könnte auf die naked-ISR verzichtet werden.
Wilhelm M. schrieb: > Im Übrigen ist natürlich eine naked-ISR übel. Jain. Da hier so oder so nix anderes läuft, ist das schon OK. Es muss nicht immer die ultra portable, erweiterbare und lehrbuchartige Lösung sein. > Ich hätte komplett auf > Interrupts verzichtet und den ADC ge-polled. Wäre wohl auch nicht > langsamer, dafür aber könnte auf die naked-ISR verzichtet werden. Reine Formsache. >Der Rest ist natürlich unspektakulär, man würde das Display kapseln und >vllt sogar mit den Led-Pins parametrieren, so dass man das Ganze leicht >auf mehr als 12 Leds erweitern kann. Naja, hier liegt aber auch oft die Gefahr, eine Lösung zu allgemeingültig und erweiterbar zu machen, was dann aber keiner braucht, wohl aber Aufwand und Ressourcen kostet.
Falk B. schrieb: > Wilhelm M. schrieb: >> Im Übrigen ist natürlich eine naked-ISR übel. > > Jain. Da hier so oder so nix anderes läuft, ist das schon OK. Es muss > nicht immer die ultra portable, erweiterbare und lehrbuchartige Lösung > sein. Sowas ist einfach nur Gefrickel. Es geht hier darum, wie man es besser machen kann: durch Einsatz von C++ und sonstigen Maßnahmen. Und das gehört ganz klar dazu. >> Ich hätte komplett auf >> Interrupts verzichtet und den ADC ge-polled. Wäre wohl auch nicht >> langsamer, dafür aber könnte auf die naked-ISR verzichtet werden. > > Reine Formsache. Sehe ich nicht so: s.o. >>Der Rest ist natürlich unspektakulär, man würde das Display kapseln und >>vllt sogar mit den Led-Pins parametrieren, so dass man das Ganze leicht >>auf mehr als 12 Leds erweitern kann. > > Naja, hier liegt aber auch oft die Gefahr, eine Lösung zu > allgemeingültig und erweiterbar zu machen, was dann aber keiner braucht, > wohl aber Aufwand und Ressourcen kostet. Wie gesagt, es ging darum, wie man es besser machen kann. Und dazu gehört die Erweiterbarkeit. Ob das jemand braucht, steht nicht zur Debatte.
Wilhelm M. schrieb: > > Wie gesagt, es ging darum, wie man es besser machen kann. Und dazu > gehört die Erweiterbarkeit. Ob das jemand braucht, steht nicht zur > Debatte. Erweiterbarkeit ist aber erst "besser" nach dem klar ist, dass eine Erweiterung benötigt wird. Vorher ist Erweiterbarkeit erst mal teuerer und komplexer.
Torsten R. schrieb: > Wilhelm M. schrieb: >> >> Wie gesagt, es ging darum, wie man es besser machen kann. Und dazu >> gehört die Erweiterbarkeit. Ob das jemand braucht, steht nicht zur >> Debatte. > > Erweiterbarkeit ist aber erst "besser" nach dem klar ist, dass eine > Erweiterung benötigt wird. Vorher ist Erweiterbarkeit erst mal teuerer > und komplexer. Das Problem ist aber, dass du vorher in der Regel noch nicht weißt, was du später wie erweitern musst. Und wenn du dir die Möglichkeiten dazu dann schon von vorne herein verbaut hast, ist der Aufwand, das nachträglich zu korrigieren, meistens sehr hoch. Der Zusatzaufwand, es von vorne herein erweiterbar zu gestalten, ist zwar auch vorhanden, aber oft im Vergleich gering.
:
Bearbeitet durch User
Rolf M. schrieb: > Das Problem ist aber, dass du vorher in der Regel noch nicht weißt, was > du später wie erweitern musst. Und wenn du dir die Möglichkeiten dazu > dann schon von vorne herein verbaut hast, ist der Aufwand, das > nachträglich zu korrigieren, meistens sehr hoch. Wir reden ja nach wie vor über _Soft_ware. Da verbaust Du Dir nicht mal eben etwas. > Der Zusatzaufwand, es > von vorne herein erweiterbar zu gestalten, ist zwar auch vorhanden, aber > oft im Vergleich gering. Wenn Du vorher nicht weißt, was Du später erweitern musst, dann würde ich es lassen, an jeder Stelle Erweiterung-Punkte vorzusehen. Ich würde einfach warten, bis die Anforderungen kommen. In der Regel kommen sie dann nämlich nie, oder nicht so, wie Du sie vorgehen hast.
:
Bearbeitet durch User
Torsten R. schrieb: > Wenn Du vorher nicht weißt, was Du später erweitern musst, dann würde > ich es lassen, an jeder Stelle Erweiterung-Punkte vorzusehen. Ich hatte ganz konkret die Parametrierung mit den Ausgängen für das Charlyplexing vorgeschlagen, also seht konkret. Das könnte folgendermaßen aussehen für 12 Leds:
1 | using line0 = Pin<Port<E>, 4>; |
2 | using line1 = Pin<Port<E>, 5>; |
3 | using line2 = Pin<Port<E>, 6>; |
4 | using line3 = Pin<Port<E>, 7>; |
5 | using lines = Meta::List<line0, line1, line2, line3>; |
6 | using charly = Charly<lines>; |
Und in einem anderen Projekt dann:
1 | using line0 = Pin<Port<E>, 4>; |
2 | using line1 = Pin<Port<E>, 5>; |
3 | using line2 = Pin<Port<E>, 6>; |
4 | using line3 = Pin<Port<E>, 7>; |
5 | using line4 = Pin<Port<D>, 0>; |
6 | using lines = Meta::List<line0, line1, line2, line3, line4>; |
7 | using charly = Charly<lines>; |
:
Bearbeitet durch User
Wilhelm M. schrieb: > Torsten R. schrieb: >> Wenn Du vorher nicht weißt, was Du später erweitern musst, dann würde >> ich es lassen, an jeder Stelle Erweiterung-Punkte vorzusehen. > > Ich hatte ganz konkret die Parametrierung mit den Ausgängen für das > Charlyplexing vorgeschlagen, also seht konkret. Ja, und Rolf schrieb: "Das Problem ist aber, dass du vorher in der Regel noch nicht weißt, was du später wie erweitern musst." Genau darauf bin ich eingegangen: Wenn Du in der Regel vorher nicht weißt, welche Probleme Du in der Zukunft lösen sollst, dann würde ich nicht raten und hoffen, sondern warten :-)
Torsten R. schrieb: > Genau darauf bin ich eingegangen: Wenn Du in der Regel vorher nicht > weißt, welche Probleme Du in der Zukunft lösen sollst, dann würde ich > nicht raten und hoffen, sondern warten :-) Hä? Ich hatte ganz konkret über die Ausgänge beim Charlyplexing gesprochen: Wilhelm M. schrieb: > Der Rest ist natürlich unspektakulär, man würde das Display kapseln und > vllt sogar mit den Led-Pins parametrieren, so dass man das Ganze leicht > auf mehr als 12 Leds erweitern kann. Auch den Inhalt der LUT kann man > zur Compilezeit erzeugen lassen. Und dann kamst Du mit: Torsten R. schrieb: > Erweiterbarkeit ist aber erst "besser" nach dem klar ist, dass eine > Erweiterung benötigt wird. Vorher ist Erweiterbarkeit erst mal teuerer > und komplexer. Also: hier ist sehr klar, wie und wo ich eine Erweiterbarkeit einbauen wollte.
Wilhelm M. schrieb: > Hä? Ich hatte ganz konkret über die Ausgänge beim Charlyplexing > gesprochen: Du hattest ganz konkret gesagt: "Wie gesagt, es ging darum, wie man es besser machen kann. Und dazu gehört die Erweiterbarkeit." Dem habe ich widersprochen. Erweiterbarkeit ist nicht besser. Im Gegenteil. In der Regel werden wir immer falsch raten, wenn es darum geht zu raten, was der Kunde als nächstes möchte und ob er was neues möchte. Die Verwirrung bei Dir ist dann an der Stelle entstanden, an der Du meine Antwort auf Rolfs Antwort auf meine Antwort auf Deinen Post für eine Antwort auf Deinen Post gehalten hast ;-) Deinen Code habe ich mir im Detail nicht angeguckt. Wenn ich mir das von Dir gezeigte Skelett angucken, dann würde ich an der Stelle auch eher von Wiederverwendung sprechen. Wenn die eigentliche Aufgabe war, 12 LEDs anhand eines analogen Eingangs anzusteuern und Du entwickelst darauf hin diese Port-Library, dann würde ich das als "über das Ziel hinaus" bezeichnen. Aber sicher ist es "schön" so eine Library zu haben, vor allem, wenn einem immer wieder ähnliche Anforderungen auf dem Tisch kommen. So eine Library entsteht aber in der Regel eher aus der Retroperspektive oder weil man einfach mal Lust hat, sich mit etwas interessantem zu beschäftigen.
Torsten R. schrieb: > Wenn die eigentliche Aufgabe war, 12 LEDs anhand eines analogen Eingangs > anzusteuern und Du entwickelst darauf hin diese Port-Library, dann würde > ich das als "über das Ziel hinaus" bezeichnen. Die Port-Abstraktion ist natürlich schon da, wie viele andere Dinge auch: ADC, Timer, Event-Routing, ... Was jetzt noch notwendig ist, ist das eigentliche Charly-Plexing. Dies kann man in Form der LUT machen, so wie im C-Code des VU-Meters. Und genau nur dort wollte ich ansetzen: die LUT kann zur Compilezeit eben aus der Anzahl der Ausgänge berechnet werden.
Moin, Wilhelm M. schrieb: > die LUT kann zur Compilezeit eben > aus der Anzahl der Ausgänge berechnet werden. Da wage ich zu widersprechen, denn die Bloedheit des Schaltplanzeichners und Layouters ist unberechenbar (wie man deutlich erkennen kann) ;-) Ansonsten keimt in mir so der leichte Zweifel, ob der Maechtigkeit von C++ und der vielfaeltigen Moeglichkeiten, die die Sprache bietet, dass wenn ich so eine Aufgabe an jeweils N C++ Programierer vergeben wuerde, ich mit mindestens N+1 grundverschiedenen Ansaetzen zu rechnen haette. Und ich fuerchte, dass wenn ich dann den Code vom Programmierer A nehme und ich den vom Programmierer B warten lassen will, der mir erzaehlt, das waere so voellig unmoeglich, er muesste erstmal alles umschreiben, weil das ja allen C++ Paradigmen/Dogmen die er kennt diametral entgegensteht. Da habe ich so ein bisschen die Hoffnung, das bei primitiveren Programmiersprachen es nicht gnaz so viele verschiedene Moeglichkeiten gibt, etwas so universell und generisch und dabei trotzem auf viele Arten zu programmieren. Gruss WK
Dergute W. schrieb: > Da wage ich zu widersprechen, denn die Bloedheit des Schaltplanzeichners > und Layouters ist unberechenbar (wie man deutlich erkennen kann) ;-) Die Reihenfolge der Ausgänge kannst Du in der Parameterliste frei wählen entsprechend Deinem Layout. Dergute W. schrieb: > Ansonsten keimt in mir so der leichte Zweifel, ob der Maechtigkeit von > C++ und der vielfaeltigen Moeglichkeiten, die die Sprache bietet, dass > wenn ich so eine Aufgabe an jeweils N C++ Programierer vergeben wuerde, > ich mit mindestens N+1 grundverschiedenen Ansaetzen zu rechnen haette. > Und ich fuerchte, dass wenn ich dann den Code vom Programmierer A nehme > und ich den vom Programmierer B warten lassen will, der mir erzaehlt, > das waere so voellig unmoeglich, er muesste erstmal alles umschreiben, > weil das ja allen C++ Paradigmen/Dogmen die er kennt diametral > entgegensteht. Das ist grundsätzliche immer so, auch bei C und verschiedenen Bibliotheken. So auch hier mit der Bibliothek und Konventionen, die ich oben benutzt habe. Man nehme nur mal die STM-HAL, für mich ist das ein Grauss, andere mögen es toll finden. > Da habe ich so ein bisschen die Hoffnung, das bei primitiveren > Programmiersprachen es nicht gnaz so viele verschiedene Moeglichkeiten > gibt, etwas so universell und generisch und dabei trotzem auf viele > Arten zu programmieren. Selbst in Assembler gibt es beliebig viele Bibliotheken, jede ist anders.
Wilhelm M. schrieb: > Dergute W. schrieb: >> Ansonsten keimt in mir so der leichte Zweifel, ob der Maechtigkeit von >> C++ und der vielfaeltigen Moeglichkeiten, die die Sprache bietet, dass >> wenn ich so eine Aufgabe an jeweils N C++ Programierer vergeben wuerde, >> ich mit mindestens N+1 grundverschiedenen Ansaetzen zu rechnen haette. >> ... > > Das ist grundsätzliche immer so, auch bei C und verschiedenen > Bibliotheken. Qualitativ ja, quantitativ gibt es aber Unterschiede: Gibt es in C für eine bestimmte Aufgabe n verschiedene Ansätze, werden es in C++ mindestens 10·n sein¹. Noch mehr Ansätze (grob geschätzt 100·n) gibt es – trotz des geringeren Sprachumfangs – nur noch in Assembler. Das liegt am Fehlen jeglicher Restriktionen, die den Programmierer bei der Wahl seines Ansatzes in eine bestimmte Richtung lenken könnten. ──────────── ¹) unter der Annahme, dass die Anzahl der möglichen Ansätze quadratisch mit dem Sprachumfang steigt und der Umfang des Standarddokuments als Maß für den Sprachumfang herangezogen werden kann
Yalu X. schrieb: > Gibt es in C für eine bestimmte Aufgabe n verschiedene Ansätze, werden > es in C++ mindestens 10·n sein¹. Das ist wohl auch eine philosophische Frage, fürchte ich. Sie akkumuliert in den Ideen hinter Perl und Python: während in Perl das TIMTOWDTI (there is more than one way to do it) angenommen wird, sagt das "Zen of Python" (PEP20): "There should be one-- and preferably only one --obvious way to do it." Auch in C und C++ gibt es meistens mehrere Wege, aber in der Regel ist in beiden Sprachen je einer für den Anwendungsfall am Besten geeignet. > Noch mehr Ansätze (grob geschätzt 100·n) gibt es – trotz des geringeren > Sprachumfangs – nur noch in Assembler. Naja... ich würde sagen, nicht trotz, sondern gerade deswegen.
Beitrag #7467907 wurde von einem Moderator gelöscht.
Beitrag #7467918 wurde von einem Moderator gelöscht.
Beitrag #7467925 wurde von einem Moderator gelöscht.
Beitrag #7467940 wurde von einem Moderator gelöscht.
Beitrag #7467942 wurde von einem Moderator gelöscht.
Beitrag #7467953 wurde von einem Moderator gelöscht.
Beitrag #7468067 wurde von einem Moderator gelöscht.
Beitrag #7468068 wurde von einem Moderator gelöscht.
Beitrag #7468082 wurde von einem Moderator gelöscht.
Beitrag #7468083 wurde von einem Moderator gelöscht.
Beitrag #7468088 wurde von einem Moderator gelöscht.
Beitrag #7468089 wurde von einem Moderator gelöscht.
Beitrag #7468096 wurde von einem Moderator gelöscht.
Beitrag #7468097 wurde von einem Moderator gelöscht.
Beitrag #7468103 wurde von einem Moderator gelöscht.
Beitrag #7468104 wurde von einem Moderator gelöscht.
Beitrag #7468312 wurde von einem Moderator gelöscht.
Beitrag #7468313 wurde von einem Moderator gelöscht.
Beitrag #7468315 wurde von einem Moderator gelöscht.
Beitrag #7468327 wurde von einem Moderator gelöscht.
Beitrag #7468328 wurde von einem Moderator gelöscht.
Wo sind die Löschmods, die rückstandsfrei löschen können? Kann doch nicht so schwer sein.
Beitrag #7468335 wurde von einem Moderator gelöscht.
Beitrag #7468336 wurde von einem Moderator gelöscht.
Beitrag #7468349 wurde von einem Moderator gelöscht.
Beitrag #7468350 wurde von einem Moderator gelöscht.
Beitrag #7468394 wurde von einem Moderator gelöscht.
Beitrag #7468396 wurde von einem Moderator gelöscht.
Beitrag #7468409 wurde von einem Moderator gelöscht.
Beitrag #7468411 wurde von einem Moderator gelöscht.
Beitrag #7468418 wurde vom Autor gelöscht.
Beitrag #7468434 wurde von einem Moderator gelöscht.
Beitrag #7468435 wurde von einem Moderator gelöscht.
Beitrag #7468456 wurde von einem Moderator gelöscht.
Beitrag #7468457 wurde von einem Moderator gelöscht.
Beitrag #7468479 wurde von einem Moderator gelöscht.
Beitrag #7468480 wurde von einem Moderator gelöscht.
Beitrag #7468624 wurde von einem Moderator gelöscht.
Beitrag #7468625 wurde von einem Moderator gelöscht.
Beitrag #7468626 wurde von einem Moderator gelöscht.
Beitrag #7468650 wurde von einem Moderator gelöscht.
Beitrag #7468652 wurde von einem Moderator gelöscht.
Beitrag #7468657 wurde von einem Moderator gelöscht.
Beitrag #7468750 wurde von einem Moderator gelöscht.
Beitrag #7468751 wurde von einem Moderator gelöscht.
Beitrag #7468823 wurde von einem Moderator gelöscht.
Beitrag #7468824 wurde von einem Moderator gelöscht.
Beitrag #7468835 wurde von einem Moderator gelöscht.
Beitrag #7468836 wurde von einem Moderator gelöscht.
Beitrag #7468859 wurde von einem Moderator gelöscht.
Beitrag #7468860 wurde von einem Moderator gelöscht.
Spess53 .. schrieb im Beitrag #7468626: > Don Quijote reitet wieder auf seiner Rosinante aus. Die Windmühlen > warten schon. Viel Spaß bei deinem sinnlosen Kampf gegen die > Riesen, den du eh verlierst. Das Lustige ist ja, daß dieser arme Mensch hier zwar einerseits unablässig von Effizienz faselt, andererseits aber gleichzeitig keine Mühen scheut, um... naja... den Benutzern des Forums allenfalls ein mitleidiges Lächeln und den Moderatoren ein paar müde Mausklicks abzuringen. ;-)
Beitrag #7468951 wurde von einem Moderator gelöscht.
Beitrag #7468952 wurde von einem Moderator gelöscht.
Beitrag #7468974 wurde von einem Moderator gelöscht.
Beitrag #7468975 wurde von einem Moderator gelöscht.
Beitrag #7468998 wurde von einem Moderator gelöscht.
Beitrag #7468999 wurde von einem Moderator gelöscht.
Beitrag #7469001 wurde von einem Moderator gelöscht.
Beitrag #7469036 wurde von einem Moderator gelöscht.
Beitrag #7469037 wurde von einem Moderator gelöscht.
Beitrag #7469092 wurde von einem Moderator gelöscht.
Beitrag #7469093 wurde von einem Moderator gelöscht.
Beitrag #7469097 wurde von einem Moderator gelöscht.
Ein T. schrieb: > den Benutzern des Forums allenfalls ein mitleidiges Lächeln > und den Moderatoren ein paar müde Mausklicks abzuringen. ;-) Erfolg hat er schon, weil entsprechende Threads irgendwann gesperrt werden.
Beitrag #7469115 wurde von einem Moderator gelöscht.
Beitrag #7469116 wurde von einem Moderator gelöscht.
Beitrag #7469120 wurde von einem Moderator gelöscht.
Beitrag #7469121 wurde von einem Moderator gelöscht.
Beitrag #7469128 wurde von einem Moderator gelöscht.
Beitrag #7469129 wurde von einem Moderator gelöscht.
Johann L. schrieb: > Ein T. schrieb: >> den Benutzern des Forums allenfalls ein mitleidiges Lächeln >> und den Moderatoren ein paar müde Mausklicks abzuringen. ;-) > > Erfolg hat er schon, weil entsprechende Threads irgendwann gesperrt > werden. Und weil, wahrscheinlich viele Leute, wie ich irgendwann einfach keinen Bock mehr haben, sich ihr EMail-Postfach mit Nachrichten voll-müllen zu lassen und dann aufhören, den Thread zu beobachten.
Torsten R. schrieb: > Und weil, wahrscheinlich viele Leute, wie ich irgendwann einfach keinen > Bock mehr haben, sich ihr EMail-Postfach mit Nachrichten voll-müllen zu > lassen und dann aufhören, den Thread zu beobachten. Zumindest hier im Forum würde es gut für die Darstellung, wenn da stehen würde "123 Beiträge wurden von Moderatoren gelöscht", anstatt jeden Beitrag einzeln aufzuzählen.
Torsten R. schrieb: > Und weil, wahrscheinlich viele Leute, wie ich irgendwann einfach keinen > Bock mehr haben, sich ihr EMail-Postfach mit Nachrichten voll-müllen zu > lassen und dann aufhören, den Thread zu beobachten. Tipp: Die "E-Mail-Benachrichtigungen für beobachtete Threads" abschalten. Wenn man hier mal wieder stöbern will, reicht auch ein Klick auf "Beobachtete Threads", um zu sehen, was es denn neues gibt. Man muss sich ja nicht durch jeden neuen Beitrag triggern lassen.
:
Bearbeitet durch Moderator
Johann L. schrieb: > Ein T. schrieb: >> den Benutzern des Forums allenfalls ein mitleidiges Lächeln >> und den Moderatoren ein paar müde Mausklicks abzuringen. ;-) > > Erfolg hat er schon, weil entsprechende Threads irgendwann gesperrt > werden. Das geschieht doch üblicherweise erst dann, wenn ohnehin nichts mehr im Thread los ist, insofern halte ich das nicht für einen großen Verlust -- und wenn dann mal wieder jemand über Hochsprachen reden will, macht die Betreffende statt Leichenfledderei eben einen neuen Thread auf, das hat doch auch etwas für sich. :-)
Johann L. schrieb: > Zumindest hier im Forum würde es gut für die Darstellung, wenn da stehen > würde "123 Beiträge wurden von Moderatoren gelöscht", anstatt jeden > Beitrag einzeln aufzuzählen. Halte ich auch für eine gute Idee -- es reduziert das "Erfolgserlebnis" dieses armen Menschen auf eine kleine Zahl und verbessert die UX für alle anderen Teilnehmer.
Beitrag #7469403 wurde von einem Moderator gelöscht.
Beitrag #7469404 wurde von einem Moderator gelöscht.
Beitrag #7469409 wurde von einem Moderator gelöscht.
Beitrag #7469410 wurde von einem Moderator gelöscht.
Beitrag #7469413 wurde von einem Moderator gelöscht.
Beitrag #7469414 wurde von einem Moderator gelöscht.
Beitrag #7469415 wurde von einem Moderator gelöscht.
Beitrag #7469416 wurde von einem Moderator gelöscht.
Beitrag #7469419 wurde von einem Moderator gelöscht.
Beitrag #7469420 wurde von einem Moderator gelöscht.
Beitrag #7469422 wurde von einem Moderator gelöscht.
Beitrag #7469423 wurde von einem Moderator gelöscht.
Beitrag #7469425 wurde von einem Moderator gelöscht.
Beitrag #7469426 wurde von einem Moderator gelöscht.
Beitrag #7469427 wurde von einem Moderator gelöscht.
Beitrag #7469428 wurde von einem Moderator gelöscht.
Beitrag #7469430 wurde von einem Moderator gelöscht.
Beitrag #7469431 wurde von einem Moderator gelöscht.
Beitrag #7469434 wurde von einem Moderator gelöscht.
Beitrag #7469435 wurde von einem Moderator gelöscht.
Beitrag #7469437 wurde von einem Moderator gelöscht.
Beitrag #7469438 wurde von einem Moderator gelöscht.
Beitrag #7469441 wurde von einem Moderator gelöscht.
Beitrag #7469442 wurde von einem Moderator gelöscht.
Beitrag #7469452 wurde von einem Moderator gelöscht.
Beitrag #7469454 wurde von einem Moderator gelöscht.
Beitrag #7469462 wurde von einem Moderator gelöscht.
Beitrag #7469463 wurde von einem Moderator gelöscht.
Beitrag #7469466 wurde von einem Moderator gelöscht.
Beitrag #7469467 wurde von einem Moderator gelöscht.
Beitrag #7469471 wurde von einem Moderator gelöscht.
Beitrag #7469472 wurde von einem Moderator gelöscht.
Beitrag #7469476 wurde von einem Moderator gelöscht.
Beitrag #7469477 wurde von einem Moderator gelöscht.
Beitrag #7469478 wurde von einem Moderator gelöscht.
Beitrag #7469479 wurde von einem Moderator gelöscht.
Beitrag #7469481 wurde von einem Moderator gelöscht.
Beitrag #7469482 wurde von einem Moderator gelöscht.
Beitrag #7469484 wurde von einem Moderator gelöscht.
Beitrag #7469485 wurde von einem Moderator gelöscht.
Beitrag #7469488 wurde von einem Moderator gelöscht.
Beitrag #7469489 wurde von einem Moderator gelöscht.
Beitrag #7469493 wurde von einem Moderator gelöscht.
Beitrag #7469494 wurde von einem Moderator gelöscht.
Beitrag #7469501 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten