Announcement: there is an English version of this forum on Ich habe ziemlich viel Erfahrung mit C und Assembler. Ich bin auch ein ganz passabler C++-Programmierer, inklusive der Standard Library. Im Unterschied zu vielen anderen Programmiersprachen braucht es für C++ wesentlich mehr, um die Philosophie zu kapieren. Deshalb gibt es auch eine grosse Anzahl Bücher für (sehr) Fortgeschrittene, z.B. "Effective C++". Nun denn, ich bin kein Experte, aber so langsam beginne ich die Philosophie zu verinnerlichen. Wo ich aber an meine Grenzen komme: Etwas hardwarenahes zu schreiben und trotzdem der C++-Philosphie treu zu bleiben. Ich suche deshalb nach Literatur zu Best Practices für hardwarenahes C++. So etwas im Stil von "Effective C++" für Leute, die hardwarenah oder mit C-Interfaces arbeiten müssen. Habe heute bereits auf Stackoverflow eine ähnliche Frage gestellt, mir scheint aber, die Leute dort sind zu wenig auf Mikrocontroller u.ä. unterwegs. Deshalb habe ich noch eine gewisse Hoffnung hier. (Und, bevor hier Trivialitäten kommen: Ich kriege in C++ auch hardwarenahes das meiste problemlos hin, mir geht es eher darum, gute Designkonzepte kennen zu lernen.)
cplusplusser schrieb: > der C++-Philosphie Sowas gibt es? Wäre mir neu. C++ ist ein absolutes Kuddelmuddel, eine wirre Anreihung an Sprachfeatures ohne erkennbares Konzept dahinter. Es gibt nicht "den" C++-Stil. Bei Microcontrollern sollte man IMHO minimalistisches C++ verwenden. Ein bisschen Templates, Klassen, Überladung & co? Kein Ding. STL? Vorsichtig. Boost u.ä.? Wenn man zu viel Flash und RAM hat. Davon abgesehen ist alles Geschmackssache.
Hatte mich eine gewisse Zeit mit C++ beschäftigt. Habe es dann jedoch nicht weiter verfolgt. Denn für mich war C++ nicht besser, als C; eher schlechter. So richtig an der Hardware ist man bei C++ nicht wirklich. Muss noch hinzufügen, dass ich immer nur auf der Hardwareebene programmiert habe. Also keine bunten Klicki-Micki-Sachen auf den Bildschirm gezaubert habe. Dort macht es mit Sicherheit mehr Sinn C++ oder C# einzusetzen. Das ist meine Erfahrung zu C++ und Hardware nahes programmieren.
> So richtig an der Hardware ist man bei C++ nicht wirklich.
Das ist leeres Geschwätz. Kann man leicht merken, da du nicht konkret
wirst.
Schau dir mal Real-Time C++ Efficient Object-Oriented and Template Microcontroller Programming von Chris Kormanyos Das Buch hat mir die Augen geöffnet was C++ auf uCs angeht. Geht sehr detailliert auf alle möglichen Sprachkonstrukte von C++11 ein unter dem Gesichtspunkt Mikrocontroller. Immer im Blick dabei die Laufzeit und die Speicherplatzkosten. Gelegentlich wird an einem Atmega ein Beispiel gezeigt, aber der großteil ist sehr allgemein gehalten. Gibt auch viele Hinweise zum Speichermanagement in uCs und wie man dann halt die STL doch noch effizient verwenden kann. Insbesondere werden viele Templates verwendet. Dadurch das alle Informationen zur Compilezeit bekannt sind, kann sehr kompakter Code erzeugt werden.
OldMan schrieb: > Denn für mich war C++ nicht besser, als C Hinter C++ steckt eben mehr als hinter C. In der Embedded-Welt schafft man fast alles mit C. Klassen nimmt man vielleicht als praktisches Hilfsmittel zur Strukturierung wahr. In Tat und Wahrheit steckt aber sehr viel mehr hinter C++, da es viel mehr Abstraktion bietet. Für den Programmierer aus der E-Technik-Ecke sind abstrakte Software-Konzepte aber wenig gewohnt, weshalb C++ hier nicht so beliebt ist. Sobald ein Programm aber wirklich extrem komplex wird, beginnt man intensiver über solche Abstraktionen nachzudenken. Ich spreche hier von Programmen wie z.B. Compilerframeworks, GUI-Libraries, Multiphysik-Simulationen, Game-Engines, usw.
P. M. schrieb: > In der Embedded-Welt schafft > man fast alles mit C. Da gebe ich Dir recht, auch in Bezug auf P. M. schrieb: > Sobald ein > Programm aber wirklich extrem komplex wird, beginnt man intensiver über > solche Abstraktionen nachzudenken. Ich spreche hier von Programmen wie > z.B. Compilerframeworks, GUI-Libraries, Multiphysik-Simulationen, > Game-Engines, usw. volle Zustimmung. Hatte ich auch so geschrieben: OldMan schrieb: > Also keine bunten Klicki-Micki-Sachen auf den > Bildschirm gezaubert habe. Dort macht es mit Sicherheit mehr Sinn C++ > oder C# einzusetzen. Auch wenn es etwas lax formuliert war ;-)
kopfkratz Ja wo ist denn nun das Problem ? Objektorientiert zu programmieren bedeutet eine passende Schnittstelle mit z.B. Setter/Getter zu implementieren und den Rest so zu kapseln das man ohne Probleme davon erben kann und es immer noch geht. Es gibt nicht den "absoluten" Stil, jeder wie er es am besten kann/versteht. Wenn genügend Ressourcen zur Verfügung stehen kann man auch z.B. Operatoren überladen oder einen Vector aus der STL nehmen. Es kommt hat immer darauf an was man kann und haben will. Bei z.B. einem Atmel Tiny11 macht C++ keinen wirklichen Sinn, bei einem ARM schon eher. Also erstmal den µC betrachten, dann dessen Ressourcen evaluieren und danach entscheiden ob C oder C++ oder doch lieber Assembler. Und was spricht dagegen vorhandenen C Source der "hardwarenah" ist zu kapseln ?
> Objektorientiert zu programmieren bedeutet eine passende > Schnittstelle mit z.B. Setter/Getter zu implementieren > und den Rest so zu kapseln das man ohne Probleme davon > erben kann und es immer noch geht. Da bin ich aber ganz anderer Meinung. Objektorientiert programmieren bedeutet für mich, dass Daten und zugehöriger Code zusammenhängend strukturiert werden. Das kann man auch in C tun. C++ unterstützt objektorientierte Programmierung.
kopfkratzer schrieb: > Objektorientiert zu programmieren bedeutet eine passende Schnittstelle > mit z.B. Setter/Getter zu implementieren und den Rest so zu kapseln das > man ohne Probleme davon erben kann und es immer noch geht. Dann wundert mich nicht, dass du das Problem nicht verstehst... C++ ist weit, weit, weit mehr als nur kapseln und vererben... Wenn es Richtung Hardware geht, dann beginnen sich die Abstraktionsfeatures langsam mit der expliziten Kontrolle und Performance zu beissen. Da möchte ich eben mehr wissen. Und hier spricht auch niemand von einem kleinen Roboter mit einem Atmega, sondern von wirklich komplexen Softwares, die gleichzeitig die Hardware extrem ausreizen müssen.
Viele Arduino Bibliotheken sind in C++ geschrieben. Beispiel: https://code.google.com/p/xbee-arduino/source/browse/XBee.cpp
ARDuino schrieb: > Viele Arduino Bibliotheken sind in C++ geschrieben. Da sprichst Du zwei Worte an, dessen Verständnis viele allgemein in C++ und Arduino (eines der Worte) hinein interpretieren. Die meisten denken immer an verkapselte und überfrachtete Bibliotheken und viel Overhead. Das kann man nutzen, muss man aber nicht.
cplusplusser schrieb: > Ich suche deshalb nach > Literatur zu Best Practices für hardwarenahes C++. Du suchst, weil es hardwarenahes C++ nicht gibt. Richtig hardwarenah ist und bleibt nur Assembler. Pure 1:1 Funktionalität ohne zusätzliches Palaver.
cplusplusser schrieb: > weit, weit, weit mehr als nur kapseln und vererben... Wenn es Richtung > Hardware geht, dann beginnen sich die Abstraktionsfeatures langsam mit > der expliziten Kontrolle und Performance zu beissen. Da möchte ich eben > mehr wissen. Entweder oder. Beides zusammen wird wohl kaum gehen. Was man früher in DOS machen könnte geht mit Windows oder Linux eben nicht mehr. Hardwarebezogene Libraries wären vielleicht eine Möglichkeit, aber die müsste man sich selbst erstellen und das kann man auch in C. C++ bedeutet enormes Overhead an code und genau das will man bei uC nicht. Und wenn man nicht Kernel oder Embedded benutzt, was soll dann C++ mehr bieten ? Warum uberhaupt bei uC benutzen ? Scelumbro schrieb: > Speicherplatzkosten. Gelegentlich wird an einem Atmega ein Beispiel > gezeigt, aber der großteil ist sehr allgemein gehalten. Vielleicht ist C++ für ARM geeignet, aber bestimmt nicht für ATMEGA oder so. Wer die wirklichen Vorteile von C++ nutzen will, hat in der uC-Welt nichts verloren. Du willst doch nicht im Ernst behaupten, dass du weisst, was diese Zeile genau macht, wieviel Code, Speicher, Stack usw. gebraucht wird:
1 | public int getDigitalLsb(int sample) { |
2 | return this.getProcessedPacketBytes()[this.getStartIndex() + 3 + this.getSampleWidth() * sample + 1]; |
3 | }
|
> Insbesondere werden viele Templates verwendet. Dadurch das alle > Informationen zur Compilezeit bekannt sind, kann sehr kompakter Code > erzeugt werden. Der in plain C noch kompakter wäre, von Assembler gar nicht zu reden. cplusplusser schrieb: > Und hier spricht auch niemand von einem kleinen Roboter mit > einem Atmega, sondern von wirklich komplexen Softwares, die gleichzeitig > die Hardware extrem ausreizen müssen. Und dann gleich in C++ ? Ein Beispiel, bitte.
Marc Vesely schrieb: > C++ bedeutet enormes Overhead an code Wenn man C++ nicht verstanden hat. Sonst stimmt das einfach nicht.
Habe meine Wortuhr-Software mit C++ programmiert. Braucht nur gut 6KB wo andere einen ganzen Atmega32 komplett ausfüllen. Ich benutze ausgiebig Templates, um Konstanten durchzureichen, und verlasse mich auf den Inliner vom GCC. Funktioniert prächtig.
Marc Vesely schrieb: > Du willst doch nicht im Ernst behaupten, dass du weisst, was diese > Zeile genau macht, wieviel Code, Speicher, Stack usw. gebraucht wird: Genau das will ich ja lernen! Genau darum dreht sich die Frage! Ich will wissen, wie ich Code auf einer hohen Abstraktionsebene beschreiben kann/soll, der dann auch auf der untersten Ebene effizient umgesetzt werden kann.
Marc Vesely schrieb: > Du willst doch nicht im Ernst behaupten, dass du weisst, was diese > Zeile genau macht, wieviel Code, Speicher, Stack usw. gebraucht wird: >
1 | > public int getDigitalLsb(int sample) { |
2 | > return this.getProcessedPacketBytes()[this.getStartIndex() + 3 + |
3 | > this.getSampleWidth() * sample + 1]; |
4 | > } |
5 | >
|
Ich seh an dieser Stelle nichts, was jetzt irgendwie speziell C++ wäre, ausser ein paar syntaktischen Dingen. Diese Codestelle würde in C auch nicht grossartig anders aussehen. > Wer die wirklichen Vorteile von C++ nutzen will, hat > in der uC-Welt nichts verloren. Auf kleinen µC kann man einige Dinge nicht wirklich ausreizen. Zustimmung. Aber es ist nicht so, dass man überhaupt nichts von C++ zu seinem Vorteil benutzen kann.
:
Bearbeitet durch User
Marc Vesely schrieb: > Und dann gleich in C++ ? > Ein Beispiel, bitte. Wie geschrieben wurde: GUI-Library, Multiphysik-Simulation, Compiler, Mathe-Library, Game Engine, usw. Marc Vesely schrieb: > Der in plain C noch kompakter wäre, von Assembler gar nicht zu reden. Eben nicht. Ein guter Compiler kann je nach Bedürfnis in die eine oder andere Richtung optimieren. Das kann man bei einem Assemblerprogramm schlecht nachträglich. Je höher das Abstraktionslevel ist, desto mehr Möglichkeiten für Optimierung hat der Compiler. Und mal ganz ehrlich: Was man mit mit Templates in wenigen Zeilen erledigt, dafür sitzt du eine ganze Woche vor deinem Assembler-Programm.
cplusplusser schrieb: > Marc Vesely schrieb: >> Und dann gleich in C++ ? >> Ein Beispiel, bitte. > > Wie geschrieben wurde: GUI-Library, Multiphysik-Simulation, Compiler, > Mathe-Library, Game Engine, usw. Geht auch noch banaler. Eine simple Kommunikationsbasisklasse mit Ausgabeoperationen wie zb print. Davon hergeleitet dann zb eine Klasse für LCD oder UART. Und schon kann man ein Programm recht einfach von UART auf LCD, zumindest in den Basisdingen umstellen. Oder auch SPI oder I2C. Die Arduino Leute ziehen das gar nicht schlecht auf. Das einzige 'Problem' sind die weit unten sitzenden Funktionalitäten für digitalWrite und digitalRead. Da die einen Haufen Sonderfälle berücksichtigen, sind sie relativ langsam. Da müsste man sich ein anderes Konzept überlegen, wie man den einzelnen Klassen die zu benutzenden Pins unterjubeln kann, ohne dem Compiler die Optimierungsmöglichkeiten zu nehmen.
:
Bearbeitet durch User
Wenn man auf hoher Abstraktionsebene arbeitet, dann hat das einen gewissen Overhead. Das liegt in der Natur der Sache. Die Programmiersprache kann höchstens versuchen, den Overhead auf ein Minimum zu reduzieren. C++ bekommt das sogar halbwegs gut hin. Das gilt nicht nur für C++, auch in C kann man auf hoher Abstraktionsebene arbeiten und hat ähnlichen Overhead. Die HAL für den STM32 ist ein Beispiel dafür.
C++ bietet gegenüber c viele Vorteile, ohne dabei mehr Speicher zu verbrauchen. So können beispielsweise Templates genutzt werden, um komplexe berechnungen zur compiletime zu erledigen. Trotzdem gibt es auch für den uc ungeeignete Dinge, wie z.B. std::vector. Wenn man da mal vergisst, die Exceptions abzufangen wenn der Speicher ausgeht (, was natürlich auch verhindert werden könnte, wenn dessen grösse bekannt und konstant ist ), kann man ewig nach dem fehler suchen. Grundsätzlich gibt es keinen echten grund gegen c++ auf dem uc, aber aufgrund der Art und Weise, wie exeptions in c++ umgesetzt wurden, bevorzuge ich c. Den ganzen rest an C++ finde ich genial umgesetzt.
Karl Heinz schrieb: > Ich seh an dieser Stelle nichts, was jetzt irgendwie speziell C++ wäre, > ausser ein paar syntaktischen Dingen. Diese Codestelle würde in C auch > nicht grossartig anders aussehen. Der daraus entstehende Code aber schon. Allein durch die VTABLES gibts in C++ bei fast allen Funktionsaufrufen eine Indirektion mehr. Mag sein dass der Compiler das in speziellen (einfachen) Fällen erkennt und wegoptomiert, darauf verlassen würde ich mich aber nicht. Allgemein: Computer arbeiten in Ihrenm Kern nun mal prozedural (von totalen Exoten mal abgesehen). Wenn man auf die tiefste Ebene der Softwareentwicklung abzielt ist eine nicht-prozedurale Sprache daher grundsätzlich im Weg. D.h. Es wird immer ein Eckerl im Code übrigbleiben das klassisch prozedural erledigt werden muss, oder die "höhere Philisophie" der Sprache muss verletzt werden. In C++ ist das der unvermeidliche der Einsatz globaler Variablen (SFRs, TIMER usw).
Daniel A. schrieb: > Grundsätzlich gibt > es keinen echten grund gegen c++ auf dem uc, aber aufgrund der Art und > Weise, wie exeptions in c++ umgesetzt wurden, bevorzuge ich c. Den > ganzen rest an C++ finde ich genial umgesetzt. Du musst doch keine Exceptions verwenden. Eine Menge C++-Software verzichtet komplett auf Exceptions, nicht nur auf Mikrocontrollern.
Hallo allerseits, ich verstehe die heftige Ablehnung von C++ nicht. Mit C++ sind die gleichen Sachen genauso möglich wie in C. Dazu habe ich eine Masse an Features, die mir Arbeit abnehmen können, WENN ich sie beherrsche! Sonst lass ich davon die Finger. LKW-Motor und Rennsport vertragen sich auch nicht gut trotz der PS, muss man halt vorher wissen. Wer des Englischen mächtig ist, hat hier eine Quelle vom Entwickler von C++ http://www.stroustrup.com/bs_faq.html#C-is-better Gruß Felix
gnuopfer schrieb: > Karl Heinz schrieb: Allein durch die VTABLES gibts > in C++ bei fast allen Funktionsaufrufen eine Indirektion mehr. Die gibt es aber nur, wenn man Polymorphismus und virtuelle Methoden verwendet. Will man etwas vergleichbares in C haben, muss man es von Hand nachprogrammieren, was wahrscheinlich nicht viel effizienter wird.
FelixW schrieb: > ich verstehe die heftige Ablehnung von C++ nicht. > Mit C++ sind die gleichen Sachen genauso möglich wie in C. Die Ablehnung ist eigentlich einfach zu verstehen: C++ ist eine überkomplexe Sprache mit zahlreichen Fallstricken und Problemen. Kann man C++ sinnvoll einsetzen? Ja. Aber es ist oft sehr schwierig. Gerade wenn man mehrere Entwickler mit unterschiedlichem Kenntnisstand unter einen Hut bringen möchte. Viele Konzepte aus dem OOP-Bereich lassen sich darüber hinaus sinnvoll mit C umsetzen. (z.B. Polymorphie, Klassen, Information Hiding)
Stefan us schrieb: >> Objektorientiert zu programmieren bedeutet eine passende >> Schnittstelle mit z.B. Setter/Getter zu implementieren >> und den Rest so zu kapseln das man ohne Probleme davon >> erben kann und es immer noch geht. > > Da bin ich aber ganz anderer Meinung. Objektorientiert programmieren > bedeutet für mich, dass Daten und zugehöriger Code zusammenhängend > strukturiert werden. Das kann man auch in C tun. > > C++ unterstützt objektorientierte Programmierung. Ach Leuts man kann sogar in Assembler "strukturiert" programmieren ... Nur wird's dann bei Vererbung und Kapselung etwas "kritischer" ... Ob ich nun
1 | void setLED() |
in C implemetiere oder eine ganze Klasse mit
1 | class mycontroller |
2 | {
|
3 | ...
|
4 | public void setLED() |
5 | ...
|
6 | }
|
baue bleibt sich erstmal gleich. Nur wenn ich dann das Programm erweitern will ...
cplusplusser schrieb: > Möglichkeiten für Optimierung hat der Compiler. Und mal ganz ehrlich: > Was man mit mit Templates in wenigen Zeilen erledigt, dafür sitzt du > eine ganze Woche vor deinem Assembler-Programm. Stimmt. Aber das ist es eben, was ich versuche, klarzumachen. Wenige Zeilen, ja. Aber vielleicht 2KB Code und 1ms Ausführungszeit. Weiss man ja nie genau. Und wenn ich jedesmal durch generierten Code gehen muss, um zu sehen, was da aus wenigen Zeilen geworden ist... Im Assembler ist eine Zeile immer eine Zeile.
:
Bearbeitet durch User
gnuopfer schrieb: > Karl Heinz schrieb: >> Ich seh an dieser Stelle nichts, was jetzt irgendwie speziell C++ wäre, >> ausser ein paar syntaktischen Dingen. Diese Codestelle würde in C auch >> nicht grossartig anders aussehen. > > Der daraus entstehende Code aber schon. Bei dem Code Snippet? Unwahrscheinlich. > Allein durch die VTABLES gibts > in C++ bei fast allen Funktionsaufrufen eine Indirektion mehr. So ein Quatsch. Nur dann, wenn ich Polymorphie auch tatsächlich benutze, geht der Call indirekt. Aber das hab ich in C auch, wenn ich Polymorphie durch Funktionspointer nachbilde. Benutze ich keine polymorphen Zeiger, dann kostet mich auch ein Funktionsaufruf nichts zusätzlich. Selbst dann nicht, wenn die Funktion an und für sich virtuell ist. Denn der Compiler kennt dann ja den Runtime-Type und kann die Funktion direkt aufrufen. Das eine 'Optimierung' zu nennen ist schon fast eine Frechheit, verglichen mit dem was C++ Compiler sonst noch so alles an Optimierungen drauf haben. Das ist trivial und keine Optimierung. Ein
1 | LCD myLCD; |
2 | |
3 | myLCD.write( "Hallo World" ); |
ist genauso effizient wie die Entsprechung in C. Selbst dann wenn LCD von einer Klasse Characterdevice hergeleitet ist und der Member write virtual ist.
:
Bearbeitet durch User
Marc Vesely schrieb: > cplusplusser schrieb: >> Möglichkeiten für Optimierung hat der Compiler. Und mal ganz ehrlich: >> Was man mit mit Templates in wenigen Zeilen erledigt, dafür sitzt du >> eine ganze Woche vor deinem Assembler-Programm. > > Stimmt. > Aber das ist es eben, was ich versuche, klarzumachen. > Wenige Zeilen, ja. Aber vielleicht 2KB Code und > 1ms Ausführungszeit. Eben nicht. Das versuchen dir die Leute klar zu machen. Dieses Märchen ist und bleibt ein Märchen. Ganz im Gegenteil ist es oft so, dass C++ Compiler kleineren Code generieren, als ein entsprechender C Compiler aus einem funktional gleichwertigem C Code machen kann. OK, es reisst sich nicht viel und genau so oft sind die beiden gleich auf. Aber signifikant schlechteren Code generiert ein C++ Compiler nur höchst selten.
:
Bearbeitet durch User
Karl Heinz schrieb: > Ganz im Gegenteil ist es oft so, dass C++ Compiler kleineren Code > generieren, als ein entsprechender C Compiler aus einem funktional Ja, bei normalem Code. Karl Heinz schrieb: > genau so oft sind die beiden gleich auf. Aber signifikant schlechteren > Code generiert ein C++ Compiler nur höchst selten. Mag sein, dass der C++ sogar effizienteren und kleineren Code erzeugt als C, aber nur da, wo seine Stärken eben nicht voll genutzt werden. Sobald man die wirklichen Vorteile von C++ in der uC-Welt ausnutzen will, ist es damit vorbei. Nichts gegen C++ aber es ist ein bisschen wie "Mit Kanonen auf Spatzen schiessen". Es gibt nur sehr wenig, was der C++ kann und normales C nicht. Und das, was der C++ kann und normales C nicht, kostet Code und Rechenzeit. Beides ist bei uC (immer noch) kostbar. In Windows ja, aber für Mikrocontroller ?
Die ganze Diskussion C/C++ auf Mikrocontroller destilliert zu:
Was der Bauer nicht kennt, frisst er nicht.
Das oben genannte Büchlein ist ganz nett, ganz gut für den Einstieg
geeignet, wenn man nicht so recht weiß, wie man C++-Features auf
Mikrocontrollern sinnvoll einsetzen kann.
Hi, Scelumbro schrieb: > Schau dir mal > Real-Time C++ Efficient Object-Oriented and Template > Microcontroller Programming > von Chris Kormanyos von http://www.springer.com/computer/communication+networks/book/978-3-642-34687-3: "The C++ language has powerful object-oriented and template features that can improve software design and portability while simultaneously reducing code complexity and the risk of error. Furthermore, C++ compiles highly efficient native code. This unique and effective combination makes C++ well-suited for programming microcontroller systems that require compact size, high performance and safety-critical reliability." Was gib es da noch groß zu diskutieren! Im Übrigen macht's doch eh jeder so, wie er's am besten kann. gnuopfer schrieb: > Wenn man auf die tiefste Ebene der Softwareentwicklung > abzielt ist eine nicht-prozedurale Sprache daher grundsätzlich im Weg. Wo ist denn C++ nicht-prozedural? Grüße, Markus
Marc Vesely schrieb: > public int getDigitalLsb(int sample) { > return this.getProcessedPacketBytes()[this.getStartIndex() + 3 + > this.getSampleWidth() * sample + 1]; > } kopfkratzer schrieb: > class mycontroller > { > ... > public void setLED() > ... > } Warum wird hier Java-code geposted, wenn es um c++ geht? In c++ müsste es so aussehen (, zumindest wenn public und this keine makros sind):
1 | public:
|
2 | inline int getDigitalLsb(const int sample) { |
3 | return this->getProcessedPacketBytes()[this->getStartIndex() + 3 + this->getSampleWidth() * sample + 1]; |
4 | }
|
1 | class mycontroller { |
2 | public:
|
3 | void setLED(); |
4 | }
|
Markus schrieb: > Was gib es da noch groß zu diskutieren! Über Wunschvorstellungen des Marketings? Nö danke, da hab ich in Asm mit 'sbi PortA,0' mein Portbit viel einfacher und schneller gesetzt als mich erst durch komplexe Anweisungssyntax-Programmierpower zu quälen. Und von 'reducing software-complexity' kann da doch schon mal gleich gar nicht die Rede sein. Wer das noch als 'well-suited for programming microcontroller' empfindet, na ja ...
Was für eine sinnlose Diskussion. Aber zumindest wissen wir alle dass der Fragesteller ziemlich viel Erfahrung in C und Assembler hat und auch ein ganz passabler C++ Programmierer ist. Wer so seine eigne Frage eröffnet dem gebührt wirklich voller und uneingeschränkter Respekt.
Markus schrieb: > Was gib es da noch groß zu diskutieren! Vielleicht darüber wie naiv man sein muss, um alles zu glauben, was einem so vorgesetzt wird ?
tictactoe schrieb: > Habe meine Wortuhr-Software mit C++ programmiert. Braucht nur gut 6KB wo > andere einen ganzen Atmega32 komplett ausfüllen. Der Unterschied hat aber überhaupt nichts mit C++ zu tun. Man kann beliebig schlecht programmieren, da gibt es keine untere Grenze. Und Uhren werden ja gerne als Einsteigerprojekt mit 0 Programmiererfahrung genommen. Das Code-Wasting liegt oft nur an undurchdachten copy&paste Monstern. Wer sich vorher keinen Ablaufplan erstellt, braucht automatisch ein Vielfaches an Code. Für eine Uhr würde ich in C auf dem AVR etwa 2kB Flash als dicke ausreichend ansehen. Und auf nem ARM dürften 8kB genug sein.
Markus schrieb: > gnuopfer schrieb: >> Wenn man auf die tiefste Ebene der Softwareentwicklung >> abzielt ist eine nicht-prozedurale Sprache daher grundsätzlich im Weg. > > Wo ist denn C++ nicht-prozedural? Überall dort wo Leute in "Objektoritierter Philosophie" entwicklen wollen. Wenn ich im kompatiblen C-subset von C++ schreibe und das dann mit einem C++ Compiler übersetzte wird ja kein C++ draus.
Ich programmiere privat gerne in C++, Mikrocontroller habe ich jedoch bislang nur in Assembler und C programmiert. Aber es ist nur eine Frage der Zeit, bis auch mal C++ auf einem ATtiny ausprobiere. Soll ja gehen. Auch ich bin der Meinung, dass C++ einige Fallstricke mit sich bringt. Aber tut das nicht Programmiersprache, sobald sie erwachsen ist? Selbst Java ist nicht frei von gemeinen Anfängerfallen. Apropos Java: Gibt es eigentlich einen Java Compiler, der Maschinencode erzeugt (also ohne VM auskommt)? Das wäre vielleicht eine Alternative für die Leute, denen C++ zu kompliziert ist.
Also jetzt möchte ich auch mal meinen Senf dazu geben. Wenn man wirklich effizient programmieren muss und es auf jedes NOP ankommt, dann bleibt doch gar nichts übrig als sich den Assemblercode anzuschauen. Entweder den, den man selbst geschrieben hat, oder den, den der Compiler verbrochen hat. Ob der das jetzt von C, C++ oder sonstwoher übersetzt hat. Allein schon ein Funktionsaufruf in C verursacht ein Haufen PUSH und POP bei dem ich mir manchmal denke: "Das hättest du (Compiler) dir sparen können. Kann ich dir das irgendwie beibringen, dass du nur R0 und R1 verwendest und R2..R15 in Ruhe lässt..?" Einfach mal ausprobieren. Da der TO offensichtlich Assembler "spricht" ist das doch eine einfache Übung. Mal so richtig mit C++ ranklotzen und schauen was der Compiler übersetzt. Dann merkst du schnell, ob das das ist was du möchtest, oder ob Klimmzüge gemacht werden (müssen), die du gar nicht willst.
stefanus schrieb: > Apropos Java: Gibt es eigentlich einen Java Compiler, der Maschinencode > erzeugt (also ohne VM auskommt)? Das wäre vielleicht eine Alternative > für die Leute, denen C++ zu kompliziert ist. z.B. den gcj, der bei der GCC dabei ist. Könnte sich vielleicht sogar mit dem AVR-Backend koppeln lassen? Fehlt halt die gesamte Lib / Classpath aussenrum. Problem: C++ kann man ganz ohne dynamische Speicherverwaltung nutzen. Also ohne malloc/free/new/delete. Muss halt auf einige Sprachkonstrukte verzichten. Bei Java ist das denke ich sprachbedingt garnicht möglich. Objekte müssen immer auf den Heap, und können nicht am Stack angelegt werden.
:
Bearbeitet durch User
Daniel V. schrieb: > Einfach mal ausprobieren. Da der TO offensichtlich Assembler "spricht" > ist das doch eine einfache Übung. Mal so richtig mit C++ ranklotzen und > schauen was der Compiler übersetzt. Darum gehts eigentlich gar nicht. In meinem Fall ist es eher so, dass ich ein grosses Framework auf hoher Abstraktionsebene habe. Sowas schreibt kein Mensch in Assembler. Gleichzeitig muss gewährleistet sein, dass es auf Maschinenebene extrem performant ausgeführt wird. Und hier kann man nicht einfach kritische Code-Abschnitte direkt in Assembler schreiben. Es muss z.B. darauf geachtet werden, dass höher abstrahierte Datentypen so aufgebaut werden, dass sie maschineneffizient umgesetzt werden, z.B. Stichworte sind Alignment, Bitoperationen, Call by Value/Reference, Move-Operationen, usw.
cplusplusser schrieb: > Daniel V. schrieb: >> Einfach mal ausprobieren. Da der TO offensichtlich Assembler "spricht" >> ist das doch eine einfache Übung. Mal so richtig mit C++ ranklotzen und >> schauen was der Compiler übersetzt. > > Darum gehts eigentlich gar nicht. In meinem Fall ist es eher so, dass > ich ein grosses Framework auf hoher Abstraktionsebene habe. Sowas > schreibt kein Mensch in Assembler. Gleichzeitig muss gewährleistet sein, > dass es auf Maschinenebene extrem performant ausgeführt wird. Und hier > kann man nicht einfach kritische Code-Abschnitte direkt in Assembler > schreiben. Es muss z.B. darauf geachtet werden, dass höher abstrahierte > Datentypen so aufgebaut werden, dass sie maschineneffizient umgesetzt > werden, z.B. Stichworte sind Alignment, Bitoperationen, Call by > Value/Reference, Move-Operationen, usw. Ich habe ja nicht gesagt, dass kritische Codeabschnitte seblst geschrieben werden sollen. Aber man kann doch mal nachschauen, was der Compiler draus gemacht hat. Und wenn man selbst Assembler "spricht", dann kann man auch noch beurteilen, ob der Code so wie er ist "effizient" ist. Wenn ja, dann ist gut. Wenn nein, dann kann man sich mal damit befassen, warum der Compiler das nicht entsprechend übersetzt hat und wie man ihn dazu bekommt, etwas effizienteres zu übersetzen.
:
Bearbeitet durch User
gnuopfer schrieb: > Wenn ich im kompatiblen C-subset von C++ schreibe und das dann mit einem > C++ Compiler übersetzte wird ja kein C++ draus. LOL. Genau. Wenn ich C++ voll ausnutze, ist ein MEGA schnell überfördert und ich als Programmierer habe auch nicht die leiseste Ahnung wie die Dinge wirklich ablaufen und wieviel Zeit das Ganze braucht. Beim Windows interessiert mich das wenig, bei uC aber sehr viel. Frage an Radio Eriwan: Kann ich meinen Acker auch mit BMW X3 pflügen ? Im Prinzip ja, aber...
Marc Vesely schrieb: > Wenn ich C++ voll ausnutze, ist ein MEGA schnell überfördert und ich > als Programmierer habe auch nicht die leiseste Ahnung wie die Dinge > wirklich ablaufen und wieviel Zeit das Ganze braucht. Wenn ich C voll ausnutze, ist ein MEGA schnell überfördert und ich als Programmierer habe auch nicht die leiseste Ahnung wie die Dinge wirklich ablaufen und wieviel Zeit das Ganze braucht. Wenn ich ASM voll ausnutze, ist ein MEGA schnell überfördert und ich als Programmierer kann zwar kleine Abschnitte im Detail nachvollziehen, habe aber keine Ahnung wie das Große Ganze wirklich abläuft und wieviel Zeit das Ganze braucht. Ganz einfach: Für einen Schlechten Programmierer ist die Wahl der Programmiersprache egal. Er wird in jeder Müll produzieren. Für einen Guten Programmierer ist die Wahl der Programmiersprache egal. Er versteht die zur Verfügung stehenden Sprachkonstrukte und kann selbständig auswählen, welche Hochsprachen-Features evtl. auf einem kleinen AVR keinen Sinn machen, und diese einfach meiden. Wenn jemand Angst hast, mit C++ überfordert zu sein: Finger weg oder Reinknieen und Lernen.
Marc Vesely schrieb: > gnuopfer schrieb: >> Wenn ich im kompatiblen C-subset von C++ schreibe und das dann mit einem >> C++ Compiler übersetzte wird ja kein C++ draus. > > LOL. > Genau. > Wenn ich C++ voll ausnutze, ist ein MEGA schnell überfördert und ich > als Programmierer habe auch nicht die leiseste Ahnung wie die Dinge > wirklich ablaufen und wieviel Zeit das Ganze braucht. > Beim Windows interessiert mich das wenig, bei uC aber sehr viel. > Jetzt weiß ich warum viele Programme unter Windows manchmal "hängen". Weils dem Programmierer egal war...
Εrnst B✶ schrieb: > Für einen Schlechten Programmierer ist die Wahl der Programmiersprache > egal. Er wird in jeder Müll produzieren. Sage ich doch. Εrnst B✶ schrieb: > Er versteht die zur Verfügung stehenden Sprachkonstrukte und kann > selbständig auswählen, welche Hochsprachen-Features evtl. auf einem > kleinen AVR keinen Sinn machen, und diese einfach meiden. Sage ich doch.
Marc Vesely schrieb: > Wenn ich C++ voll ausnutze, ist ein MEGA schnell überfördert und ich > als Programmierer habe auch nicht die leiseste Ahnung wie die Dinge > wirklich ablaufen und wieviel Zeit das Ganze braucht. Das stimmt eigentlich nicht. Templates beispielsweise kann man voll ausreizen. Auch die Standard Library gilt eigentlich als sehr effizient, da dort viel mehr Grips und Architektur-Anpassungen reingesteckt wurde, als es ein einzelner Programmierer jemals könnte. Vererbungshierarchien kann ein Compiler ebenfalls problemlos optimieren. Einzig bei virtueller Vererbung sollte man vorsichtig sein. Kann sein dass C++ auf einem Atmega nicht gut funktioniert, weil die Compiler/Libraries nicht dafür angepasst wurden. An der Sprache und ihren Prinzipien liegt es aber garantiert nicht.
cplusplusser schrieb: > Kann sein dass C++ auf einem Atmega nicht gut funktioniert, weil die > Compiler/Libraries nicht dafür angepasst wurden. Eine C++ - Standardlib gibt es dafür schlicht nicht. Oliver
Marc Vesely schrieb: > Sage ich doch. Ja, der zweite Abschnitt in meinem Post war nicht auf dein Zitat bezogen, sondern auf die Diskussion hier insgesamt.
Oliver S. schrieb: > Eine C++ - Standardlib gibt es dafür schlicht nicht. Sagen wir's mal provokant für den Hobby-Bereich: Es gibt für AVR viel mehr schlechte C++ - Libraries als gute C - Libraries. Es gibt viel mehr schlechte C++ - Programmierer, die für AVR schreiben, als gute C - Programmierer. C++ am AVR verwenden = Der Masse hinterherlaufen. C am AVR verwenden = der kleinen Elite angehören. Warum? Arduino! Passt natürlich nicht auf den Nutzerdurchschnitt hier im Forum :)
Stefan us schrieb: > Objektorientiert programmieren bedeutet für mich, dass Daten und > zugehöriger Code zusammenhängend strukturiert werden. Das kann man auch > in C tun. Das ist für mich erstmal nur strukturierte Programmierung. Objektorientierte Programmierung geht da noch deutlich weiter. > C++ unterstützt objektorientierte Programmierung. C++ hat im Gegensatz zu C bereits Sprachmittel eingebaut für die objektorientierte Programmierung. In C kann man auch objektorientiert programmieren, aber man muß das, was in C++ schon enthalten wäre, mühevoll selbst nachbilden. jaja schrieb: > ARDuino schrieb: >> Viele Arduino Bibliotheken sind in C++ geschrieben. > > Da sprichst Du zwei Worte an, dessen Verständnis viele allgemein in C++ > und Arduino (eines der Worte) hinein interpretieren. Die meisten denken > immer an verkapselte und überfrachtete Bibliotheken und viel Overhead. Das ist mein Eindruck von den Arduino-Bibilotheken. Das liegt aber nicht daran, daß sie in C++ geschrieben sind. Marc Vesely schrieb: > C++ bedeutet enormes Overhead an code und genau das will man bei uC > nicht. So pauschal die Aussage ist, so falsch ist sie auch. > Vielleicht ist C++ für ARM geeignet, aber bestimmt nicht für ATMEGA > oder so. Wer die wirklichen Vorteile von C++ nutzen will, hat in der > uC-Welt nichts verloren. Wo kommt eigentlich diese Idee her, daß man, sobald man C++ nutzt, gleich automatisch immer sämtliche Features der Sprache auch verwenden muß? Ich empfehle doch auch nicht, C auf einem tiny nicht zu verwenden, nur weil die Ausgabe eines float per printf() zuviel Flash braucht. Dann verwende ich halt keine floats und kein printf, schon hab ich das Problem gar nicht. Der Rest der Sprache wird doch dadurch nicht automatisch nutzlos. Genauso unsinnig ist es dann auch, C++ dort nicht zu verwenden, nur weil Exceptions ja soviel Overhead haben. Daniel A. schrieb: > Grundsätzlich gibt es keinen echten grund gegen c++ auf dem uc, aber > aufgrund der Art und Weise, wie exeptions in c++ umgesetzt wurden, > bevorzuge ich c. Du findest die Art und Weise, wie sie in C umgesetzt sind (nämlich gar nicht) also besser? Und std::vector gibt es in C nicht, und auch nichts direkt vergleichbares. Warum ist es also besser, in C keinen std::vector zu benutzen, als ihn in C++ nicht zu benutzen? gnuopfer schrieb: > Computer arbeiten in Ihrenm Kern nun mal prozedural (von totalen Exoten > mal abgesehen). Wenn man auf die tiefste Ebene der Softwareentwicklung > abzielt ist eine nicht-prozedurale Sprache daher grundsätzlich im Weg. > D.h. Es wird immer ein Eckerl im Code übrigbleiben das klassisch > prozedural erledigt werden muss, oder die "höhere Philisophie" der > Sprache muss verletzt werden. In C++ ist das der unvermeidliche der > Einsatz globaler Variablen (SFRs, TIMER usw). Der Vorteil von C++ ist hier, daß man z.B. im Gegensatz zu Java nicht gezwungen wird, wirklich den gesamten Code strengstens objektorientiert zu schreiben aber im Gegensatz zu C trotzdem die Sprachmittel dafür hat. Man kann es also dort nutzen, wo es sinnvoll ist und dort lassen, wo es nicht sinnvoll ist. drama schrieb: > Du musst doch keine Exceptions verwenden. Eine Menge C++-Software > verzichtet komplett auf Exceptions, nicht nur auf Mikrocontrollern. Die Meinung, man müsse in C++ zwingend Exceptions nutzen, ist erstaunlich weit verbreitet. Selbst Linus Torvalds führt das als einen der Hauptgründe auf, warum er gegen C++ im Linux-Kernel ist. Wenn man sich die anderen fadenscheinigen Argumente durchliest, bekommt man das Gefühl, daß der wahre Grund einfach nur darin liegt, daß er die Sprache nicht mag. drama schrieb: > Viele Konzepte aus dem OOP-Bereich lassen sich darüber hinaus sinnvoll > mit C umsetzen. (z.B. Polymorphie, Klassen, Information Hiding) Das sehe ich anders. Schau dir mal gtk+ an. Da wird das alles in C umgesetzt, und der Code ist in meinen Augen häßlich. Funktionsnamen werden ewig lang, da der Klassenname immer im Funktionsnamen enthalten sein muss und dazu dann auch keine Namespaces oder überladene Funktionen zur Verfügung stehen. Um Polymorphie nachzubauen müssen zusätzlich noch dauernd irgendwelche Makros verwendet werden, die die selbstgestrickten vtable-Pointer richtig hinbiegen.
cplusplusser schrieb: > Das stimmt eigentlich nicht. Templates beispielsweise kann man voll > ausreizen. Auch die Standard Library gilt eigentlich als sehr effizient, Langer Diskussion kurzer Sinn: Wer oder was hindert dich daran, C++ zu benutzen ?
Marc Vesely schrieb: > cplusplusser schrieb: >> Das stimmt eigentlich nicht. Templates beispielsweise kann man voll >> ausreizen. Auch die Standard Library gilt eigentlich als sehr effizient, > > Langer Diskussion kurzer Sinn: > Wer oder was hindert dich daran, C++ zu benutzen ? Weil es hier bloß um Selbstdarstellung geht. Das liest man in jedem Post, dazu muss man nicht mal zwischen den Zeilen lesen. Die Antwort das es keinen großen Sinn macht sich mit echtem C++, -was immer echtes C++ sein mag und wo der Unterschied zu unechtem ist- unter besonderer Berücksichtigung der Hardwarenähe auf klassischen Mikrokontrollern zu machen gibt er sich selbst mit dem Hinweiss dass er keine Literatur dazu findet. Sicher das eine oder andere Buch wird es geben. Es gibt schließlich auch Bücher über das Baden und verköstigen des Morgenurins. Zudem ist es an sich ein Widerspruch eine Sprache deren Konzept dazu optimiert wurde um sich von der Hardwareebene weg-zu-abstrahieren dazu zu vergewaltigen eben genau das zu tun. Lachhaft die ganze Diskussion. Jede Sprache hat ihr optimales Einsatzgebiet. C++, c# und objective C bei der Programmierung complexer Betriebssysteme auf den oberen Ebenen und C und Assembler in Hardwarenähe. Wer will kann natürlich auch ne Datenbankanwendung für nen PC in Assembler programmieren und der nächste Freak programmiert seinen Tiny13 in C++ um ne LED einzuschalten. Bei Arduino ist das ne Feine Sache um Künstlern und Menschen die keine Ahnung vom Programmieren haben ein mächtiges Framework an die Hand zu geben und diese soweit wie möglich von der Hardware aus Bits und Bytes wegzuhalten. Dafür ist C++ eben optimiert.
Rolf Magnus schrieb: > Wo kommt eigentlich diese Idee her, daß man, sobald man C++ nutzt, > gleich automatisch immer sämtliche Features der Sprache auch verwenden > muß? Da treibts du dich aber nicht viel in der "C++ Community" herum, wenn die diese Frage ernsthaft stellst. Um als "guter C++ Programmierer" zu gelten ist es zwingend erforderlich in einem Programm alle entfernt anwendbaren Features zu verwenden. Natürlich musst du alle Publikationen von den C++-Heiligen als einzig richtigen Weg der Softwareentwicklung anerkennen, sonst bist du -halt dich fest- : ein Ewiggestriger ! Ein Mühlstein am Hals der der modernen Softwareentwicklung ! Nebenbei gibts dann auch keine Punkte mehr auf Stackoverflow,Reddit und Co !
Mal zur Abwechslung kurz auf die Frage des OT eingehen: cplusplusser schrieb: > Ich suche deshalb nach Literatur... Nicht, daß ich dir direkt damit helfen kann - ich kenne keine Literatur dazu. Aber wenn du dsbzgl. herumfragst, solltest du auch dazu sagen, welche Art Hardware du im Auge hast. Auf einem Controller der Größenordnung AVR oder PIC sieht es sicher ganz anders aus als auf einem deutlich kräftigeren ARM (welchen auch immer) etc.. Wenn du entsprechend genauer fragst, bekommst du vieleicht auch eher sinnvolle Antworten. Daß es ein Buch gibt, mit dem man die ganze Controllerwelt abdeckt hinsichtlich C++, halte ich für etwas unwahrscheinlich. Zu AVR mit C++ gibt es hier im Forum auch schon ein paar Diskussionen (die auch nicht gleich so sinnlos entartet sind wie hier).
Thomas Holmes schrieb: > Weil es hier bloß um Selbstdarstellung geht. Auch in diesem Thread merkt man es wieder: Die einen User sind freundlich und geben objektiv abgewägte Antworten. Die anderen User sind unfreundlich und primär darauf aus, den Threadstarter zu verreissen. Weil er vielleicht mit seiner Frage die Überzeugung gewisser Leute auf die Probe stellt? Könnte ja sein, dass man plötzlich alt aussieht, wenn der Praktikant saugute C++-Programme für Mikrocontroller schreibt und man aus seiner C-Komfortzone herauskommen müsste... Jedenfalls habe ich keine sachliche Argumente gelesen, warum C++ hardwarenah nichts taugen soll. Im Gegenteil, es wurde eher dargelegt, dass - vernünftiger Compiler, Library und Programmierer vorausgesetzt - C++ auf einem Mikrocontroller genau performant ist wie C.
cplusplusser schrieb: > Jedenfalls habe ich keine sachliche Argumente gelesen, warum C++ > hardwarenah nichts taugen soll. Im Gegenteil, es wurde eher dargelegt, > dass - vernünftiger Compiler, Library und Programmierer vorausgesetzt - > C++ auf einem Mikrocontroller genau performant ist wie C. Thomas Holmes schrieb: > Zudem ist es an sich ein Widerspruch eine Sprache deren Konzept dazu > optimiert wurde um sich von der Hardwareebene weg-zu-abstrahieren dazu > zu vergewaltigen eben genau das zu tun. Lachhaft die ganze Diskussion. Kann ich mich nur anschliessen. Und amputiertes C++ ist eben kein C++ mehr. Und dann benutze ich C++ nicht weil ich es wirklich brauche, sondern weil es im Trend ist.
Thomas Holmes schrieb: > Zudem ist es an sich ein Widerspruch eine Sprache deren Konzept dazu > optimiert wurde um sich von der Hardwareebene weg-zu-abstrahieren dazu > zu vergewaltigen eben genau das zu tun. Da hapert es aber wieder am Verständnis von C++ ... C++ wurde bewusst entwickelt, um einerseits abstrahieren zu können, aber gleichzeitig die effizienten und hardwarenahen Aspekte von C zu behalten. Daß je nach Einsatzfall mal mehr das eine überwiegt und mal mehr das andere, liegt auf der Hand. Aber im Gegensatz zu den meisten anderen OO-Sprachen soll es eben gerade nicht NUR abstrahieren.
Marc Vesely schrieb: > Und dann benutze ich C++ nicht weil ich es wirklich brauche, sondern > weil es im Trend ist. Oder weil eben Teile von C+++ gerade nützlich sind, und man die (in einem konkreten Fall) weniger sinnvollen einfach weglässt, ohne daß sie schaden?
Marc Vesely schrieb: > Thomas Holmes schrieb: >> Zudem ist es an sich ein Widerspruch eine Sprache deren Konzept dazu >> optimiert wurde um sich von der Hardwareebene weg-zu-abstrahieren dazu >> zu vergewaltigen eben genau das zu tun. Lachhaft die ganze Diskussion. > > Kann ich mich nur anschliessen. > Und amputiertes C++ ist eben kein C++ mehr. > Und dann benutze ich C++ nicht weil ich es wirklich brauche, sondern > weil es im Trend ist. Das Konzept von C++ wurde optimiert, um von der Hardwareebene weg zu abstrahieren? Das ist doch Unsinn. Es gibt Pointers, man kann tief in die Speicherverwaltung eingreifen, die primitiven Datentypen sind direkt auf Maschinenworte abgebildet, usw. Man hat in C++ sogar vollste Kontrolle über die Hardware! Des weiteren beissen sich Templates und die Standard Library überhaupt nicht mit hardwarenaher Software. Einzig bei der Vererbung muss man sorgfältig sein.
Marc Vesely schrieb: > cplusplusser schrieb: > Jedenfalls habe ich keine sachliche Argumente gelesen, warum C++ > hardwarenah nichts taugen soll. Im Gegenteil, es wurde eher dargelegt, > dass - vernünftiger Compiler, Library und Programmierer vorausgesetzt - > C++ auf einem Mikrocontroller genau performant ist wie C. > > Thomas Holmes schrieb: > Zudem ist es an sich ein Widerspruch eine Sprache deren Konzept dazu > optimiert wurde um sich von der Hardwareebene weg-zu-abstrahieren dazu > zu vergewaltigen eben genau das zu tun. Lachhaft die ganze Diskussion. > > Kann ich mich nur anschliessen. > Und amputiertes C++ ist eben kein C++ mehr. > Und dann benutze ich C++ nicht weil ich es wirklich brauche, sondern > weil es im Trend ist. Ab wann ist denn ein Programm kein amputiertes C++ mehr? Reicht die Verwendung von Klassen oder müssen es alle C++11 Features sein? Vielleicht noch mit STL und Boost? Allein die Verwendung von Objektorientierung und Templates kann einen Code sauberer und übersichtlicher ohne das Ergebnis aufzublähen.
Rolf Magnus schrieb: > Die Meinung, man müsse in C++ zwingend Exceptions nutzen, ist > erstaunlich weit verbreitet. Selbst Linus Torvalds führt das als einen > der Hauptgründe auf, warum er gegen C++ im Linux-Kernel ist. Wenn man > sich die anderen fadenscheinigen Argumente durchliest, bekommt man das > Gefühl, daß der wahre Grund einfach nur darin liegt, daß er die Sprache > nicht mag. Kann man ihm es denn übelnehmen? ;) http://harmful.cat-v.org/software/c++/linus Viel Spass noch beim Religionskrieg.. .. duck und weg ..
:
Bearbeitet durch User
Scelumbro schrieb: > Allein die Verwendung von Objektorientierung und Templates kann einen > Code sauberer und übersichtlicher ohne das Ergebnis aufzublähen. Stimmt! So habe ich im Jahre 2005 Software für einen ATmega128 geschrieben (mit WinAVR). Lief prima. Schnell genug, kompakt genug.
mse2 schrieb: > So habe ich im Jahre 2005 Software für einen ATmega128 > geschrieben Ja, sonst hätte auch ein Mega8 gereicht ;-) cplusplusser schrieb: > Man hat in C++ sogar vollste > Kontrolle über die Hardware! Sag mal an, wie Du ein Portbit setzt! Wehe, das geht über 'sbi PortA,0' hinaus. Dann ist es eben nur -komplizierter -umständlicher -intransparent -langsamer -aufgeblähter -mehr Schreibaufwand
Moby schrieb: > Sag mal an, wie Du ein Portbit setzt! > Wehe, das geht über 'sbi PortA,0' hinaus. > Dann ist es eben nur > -komplizierter > -umständlicher > -intransparent > -langsamer > -aufgeblähter > -mehr Schreibaufwand Wenn es komplizierter, umständlicher, intransparent, langsamer, aufgeblähter als in C ist und mehr Schreibaufwand bedeudet, hat man etwas falsch gemacht. Denn die C-Version wäre ja ebenfalls gültiges C++. Also hat jemand etwas mit C++ hingemurkst, was gar keinen Sinn macht. Das kommt davon, wenn man von seinen Werkzeugen keine Ahnung hat.
Hier gibt es ein ziemlich gutes C++ Projekt. Sehr Hardware-nahe, sehr performant ( muss es sein für Audioprocessing): https://github.com/sensorium/Mozzi
Marc Vesely schrieb: > amputiertes C++ ist eben kein C++ mehr Blödsinn. Sobald ein Programm ein Feature benutzt, das erfordert daß es mit einem C++ Compiler, statt dem C Compiler übersetzt werden muß, ist es per Definition ein C++ Programm. Vielleicht läßt du uns ja mal deine Definition von "echtem C++" wissen? Wieviel Prozent C++ Features müssen denn verwendet werden, damit du es gelten läßt? Mir sind oft schon simple Features wie das Überladen von Funktionen oder die Verwendung (typsicherer) Templates statt Makros für z.B. min() und max() den Schritt zu C++ wert. Oder auch const Referenzen und die Möglichkeit, Funktionen komplexe Datentypen zurückgeben zu lassen. Und im Gegensatz zu Java oder C# kann C++ wenigstens in effizienten Maschinencode übersetzt werden. Vor 10 (eher 20) Jahren war das noch anders. Aber die Compiler sind heutzutage wesentlich besser geworden. XL
>Mir sind oft schon simple Features wie das Überladen von Funktionen oder >die Verwendung (typsicherer) Templates statt Makros Die werden in der oben erwähnten Lib in aller Ausführlichkeit verwendet. Und das auf Atmegas ..
Axel Schwenke schrieb: > Vielleicht läßt du uns ja mal deine Definition von "echtem C++" wissen? > Wieviel Prozent C++ Features müssen denn verwendet werden, damit du es > gelten läßt? Es geht nicht um meine Definition von C++, es geht darum wieviel von C++ tatsächlich gebraucht wird. Niemand hindert TO daran, C++ zu benutzen, von mir aus auch Basic oder Assembler. Ich glaube sogar Rufus und Karl Heinz, daß der C++ kompakteren Code compiliert als plain C. Nur passiert das alles dort, wo seine Stärken und die wirklichen Vorteile nicht ausgenutzt werden und solange er sich in der normalen C-Syntax bewegt. Die ganze Diskussion dient nur dazu, um zu zeigen wie versiert der TO in C++ ist und hat etwa so viel Sinn wie die Frage, womit man in Windows8 bitbanging am LPT-Port am besten macht - mit VS, Delphi, C++ oder Java.
Marc Vesely schrieb: > Axel Schwenke schrieb: >> Vielleicht läßt du uns ja mal deine Definition von "echtem C++" wissen? >> Wieviel Prozent C++ Features müssen denn verwendet werden, damit du es >> gelten läßt? > > Es geht nicht um meine Definition von C++, es geht darum wieviel von > C++ tatsächlich gebraucht wird. ... > Ich glaube sogar Rufus und Karl Heinz, daß der C++ kompakteren Code > compiliert als plain C. > Nur passiert das alles dort, wo seine Stärken und die wirklichen > Vorteile nicht ausgenutzt werden Wenn der C++ Compiler kompakteren Maschinencode erzeugt und der Quellcode außerdem noch lesbarer ist (durch Überladung, Typsicherheit, Referenzen statt Pointer etc.) dann ist doch damit ein Vorteil von C++ ausgenutzt. Reicht das denn nicht? Wieso sollte das nicht als "Stärke" und "wirklicher Vorteil" von C++ gelten? Es tut mir leid, aber ich kann beim besten Willen nicht erkennen, was dein Argument gegen diese Verwendung von C++ sein soll. Liegt es vielleicht daran, daß du (unbewußt?) einen bestimmten Programmierstil mit C++ assoziierst? Dem ist nicht so. Und ich empfinde es als einen großen Vorteil von C++, daß es dem Nutzer freistellt, welche Sprachfeatures er benutzen möchte und welche nicht. Man kann auch rein prozedurale C++ Programme schreiben, wenn man möchte. Und das ist auch gut so! Der Gegenentwurf dazu ist Java, das nicht mal den zutiefst logischen prozeduralen main() Einsprungpunkt erlaubt, sondern den affigen Würg- around mit einer statischen main() Methode gehen muß. Das ist grottiges Design und ich frage lieber gar nicht, unter welchen Drogen Gosling gestanden hat als er sich das ausdachte... XL
Axel Schwenke schrieb: > Liegt es vielleicht daran, daß du (unbewußt?) einen bestimmten > Programmierstil mit C++ assoziierst? Nein, das ist es nicht, aber... cplusplusser schrieb: > Wo ich aber an meine Grenzen komme: Etwas hardwarenahes zu schreiben und > trotzdem der C++-Philosphie treu zu bleiben. Vielleicht solltest du TO nach C++ Philosophie fragen ? Axel Schwenke schrieb: > Es tut mir leid, aber ich kann beim besten Willen nicht erkennen, was > dein Argument gegen diese Verwendung von C++ sein soll. Habe doch gar nichts gegen C++ gesagt und solange es (einigermassen) transparent bleibt, ist es auch OK. Wie gesagt, ich möchte halt gern wissen was für Code mein Compiler generiert hat, zumindest wenn es um Hardware geht. Und solange es um reine Hardware geht, werden sowohl C als auch C++ wahrscheinlich denselben Code generieren. Ich kann auch inline Portbits setzen und rücksetzen, nur ist mein Programm halt in C++, anstatt in plain C oder Assembler. Wozu dann das Ganze überhaupt ? Nicht C++ als solches, sondern die ganze Diskussion.
Ich höre hier städig die Mär der C++ Compiler erzeuge kompakteren Code als der C Compiler. Welcher C++ Compiler eigentlich? Und wo sind die Bewise für diese Behauptung?
Selten so viele unschlüssige Argumente gegen C++ (verglichen mit C) auf einem Haufen gesehen. Mit Assembler wär' das nicht passiert!
Ich verstehe es auch nicht. Man verzichtet auf die Vorteile von C++ komplett, weil man auf einem µC nicht alle Vorteile nutzen kann. Sobald die Nutzung von C++ auch nur einen Vortiel bietet, ist es doch unsinnig, darauf einfach nur aus Prinzip zu verzichten. Diese Entscheidung hat nichts mit Philosophie zu tun, sondern mit praktischem Nutzen.
Guten Morgen, Rolf Magnus schrieb: > Ich verstehe es auch nicht. Man verzichtet auf die Vorteile von > C++ > komplett, weil man auf einem µC nicht alle Vorteile nutzen kann. > Sobald die Nutzung von C++ auch nur einen Vortiel bietet, ist es doch > unsinnig, darauf einfach nur aus Prinzip zu verzichten. Diese > Entscheidung hat nichts mit Philosophie zu tun, sondern mit praktischem > Nutzen. So ist der Idealzustand, sollte man meinen. Aber das Thema ist aus irgend welchen unerfindlichen Gründen emotional total aufgeladen. Kann sein, dass die Leute mal ausprobieren, wie die andere Sprache ist. Da es aber doch Unterschiede gibt, die man erst mal lernen muss, tut man sich am Anfang schwer. Anstatt mal in sich zu gehen und die Gründe zu erkennen wird das dann auf die Sprache abgewälzt und diese für doof befunden. Ein schönes Beispiel ist Moby. Das einzige, was er auf einem µC zu machen scheint, ist einzelne Port bits zu schalten. Man sieht genau, entweder will er nur trollen, oder er hat sich noch nie mit einer anderen Sprache beschäftigt (gut, ich tippe auf Troll <*(((>< ). Moby schrieb: > Sag mal an, wie Du ein Portbit setzt! > Wehe, das geht über 'sbi PortA,0' hinaus. Würde ich übrigens in C++ genau so schreiben wie in C und wie es üblich ist. Und Oh, sieh mal, wass der Assembler output draus macht,
1 | #include <avr/io.h> |
2 | int main(void) |
3 | {
|
4 | PORTB |= (1 << PB0); |
5 | }
|
macht der Compiler ein
1 | main: |
2 | /* prologue: function */ |
3 | /* frame size = 0 */ |
4 | /* stack size = 0 */ |
5 | .L__stack_usage = 0 |
6 | sbi 56-32,0 ; ,, |
7 | ldi r24,lo8(0) ; , |
8 | ldi r25,hi8(0) ; , |
9 | /* epilogue start */ |
10 | ret |
11 | .size main, .-main |
Ja, ich weiß, dass das Programm nutzlos ist, aber Moby braucht ja nichts anderes. Meine Gegenfrage an der Stelle lautet, wie sieht denn bei dir die USB-Stack Implementierung eines CDC Devices auf dem Mega32U4 aus? Kannst du das nach einem Jahr noch lesen oder anwenden? Ein nettes Buch ist übrigens "Weniger schlecht programmieren". Das beleuchtet die Dinge mal aus einer anderen Sicht. PS: An dieser Stelle wollte ich grad schreiben, was man alles schönes mit der STL machen kann, z.Bsp einen eigenen Allokator einsetzen um den freien Speicher zu verwalten, aber das wird einem sicher wieder als: 'Das muss man dann so machen, auch wenn man nur einen Portpin setzen will' ausgelegt. Deswegen lass ich das einfach. Der Großteil der C-Leute hier würden statt C++ eh einfach C mit Klassen programmieren, wenn sie sich mal dran setzten würden. So denne, viele Worte, wenig Sinn. Leben und Leben lassen. Gottseidank gibt es ja die Möglichkeit, dass auf den µC jeder für sich in seiner Lieblingssprache glücklich werden kann. Daher besteht auch nicht die Notwendigkeit, mal über seinen Tellerrand zu schauen.
nicht"Gast" schrieb: > Meine Gegenfrage an der Stelle lautet, wie sieht denn bei dir die > USB-Stack Implementierung eines CDC Devices auf dem Mega32U4 aus? Kannst > du das nach einem Jahr noch lesen oder anwenden? Da wirst du von Moby keine Antwort kriegen. Der müllt mit guter Regelmäßigkeit die Threads mit immer den gleichen schwachsinnigen Behauptungen voll. Wer wissen will wie C++ im Controllerbereich sinnvoll und gut eingesetzt werden kann, sollte sich mal die MBED-Quellen rein ziehen. Moby braucht das aber nicht tun. Der hasst sowieso alles was ARM oder CORTEX im Namen trägt. Ich programmiere meine Controller (AVR, LPC, STM32) auch in C++. Wenn man das so macht wie z.B. bei MBED, kostet das kein Byte mehr Programmgröße und auch keine Laufzeit. Für mich erhöht es die Les- und Wartbarkeit aber deutlich.
Überhaupt nicht den vollen Umfang einer Sprache laut DIN Normen verwenden zu dürfen, ist im Bereich von sicherheitskritischer Software nichts ungewöhnliches. Es wird dabei grundsätzlich verlangt ein C-Subset zu definieren, zu dem die dynamische Speicheranforderung z.B. nicht gehören darf. C++ wird aber genau wie C explizit aufgezählt. Das ein abgerüstetes C++ kein C++ mehr ist, und man so gleich in C schreiben kann, zieht so nicht. Denn ähnliches wie bei C wird bei C++ auch gemacht. Das nennt sich dann Embedded C++ (EC++) oder Extended Embedded C++ (EEC++) das von einem Industriekonsortium definiert wurde. siehe S.205: ftp://ftp.iar.se/WWWfiles/8051/webic/doc/EW8051_CompilerReference.pdf EC++ Umfang ============ Zugelassene Funktionalität bei EC++: - Klassen - Vererbung - Überladen - typsichere Speicherverwaltung mit new und delete (nicht bei sicherheits-kritischer Software) - Inline Funktionen Fehlende Funktionalität bei EC++: - Templates - Multiple und virtuelle Vererbung - Exception Handling - RTTI - keine neue cast Syntax - Namespaces - keine STL EEC++ Umfang ============= Zugelassene Funktionalität bei EC++: - Klassen - Vererbung - Überladen - typsichere Speicherverwaltung mit new und delete (nicht bei sicherheits-kritischer Software) - Inline Funktionen - Templates - Namespaces - static_cast, const_cast, reinterpret_cast - STL Also kritische Sachen fehlen bei beiden. - Multiple und virtuelle Vererbung - Exception Handling - RTTI Das deckt sich überbrigens mit diesem Artikel: http://www.mikrocontroller.net/articles/C_vs_C%2B%2B Alles in allem steckt da immer genug C++ drin, und man sollte einfach wie immer das gerade geeignete Werkzeug wählen. Noch eine kurze Bemerkung zu Assembler. Damit wird man nur Software bis SIL2 zertifiziert bekommen. Wichtig sind klare Lesbarkeit, Übersichtlichkeit und Testbarkeit des Codes. Assembler will man da nur in Ausnahmefällen sehen.
Hallo temp, verfolge diesen Thread mit Interesse und habe deinen Beitrag mit Freude wahrgenommen. Das Dokument welches du genannt und den Link gestellt hast, bezieht sich auf 8051. Kann man es trotzdem universell verstehen?
Hallo Maude, hier das selbe in Grün für Mikrocontroller mit ARM-Core. ftp://ftp.iar.se/WWWfiles/arm/webic/doc/EWARM_DevelopmentGuide.ENU.pdf Also was die IAR Embedded Workbench also angeht ja.
nicht"Gast" schrieb: > Ein schönes Beispiel ist Moby. Das einzige, was er auf einem µC zu > machen scheint, ist einzelne Port bits zu schalten. Nun mal langsam! Wir sind beim Thema hardwarenahes Programmieren und da ist es doch recht und billig, die C++ abstrakte Diskussion hier mal wieder zurück in die Niederungen der Realität zu bringen... Zu den hardwarenahen Basics gehört nun mal zuallererst, wie man überhaupt was nach außen hin bewirken kann- sprich ein Portbit zu schalten. Das Beispiel zeigt dankenswerterweise gleich mal überdeutlich, wie geeignet, wie auf den Punkt, wie 1:1 die Funktion ohne Ballast umgesetzt mit Assembler agiert wird. Schon ein "PORTB |= (1 << PB0);" in purem C zeigt doch schon den Mehraufwand- und ist doch nur ein fader Vorgeschmack auf das, was einen auf noch abstrakteren Leveln erwartet. Aber soll doch jeder seinen Controller ganz nach Lust und Laune mit Datenstrukturen, basierend auf überbordenden Quelltexten zupflastern wie er will. Aber dann bitte nicht beschweren, wenn der Controller wieder eine Nummer größer gewählt oder gleich auf eine fette 32-Bit Architektur gewechselt werden muß! Die Sinnhaftigkeit hardwarenahen Einsatzes von C++ perfekt auf den Punkt bringt es Thomas Holmes im Beitrag #3890322: > Zudem ist es an sich ein Widerspruch eine Sprache deren Konzept dazu > optimiert wurde um sich von der Hardwareebene weg-zu-abstrahieren dazu > zu vergewaltigen eben genau das zu tun. Zum schließlich immer wieder zu hörenden Argument gegen simples Asm: nicht"Gast" schrieb: > Meine Gegenfrage an der Stelle lautet, wie sieht denn bei dir die > USB-Stack Implementierung eines CDC Devices auf dem Mega32U4 aus? kann ich nur sagen: Viel besser als Du glaubst. Weil das der effizient proggende Bastler einfach auf Fertigmodule a'la FTDI auslagert, die seriell bedient werden. Wie man überhaupt vieles in punkto Netzwerk, Massenspeicher, Display Speziallösungen überlassen kann, sollte, aus Zeitgründen muß!
nicht"Gast" schrieb: > Der Großteil der C-Leute hier würden statt C++ eh einfach C mit Klassen > programmieren, wenn sie sich mal dran setzten würden. Ich denke, das ist ein wichtiger Punkt. Viele Programmierer aus der E-Technik Ecke können sehr gut Assembler und C. Dabei spricht man in der Sprache der Maschine. C++ und andere höhere Sprachen hingegen machen es möglich, mehr und mehr in der Sprache des Problems zu sprechen. Aber diese Welt wird leider in E-Technik Studiengängen nicht vermittelt. Das Mass der Dinge bei den meisten E-Technikern ist deshalb die Effizienz auf dem Rechner, nicht die Klarheit und Eleganz der Software. Obwohl heutige Compiler dermassen gut optimieren, dass man sich auf Implementationsebene kaum mehr Gedanken um die Maschinenebene machen müsste. Das ist wirklich schade, denn eigentlich würde sich damit eine völlig neue Toolbox öffnen, wie man komplexe Software-Probleme lösen kann. Da beneide ich meine Kollegen mit einem Informatik-Abschluss.
Moby schrieb: > Zu den hardwarenahen Basics > gehört nun mal zuallererst, wie man überhaupt was nach außen hin > bewirken kann- sprich ein Portbit zu schalten. Und wie machst du das mit dem Port - sagen wir, mit einer Mehrfarben-LED dran - dann, wenn deine Software auf verschiedenen Architekturen laufen soll und verschiedene Module darauf zugreifen können, um Statusinformationen auszugeben, wobei die Ausgabe nach Priorität arbitriert werden muss und in den Systemeinstellungen die Default-Farben überschrieben werden dürfen? Dann interessiert sich nämlich kein Schwein mehr für das eigentliche Setzen/Löschen des Pins. Dann interessiert nur noch, ob für die Statusroutinen ein Interface bereit gestellt werden kann, das systemweit transparent, flexibel und fehlersicher aufgerufen werden kann, ohne dass die Performance in den Keller geht. Und dann willst du eben eine Programmiersprache verwenden, die möglichst hohe Abstraktion erlaubt. Der vorliegende Fall mag man mit C noch erledigen können. Aber was passiert, wenn das Interface auch noch Blinkpatterns und Farbeingaben verstehen soll, die in verschiedenen Formaten vorliegen können? Dann bist du plötzlich froh um Klassen oder Templates.
cplusplusser schrieb: > Und wie machst du das mit dem Port - sagen wir, mit einer Mehrfarben-LED > dran - dann, wenn deine Software auf verschiedenen Architekturen laufen > soll und verschiedene Module darauf zugreifen können, um > Statusinformationen auszugeben, wobei die Ausgabe nach Priorität > arbitriert werden muss und in den Systemeinstellungen die Default-Farben > überschrieben werden dürfen? Das hast Du aber schön zusammenkonstruiert. Und es zeigt mir: Allein durch die Verwendung dieser komplexen Programmiersprache schafft man sich Probleme und Umstände, die man ohne sie nicht hätte. Mangels Alternative mag das alles ja in der Windows-Entwicklung unumgänglich sein, nicht aber doch bei Mikrocontrollern! Meine Software wie die Millionen anderer einfacher bis mittelkomplexer 8-Bit Apps muß nicht auf verschiedenen Architekturen laufen, da langt eine. Zugriff auf Mehrfarben-LED? Lächerlich: cplusplusser schrieb: > Dann interessiert nur noch, ob für die > Statusroutinen ein Interface bereit gestellt werden kann, das systemweit > transparent, flexibel und fehlersicher aufgerufen werden kann, ohne dass > die Performance in den Keller geht. Interface ist in Asm meinetwegen ein Word im SRAM, welches ein Timerinterrupt in Reality umsetzt. Auf das kann zugreifen wer mag, und wo sollen da Performanceprobleme auftauchen? Die Notwendigkeit verschiedener Formate besteht da auch nicht- die tauchen nur auf wenn man in diesem OOP Universum gefangen ist ;-) Oh mei oh mei. BastiDerBastler schrieb: > Moby würde seine Freude an Templates haben, wenn er sie verstünde... Und Du an hardwarenahem Asm, wenn... ;-) Ich will Euch Eure Freude an den vielerlei OOP Konstrukten ja nicht nehmen- allein, bei Millionen einfacher bis mittelkomplexer 8-Bit Apps sind sie schlicht eines: Überflüssig!
Moby schrieb: > Das hast Du aber schön zusammenkonstruiert. Das Beispiel ist überhaupt nicht zusammenkonstruiert. Stell dir beispielsweise eine Firma vor, die drahtlose Sensor-Nodes entwickelt. Um schnell sehen zu können, was ein Node tut, hat man eine Mehrfarben-Status-LED auf jedem dieser Geräte. Moby schrieb: > Meine Software wie die Millionen anderer einfacher bis mittelkomplexer > 8-Bit Apps muß nicht auf verschiedenen Architekturen laufen, da langt > eine. Nun gibt es extrem kleine Nodes mit einem Atmega, solche auf ARM und solche auf einem Rasperry-Pi. Moby schrieb: > Interface ist in Asm meinetwegen ein Word im SRAM, welches ein > Timerinterrupt in Reality umsetzt. Auf den grösseren Nodes kann der Benutzer eigene Programme installieren und ebenfalls auf die LED zugreifen. Wobei das Betriebssystem dann über die Priorität entscheiden muss. Die einzelnen Module können verschiedene Blinkpatterns liefern. Im einfachsten Fall gibt das Modul bloss eine Farbe an, es kann aber auch An-Aus-Zeiten liefern oder sogar eine komplette Wellenform. Moby schrieb: > Ich will Euch Eure Freude an den vielerlei OOP Konstrukten ja nicht > nehmen- allein, bei Millionen einfacher bis mittelkomplexer 8-Bit Apps > sind sie schlicht eines: Überflüssig! Wenn man nach dem Motto arbeitet: Frickeln, bis es läuft, dann ja. Wenn man grundsätzlich so programmiert, dass es flexibel, übersichtlich und erweiterbar bleibt, dann nein.
Moby schrieb: > Aber dann bitte nicht beschweren, wenn der Controller wieder > eine Nummer größer gewählt oder gleich auf eine fette 32-Bit Architektur > gewechselt werden muß! Moby schrieb: > Weil das der effizient > proggende Bastler einfach auf Fertigmodule a'la FTDI auslagert, die > seriell bedient werden Lustig, lieber einen Haufen zusätzliche Harware verbauen als einen größeren Controller? Da hast du ja fett Geld, Platz und Fehlerquellen gespart. Moby schrieb: > Bastler Erklärt einiges :)
Wir sollten Schichten einlegen. Denn Moby hält die Diskussion ja nur am laufen und "schlägt" dann einen jeden mit seiner Geduld, argumentiert indem er die Intention des Gesprächspartners verdreht oder pervertiert. Wenn nun aber von 20 Leuten immer nur einer mit ihm diskutiert, dann wird ihm das Unterfangen vielleicht irgendwann genauso dumm vorkommen, wie es eben ist ;)
cplusplusser schrieb: > Das Beispiel ist überhaupt nicht zusammenkonstruiert. Stell dir > beispielsweise eine Firma vor, die drahtlose Sensor-Nodes entwickelt. Um > schnell sehen zu können, was ein Node tut, hat man eine > Mehrfarben-Status-LED auf jedem dieser Geräte. cplusplusser schrieb: > Die einzelnen Module können verschiedene Blinkpatterns liefern. Im > einfachsten Fall gibt das Modul bloss eine Farbe an, es kann aber auch Wow. Und ich als Benutzer muss dann jedesmal mein 1245 Seiten dickes Handbuch holen, wo die verschiedenen Blinkpattern abgebildet sind, etwa eine halbe Stunde damit verbringen um dann endlich die richtigen Pattern gefunden zu haben. Dass in der Zwischenzeit dein hochmodernes Atomreaktor, welcher mit drahtlosen Sensor-Nodes die wiederum in C++ programmiert sind, in die Luft gegangen ist, macht ja nichts, Hauptsache C++.
Und eines darf man in so einer Diskussion nie machen! Man darf nie konkrete Beispiele bringen, seien sie auch nur auf die Schnelle konstruiert und entsprechend deklariert. Damit liefert man eine vergrößerte Angriffsfläche, die Gegenseite ist meist "klüger", unterlässt soetwas, und hackt dann auf den Beispielen rum.
cplusplusser schrieb: > Wenn > man grundsätzlich so programmiert, dass es flexibel, übersichtlich und > erweiterbar bleibt Es ist ein schwerer Irrtum zu glauben, daß es dazu OOP bedarf. Wenn aber tatsächlich verschiedene Architekturen zu bedienen, komplexere Systeme zu programmieren, große Datenmengen zu händeln und größere Berechnungen anzustellen sind- da hat OOP sicher seine unbestreitbaren Vorteile. Es ist immer noch das Projekt selbst, daß die besten, schnellsten, einfachsten Methoden zu seiner Umsetzung bestimmt.
Marc Vesely schrieb: > Wow. > Und ich als Benutzer muss dann jedesmal mein 1245 Seiten dickes > Handbuch holen, wo die verschiedenen Blinkpattern abgebildet sind, > etwa eine halbe Stunde damit verbringen um dann endlich die richtigen > Pattern gefunden zu haben. Na komm, jetzt wirds lächerlich. Auf Funktionen verzichten, nur weil der feine Herr Vesely dann vielleicht mal ein Handbuch aufschlagen muss? Und mit dem Handbuch-Argument schlägst du dich eigentlich gleich selbst, denn je besser gekapselt eine Funktionalität ist, desto schneller blickt man durch. Bei Moby dürftest du dich für die gleiche Funktion durch duzende Zeilen Assembler wühlen, bei mir verrät dir vermutlich schon der Klassenname, wo du schauen musst.
nicht"Gast" schrieb: > lieber einen Haufen zusätzliche Harware verbauen als einen größeren > Controller? Da hast du ja fett Geld, Platz und Fehlerquellen gespart. Genau so schauts aus! Du solltest noch mal drüber nachdenken!
Moby schrieb: > Es ist ein schwerer Irrtum zu glauben, daß es dazu OOP bedarf. Jedenfalls lassen deine Vorschläge mit SRAM-Zugriff und Portpin keine Ansätze von Modularisierung und Portabilität erkennen. Es braucht nicht zwingend OOP, aber es ist ein sehr effizientes Hilfsmittel verglichen mit dem Overhead, den es generiert. Und C++ ist ja nicht nur OOP sondern auch Templates und die Standard Library, die ebenfalls stark zur Portabilität und Kapselung beitragen.
Thomas Holmes schrieb: > Ich höre hier städig die Mär der C++ Compiler erzeuge kompakteren Code > als der C Compiler. Welcher C++ Compiler eigentlich? Und wo sind die > Bewise für diese Behauptung? So pauschal ist diese Aussage natürlich genauso falsch wie die Behauptung, daß allein durch die Verwendung von C++ ein riesiger Overhead gegenüber C entstünde. Ich sag's ja schon immer: Alle pauschalen Aussagen sind falsch. Moby schrieb: > Schon ein "PORTB |= (1 << PB0);" in purem C zeigt doch schon den > Mehraufwand- und ist doch nur ein fader Vorgeschmack auf das, was einen > auf noch abstrakteren Leveln erwartet. Eine Abstraktion in C++ hat bei mir z.B. mal so ausgesehen:
1 | portb[0] = true; |
und daraus hat der Compiler das von dir genannte SBI gemacht. Was ist daran nun so schlimm? cplusplusser schrieb: > Das ist wirklich schade, denn eigentlich würde sich damit eine völlig > neue Toolbox öffnen, wie man komplexe Software-Probleme lösen kann. Da > beneide ich meine Kollegen mit einem Informatik-Abschluss. Da muß man aber aufpassen, denn es gibt auch das krasse Gegenteil. Leute, die so auf Abstraktion und Software-Design gehen, daß am Schluß träge, ressourcenfressende Bloatware rauskommt, und da der Programmierer nicht versteht, was eigentlich auf dem Rechner passiert, hat er auch keine Idee, wie er das verbessern kann. Man muß beide Aspekte verstehen und im Auge behalten. Und je nach Umfang des Programms und den Ressourcen der Hardware, auf der es laufen soll, ist mal das eine und mal das andere wichtiger. Ich frag mich auch bis heute, warum auf meinem Android-Handy ein simpler Button, der nix weiter tut, als beim Antippen das Fotolicht zu toggeln, über 30 mal so viel RAM braucht, wie ein C64 insgesamt hatte.
Vielleicht: C++ > C, weil man mit C++ auch C-Programme kompilieren kann. Jedes Argument für C ist also auch eins für C++. C > ASM, weil man in C auch einfach Inline-ASM einbinden oder externe ASM-Files dazulinken kann. Jedes Argument für ASM ist also auch eines für C und für C++. Damit sind schonmal 90% der Argumente von Moby entkräftet. Und nun: Jedes Argument gegen C++ zählt nur, wenn es auch gleichzeitig als Argument gegen C und als Argument gegen ASM gilt. Denn: Was C "mehr" als ASM bietet ist optional, und muss nicht verwendet werden. Das was C++ mehr als C bietet ist optional, und muss nicht verwendet werden. So, das waren dann die letzten 9.99999% seiner Argumente.
cplusplusser schrieb: > Bei Moby dürftest du dich für die gleiche Funktion durch > duzende Zeilen Assembler wühlen, bei mir verrät dir vermutlich schon der > Klassenname, wo du schauen musst. Aber woher denn. Als ob man in Asm weniger gut dokumentieren könnte... BastiDerBastler schrieb: > Moby hält die Diskussion ja nur am > laufen und "schlägt" dann einen jeden mit seiner Geduld, argumentiert > indem er die Intention des Gesprächspartners verdreht oder pervertiert Konkret bitte? Weißt Du eigentlich, was eine Diskussion nur auf Laufen halten kann? Argumente an denen was dran ist! Eng wirds natürlich wenn die ausgehen. Dann bleibt nur, über böseartige Verdrehungen und Pervertierungen zu jammern ;-)
Rolf Magnus schrieb: > Da muß man aber aufpassen, denn es gibt auch das krasse Gegenteil. > Leute, die so auf Abstraktion und Software-Design gehen, daß am Schluß > träge, ressourcenfressende Bloatware rauskommt, und da der Programmierer > nicht versteht, was eigentlich auf dem Rechner passiert, hat er auch > keine Idee, wie er das verbessern kann. Und da sind wir wieder bei der Einstiegsfrage! Ich möchte die Abstraktion von C++ nutzen und gleichzeitig verstehen, worauf man achten muss, dass die Software auch auf der untersten Ebene effizient ist. Es wurde mittlerweile vermutlich genügend dargelegt, dass C++ auch auf einem kleine Controller fast immer die bessere Option als C oder Assembler ist, so lange man nicht kompletten Blödsinn damit anstellt.
cplusplusser schrieb: > Na komm, jetzt wirds lächerlich. Auf Funktionen verzichten, nur weil der > feine Herr Vesely dann vielleicht mal ein Handbuch aufschlagen muss? Und Ja, bei solchen Beispielen schon. So etwas kann man mit einem Template sehr schön machen, nur sollte man es eben nicht mit Blinkpattern tun. Andererseits könnte man mit Template und Anwesenheitskontrolle genau wissen, ob und wann ich heute zur Arbeit gekommen bin, dementsprechend blinken oder Klartext ausgeben.
:
Bearbeitet durch User
Ahab schrieb: > amit sind schonmal 90% der Argumente von Moby entkräftet. Du übersiehst da was. Indem man von Asm über C und C++ fortlaufend weiter aufpfropft (in der lobenswerten Absicht flexibler zu werden) verkompliziert man es für den konkreten einfachen Fall nur immer weiter. Soll ja keiner glauben, daß die Vorteile der Hochsprachen ohne Preis daherkommen.
Moby schrieb: > Argumente an denen was dran ist! Habe ich von dir nicht viele gelesen. Deine Argumentation ist hauptsächlich so, dass du erklärst, dass man dies und jenes auch in Assembler oder C hinkriegen könne und dass du die Anforderungen so verdrehst, dass die Vorteile von höherer Abstraktion nicht zum tragen kommen können. ("Portabilität, das brauche ich doch nicht in der 8-Bit-Welt.") Von dir kam kein stichhaltiges Argument, dass C++-Code inakzeptabel grösser/langsamer sei. Es kaum auch kein Argument, dass die Softwareentwicklung damit prinzipiell schwieriger würde. Du konntest auch nicht aufzeigen, dass man die höheren Abstraktionen in Assembler/C genau so hinkriegt. Usw.
Moby schrieb: > Indem man von Asm über C und C++ fortlaufend > weiter aufpfropft (in der lobenswerten Absicht flexibler zu werden) > verkompliziert man es für den konkreten einfachen Fall nur immer weiter. > Soll ja keiner glauben, daß die Vorteile der Hochsprachen ohne Preis > daherkommen. Dann leg das doch endlich mal mit konkreten Beispielen dar! In welcher Art und Weise ist ein in C++ geschriebenes Programm weniger effizient als ein Assembler-Programm?
cplusplusser schrieb: > In welcher > Art und Weise ist ein in C++ geschriebenes Programm weniger effizient > als ein Assembler-Programm? Indem eine durchschnittliche, hardwarenahe Steuerungsanwendung in Asm - mit wenigen Instruktionen wesentlich schneller erstellt ist - weniger Platz benötigt - schneller abläuft. -> kleinerer, günstigerer Controller -> niedrige Einstiegshürden und Einarbeitungszeit ------------------------------------------------- Niedriger Aufwand! cplusplusser schrieb: > Portabilität, das brauche ich doch nicht in der > 8-Bit-Welt ... wir waren doch gerade bei Verdrehungen, du meine Güte.
cplusplusser schrieb: > dass du die Anforderungen so > verdrehst, Ich verdrehe sie nicht, ich sehe sie nur und reagiere mit dem Nötigen. Du versuchst offensichtlich auf Biegen und Brechen OOP zur Anwendung zu bringen. Das kommt dann bei raus: Rolf Magnus schrieb: > Ich frag mich auch bis heute, warum auf meinem Android-Handy ein simpler > Button, der nix weiter tut, als beim Antippen das Fotolicht zu toggeln, > über 30 mal so viel RAM braucht, wie ein C64 insgesamt hatte.
Moby schrieb: > Soll ja keiner glauben, daß die Vorteile der Hochsprachen ohne Preis > daherkommen. Du musst aus Deiner eindimmensionalen Denke rauskommen. "Vorteil" und "Preis" für sich alleine betrachtet, verdeckt den wesentlichen Aspekt: Vorteil Mehrwert = --------- Preis
Moby schrieb: > Indem eine durchschnittliche, hardwarenahe Steuerungsanwendung in Asm > > - mit wenigen Instruktionen wesentlich schneller erstellt ist Falsch. Die Entwicklungszeit dauert mit ASM länger, da schon bei mittelgroßen Programmen mehr Fehler gemacht werden, die dann alle gesucht und gefunden werden wollen. > - weniger Platz benötigt Falsch. Weil ASM-Module immer nur für einen konkreten Zweck programmiert werden, können sie innerhalb eines mittelgroßen Programms nicht mehrfach uiniversell genutzt werden. Folge: Bei Übertragung von Fall A auf Fall B in demselben Programm wird der Code kopiert und dann angepasst. Folge: Es ist jede Menge redundantes Zeugs in einem ASM-Programm. In Hochsprachen fügt man der Funktion einfach einen weiteren Parameter hinzu, um Fall A und B gleichzeitig abzufackeln. > - schneller abläuft. Falsch. Moderne Compiler können - gerade bei Programmen, die nicht winzigklein sind - in der Gesamtheit des Programms wesentlich besser optimieren als der Mensch. > -> kleinerer, günstigerer Controller Falsch Schlussfolgerung, siehe oben. > -> niedrige Einstiegshürden und Einarbeitungszeit Falsch. Man muss für jede µC-Familie eine andere Assembler-Sprache lernen. > Niedriger Aufwand! Falsch. Siehe oben. Programmiere mal einen STM32 in Assembler. Viel Spaß.
Hobby-Theoretiker schrieb: > Vorteil > Mehrwert = --------- > Preis Schon klar. Es gilt aber auch: - Jeder Preis schränkt ein - Der Vorteil hängt empfindlich von reellen Anforderungen und Voraussetzungen ab --------------------------- Damit bleibt der Mehrwert diskussionswürdig, bei hardwarenaher Programmierung allemal...
Frank M. schrieb: >> Niedriger Aufwand! > > Falsch. Siehe oben. Programmiere mal einen STM32 in Assembler. Viel > Spaß. Habe ich doch. Timergesteuertes LED blinken. Und das war für mich schon der Grund genug eine Ehescheidung zwischen ARM und Assembler zu verkünden.
:
Bearbeitet durch User
Frank M. schrieb: > Die Entwicklungszeit dauert mit ASM länger, da schon bei mittelgroßen > Programmen mehr Fehler gemacht werden, die dann alle gesucht und > gefunden werden wollen. Sicher. Ab einer gewissen Projektgröße. Von der spreche ich aber hier nicht. Und bis dahin ist es eine Frage mit welcher Vorbereitung/Grundstock an Programmen und Erfahrung man da rangeht. Frank M. schrieb: > Weil ASM-Module immer nur für einen konkreten Zweck programmiert werden, > können sie innerhalb eines mittelgroßen Programms nicht mehrfach > uiniversell genutzt werden Quatsch. Asm-Module können natürlich in gleicher Weise angewandt werden... Frank M. schrieb: > Es ist jede Menge redundantes Zeugs in einem ASM-Programm. In OOP-Konstruktionen jedenfalls ganz sicher (jede Menge ungenutzter Datenspeicherplatz und nie genutzte Methoden). Frank M. schrieb: > Moderne Compiler können - gerade bei Programmen, die nicht winzigklein > sind - in der Gesamtheit des Programms wesentlich besser optimieren als > der Mensch. Sie können oft gut optimieren. Aber sie kennen nicht Sinn und Zweck der Anwendung... Die Optionen wollen je nach Fall richtig eingestellt sein. Auch Compiler enthalten Fehler. Frank M. schrieb: > Man muss für jede µC-Familie eine andere Assembler-Sprache lernen. Man muß für Millionen typischer 8-Bit Anwendungen genau eine Sprache lernen, und die besteht aus wenigen Dutzend Instruktionen/Anweisungen. OOP ist ein bücherfüllendes Universum- in 99% überflüssig für den konkreten Anwendungsfall des genannten Anwendungstyps. Frank M. schrieb: > Programmiere mal einen STM32 in Assembler. Das würde ich allerdings auch nicht empfehlen. Gibt ja Simply AVR ;-)
Moby schrieb: > Frank M. schrieb: >> Die Entwicklungszeit dauert mit ASM länger, da schon bei mittelgroßen >> Programmen mehr Fehler gemacht werden, die dann alle gesucht und >> gefunden werden wollen. > > Sicher. Ab einer gewissen Projektgröße. Von der spreche ich aber hier > nicht. Achso. Ich wusste nicht, dass Du Mickey-Mouse-Progrämmchen meinst und dass ein AVR-Tiny für Dich und alle Zeit ausreicht. Auf Deinen Rest gehe ich gar nicht ein. Wir haben offenbar verschiedene Vorstellungen davon, wie umfangreich "durchschnittliche" Programme tatsächlich sind. Du redest von Programmen, die man in 30 Minuten hinrotzen kann und ich von Software-Projekten, die innerhalb von Wochen/Monaten - teilweise Jahren - wachsen... für mich absolut durchschnittlich.
:
Bearbeitet durch Moderator
Moby schrieb: > Hobby-Theoretiker schrieb: >> Vorteil >> Mehrwert = --------- >> Preis > > Schon klar. Es gilt aber auch: > - Jeder Preis schränkt ein > - Der Vorteil hängt empfindlich von reellen Anforderungen und > Voraussetzungen ab > --------------------------- > Damit bleibt der Mehrwert diskussionswürdig, bei hardwarenaher > Programmierung allemal... Ein Programmierer teilt ein Problem ist Teilprobleme ein, die sich einzeln leicht lösen lassen. Ein Moby teilt ein Problem in Teil-uCs ein, die sich einzeln leicht in ASM programmieren lassen. Obwohl ich mich damit angreifbar mache, mal ein Beispiel warum hardwarenahe Progammierung nicht der den Großteil der Arbeit bei einem uC Projekt ausmacht (jetzt mal abgesehen von Projekten die an den Grenzen der Hardware arbeiten oder von Blinky): Ich implementiere einen Ethernetstack auf einem uC. Die Hardwareverbindung ENC28J60 -(SPI+ISR)-> uC läuft nach zwei Stunden. Der Rest des Stacks von der Initialisierung des ENC28J60 bis hin zum UDP Handlers hat an sich nichts mit Pintoggelei zu tun. Wenn man diesen in C oder gar C++ schreibt (wie ich es tue) kann man den Stack aber leicht auf andere uCs portieren. Sollte sich wirklich irgendjemand mal antuen so einen Stack in ASM zu schreiben wäre dieser für immmer auf die eine uC Familie festgelegt.
Moby schrieb: > Frank M. schrieb: >> Weil ASM-Module immer nur für einen konkreten Zweck programmiert werden, >> können sie innerhalb eines mittelgroßen Programms nicht mehrfach >> uiniversell genutzt werden > > Quatsch. Asm-Module können natürlich in gleicher Weise angewandt > werden... Achja? Wie sieht bei dir denn das Assembler-Pendant zu einer eine C++ Container-Klasse für einen per Template wählbaren Datentyp aus? (Ja, auch C++ wird hier Code duplizieren müssen. Aber erstens passiert das nicht mühsam von Hand und zweitens kann der Compiler automatisch entscheiden, was er dupliziert und was universell ist.) Moby schrieb: > Sicher. Ab einer gewissen Projektgröße. Von der spreche ich aber hier > nicht. Du schränkst die Aufgabenstellung die ganze Zeit so weit ein, bis sie auf deine Argumentation passt. Hier sprechen wir aber von einem generellen Ansatz für die Software-Entwicklung.
Moby schrieb: > Indem eine durchschnittliche, hardwarenahe Steuerungsanwendung in Asm > > - mit wenigen Instruktionen wesentlich schneller erstellt ist > - weniger Platz benötigt > - schneller abläuft. > > -> kleinerer, günstigerer Controller > -> niedrige Einstiegshürden und Einarbeitungszeit > ------------------------------------------------- > Niedriger Aufwand! Selten so einen Schwachsinn wie den von Moby gelesen. Ich habe auch Assembler auf Z8, Z80 und 8051 hinter mir. Wenn ich von diesem Code auch nur ansatzweise was nach avr, pic oder arm retten wollte, kommt es einer Neuentwicklung gleich. Alles was in C oder C++ geschrieben ist, kann man fast unverändert übernehmen. Natürlich bis auf den Teil der die Hardware bedient. Wem sein Horizont aber auf 8bit AVR eingeschränkt ist, kann das nicht nachvollziehen. Der taugt hier aber auch nicht als Gesprächspartner.
Ihr seid hier eucht schlimm und jeder versucht den anderen hier zu überzeugen. Macht doch einfach ein Beispiel, (z.B. http://globalday.coderetreat.org/) und zieht das mit verschiendenen Arten auf verschiedenen Plattformen zu programmieren durch, messt die Zeit für die Implementierung und baut dann alle gemeinsam eine Änderung ein; dann werdet ihr sehr schnell sehen, was sich wofür besser eignet. Endlose Diskussionen bringen nach meiner Erfahrung nichts, ihr müsst das einmal 1:1 an einer Aufgabe vergleichen und dann eure Schlüsse ziehen. Für mich ist das klar: C++ aber mit Augenmerk und vorher Gedanken über die !!!Architektur!!!! machen :) Das ist wurscht ob C oder C++ ... da kommt dann wirklich heraus, was nützlich ist.
temp schrieb: > Wenn ich von diesem Code auch > nur ansatzweise was nach avr, pic oder arm retten wollte, kommt es einer > Neuentwicklung gleich. Man muß nichts "neu" entwickeln und portieren weil man für Millionen klassischer 8-Bit Anwendungen locker auf der schön einfachen 8-Bit (AVR oder PIC) Schiene bleiben kann. temp schrieb: > Alles was in C oder C++ geschrieben ist, kann man > fast unverändert übernehmen. Hardwarenahe Dinge bestimmt nicht. Vieles andere was mittelbar mit der Hardware zusammenhängt auch nicht. Das Portabilitätsargument spielt überhaupt nur dann eine Rolle wenn man wirklich zum Controllerarchitektur-Wechsel gezwungen ist (hoffentlich nicht gerade durch OOP Einsatz ;-) temp schrieb: > Wem sein Horizont aber auf 8bit AVR eingeschränkt ist, kann das > nicht nachvollziehen. Der Horizont muß zunächst mal soweit reichen wie es die tatsächlichen Bedürfnisse der Anwendung erfordern. Und da reicht auch 8 Bit schon seeehr weit... Darüber hinaus schadet der Blick natürlich nicht. Stellt sich aber dabei heraus, daß Hochsprache (C++) oder ein komplexerer Controller (ARM) die Dinge in der konkreten Anwendung nur verkomplizieren statt vereinfachen, sollte einem der Ruf des Neandertalers und Anwenders "veralteter" Technik herzlich egal sein.
Moby schrieb: > Man muß nichts "neu" entwickeln und portieren weil man für Millionen > klassischer 8-Bit Anwendungen locker auf der schön einfachen 8-Bit (AVR > oder PIC) Schiene bleiben kann. Moby schrieb: > Hardwarenahe Dinge bestimmt nicht. Vieles andere was mittelbar mit der > Hardware zusammenhängt auch nicht. Das Portabilitätsargument spielt > überhaupt nur dann eine Rolle wenn man wirklich zum > Controllerarchitektur-Wechsel gezwungen ist Moby schrieb: > Der Horizont muß zunächst mal soweit reichen wie es die tatsächlichen > Bedürfnisse der Anwendung erfordern. Moby, du bist wieder gleich weit: Du schränkst die Aufgabenstellung einfach so lange ein, bis deine Argumente passen. Im Prinzip hast du wunderschön dargelegt, dass bei wenig komplexen, nicht zu portierenden/skalierenden Projekten auf 8 Bit und wenn man schon gut C/Assembler kann, mit C++ keine grossen Vorteile zu erwarten sind. Alle anderen Fälle hast du ausgeklammert, weil deine Argumentation dort nicht passt und C++ folglich Vorteile bringen wird.
> Moby, du bist wieder gleich weit: Du schränkst die Aufgabenstellung > einfach so lange ein, bis deine Argumente passen. > ... Das hatten wir alles schon. Mehrfach. Nützt aber nichts. Beim nächsten Thread wird er wieder von vorne anfangen. Ungefragt und völlig aus dem Zusammenhang gerissen. Nur bei AVR-ASM Threads, da schweigt er.
Ganz ehrlich: TL;DR; Was mich aber wirklich brennend interessiert: Wurde jetzt die "Philosophie" des TO hinter C++ hier mal näher definiert? (also das von gaaaaaaaaanz oben) Thx&Grüße, tk
Tobias K. schrieb: > Ganz ehrlich: TL;DR; > > Was mich aber wirklich brennend interessiert: Wurde jetzt die > "Philosophie" des TO hinter C++ hier mal näher definiert? Schau in den Nachbar-Thread, da wurde eine mögliche Philosphie für eine C++ - Lib dargelegt. TL;DR: - Man kann eine C++-Library schreiben, die das AVR-Programmieren (auch für Einsteiger) einfacher macht. - Durch die Compiler-Optimierung wird aus einem "LED.on()" trotzdem eine einzelne "sbi"-Instruktion, obwohl zwei Level von Templates dazwischen liegen. - Dadurch entfällt der größte Nachteil der Arduino-Bibs, die ja auch auf C++ aufbauen. - Die Template-Sachen lassen sich in den Headern verstecken, und müssen vom Anwender nicht zwingend gesehen & verstanden werden. - Hier kann man eine solche Library nicht Programmieren, weil die C- und ASM- Trolle der Meinung sind, die Benutzung "ihrer" Programmiersprache wird gerichtlich untersagt, sobald das C++-Framework fertig ist.
Ahab schrieb: > - Durch die Compiler-Optimierung wird aus einem "LED.on()" trotzdem eine > einzelne "sbi"-Instruktion, obwohl zwei Level von Templates dazwischen > liegen. > - Dadurch entfällt der größte Nachteil der Arduino-Bibs, die ja auch auf > C++ aufbauen. Wie ich hier schon einmal erwähnt habe, könnte man die Arduino-Bibs ohne Änderungen am API und ohne Einschränkungen der Funktionalität noch stark optimieren, wenn man nur wollte: Beitrag "Re: Ist Arduino verpönt?" Um die Funktionen digitalRead und digitalWrite zu optimieren, bedarf es nicht einmal spezieller C++-Features wie Templates u.ä. Gewöhnliches C (gespickt mit ein paar ganz wenigen GCC-Features) ist schon ausreichend. Ich frage mich nur, warum dies von den Arduino-Entwicklern keiner tut. Die Arduino-Befürworter kämen in den Genuss einer höheren Performance, ohne dass sie dafür ihren Awendungscode umschreiben müssen, und den Arduino-Gegnern, die sich immer wieder auf die extreme Ineffizienz der Arduino-Bibs berufen, könnte damit gewaltig Wind aus den Segeln genommen werden. Aber mir ist das ja wurscht, da ich auf den AVRs weder die Arduio-Bibs noch C++ verwende :)
Wenn Du echte Objektorientierung mit echtem Mehrwert auf Mikrocontrollern haben möchtest, dann nimm ein RTOS mit Warteschlangen, zum Beispiel Open/FreeRTOS und lasse jedes Objekt so wie in Smalltalk als eigenen Task laufen.
Ok - Danke. Es geht also oft um: - Nutzbare Libraries - Präprozessor: Templates/Makros - Laufzeit: Objektorientierung - Compileroptimierungen Ich krieg nur den Bogen zu TO noch nicht hin: "Wo ich aber an meine Grenzen komme: Etwas hardwarenahes zu schreiben und trotzdem der C++-Philosphie treu zu bleiben." Also ich werfe jetzt mal Objective-C in die Runde: Schon vor ~6 Jahren konnte man für das iPhone 3G flüssige Apps schreiben, wenn man sich nur an die Spielregeln und Konventionen hielt. Ist das jetzt eine vergleichbare Philosophie, halt nur von Apple für ObjC? Und falls ja: was ist das vergleichbare für C++? thx, tk PS: Die Apps, die damals einfach mal einen großen Berg alten C++Code aufs iPhone portiert haben (da gcc), waren oft die, die nicht sauber liefen.
Christian Berger schrieb: > Wenn Du echte Objektorientierung mit echtem Mehrwert auf > Mikrocontrollern haben möchtest, dann nimm ein RTOS mit Warteschlangen, > zum Beispiel Open/FreeRTOS und lasse jedes Objekt so wie in Smalltalk > als eigenen Task laufen. Das ist das pure Gegenteil von dem, was in diesem Thread gefordert wurde. Es ging ja genau um die Frage, wie man C++ einsetzen kann für die Entwicklung effizienter, hardwarenaher Programme. Da passen Ideen wie RTOS und jedes Objekt in separatem Task sicher nicht rein - auch wenn das in gewissen Fällen sicher seine volle Berechtigung hat. Tobias K. schrieb: > Was mich aber wirklich brennend interessiert: Wurde jetzt die > "Philosophie" des TO hinter C++ hier mal näher definiert? Damit meine ich nichts esoterisches, sondern halt die ganzen "Best Practices" die für C++ empfohlen werden. Findet man beispielsweise im Buch "Effective C++".
Tobias K. schrieb: > Ich krieg nur den Bogen zu TO noch nicht hin: > "Wo ich aber an meine Grenzen komme: Etwas hardwarenahes zu schreiben > und > trotzdem der C++-Philosphie treu zu bleiben." Ok, dann führe ich das noch etwas aus. Wie bereits gesagt: Damit meine ich nichts esoterisches, sondern halt die ganzen "Best Practices" die für C++ empfohlen werden. Findet man beispielsweise im Buch "Effective C++". Wenn du Assembler oder C lernst, dann lernst du die ganzen Sprachkonstrukte kennen und gut ist. Aspekte wie "Algorithmen und Datenstrukturen" oder Design Patterns werden separat gelehrt, weil sie unabhängig von der Programmiersprache sind. Bei C++ hingegen sind viele höhere Konzepte schon auf der Sprachebene gewissermassen - wie soll ich sagen - angedacht. _Beispiel_: Memory Leaks. Dank Destruktoren hast du ein Sprachmittel, das dir hilft bzw. ermöglicht, Memory Leaks zuverlässig zu vermeiden. Aber du musst ein paar Regeln kennen, wie man es einsetzen soll, damit es seinen Zweck sicher erfüllt. Das habe ich mit "Philosophie" gemeint. Besser wäre gewesen, "Best Practices".
Argh, Leute. BITTE BITTE NICHT SCHON WIEDER. > Christian Berger schrieb: >> Wenn Du echte Objektorientierung mit echtem Mehrwert auf >> Mikrocontrollern haben möchtest, dann nimm ein RTOS mit Warteschlangen, >> zum Beispiel Open/FreeRTOS und lasse jedes Objekt so wie in Smalltalk >> als eigenen Task laufen. > > Das ist das pure Gegenteil von dem, was in diesem Thread gefordert > wurde. Es ging ja genau um die Frage, wie man C++ einsetzen kann für die > Entwicklung effizienter, hardwarenaher Programme. Da passen Ideen wie > RTOS und jedes Objekt in separatem Task sicher nicht rein - auch wenn > das in gewissen Fällen sicher seine volle Berechtigung hat. > Ich sag's mal so: Wer frickeln will, oder sich mit auf akademische Weise mit C++ nah an der Hardware beschäftigen möchte, der soll sich damit rumschlagen, und am Schluss selber Bilanz ziehen, ob sich das ganze gelohnt hat - nur um ein paar Hardware-Register 'schöner' anzusteuern. Aber, ohne jetzt in die Details zu gehen: Eine saubere, robuste industriekompatible Lösung basiert typischerweise auf einem Kernel, welches aus vielen, schon genannten Gründen NICHT in C++ geschrieben wird. Im Userspace ist C++ legitim, solange man keine hirntoten Template-Moloche wie Boost einsetzt. Verschont uns jedoch bitte damit, einen neuen, echt portablen "Programmier-Standard" für HW auf C++-Basis finden zu wollen. Das ist bisher etwa ähnlich gescheitert wie die vieldiskutierten Ansätze zum grafischen Programmieren. Im Endeffekt zählt für die Industrie nur: Zeit (Zeit ist Geld) und Robustheit. Das bedeutet schon mal, dass man am besten mit einem wohldefinierten Standard fährt (dazu gehört C++ schon mal nicht).
Fitzebutze schrieb: > Verschont uns jedoch bitte damit, einen neuen, echt portablen > "Programmier-Standard" für HW auf C++-Basis finden zu wollen. Das ist > bisher etwa ähnlich gescheitert wie die vieldiskutierten Ansätze zum > grafischen Programmieren. Im Endeffekt zählt für die Industrie nur: Zeit > (Zeit ist Geld) und Robustheit. Das bedeutet schon mal, dass man am > besten mit einem wohldefinierten Standard fährt (dazu gehört C++ schon > mal nicht). Lies dir den obigen Thread doch mal komplett durch. Dort wurde wohl wirklich alles zum Thema gesagt. Deine pauschale Aussage, was in der Industrie gefragt sei und was nicht, erinnert mich an eine ganze Liste von kurzsichtigen Fehleinschätzungen, z.B. hier: http://lustich.de/witze/andere/die-groessten-irrtuemer-unserer-zeit/ Klar mag es sein, dass du in deiner Berufskarriere nichts anderes gesehen hast und deine Komfortzone mit C gefunden hast. Zum Glück gibt es aber auch Leute, die nach vorne schauen um bessere Konzepte zu entwickeln. Ansonsten würden wir heute noch in Assembler schreiben...
Hm ok. Ich persönlich finde es ja schade, dass C++ keine so eine höhere Philosophie hat bzw. keine vernünftige einheitliche abstrakte Grundlage. Diese vielen Paradigmen in einer Sprache machen mich kirre, weil man halt im echten Leben nicht alles alleine machen will sondern auf Arbeiten anderer aufbaut oder noch besser mit Anderen zusammenarbeitet. Zwei C++-Vollprofis haben halt leider oft immer noch grundverschiedene Ansätze und verstehen sich gegenseitig nur bedingt. Daher gibt es ja im industriellen Bereich so viel Symptombekämpfung wie MISRA usw. Ich für meinen Teil halte die aufgebohrten C-Ansätze (sei es jetzt z.B. Apple oder auch Gnome) durchaus für legitim und sie geben dem Umfeld, in der man entwickelt, eine Systematik und einen Namen. Und sowas wie Arduino lebt ja auch nur durch entsprechendes Angebot/Nachfrage... Viele Grüße, tk
Tobias K. schrieb: > Ich persönlich finde es ja schade, dass C++ keine so eine höhere > Philosophie hat bzw. keine vernünftige einheitliche abstrakte Grundlage. Sagen wir es mal so: Einfache Programmiersprachen wie C kennen überhaupt keine Philosophie. Andere objektorientierte Sprachen wie Java zwingen dem Programmierer relativ stark eine bestimmte Philosophie auf. C++ wählt den Königsweg: Es bietet diverse Konzepte für höhere Abstraktion, ohne aber etwas aufzuzwingen. Der Programmierer entscheidet sich dann selbst, was er davon nutzt und was nicht. Das ist aber nicht chaotischer als in C, denn auch dort muss der Programmierer selbst entscheiden, wie er die höhere Abstraktion behandelt. Das Problem von C++ ist vielleicht, dass es den Programmierer dazu verleiten kann, eine Vielzahl seiner Konzepte zu nutzen, die für den vorliegenden Fall gar nicht notwendig wären. Das ist bei einem C-Programmierer, der zu viele Halbwissen über Software Engineering hat, aber wohl nicht anders.
P. M. (o-o) schrieb: > Deine pauschale Aussage, was in der Industrie gefragt sei und was nicht, > erinnert mich an eine ganze Liste von kurzsichtigen Fehleinschätzungen > Klar mag es sein, dass du in deiner Berufskarriere nichts anderes > gesehen hast und deine Komfortzone mit C gefunden hast. Zum Glück gibt > es aber auch Leute, die nach vorne schauen um bessere Konzepte zu > entwickeln. Ansonsten würden wir heute noch in Assembler schreiben... Nur mal zur Erinnerung was einer schrieb, dessen Karriere hier im Forum mit Abstand nicht toppen kann: http://harmful.cat-v.org/software/c++/linus Zitat " C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C. C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny) - inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app. In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap. So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage. If you want a VCS that is written in C++, go play with Monotone. Really. They use a "real database". They use "nice object-oriented libraries". They use "nice C++ abstractions". And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess. But I'm sure you'd like it more than git. Linus "
Jetzt wird der Thread wieder von Leuten gekapert, die verschont bleiben wollen davon und trotzdem in den Thread schauen...
cplusplusser schrieb: > Du schränkst die Aufgabenstellung > einfach so lange ein, bis deine Argumente passen. Und Dir scheinen andere Dinge wichtiger zu sein als die eigentliche Aufgabenstellung. Vermutlich weißt Du nicht was 'Millionen klassischer 8-Bit Projekte' bedeutet. cplusplusser schrieb: > Alle anderen Fälle hast du ausgeklammert, weil deine Argumentation > dort nicht passt und C++ folglich Vorteile bringen wird. Richtig. Ich sagte doch schon ...im Beitrag #3891863: > Wenn aber tatsächlich verschiedene Architekturen zu bedienen, komplexere > Systeme zu programmieren, große Datenmengen zu händeln und größere > Berechnungen anzustellen sind- da hat OOP sicher seine unbestreitbaren > Vorteile. Es ist immer noch das Projekt selbst, daß die besten, > schnellsten, einfachsten Methoden zu seiner Umsetzung bestimmt. Stefan schrieb: > Nur bei AVR-ASM Threads, da schweigt er. Die lese ich wohlwollend. Und freue mich, daß nicht alle Schafe einem Hype hinterher rennen weils modern erscheint ;-) cplusplusser schrieb: > _Beispiel_: Memory Leaks. Dank Destruktoren hast du ein Sprachmittel, > das dir hilft bzw. ermöglicht, Memory Leaks zuverlässig zu vermeiden. > Aber du musst ein paar Regeln kennen, wie man es einsetzen soll, damit > es seinen Zweck sicher erfüllt. Memory Leaks? Destruktoren? Bei Asm noch nie nötig gehabt. Da ist ja alles Gott sei Dank unter eigener Kontrolle. Aber sind schöne Beispiele, wie man via OOP eine Problemlösung programmtechnisch künstlich verkompliziert. cplusplusser schrieb: > Hier sprechen wir aber von einem > generellen Ansatz für die Software-Entwicklung. Der schaut bei mir so aus: Keep it simple!
Moby schrieb: > Und Dir scheinen andere Dinge wichtiger zu sein als die eigentliche > Aufgabenstellung. Vermutlich weißt Du nicht was 'Millionen klassischer > 8-Bit Projekte' bedeutet. Es ging in diesem Thread nie speziell um 8-Bit-Projekte, damit bist du irgendwann gekommen. Es ging um allgemeine Ansätze der hardwarenahen Softwareentwicklung. Und da wurde klar gezeigt, dass diese sogar auch auf 8-Bittern durchaus Vorteile bringen können. Du hast dich dann jeweils abgemüht, die Aufgabenstellung noch weiter einzuschränken, bis C++ wirklich keinen Vorteil mehr ausspielen kann. Moby schrieb: > Memory Leaks? Destruktoren? Bei Asm noch nie nötig gehabt. Da ist ja > alles Gott sei Dank unter eigener Kontrolle. Aber sind schöne Beispiele, > wie man via OOP eine Problemlösung programmtechnisch künstlich > verkompliziert. Du scheinst keinen Plan zu haben, was ein Memory Leak ist und wie es entsteht. Hat nämlich nichts mit der Programmiersprache zu tun.
Moby schrieb: > cplusplusser schrieb: >> _Beispiel_: Memory Leaks. Dank Destruktoren hast du ein Sprachmittel, >> das dir hilft bzw. ermöglicht, Memory Leaks zuverlässig zu vermeiden. >> Aber du musst ein paar Regeln kennen, wie man es einsetzen soll, damit >> es seinen Zweck sicher erfüllt. > > Memory Leaks? Destruktoren? Bei Asm noch nie nötig gehabt. Da ist ja > alles Gott sei Dank unter eigener Kontrolle. Aber sind schöne Beispiele, > wie man via OOP eine Problemlösung programmtechnisch künstlich > verkompliziert. Das sagt einfach schon alles aus... Deine Projekte sind einfach so trivial, dass C oder C++ keinen Vorteil bringt. Aber das sagten schon Unzählige vor mir.
cplusplusser schrieb: > Und da wurde klar gezeigt, Klar gezeigt wurde hier für OOP gar nichts. Daß via Asm der hardwarenahe Zugriff der beste, einfachste, direkteste, effektivste ist steht außer Frage. cplusplusser schrieb: > Du scheinst keinen Plan zu haben, was ein Memory Leak ist und wie es > entsteht. Hat nämlich nichts mit der Programmiersprache zu tun. Ach ja? Dann muß ich bei meinen Asm-Programmen nochmal suchen ;-) TriHexagon schrieb: > Deine Projekte sind einfach so trivial, dass C oder C++ keinen Vorteil > bringt. OOP macht selbst triviale Projekte zu Codemonstern. So wird ein Schuh draus.
P. M. schrieb: > Zum Glück gibt > es aber auch Leute, die nach vorne schauen um bessere Konzepte zu > entwickeln. --> Rolf Magnus schrieb: > Ich frag mich auch bis heute, warum auf meinem Android-Handy ein simpler > Button, der nix weiter tut, als beim Antippen das Fotolicht zu toggeln, > über 30 mal so viel RAM braucht, wie ein C64 insgesamt hatte. Sind das etwa die besseren Konzepte ??? Wer mit OOP liebäugelt dem sei dringend ein Blick in die Mobile- & PC-Softwareentwicklung empfohlen und wie hier Performance- und Platzbedarf der Programme explodiert ist. Effizienz mag es da vielleicht noch hinsichtlich der Entwicklungszeit geben. Die resultierende Programme aber sind alles andere!
Moby schrieb: > TriHexagon schrieb: >> Deine Projekte sind einfach so trivial, dass C oder C++ keinen Vorteil >> bringt. > > OOP macht selbst triviale Projekte zu Codemonstern. So wird ein Schuh > draus. Muss man auch nicht nutzen, aber was ist mit Portabilität, Strukturierung von Code/Daten, Abstraktion von elementaren Aufgaben wie Rechenoperationen, etc. . Das sind noch längst nicht alle, ergo ich muss mich bei C und C++ nicht um jeden Scheiß kümmern und kann mich um die Aufgabe selber kümmern. Wie es mich bei ASM immer wieder nerft, nachzusehen welche Instruktion welche Register verändert, welche Register darauf anwendbar sind und welche Eigenheiten diese besitzt. Nein danke. Es gibt einen Grund weshalb man heutzutage ausschließlich mit Hochsprachen arbeitet
TriHexagon schrieb: > Wie es mich bei ASM immer wieder nerft, nachzusehen welche Instruktion > welche Register verändert, welche Register darauf anwendbar sind und > welche Eigenheiten diese besitzt. Das ist eine (im Fall der einfachen AVR-architektur) relativ einfache Übungssache und immer noch weit vom umfangreichen bücherfüllenden Sprach- und Anweisungsumfang bzw. Syntax-Eigenheiten der Hochsprache/OOP entfernt. TriHexagon schrieb: > Es gibt einen Grund > weshalb man heutzutage ausschließlich mit Hochsprachen arbeitet Nix mit ausschließlich... TriHexagon schrieb: > ergo ich muss > mich bei C und C++ nicht um jeden Scheiß kümmern und kann mich um die > Aufgabe selber kümmern. Dieser Stand ist mit Asm und der Sammlung von Basicfunktionen für seine Hardware genauso erreichbar. Nur dann im Ergebnis mit effizienteren Programmen. Ich möchte aber Asm nicht als das Nonplusultra ansehen. Wirklich vereinfachende Problem-Abstraktion/Bezogenheit fern jeder Registerkonfiguritis ist meiner Meinung nach nicht auf Software-Ebene sondern nur durch intelligentere Controller-Hardware zu erreichen.
@Moby: also ich kann ja echt viele Standpunkte nachvollziehen, aber bitte nicht diese Speichernummer mit dem Farbton von "Früher war alles besser". Polemische Antwort: Kannst ja gern deinen C64 mit dir rumtragen, oder halt einfach eine zusätzliche Taschenlampe.
Nicht: Tobias K. schrieb: > Früher war alles > besser". sondern "Früher war auch nicht alles schlecht" !!! Tobias K. schrieb: > Kannst ja gern deinen C64 mit dir rumtragen Keinen C64, aber manches winzige 8-Bit System. Was andere mit hochmodernen fetten Linux-Rasberry Klötzen lösen müssen ;-)
Einigen wir uns auf: "Früher war's anders" ;) Ist halt wie immer die Frage, was Du vor hast. BTT: Das reine manuelle Schreiben von C/ASM-Code hat imho nichts mit modernem Softwareengineering zu tun. Dass das trotzdem sehr gut funktioniert, steht auf einem anderen Blatt. Gerüstet für die Zukunft ist man damit aber noch lange nicht, dafür ist Silizium zu billig. Die legitime Frage des TO war ja nun, ob C++ da was beitragen kann. Und Yalu warf auch schon die Frage auf, warum keiner die Arduino libs dahingehend verbessert. Grüße, tk
:
Bearbeitet durch User
>Yalu warf auch schon die Frage auf, warum keiner die Arduino libs >dahingehend verbessert. Das ist wie das Klo putzen in einer WG: irgendeiner sollte es mal machen. Ja warum macht es eigentlich keiner? Warum machst es Du nicht?
WG-Analogie: Ich beschwere mich nicht, dass das Klo dreckig ist. Mir reicht das vollkommen.
Fitzebutze schreib >Verschont uns jedoch bitte damit, einen neuen, echt portablen >"Programmier-Standard" für HW auf C++-Basis finden zu wollen. Das ist >bisher etwa ähnlich gescheitert wie die vieldiskutierten Ansätze zum >grafischen Programmieren. Die grafische Programmierung ist überhaupt nicht gescheitert. Erstens gibt es LabView für teures Geld und zweitens gibt es einen Codegenerator für Matalb Simulink, der in der Automobilindustrie mittlerweile häufig zu finden ist. Selbst der vielfach erwähnte Arduino wird unterstützt: http://de.mathworks.com/hardware-support/arduino-simulink.html
P. M. schrieb: > Klar mag es sein, dass du in deiner Berufskarriere nichts anderes > gesehen hast und deine Komfortzone mit C gefunden hast. Zum Glück gibt > es aber auch Leute, die nach vorne schauen um bessere Konzepte zu > entwickeln. Ich nehme stark an, du hast so ziemlich alles gesehen ? TriHexagon schrieb: > welche Eigenheiten diese besitzt. Nein danke. Es gibt einen Grund > weshalb man heutzutage ausschließlich mit Hochsprachen arbeitet Für alle die hier nur das, was die rausgegoogelt haben, wiederholen: C++ ist weder für Mikrocontroller gedacht, noch geschrieben worden. Wenn es um Hardware geht, ist die Frage: plain C oder C++ absolut irrelevant. Einzelne bits setzen, Register mit irgendwelchen Werten laden usw. ist bestimmt nicht das, wofür C++ geschrieben wurde. Also wird C++ bestenfalls genau dasselbe compilieren wie plain C. Damit ist die Frage die der TO (zwecks Selbstdarstellung) gestellt hat, schon mal sinnlos. Alle die mit irgendwelchen Argumenten für C++ um sich werfen und unzählige Vorteile diese Sprache anpreisen, reden in Wirklichkeit von Windows oder Linux. Und das ist weit, weit entfernt von Mikrocontrollern.
Auf das C++-Bullshit-Bingo möchte ich nicht weiter eingehen, aber schön, dass mal jemand Linus zitiert hat. Auch wenn er's drastisch ausdrückt: Er hat recht, und ich kann mich dem aus Erfahrung nur anschliessen. Es gibt in der Industrie, in der ich tätig bin, einen gewissen Anspruch an Robustheit und Wartungsfähigkeit des Codes. D.h. ziemlich strenge Regeln, wie ein Programm zu laufen hat. Und gerade da gilt: Never change the running horse (freier: "Wenn's tut, änder's nicht"). Nächstes Prinzip: Keep it simple. Denn irgendwann kostet die Fehlersuche mehr, als ein komplettes Redesign. Wenn sich der Code dann nicht sauber debuggen oder lesen lässt, fliegt er in die Tonne. Das mag eine radikale und vernichtende Meinung gegenüber Neuansätzen sein, aber ich bin als Kernel-Entwickler auch anderen gegenüber verpflichtet, einem Standard zu folgen, den alle verstehen. Die Gründe, warum fast alle robusten Kernels ausschliesslich in C geschrieben sind, brauche ich ja wohl nicht darzulegen. Also warum der ganze Aufriss? C++ ist prinzipiell over-engineered, und gaukelt einem eine falsche Einfachheit vor, die sehr leicht zu einem heftigen Missbrauch der Sprache führen kann. Ein abstrahierter High-Level-Ansatz ist auf einem HW-Treiber-Level komplett für die Katz, und erst recht, wenn sich ein Informatiker mit einem abstrahierten OO-Verständnis dahintermacht. Man kann durchaus in C++ einen robusten HW-Treiber schreiben. Aber es ist schlicht sinnlos, weil man gegenüber C kaum Zeit spart, sondern nur potentielle Stolperfallen einführt, die teils noch compilerabhängig sind. Der wirklich einzige Vorteil, den C++ bringen könnte, ist eine mehr oder weniger saubere Initialisierung. Aber der wiegt die C-Medikamente lint, valgrind, usw. nicht auf. Dann gäbe es noch ein Argument, dass man eine grosse Anzahl von Geräteklassen mit C++ abdecken könnte. Schöne Idee, aber bringt teils einen derartigen Overhead mit, dass man das auf jeden Fall im Userspace tun sollte. NICHT auf Treiberebene!
cplusplusser schrieb: > Du scheinst keinen Plan zu haben, was ein Memory Leak ist und wie es > entsteht. Hat nämlich nichts mit der Programmiersprache zu tun. Ach. Wirklich? Zeig mir mal, was von C++ übrig blibt, wenn man sämtliche objektorientierten Ansätze herausnimmt. Naja, cout vielleicht, aber kurz dahinter hört's auf. Was lehrt uns das? Es lehrt uns, daß alles, aber wirklich ALLES was wirklich ein Stück über simples Cockney-C hinausgeht, tief unten in den Libs mit dem Alloziieren und hoffentlich korrektem Freigeben von RAM verbunden ist. Auf dem PC sollte das heutzutage kein echtes Problem mehr sein, aber wer das glaubt, der irrt gewaltig. Memory Leaks gibt es auch dort, bloß fallen sie nicht so drastisch auf wie auf einem µC. Ich hab z.B. ein Mobiltelefon im Auto eingebaut, was ich so alle 2..3 Wochen mal abklemmen muß, weil es seine Klingeltöne nicht mehr findet und demzufolge auch nicht abspielen kann. Typisches Beispiel für Memory Leak (und die Qualität von Zeugs, was aus Finnland kommt..). Wer auf einem µC brav in C programmiert und sich sowas wie malloc grundsätzlich verkneift, hat das Problem nicht, aber wer C++ benutzen will, wird um biliotheksinterne malloc's und Konsorten wohl nicht herumkommen. Insofern hängt das sehr wohl von der gewählten Programmiersprache ab. W.S.
W.S. schrieb: > Zeig mir mal, was von C++ übrig blibt, wenn man sämtliche > objektorientierten Ansätze herausnimmt. Naja, cout vielleicht, aber kurz > dahinter hört's auf. > ... Wow. Für gewönhlich bist du es doch der anderen gerne vorhält "nichts verstanden" zu haben. Und jetzt so etwas. Für OOP auf einem µC fehlte es mir bislang an einem geeigneten Problem. Ich wüsste nicht was ich dort mit Klassen beschreiben sollte. Programme für den PC, ja, die schreibe ich "natürlich" in C++. Gerne auch mit virtuellen Methoden, Templates und Operator Überladung. Die Problemstellung ist dort auch eine andere. Aber auch in C sieht ein PC Programm bei mir anders aus als bei einem µC. Bei einem RTOS geht es mir ähnlich. Dafür habe ich zwar einige Anwendungen - und dort benutze ich dann auch FreeRTOS - aber in der Regel lassen sich meine Programme nicht sinnvoll in Tasks aufteilen. Dennoch stelle ich für µC nach und nach auf C++ um. Nicht für OOP sondern wegen der Namespaces und der besseren Typsicherheit (v.a. enums). Mehr nutze ich eigentlich nicht davon. Und da der GCC ja C++ unterstützt entsteht da auch kein besonderer Mehraufwand. "Richtiges C++" ist das freilich nicht. C++ ist es aber dennoch da ein C Compiler mir das nicht übersetzt. Was Linus' Kommentare zu der Sprache angeht: Er war schon immer nicht gerade auf den Mund gefallen. Höflich formuliert könnte man auch sagen er ist ein Mann der klaren Worte. Wobei ich nicht viel darauf gebe. Ich interessiere mich nicht für Meinungsäußerungen in denen Argumente Beschimpfungen gemeinsam verwendet werden. Ein Ingenieur/Informatiker sollte es besser wissen und können wie Herr Tanenbaum es ihm schön demonstriert hat.
W.S. schrieb: > Zeig mir mal, was von C++ übrig blibt, wenn man sämtliche > objektorientierten Ansätze herausnimmt. Naja, cout vielleicht, aber kurz > dahinter hört's auf. Wow, reduzierst du jetzt wirklich C++ auf seine Standardbibliothek? Teile lassen sich darin immer noch nutzen wie z.B. std::array. Soweit ich mich erinnere ist das aber auch bei C der Fall. Klassen, Templates, etc. lassen sich aber immer noch nutzen, also das was C++ ausmacht. W.S. schrieb: > Wer auf einem µC brav in C programmiert und sich sowas wie malloc > grundsätzlich verkneift, hat das Problem nicht, aber wer C++ benutzen > will, wird um biliotheksinterne malloc's und Konsorten wohl nicht > herumkommen. Insofern hängt das sehr wohl von der gewählten > Programmiersprache ab. Also nochmal, man muss nicht alle Features benutzen die C++ bietet. Es lässt sich malloc/new genauso vermeiden wie in C.
Stefan schrieb: >> Moby, du bist wieder gleich weit: Du schränkst die > Aufgabenstellung >> einfach so lange ein, bis deine Argumente passen. >> ... > > Das hatten wir alles schon... Stefan schrieb: > Für OOP auf einem µC fehlte es mir bislang an einem geeigneten Problem. > Ich wüsste nicht was ich dort mit Klassen beschreiben sollte. Kein geeignetes Problem für OOP? Na sowas. Ich fürchte Du hast die Aufgabenstellung auch zu sehr eingeschränkt ;-) TriHexagon schrieb: > Also nochmal, man muss nicht alle Features benutzen die C++ bietet. Das nenn ich jetzt mal geordneten Rückzug...
Moby schrieb: > TriHexagon schrieb: >> Also nochmal, man muss nicht alle Features benutzen die C++ bietet. > > Das nenn ich jetzt mal geordneten Rückzug... Mach dir mal die Bedeutung von "nicht alle" klar. Und nein, es ist nicht äquivalent zu "keine". Glaub ruhig weiterhin, dass man mit ASM und einem 8Bit Controller alle Probleme der Welt lösen kann... . Ich hab keine Lust mehr.
TriHexagon schrieb: > 8Bit Controller alle Probleme der Welt lösen kann Die Kühnheit das zu behaupten hat meines Wissens hier noch nie jemand besessen. Wahr ist: Schon mit den wenigen Asm Instruktionen lassen sich bereits auf einfachen 8-Bittern hochkomplexe Problemlösungen konstruieren. Wenn Problemlösungen aber dermaßen komplex werden können sollte man wenigstens die programmsprachlichen Mittel hierfür möglichst simpel halten, nicht nach dem Motto verfahren 'Viel hilft viel'. Das machts letztlich nur noch komplizierter.
Moby schrieb: > Stefan schrieb: >>> Moby, du bist wieder gleich weit: Du schränkst die >> Aufgabenstellung >>> einfach so lange ein, bis deine Argumente passen. >>> ... >> >> Das hatten wir alles schon... > > Stefan schrieb: >> Für OOP auf einem µC fehlte es mir bislang an einem geeigneten Problem. >> Ich wüsste nicht was ich dort mit Klassen beschreiben sollte. > > Kein geeignetes Problem für OOP? Na sowas. Ich fürchte Du hast die > Aufgabenstellung auch zu sehr eingeschränkt ;-) Oh nein, jetzt komm mir nicht so. Ich rate niemanden davon ab OOP (mit Klassen und allem) auf einem µC einzusetzen nur weil mir die entsprechenden Anwendungen fehlen. Und von C++ an sich schonmal gar nicht. Ich habe nie behauptet daß bestimmte Techniken (v.a. solche mit denen ich mich gar nicht auskenne) zu unnötig komplexen, großen oder was auch immer führen würde und man besser ... nehmen oder bei irgendetwas bleiben sollte.
Marc Vesely schrieb: > C++ ist weder für Mikrocontroller gedacht, noch geschrieben worden. > Wenn es um Hardware geht, ist die Frage: plain C oder C++ absolut > irrelevant. Einzelne bits setzen, Register mit irgendwelchen Werten > laden usw. ist bestimmt nicht das, wofür C++ geschrieben wurde. > Also wird C++ bestenfalls genau dasselbe compilieren wie plain C. Ja, und genau das will man ja. Man will in einem grossen Projekt mit C++ arbeiten können und trotzdem Code erhalten, der optimal auf die Hardware passt. Und genau DAS scheint ja möglich zu sein. Es scheint, dass einige Leute aus berechtigten oder weniger berechtigten Gründen nicht mit C++ arbeiten möchten. Ich für meinen Teil bevorzuge für ein grösseres Projekt aber ganz klar C++ gegenüber C. Und wenn man damit sogar bis auf die Hardwareebene guten Code erzeugen kann, dann sehe ich keinen Grund, warum man kein C++ einsetzen soll. Die Einwände gegenüber C++ akzeptiere ich durchaus: Es ist viel anspruchsvoller als C und bietet viel mehr Möglichkeiten, Unsinn zu machen. Das ist aber nicht eine Kritik an der Sprache, sondern eine Forderung an den Programmierer, ordentliches C++ und ordentliches Software Design zu lernen. Was ich nicht akzeptiere, ist der Einwand, C++ sei langsamer oder habe unnötigen Overhead. Man kann nämlich die meisten Features von C++ nutzen, ohne dass irgend ein Overhead im compilierten Programm entsteht.
Stefan schrieb: > Für OOP auf einem µC fehlte es mir bislang an einem geeigneten Problem. > Ich wüsste nicht was ich dort mit Klassen beschreiben sollte. Dann bist du aber ein ganzes Stück hinter dem Mond. Ich hätte (damals) für die Lernbetty ganz gern das gesamte Menü-Thema per OOP gemacht, aber genau DAS ist bei Benutzung der ja sooooo nett und einfach aussehenden OOP Teile von C++ immer wieder mit dynamischer Speicherverwaltung verbunden. Genau DAS wollte ich aber um keinen Preis, denn es ist eben gerade auf µC die Pest: RAM-hungrig, Funktionszeiger ebenfalls im RAM, schlimme Verwicklungen möglich bei Allokation/Deallokation aus Interrupts heraus und so weiter. Also fehleranfällig, wie bei meinem Telefon. Siehe auch die Lernbetty: 2 MB Flash, aber nur 64K RAM für alles. Genau deshalb habe ich dort in plain C die Menü-Funktionalität im Flash aufgebaut. Das ist dem vorhandenen Speicherbild angepaßt und es ist ne bombensichere Sache: Memory Leaks sind schlichtweg ausgeschlossen, Funktionszeiger können nicht versaut werden und so weiter. Verstehst du nun, was man (eigentlich) mit Klassen auf nem µC machen könnte, wenn es denn problemlos machbar wäre? W.S.
Ich versuch das gerade nur so sortieren... Wo war da dynamischer Speicher nötig (wegen oder trotz oder total unabhängig von 'OOP')? Lese noch ab und zu mit hier... schade, dass hier alle Threads gekapert werden, aber dann sucht man sich halt 'ne andere Plattform...
W.S. schrieb: > Genau DAS wollte ich aber um keinen Preis, denn es ist eben gerade auf > µC die Pest: RAM-hungrig, Funktionszeiger ebenfalls im RAM, schlimme > Verwicklungen möglich bei Allokation/Deallokation aus Interrupts heraus > und so weiter. Also fehleranfällig, wie bei meinem Telefon. Wenn man sauber programmiert, dann holt man sich in C++ garantiert kein Memory Leak. Stichwort RAII. Wenn man diese Regeln befolgt, dann ist ein Memory Leak nicht möglich. W.S. schrieb: > Genau DAS wollte ich aber um keinen Preis, denn es ist eben gerade auf > µC die Pest: RAM-hungrig, Funktionszeiger ebenfalls im RAM, schlimme > Verwicklungen möglich bei Allokation/Deallokation aus Interrupts heraus > und so weiter. Das sind alles Dinge, die nichts mit Klassen oder C++ zu tun haben, sondern mit einem schlechten Design. RAM-hungrig: Wo bitteschön braucht ein C++-Programm mehr RAM als ein C-Programm? Funktionszeiger im RAM: Bitte was? Allokation/Deallokation aus Interrupts heraus: Wenn in einer ISR etwas alloziert werden soll, dann ist dein Design sowieso Murks.
Naja, wenn man man C++ so verwendet wie es einem in den Lehrbüchern nahe gebracht wird, dann ist da immer dynamisches Speicherhandling dabei. Fast die gesamte std::-Lib egal ob Strings, Listen, vectoren... kommen ohne nicht aus. Trotzdem braucht man diesen Kram auf einem µC nicht zu verwenden. Ganz im Gegenteil. Es wird durch "Weglassen" von gängigen Teilen der Sprache oder der Lib's noch lange kein schlechtes Programm. Das wird es erst dann, wenn man so viel davon verwendet, dass es in keiner vernünftigen Relation zu den Resourcen des Controllers steht.
temp schrieb: > Naja, wenn man man C++ so verwendet wie es einem in den Lehrbüchern nahe > gebracht wird, dann ist da immer dynamisches Speicherhandling dabei. > Fast die gesamte std::-Lib egal ob Strings, Listen, vectoren... kommen > ohne nicht aus. Dabei sollte man aber nicht vergessen: Diese Libraries machen das Speicherhandling vollautomatisch UND sicher. Zudem gilt std:: auch als sehr effizient. Falls für deinen uC eine vernünftige Implementation besteht ist es gut möglich, dass diese dein händisch gestricktes C-Äquivalent schlägt. Das ist spätestens dann der Fall, wenn du selbst ebenfalls dynamisch Speicher allozieren musst. So sicher, schnell, flexibel, klar und effizient wie std:: kriegst du es nur mit viel Aufwand hin.
Soweit ich weiß, kann man bei den meisten std:: Klassen-template im einen eigenen Allokator vorgeben. Damit kann man die Größe der Objekte begrenzen/definieren. Nur wie man das macht weiß ich nicht. Weiß jemand Rat? PS: Darum, dass die Liste nicht zu voll wird muss man sowieso denken Gruß Felix
...ist doch echt schön, dass C++ dem Programmierer so viele Freiheiten bietet. Dann kann man auch immer schön in alle Richtungen aneinander vorbei-argumentieren... *Popcorntüte.aufmach*
Tobias K. schrieb: > ...ist doch echt schön, dass C++ dem Programmierer so viele Freiheiten > bietet. Dann kann man auch immer schön in alle Richtungen aneinander > vorbei-argumentieren... Spotten ist einfach. Jedenfalls waren es nicht Leute aus der ist-doch-eh-klar-Fraktion, welche die Computertechnik zu dem gemacht haben, was sie heute ist.
> Wer fremde Sprachen nicht kennt, > weiß nichts von seiner eigenen Johann Wolfgang von Goethe Das gilt auch für Programmiersprachen. Schon spannend, hier mitzulesen, zu sehen wie eine ausdrucksstärkere Sprache (C++) gegenüber eine ausdrucksschwache Sprache (C) von einigen vehement abgelehnt wird. Argumentativ den Funktionsumfang von Programmiersprachen zu betrachten, ist wenig zielführend, da praktisch alle (hier) benutzten Programmiersprachen Turing-vollständig sind und somit gegeneinander austauschbar. Was also bleibt, ist der Vergleich wie bestimmte Abstraktionen erreicht werden können: Müssen sie mühsam von Hand gebildet werden, oder bietet mir eine Programmiersprache eine Abstraktionsmethode "fertig" an? Oder geht es sogar darum, Abstraktionen gänzlich abzulehnen? Die Motivation dahinter erschließt sich mir nicht. Niemand käme auf die Idee, die Abstraktionstechniken der Mathematik abzulehnen. Beispiel: "3a" ist eine Abstraktion für "a+a+a" "a³" ist eine Abstraktion für "a*a*a" usw. Warum man beim Programmieren mächtigere Abstraktionen ablehnt, auch auf Mikrocontrollern, ist mir ehrlich gesagt teilweise rätselhaft. Die Emotionen für sich genommen, kann ich (irgendwie) verstehen. Aber warum baut man zu Programmiersprachen oder Abstraktionen überhaupt eine emotionale Bindung auf?
Programmiersprachen-Fan schrieb: > Warum man beim Programmieren mächtigere Abstraktionen ablehnt, Da liegst Du falsch. Man kann sich die Dinge auch einfacher oder komplizierter machen. Alles dahin wo es hingehört und Sinn macht. Programmiersprachen-Fan schrieb: > ist mir ehrlich gesagt teilweise rätselhaft Dann zieh erst mal ein größeres Mikrocontrollerprojekt durch. Am besten ohne zuvor IT studiert zu haben. Dann kannst Du den Aufwand unter dem Strich besser nachvollziehen. Programmiersprachen-Fan schrieb: > eine > emotionale Bindung Irrtum. Nüchternde Kosten/Nutzen Analyse.
Moby schrieb: > Dann zieh erst mal ein größeres Mikrocontrollerprojekt durch. > Am besten ohne zuvor IT studiert zu haben. > Dann kannst Du den Aufwand unter dem Strich besser nachvollziehen. Wie ich vermutet habe: C++ wird primär von Leuten abgelehnt, die nicht das notwendige Rüstzeug dafür mitbringen. Finde ich völlig ok, wenn man die Entscheidung für sich trifft. Wenn ich ein kompliziertes Werkzeug nicht beherrsche, dann weiche ich auch lieber auf ein einfacheres aus, das ich voll im Griff habe. Aber warum sagt ihr das nicht gleich? Warum nicht einfach hinstehen und sagen: Ich komm damit nicht klar, ich fühle mich wohler in C?
Ist doch schön cplusplusser, wenn Du an OOP-Gedankenakrobatik solche Freude hast und diese offensichtlich selbst noch auf eine (hardwarenahe) Blinkschaltung anwenden möchtest. Warum sagst Du das nicht gleich? Finde ich völlig OK. Aber schau, als freier Bastler arbeitet man anders. Nämlich absolut lösungszentriert. Da ist zum einen der schnellste Weg wichtig. Kontraproduktiv ist da eher, sich erst oder ständig langwierig mit komplizierten Werkzeugen rumzuschlagen. Nicht das Werkzeug, sondern die Lösung ist das Ziel. Verstehst Du? Und da ist schließlich zum anderen, daß ein optimales Ergebnis selbst wichtig ist. Da möchte man sowas gar nicht haben: Ralf G. schrieb: > Billig ist's auf jeden Fall nicht (Speicher/ Rechenzeit). ... um mal eine Anleihe von Experten im Nachbarthread "C++ auf einem MC" zu nehmen! Und guck mal, wie sich die Leute da einen abbrechen, um die einfache Funktionalität des TO in OOP hinzubekommen. Eine Funktionalität, die in wenigen Dutzend Asm/C zeilen implementiert wäre. Einfach nur erheiternd, das mit anzusehen. Oder soll ich sagen: grausam? Ich fühle mich da auch in einer wichtigen Einsicht bestätigt: Je flexibler die Sprache, je mehr "Ausdrucksstärke" bla bla bla desto komplizierter und umständlicher wird es, darin und damit eine gute Lösung zu finden. OOP hat ein bischen (oder doch sehr viel?) was von Brüsseler Bürokratie: Jahr für Jahr neue Regelungen, die im Einzelfall das Leben geordneter/einfacher gestalten sollen- aber es in Summe doch nur verkomplizieren und Einstiegshürden immer höher setzen. Oder laß es mich so formulieren: Dicke und immer dickere C++ Bücher (Aufwand) stehen in keiner Relation mehr zum Ergebnis. Jedenfalls was eine typische 8-Bit Controllerschaltung mit überschaubarer Funktionalität anbetrifft.
Moby schrieb: > Aber schau, als freier Bastler arbeitet man anders. Nämlich absolut > lösungszentriert. Da ist zum einen der schnellste Weg wichtig. > Kontraproduktiv ist da eher, sich erst oder ständig langwierig mit > komplizierten Werkzeugen rumzuschlagen. Nicht das Werkzeug, sondern die > Lösung ist das Ziel. Verstehst Du? Also bei Bastlern sehe ich eigentlich mehr "der Weg ist das Ziel" oder warum kauft sich der Bastler keine Fertiglösung? Moby schrieb: > Ich fühle mich da auch in einer wichtigen Einsicht bestätigt: Je > flexibler die Sprache, je mehr "Ausdrucksstärke" bla bla bla desto > komplizierter und umständlicher wird es, darin und damit eine gute > Lösung zu finden. > OOP hat ein bischen (oder doch sehr viel?) was von Brüsseler Bürokratie: > Jahr für Jahr neue Regelungen, die im Einzelfall das Leben > geordneter/einfacher gestalten sollen- aber es in Summe doch nur > verkomplizieren und Einstiegshürden immer höher setzen. Oder laß es mich > so formulieren: Dicke und immer dickere C++ Bücher (Aufwand) stehen in > keiner Relation mehr zum Ergebnis. Jedenfalls was eine typische 8-Bit > Controllerschaltung mit überschaubarer Funktionalität anbetrifft. Du sträubst dich nicht gegen C++, sondern eher gegen Software-Engineering. C++ ist eine Sprache die bestimmte Konzepte der Software-Entwicklung zur Verfügung stellt. Das mag für einen einfachen Bastler auf wenig Verständnis stoßen, hat aber ihre Berechtigung. Natürlich gibts auch in der professionelle Software-Entwicklung Bürokratie, dass nennt man dann Over-Engineering. Aber was ist denn bitteschön das Problem sich auch bei einfacheren Projekten dieser Konzepte (mit Einschränkungen) zu bedienen? Nur weil du darin keinen Sinn dahinter siehst (vielleicht weil du dich damit noch nicht ausreichend beschäftigt hast?), bedeutet es nicht, dass es gar keinen gibt.
Moby schrieb: > Aber schau, als freier Bastler arbeitet man anders. Dann bleib doch bitte bei den Bastlerthemen, und hör endlich auf hier alles platt zu quasseln. Inzwischen weiß jeder, daß es für dich mit Assembler schöner ist. > Nämlich absolut lösungszentriert. Deine Kommentare hier sind aber nicht lösungszentriert, sondern vollkommene Themaverfehlung. Es nervt langsam...
Klaus Wachtler schrieb: > hör endlich auf hier > alles platt zu quasseln. Das heißt Dir fällt dazu nichts mehr ein? Kein Problem Klaus. Kann ich doch akzeptieren. Klaus Wachtler schrieb: > Deine Kommentare hier sind aber nicht lösungszentriert, sondern > vollkommene Themaverfehlung. Und auch Deine Meinung! Klaus Wachtler schrieb: > Es nervt langsam... Tut mir immer echt furchtbar leid wenn ich (D)ein Weltbild angreife ;-) TriHexagon schrieb: > Also bei Bastlern sehe ich eigentlich mehr "der Weg ist das Ziel" oder > warum kauft sich der Bastler keine Fertiglösung? - weils (oft) billiger wird - weils (immer) passgenau wird - weil man es selbst kontrollieren und warten kann - weil man es selbst beliebig erweitern kann
Sicher kennen inzwischen 99,9% der Diskutanten Mobys Meinung. Sicher haben inzwischen 99,9% der Diskutanten begriffen, dass es niemandem, egal mit welchen Argumenten, gelingen wird, Moby von seiner Meinung abzubringen. Wer sich zu diesen 99,9% zählt, sollte sich vielleicht einfach wieder dem eigentlichen Thema des Threads zuwenden und Moby seine Meinung lassen. Wenn dieser dann die Diskussion immer noch stört, kann man weiter sehen ...
:
Bearbeitet durch Moderator
Ach Yalu, sieh dir doch um himmelswillen noch mal den Eingangstext an: cplusplusser schrieb: > Ich habe ziemlich viel Erfahrung mit C und Assembler. Ich bin auch ein > ganz passabler C++-Programmierer, inklusive der Standard Library. cplusplusser schrieb: > Wo ich aber an meine Grenzen komme: Etwas hardwarenahes zu schreiben und > trotzdem der C++-Philosphie treu zu bleiben. So. Da haben wir also eine Programmierer, der mit C und C++ aufgewachsen ist und sogar die Standard Library kennt. Fein für ihn. Aber zur Hardware, von der es in Programmiererkreisen heißt, sie würde leben und sie sei BÖSE, hat er offensichtlich wenig bis gar keine Beziehung. Er möchte aber der C++ Philosophie treu bleiben - was auch immer das sein mag. Unter Philosophie verstehe ICH was sehr viel anderes. Offenbar übersetzt sich das zu "ich möchte mit all den Angewohnheiten, die ich am PC so habe, eben auch die Dinge schreiben, die man auf einem Mikrocontroller braucht, um eine funktionable Firmware auf die Beine zu stellen. Blöderweise ticken die Uhren bzw. Systimer auf den diversen µC ziemlich anders als am PC, wo man sich dank Betriebssystem nicht wirklich um Hardwareangelegenheiten kümmern muß, sondern dies fertig vorgekaut vom BS vorgesetzt bekommt. Ich kann durchaus verstehen, daß man da vor seinem Chip in der Pappschachtel sitzt und erstmal keinen Fuß auf den Teppich kriegt. Und warum? Weil man ja seiner bisherigen Gewohnheit verhaftet ist. Auch du, Yalu hast das schon zum Besten gegeben, siehe Einrückungen in Python. Das geht wohl JEDEM so und deshalb haben wir hier Babylon. Aber anders als beim reinen Jonglieren mit diversen Programmiersprachen muß man sich beim µC eben vorrangig mit Hardware befassen und kann sich nicht so benehmen wie am PC. OK, man kann schon, aber was dabei rauskommt... Ich kann schon verstehen, wenn einem Praktiker wie Moby der Kragen platzt, wenn er solch extrem hehren Worte lesen darf: TriHexagon schrieb: > C++ ist eine Sprache die bestimmte Konzepte der > Software-Entwicklung zur Verfügung stellt. Klasse.. X-) Aber ich sehe das anders: Die Konzepte habe ich selber und von einer Programmiersprache erwarte ich keine Konzepte - sondern, daß sie mir vernünftige Ausdrucksmittel an die Hand gibt. Obendrein soll diese Sprache mir nicht meine durchaus wertvolle Arbeitszeit stehlen. Das sind völlig andere Prämissen als "Konzepte der Software-Entwicklung". Es wäre hier wohl besser, über Konzepte zur Gestaltung von Mikrocontroller-Firmware und Mikrocontroller-Anwendungen zu diskutieren. W.S.
W.S. schrieb: > Es wäre hier wohl besser, über Konzepte zur Gestaltung von > Mikrocontroller-Firmware und Mikrocontroller-Anwendungen zu diskutieren. Wenn du das diskutieren möchtest, wieso machst du dann nicht einen Thread auf, anstatt einen Thread zu kapern, in dem jemand etwas ganz anderes fragt? Naja egal, hier ist jetzt eh alles verloren. Nur schade, es mal eine interessante Frage war.
Die Eingangsfrage war eigentlich ganz bescheiden und bot kaum Anlass zu Kontroverse: cplusplusser schrieb: > Ich suche deshalb nach > Literatur zu Best Practices für hardwarenahes C++. So etwas im Stil von > "Effective C++" für Leute, die hardwarenah oder mit C-Interfaces > arbeiten müssen. Innherhalb von wenigen Postings wurde die Frage mit einer Literaturempfehlung beantwortet. Die anfänglich fruchtbare Diskussion über Sinn und Unsinn von C++ auf Mikrocontrollern war durchaus zu begrüssen, ist aber leider etwas zu sehr in einen Glaubenskrieg ausgeartet. W.S. schrieb: > Da haben wir also eine Programmierer, der mit C und C++ aufgewachsen ist > und sogar die Standard Library kennt. Fein für ihn. > > Aber zur Hardware, von der es in Programmiererkreisen heißt, sie würde > leben und sie sei BÖSE, hat er offensichtlich wenig bis gar keine > Beziehung. Was du so alles in meine Angaben hineininterpretierst. Ich verstehe das nicht: Ich habe bloss ungefähr angegeben, wie meine Kenntnisse sind, und schon wird man angefeindet. Warum immer gleich so aggressiv und auf den Mann gespielt? Zur Netiquette würde es doch eigentlich gehören, dass man wohlwollend und aktiv konstruktiv in eine Diskussion hinein geht. Immer mit der Intention, etwas zu lernen und/oder etwas zu vermitteln, unabhängig davon, ob vielleicht die eigene Meinung korrigert werden muss.
Yalu X. schrieb: > Wenn dieser dann die Diskussion immer noch stört Eventuell sollte den Forenregeln hinzugefügt werden, daß grundlegende Infragestellung des Sinn und Zwecks von Programmierkonzepten und der sich darin äußernde fehlende Respekt gegenüber der allgemein anerkannten Expertenmeinung zu ahnden ist ;-) Widerborstige, hartnäckig vorgetragene Argumente, denen nicht anders zu begegnen ist sind dann als "Störquelle" anzusehen... cplusplusser schrieb: > Glaubenskrieg Nix Glaubenskrieg. Erfahrungssache!
Warum müssen sich immer die Täter als Opfer darstellen? Wenn man ein hier diskutiertes Konzept nicht man, dann geht man eben zum nächsten Thread!
cplusplusser schrieb: > Was du so alles in meine Angaben hineininterpretierst. Ich verstehe das > nicht: Ich habe bloss ungefähr angegeben, wie meine Kenntnisse sind, und > schon wird man angefeindet. Ja, eben. Ich habe das ganz genau gelesen und präzise beantwortet. Da ist garnix angefeindet. Die Worte C++ Philosophie und treu bleiben kamen NICHT von mir, sondern von dir. Für mich wie auch für sehr viele andere Entwickler klingt das nach Ideologie. Warum willst du denn unbedingt C++ für ganz hardwarenahe Sachen verwenden? Warum??? Ist dir das so sehr wichtig, daß es Priorität vor allen anderen Aspekten hat? Warum versuchst du denn bloß nicht, anstatt dich auf eine Programmiersprache zu versteifen, lieber deine Gedanken auf eine tragfähige Struktur deiner Vorhaben zu konzentrieren? Das wäre sehr viel wichtiger. Täglich sehen wir hier Beiträge, wo Leute das Pferd konsequent vom Schwanze her aufzäumen und sie fühlen sich beleidigt, wenn man ihnen was sagt, was sie nicht gern hören wollen. Na klar, jeder hat mit jedem irgendwann mal ganz klein angefangen, aber warum muß man, wenn man in die µC Programmiererei einsteigen will, zu allererst nach C++ rufen anstatt sich in die Hardware einzulesen und sich dann zu überlegen, wie man selbige am sinnvollsten benutzt? Was ist dir wichtiger? Ein Stück Silizium zum Leben zu erwecken, so daß es zuverlässig das tut, was es soll - oder eine Art C++ Philosophie auf alles, was programmierbar ist, draufzudrücken? Schlaf mal drüber, ehe du in die Tasten haust. W.S.
Bastler schrieb: > Wenn man ein hier diskutiertes Konzept nicht mag Der Diskussion um Detailfragen fehlt zuweilen eine wichtige Dimension: Welchen Sinn und Zweck macht das Ganze überhaupt? Sinn und Zweck wiederum diskutiert man am besten bei den Detailfragen- ganz nah am Beispiel! Es geht auch weniger um 'mögen'. Höherer Ressourcen- und Bürokratiebedarf von OOP sind bei hardwarenahen Lösungen nunmal leider Fakten. So herrlich sich damit auch sonst intellektuell herumschwadronieren lässt. TO Peda als anerkannter Mann aus der Praxis hat im Nachbarthread "C++ auf MC" längst aufgegeben, ist Euch das schon aufgefallen ? ;-)
Yalu X. schrieb: > Sicher kennen inzwischen 99,9% der Diskutanten Mobys Meinung. Wenn man seine Postings so liest, bekommt man den Eindruck, daß das größte Programm, das er bisher geschrieben hat, eins ist, das lediglich eine LED blinken läßt. Zumindest basiert seine Meinung laut eigener Aussage auf solchen Programmen. Man muß ihm insofern recht geben, daß bei einem derart trivialen Programm C++ tatsächlich keinen Vorteil bietet. Praxisorientiert ist das allerdings nicht, denn in der Praxis tun die meisten Programme auch etwas.
Rolf Magnus schrieb: > daß das > größte Programm, das er bisher geschrieben hat, eins ist, das lediglich > eine LED blinken läßt. Zumindest basiert seine Meinung laut eigener > Aussage auf solchen Programmen. Wo liest Du das heraus? Weil ich die Blinkschaltung als transparentestes Beispiel für den Wahnwitz der OOP-Anwendung darauf auswähle? Was hier im Kleinen gilt verliert auch in größerem hardwarenahen Rahmen keine Gültigkeit.
Vielleicht hatte PeDa ganz praktisch keine Lust auf ASM-Dogmatiker. Und das schreibt einer, der von 8048 bis S390 auf allem möglichen in ASM programmiert hat und mit Freude immer wieder die Ergebnisse des GCC/G++ anschaut und froh ist, nicht selber die Register aussuchen zu müssen. Schreiner benutzen heute auch CNC-Maschinen, obwohl sie noch mit Säge und Hobel umgehen können. Aber nicht müssen!
Bastler schrieb: > auf allem möglichen in ASM > programmiert hat Sympathisch. 'Auf allem möglichen' ist quasi aber auch der "Fehler". Das erzwingt ja Hochsprache geradezu- wenngleich das hardwarenah nicht gerade C++ ist. Aber hättest Du die ganze Zeit auf einer erfolgreichen Architektur bleiben können (AVR), erübrigt sich mit der Zeit Bastler schrieb: > selber die Register aussuchen zu müssen Dann hättest Du die wenigen längst verinnerlicht bzw. fertige stets anwendbare Routinen in der Tasche. Bastler schrieb: > Schreiner benutzen heute auch CNC-Maschinen, obwohl sie noch mit Säge > und Hobel umgehen können. Ja, solcherlei Vergleiche sind sicher beliebt. Aber hier nicht unbedingt zielführend.
Lass dir mal erklären was der Unterschied zwischen einem Intel 8048 Microcontroller und einer IBM Mainframe /390 ist, dann verstehst du vielleicht, warum man nicht als Kompromiss beim AVR bleiben kann. Außerdem, der 8048 war vor über 30 Jahren, die Mainframe vor 20, da haben die Eltern mancher noch nicht mal geahnt, welche "Profis" sie mal großziehen werden.
Moby schrieb: > Wo liest Du das heraus? > Weil ich die Blinkschaltung als transparentestes Beispiel für den > Wahnwitz der OOP-Anwendung darauf auswähle? Du möchtest mit der simpelsten Programmieraufgabe zeigen, dass komplexe Programmierkonzepte unnötig sind. Das kann doch nicht wirklich dein ernst sein ;-)
cplusplusser schrieb: > Du möchtest mit der simpelsten Programmieraufgabe zeigen, dass OOP hardwarenah Quatsch ist, ja genau.
Das Blinkbeispiel ist eine wunderschöne Parallele zum Wahnsinn, alles mit Elektronik zu erschlagen. Die Archtektur der Wahl ist eine Kerze und eine Schachtel Streichhölzer daneben. Wesentlich weniger Umweltbelastung, billig und auch für Leute wie Moby intellektuell zu erfassen. Anzünden, Auspusten, Anzünden, Auspusten... Nachdem der Thread hier erfolgreich ramponiert ist bleibt für mich nur noch die Frage: Ist der Typ wirklich so verbohrt, oder trollt er nur?
:
Bearbeitet durch User
Klaus Wachtler schrieb: > Das Blinkbeispiel ist nur ein transparentes Beispiel gegen den Wahnsinn, auch alles Hardwarenahe in OOP erschlagen zu wollen. Nachdem Du lieber Klaus auf meine Argumente nur noch persönlich und beleidigend zu reagieren imstande bist, liefere dem TO doch lieber die gesuchten neue Designkonzepte und mach den Thread in seinem Sinne endlich erfolgreich.
Moby schrieb: > cplusplusser schrieb: >> Du möchtest mit der simpelsten Programmieraufgabe zeigen, dass > > OOP hardwarenah Quatsch ist, ja genau. Ok. Du nimmst also die vermutlich einfachste Aufgabe, die es gibt. Dann erklärst du, dass man die mit ein paar Assembler-Anweisungen lösen kann. Dann folgerst du daraus, dass man auf einem Mikrocontroller keine OOP braucht. Das ist doch etwa so, als würdest du behaupten, die Post brauche keine LKWs, weil ein Brief ja schliesslich in eine Jackentasche passt. Oder es brache keine Flugzeuge, weil zwischen den beiden Flughäfen deiner Stadt eine U-Bahn fährt.
Moby schrieb: > Aber hättest Du die ganze Zeit auf einer erfolgreichen Architektur > bleiben können (AVR), erübrigt sich mit der Zeit Dann sollte Atmel aber mal an seiner Preispolitik arbeiten. Einen 8k flash controller so derartigen Preisen anbieten zu wollen ist eine Frechheit. ebenso gibt es immernoch genug bugs und krankheiten in der AVR architektur.. seit jahren ... dazu fehlen dem AVR immernoch einige features um wirklich flexibel eingesetzt zu werden... Ja mit externer peripherie kann man was nachstricken .. aber wenn ich immer wieder merke das eine FTDI <-> uart lösung ziemlicher scheiß ist weil ich auf eine datenrate beschränkt werde .... oder ein ENJ28 SPI/LAN oder ein WLAN Modul ( doch wieder SPI/UART ) nutze ... was das ganze wieder arschlahm macht ... Moby schrieb: > Dann hättest Du die wenigen längst verinnerlicht bzw. fertige stets > anwendbare Routinen in der Tasche. Ich arbeite beruflich mit AVR ( 8-128k ) ARM ( cortex M0 -M3 ) blackfin ( BF5xx ) und brauche für einige dieser µC die selbe SW ebenso bedienen sich alle aus einer einzigen bibliothek in ASM hätte ich 3 verschiedene ASM befehlssätze lernen müssen .. 3 architekturen verstehen und die lib 3x schreiben müssen. ich habe nun alles in C und akzeptiere den overhead cplusplusser schrieb: > Du möchtest mit der simpelsten Programmieraufgabe zeigen, dass komplexe > Programmierkonzepte unnötig sind. Das kann doch nicht wirklich dein > ernst sein ;-) das will er .. egal in welchem thema/thread... er reduziert sich das so lange auf seine einfache I/O geschichte und sagt wiederholt das man nur ein "sbi" braucht ... daher glaube ich das seine programme nur aus ldr und sbi bestehen ... auch in einer leeren schreife packt er ein sbi nur um zu zeiegn das der µC noch mit dem pin wackeln kann ... ich glaube oder hoffe das weiß auch ein "C" oder C++ user ... aber der C / C++ user nimmt einfach die bitoperation ... es kommt dabei fast das selbe raus ... und akzeptiert feierlich das er die restlichen 20000 zeilen nicht in ASM schreiben muss ... denn wer schonmal einen IP stack geschrieben hat mit allen möglichen features .. der ist froh C/C++ benutzen zu dürfen... Moby schrieb: > OOP hardwarenah Quatsch ist, ja genau. ja .. das wissen doch auch die meisten die C/C++ anwenden .. das wurde hier ja auch oft gesagt .. evtl gibts einen findigen user der all seine I/O zugriffe durch ein ASM makro ersetzt nur um dich zufrieden zu stellen Klaus Wachtler schrieb: > Nachdem der Thread hier erfolgreich ramponiert ist bleibt für mich nur > noch die Frage: Ist der Typ wirklich so verbohrt, oder trollt er nur? beides ... er hat scheinbar erfahrungen mit AVRs .. und ASM programmierung .. zumindest wenn das programm nicht größer ist und sich das ganze auf weniger arbeitswege beschränkt. eine programm was temperatur ausliest und per uart versendet .. ich sage mal .. toll .. das hack ich in 5min zusammen und kanns dem praktikanten zeigen ... der sinnvolle anteil ist da 1% ... ich hab auf arbeit meist eierlegende wollmilchsäue als pflichtenheft auf dem tisch... da werden zig features reingepappt .. der eigentliche I/O anteil ist jedoch überschaubar gering .. ja ich könnte für diesen teil einen ASM treiber schreiben ... aber das wäre für mich nicht portabel ... denn nächste woche soll das feature auch auf dem cortex oder blackfin laufen ... da mein chef ja weiß das alle aus der selben lib bedient werden. für ihn heißt das : neu compilieren und fertig... ich für meinen teil finde C am schönsten .. man kann jeden bockmist verzapfen .. ist aber auch schuld ^^ ebenso lässt sich das aber portabel genug gestalten .. C++ bin ich seit studium nie so richtig warm geworden ... irgendwie komm ich da einfach nicht ran .. mag es auch daran liegen das ich das bisher niee 100% verstanden hab Javascript .. mag ich .. aufgrund der IP projekte .. sogar sehr gern
husten schrieb: > Javascript .. mag ich Ich auch! Besonders die drei scopes und dass es keinen blockscope gibt. So kann man andere leicht verwirren :-)
Moby schrieb: > Wo liest Du das heraus? Aus deinen Postings, die immer nur solche Trivialfälle beschreiben und daraus, daß du andere Beispiele mit größeren Programmen geflissentlich ignorierst. > Weil ich die Blinkschaltung als transparentestes Beispiel für den > Wahnwitz der OOP-Anwendung darauf auswähle? Ich könnte auch sagen, daß Assembler und ganz allgemein µCs ja völlig sinnlos und viel zu komplex sind. Da braucht man die passende Hard- und Software am PC, muß sich erst ein Programm schreiben, das assemblieren, dann auf den µC brennen u.s.w., und das, obwohl man eine Blinkschaltung doch auch ganz ohne sowas einfach mit einem ne555 machen kann. Also braucht man diese komplexen und umständlichen µCs gar nicht, denn dieses repräsentative Beispiel zeigt eindrucksvoll, daß ohne diese alles viel einfacher ist. Daß OOP vor allem beim Handhaben von komplexen Programmen was bringt, wurde ja schon gesagt. Daß C++ nicht nur aus OOP besteht, auch. Das trivialstmögliche Programm ist deshalb selbstverständlich vollkommen ungeeignet als Beispiel. Natürlich sind µC-Programme nicht so komplex wie die auf dem PC, aber in der Regel machen sie dann doch noch deutlich mehr als nur eine LED blinken zu lassen. Und mit einem ordentlichen Design ist der wirklich hardwarenahe Teil überschaubar und von der eigentlichen Funktionialität sauber getrennt. > Was hier im Kleinen gilt verliert auch in größerem hardwarenahen Rahmen > keine Gültigkeit. Doch, natürlich verliert es die. Ein Schäufelchen und ein Eimerchen reichen, um eine Sandburg zu bauen. Will ich aber was sinnvolles, wie z.B. ein Haus bauen, bekomme ich mit einem Eimer und einer Schaufel zwar vielleicht auch irgendwie eine Lehmhütte zusammen, aber ein ordentliches Haus wird's halt nicht. Es sollte doch klar sein, daß Erkenntnisse, die sich aus Trivialfällen ergeben, sich nicht einfach so auf die reale Welt übertragen lassen.
:
Bearbeitet durch User
husten schrieb: > ebenso gibt es immernoch genug bugs und krankheiten in > der AVR architektur.. seit jahren ... Na welche denn? Übertreib doch nicht so. husten schrieb: > eine FTDI <-> uart lösung ist eine Notlösung wenns ununbedingt USB sein muß. Ich selber setze sowieso auf modern Drahtlos. husten schrieb: > weil ich auf eine datenrate beschränkt werde .... > was das ganze wieder arschlahm macht ... Na mächtig gewaltig Egon. Hast Du Probleme. Mir langen in fast allen Steuerungsanwendungen 9600 Baud. husten schrieb: > Ich arbeite beruflich mit AVR ( 8-128k ) ARM ( cortex M0 -M3 ) blackfin > ( BF5xx ) Nun rutsche ich endgültig vor Ehrfurcht unter den Tisch... Wer nochmal hatte bestritten daß bei Portabilitätsansprüchen wie den Deinen eine Hochsprache sinnvoll ist? husten schrieb: > wer schonmal einen IP stack geschrieben hat Ist ja schon fast ein Running Gag kontra Asm. Mensch, der steckt heute schon in jedem 2€ China ESP8266 Modul drin. Sowas flanscht man bei Bedarf an und gut ist. husten schrieb: > der eigentliche I/O anteil ist jedoch überschaubar gering .. Dann bist Du bei diesem hardwarenahen Thema sowieso fehl am Platz. Und wenn Du mit C++ trotz Studium nicht viel anfangen kannst bist Du weder dem TO eine große Hilfe noch wirft das jetzt ein gutes Licht auf OOP.
Moby schrieb: > ... Der Typ erinnert mich irgendwie an einen gewissen Kurt. Fehlt nurnoch die Floskel: "da schwingt überhaupt nichts..."
Wenn du eh jede Funktion in externe Chips auslagerst und nur noch über RS232 antriggerst: wozu brauchst du dann effizientes ASM? BASIC würde es dafür auch tun... Jedenfalls verstehe ich langsam, wieso du alles mit AVR eschlagen kannst :-)
Rolf Magnus schrieb: > Es sollte doch klar sein, daß Erkenntnisse, die sich aus Trivialfällen > ergeben, sich nicht einfach so auf die reale Welt übertragen lassen. Interessant daß Du den Trivialfall nicht zur realen Welt zählst ;-) Rolf Magnus schrieb: > Will ich aber was sinnvolles, wie > z.B. ein Haus bauen, setzt sich das genauso aus funktionellen Einzelteilen bis hin zum Ganzen zusammen. Rolf Magnus schrieb: > aber ein ordentliches > Haus wird's halt nicht. Da mach Dir mal keine Sorgen. Wenn ich meine Häuser nicht fertig bekommen würde hätte ich nicht schon jahrelangen Spaß am Hobby ;-) Rolf Magnus schrieb: > Das > trivialstmögliche Programm ist deshalb selbstverständlich vollkommen > ungeeignet als Beispiel. Es ist sogar perfekt geeignet. So wie man nämlich seine Portbits unkompliziert auf Anweisung setzt initialisiert man auch seine Timer, Interrupts, serielle I/O usw. und schon kann die Kette Eingabe/Verarbeitung/Ausgabe in die Gänge kommen. Bis auf konkrete Anweisungen = 1:1 Abbildung der Funktionalität muß da nichts weiter stehen. Geistige OOP-Höhenflüge samt zugehörigem Schreibaufwand: Unnötig. Überflüssig. Bis hin zum Krampf. Rolf Magnus schrieb: > Daß OOP vor allem beim Handhaben von komplexen Programmen was bringt, > wurde ja schon gesagt. Na darauf könnten wir uns ja notfalls noch einigen, obwohl ich solche komplexen, datenintensiven Programme eher auf PC-Ebene angesiedelt sehe. Ich möchte aber nochmal in Erinnerung rufen worauf ich mich stets beziehe: Moby schrieb: > Jedenfalls was eine typische 8-Bit > Controllerschaltung mit überschaubarer Funktionalität anbetrifft.
Moby schrieb: > Ich möchte aber nochmal in Erinnerung rufen worauf ich mich stets > beziehe: > > Moby schrieb: >> Jedenfalls was eine typische 8-Bit >> Controllerschaltung mit überschaubarer Funktionalität anbetrifft. Ja, du. Aber das ist nicht die reale Welt und erst recht nicht das Berufsumfeld. Schön, dass deine Welt so überschaubar ist. Meingott, jetz antworte ich schon wieder auf die immer gleichen "Argumente". Wie war das? Never discuss with an Idiot...
Klaus Wachtler schrieb: > Jedenfalls verstehe ich langsam, wieso du alles mit AVR eschlagen kannst > :-) Hattest Du Dir nicht um Threadkaperungen Sorgen gemacht? Oder waren es dann doch Befürchtungen um Dein OOP-Weltbild? Ich meine, nachdem Du zum Thema des TO hier rein gar nichts beigetragen hast. Also Klaus, Du enttäuscht mich besonders ;-(
cplusplusser schrieb: > Das ist doch etwa so, als würdest du behaupten, die Post brauche keine > LKWs, weil ein Brief ja schliesslich in eine Jackentasche passt. Nein, du willst unbedingt ein Brief mit LKW zustellen, anstatt einen Postboten hinzuschicken. > Oder es > brache keine Flugzeuge, weil zwischen den beiden Flughäfen deiner Stadt > eine U-Bahn fährt. Nein, du willst unbedingt von einem Flughafen zum anderen fliegen, anstatt die U-Bahn zu nehmen.
Moby schrieb: > Also Klaus, Du enttäuscht mich besonders ;-( Ich habe in dem Forum zu C++ schon etwas mehr beigetragen als die meisten andern, vor allem etwas differenzierter als dein Getrolle. Liest nur nicht jeder - was mir auch nicht weh tut. Aber dann bitte nicht blöd herumtrollen. Vor allem scheinst du mein "OOP-Weltbild" nicht zu kennen.
:
Bearbeitet durch User
Moby, kann es sein dass du bei C++ nur an OOP denkst. Dann bist du aber wirklich naiv. Ob nun OOP für 8Bit µCs sinnvoll ist oder nicht, ist eine ganz andere Diskussion. OOP ist nur ein Paradigma. C++ beherrscht mehr als nur eines (genau genommen lässt sich in C++: generisch, imperativ, objektorientiert, prozedural, strukturiert programmieren). Templates sind z.B. eine hübsche Möglichkeit Code zu sparen ohne weiteren Overhead. Man schreibt einmal eine Funktionalität und diese lässt sich dann auf alle Datentypen anwenden, solang das mit dem jeweiligen Datentyp Sinn ergibt. Das ist Effizienz! Ein geniales Konzept, was man schnell vermisst (auch auf 8Bit µCs). Und C++ kann noch viel mehr.
Moby schrieb: > Rolf Magnus schrieb: >> Es sollte doch klar sein, daß Erkenntnisse, die sich aus Trivialfällen >> ergeben, sich nicht einfach so auf die reale Welt übertragen lassen. > > Interessant daß Du den Trivialfall nicht zur realen Welt zählst ;-) Kapierst du es nicht? Du reduzierst es auf den Trivialfall und folgerst dann daraus, es sei allgemeingültig. Ein Kreis mit Radius 0 hat die Fläche 0, also haben alle Kreise die Fläche 0, also brauche ich diese blöde Formel mit Pi und so nicht zur Flächenberechnung. Aber Moby, ganz ehrlich: Setz dich mal 5 Minuten hin und denke darüber nach, was du hier gerade abziehst. Wenn du dich im realen Leben in einem Fachgespräch so gibst, dann wundert mich nicht, wenn du danach in Ausbildung&Beruf einen Thread startest mit dem Titel "Warum nimmt mich auf Arbeit keiner Ernst?". Es ist ja schön und gut, wenn man in einer Diskussion seine Position verteidigt. Und du liegst auch nicht in allen Punkten falsch. Aber wer so stur auf einzelnen Positionen herumreitet, obwohl ihm schon 5 Leute gesagt haben, dass dies nun wirklich der falsche Ansatz ist, der sollte echt mal ein wenig herauszoomen und sich fragen, ob es jetzt noch um die Sache geht oder nur noch um die Angst vor einem Gesichtsverlust.
cplusplusser schrieb: > Ok. Du nimmst also die vermutlich einfachste Aufgabe, die es gibt. Dann > erklärst du, dass man die mit ein paar Assembler-Anweisungen lösen kann. > Dann folgerst du daraus, dass man auf einem Mikrocontroller keine OOP > braucht. Na ja, fast den Nagel auf den Kopf getroffen. Obwohl Du wieder mal die Eingrenzung auf Hardwarenah unterschlagen hast. Und meine Eingrenzung Moby schrieb: > Jedenfalls was eine typische 8-Bit > Controllerschaltung mit überschaubarer Funktionalität anbetrifft. Um mit Deinen hübschen Beispielen zu sprechen, ja, ein paar Briefe können in der Jackentasche durchaus schneller transportiert werden und der Post-LKW in der Garage bleiben- wie auch die U-Bahn Flugzeuge obsolet machen kann. Denn der Fall, daß sich quasi alles in einer überschaubaren Stadt abspielt tritt bei obigem Schaltungstyp in Millionen Steuerungsanwendungen wesentlich häufiger auf als in Deinem Vergleich Entfernungen realer Briefe und Orte überbrückt werden müssen ;-) Manchmal ist es leider aber so, daß Flugzeuge und Postautos (ARM & OOP) schon draußen stehen und auf Anweisung benutzt werden müssen. Glücklicherweise ist der freie Bastler aber in der Wahl seiner (einfachsten) Mittel frei ;-)
>Der Typ erinnert mich irgendwie an einen gewissen Kurt. >Fehlt nurnoch die Floskel: "da schwingt überhaupt nichts..." Mich erinnert es eher an das hier: http://www.youtube.com/watch?v=akfz5Fw-pZI
TriHexagon schrieb: > Templates sind z.B. eine hübsche Möglichkeit Code zu sparen ohne > weiteren Overhead. Man schreibt einmal eine Funktionalität und diese > lässt sich dann auf alle Datentypen anwenden, solang das mit dem > jeweiligen Datentyp Sinn ergibt. Das ist Effizienz! Nun TriHexagon, effizient ist für mich kleinster/schnellster Code mit minimalem Schreibaufwand der die Funktionalität 1:1 abbildet, ohne jedes weitere Hochsprachen-Bimbamborium. Ich mach mir weder wegen Datentypen noch irgend einem anderen C(++) Konstrukt Sorgen, glaub mir. cplusplusser schrieb: > Angst vor einem Gesichtsverlust Die plagt mich am allerwenigsten ;-) cplusplusser schrieb: > obwohl ihm schon 5 Leute > gesagt haben, dass dies nun wirklich der falsche Ansatz ist, Wie war das doch gleich nochmal mit den Millionen Fliegen die nicht irren? Schau cplusplusser, ich wünsch Dir ja viel Freude bei Deiner unbedingten C++ Anwendung auf alles nur Denkbare. Aber Du siehst ja selbst, viele Designkonzepte sind hier diesbezüglich nicht zusammengekommen ;-(
Moby schrieb: > Nun TriHexagon, effizient ist für mich kleinster/schnellster Code mit > minimalem Schreibaufwand der die Funktionalität 1:1 abbildet, ohne jedes > weitere Hochsprachen-Bimbamborium. Ich mach mir weder wegen Datentypen > noch irgend einem anderen C(++) Konstrukt Sorgen, glaub mir. Für den einzigen bekannten Anwendungsfall in Moby's Welt (LED ein/aus) ist das sicher der richtige Weg. Für alles andere hat man Hochsprachen und Programmierkonzepte entwickelt.
cplusplusser schrieb: > Für den einzigen bekannten Anwendungsfall in Moby's Welt (LED ein/aus) > ist das sicher der richtige Weg. ... und noch für soviel mehr! Immerhin schränkst Du Deinen C++ Anspruch nun schon etwas ein, bravo. Aus einer LED werden zwei ... ;-)
bal schrieb: > Fehlt nurnoch die Floskel: "da schwingt überhaupt nichts..." Darauf kannst Du lange warten... Meine vielen AVRs vibrieren nur so vor Arbeitsfreude. Und manche sogar schon viele Jahre lang ;-)
Klaus Wachtler schrieb: > Ja gut, einen Dildo kann man leicht in ASM programmieren :-) Dieses Niveau hatte ich jetzt bei Dir nicht angenommen. Du enttäuscht mich schon wieder, Klaus ;-)
Halt dem Niveau angemessen, den der Thread inzwischen hat. Er ging ja mal interessant los.
PS: Vielleicht ist das ja endlich mal ein Anlass, die letzten n-1 Beiträge zu entsorgen...
falls es wen interessiert, hier ein link zu recht extremem C++ Code, der auch auf atmegas läuft... viel spass beim lesen ;-) https://github.com/ambrop72/aprinter
Moby's Argumentation wurde schon früh im Thread etwas gewagt, aber mittlerweile ist das doch nur noch trollig.
Wie schon erwähnt, Hessi James passt ganz gut auf Mobby. Lieber nicht mit ihm anlegen: http://www.youtube.com/watch?v=akfz5Fw-pZI Entschuldigt, wenn ich jetzt doch eine On-Toppic Frage stelle. Bei dem geposteten Link https://github.com/ambrop72/aprinter/tree/master/aprinter/base wird der Code z.Teil in die Header-Files gesteckt. Geht das? Macht das Sinn?
Klar geht das - der Header wird doch eh nur textuell kopiert/eingefügt.Ob das Sinn macht, steht auf einem anderen Blatt und kommt immer drauf an... "With great power comes great responsibility" ;)
Franz schrieb: > Wie schon erwähnt, Hessi James passt ganz gut auf Mobby. Lustig. Immerhin bringt der Titelheld Leben in die vertrocknete Landschaft. Was der Situation nicht gewachsen ist geht eben unter ;-) cplusplusser schrieb: > mittlerweile ist das doch nur noch trollig. Man muß doch nicht alles als "trollig" abqualifizieren nur weils nicht ins persönliche Weltbild paßt. Ich wäre mit solcherlei Abwertungen eher vorsichtig, es sei denn die Absicht ist so eindeutig wie bei den letzten Aussagen eines gewissen Klaus.
Franz schrieb: > Entschuldigt, wenn ich jetzt doch eine On-Toppic Frage stelle. > Bei dem geposteten Link > https://github.com/ambrop72/aprinter/tree/master/aprinter/base > wird der Code z.Teil in die Header-Files gesteckt. Geht das? Macht das > Sinn? Das sind Makros und Templates. Die können nicht einzeln kompiliert und gelinkt werden. Denn die Makros werden vom Präprossor verarbeitet und bei den Templates muss der Compiler die Implementierung kennen (so kann er dazu auch noch einiges weg optimieren).
Womit wir übrigens wieder BTT wären: Wenn der Compiler z.B. entscheidet, welche Sachen er inlined und welche nicht, dann habe ich abhängig von den Randbedingungen wie zB. 'wenig RAM und einigermaßen viel Flash' doch eventuell ein Problem, das in diesem Fall von einem C++-Konzept induziert wird, oder sehe ich das falsch?
:
Bearbeitet durch User
In aller Regel kann man die Grenze, bis zu der tatsächlich inline-Code erzeugt wird, per Compileroption verschieben. Damit kann man von Fall zu Fall Flash gegen Laufzeit tauschen in gewissen Grenzen.
Tobias K. schrieb: > Womit wir übrigens wieder BTT wären: Wenn der Compiler z.B. entscheidet, > welche Sachen er inlined und welche nicht, dann habe ich abhängig von > den Randbedingungen wie zB. 'wenig RAM und einigermaßen viel Flash' doch > eventuell ein Problem, das in diesem Fall von einem C++-Konzept > induziert wird, oder sehe ich das falsch? Umgekehrt. Wenn du dein Programm auf einer höheren Abstraktionsebene definieren kannst, dann gibst du dem Compiler auch viel mehr Raum für Optimierungen. Wenn die Randbedingung von "genügend Zeit, Speicher knapp" auf "so schnell wie möglich, reichlich Speicher" wechselt, dann schreibt Moby seinen Code garantiert komplett neu. Moby schrieb: > Lustig. Immerhin bringt der Titelheld Leben in die vertrocknete > Landschaft. Was der Situation nicht gewachsen ist geht eben unter ;-) Untergehen tun vorallem Trolle, wenn sie nicht gefüttert werden. Leider bist du auf ein äusserst diskutierfreudiges Publikum gestossen mit deiner Trollerei. (Ich hoffe jedenfalls, du bist ein Troll. Falls nicht: Wenn ich nur daran denke, dass man im Berufsleben auf jemanden treffen könnte, der so argumentiert wie du, na dann, gute Nacht...)
cplusplusser schrieb: > Untergehen tun vorallem Trolle, wenn sie komplexe, fehleranfällige, rechenzeit- und speicherbelegende Programmiertechniken predigen, die Millionen einfachen 8-Bit Power Steuerungslösungen nur sinnlos aufblähen und verkomplizieren. Leider bist Du auf einen Praktiker aus Leidenschaft gestoßen, der sich damit für vielfältigen eigenen Bedarf schon zulange beschäftigt. Du kannst Dich aber praktischen Problemstellungen gerne weiter versuchen philosophisch anzunähern- vielleicht findest Du doch noch einen ganz neuartigen Zugang zu deren Lösung ;-)
Moby schrieb: > komplexe, fehleranfällige, rechenzeit- und speicherbelegende > Programmiertechniken predigen, Wogegen deine Technik (wie du sie oben beschrieben hast, "IP-Stack") ist: Du programmierst alles in ASM, und wenn es dir zu Kompliziert wird, nimmst du einen zweiten µC (nicht unbedingt einen AVR) für den jemand anders in C(++) die Firmware geschrieben hast, und verbindest ihn mit deinem ASM-AVR...
Moby schrieb: > husten schrieb: >> wer schonmal einen IP stack geschrieben hat > > Ist ja schon fast ein Running Gag kontra Asm. > Mensch, der steckt heute schon in jedem 2€ China ESP8266 Modul drin. > Sowas flanscht man bei Bedarf an und gut ist. vorgabe war : LAN .. was soll ich also mit einem WLAN chip? ebenso vorgabe : billig ... da ist kein ct übrig für ein Wiznet oder anderen fertigen LAN chip .. hmm was nun ? AVR+ ENJ28? zusammen leider teurer als ein Cortex M3+phy ... und ebenso zu langsam ... denn im PH steht vorgabe : datenrate xxMbit/s damit bleiben nur die total unnötigen 32bitter übrig ... also PIC32,Cortex M usw ... cplusplusser schrieb: > Wenn ich nur daran denke, dass man im Berufsleben auf jemanden treffen > könnte, der so argumentiert wie du, na dann, gute Nacht...) :-D Hat er denn ein Berufsleben? bisher lese ich nur : Moby schrieb: > Glücklicherweise ist der freie Bastler aber in der Wahl seiner > (einfachsten) Mittel frei ;-) und hat demnach auch keine erfahrung mit der industrieellen entwicklung .. evtl wo sogar mehrere leute an einem Projekt sitzen und software schreiben sollen. denn spätestens da .. ist C/C++ Moby schrieb: > Manchmal ist es leider aber so, daß Flugzeuge und Postautos (ARM & OOP) > schon draußen stehen und auf Anweisung benutzt werden müssen. manchmal auf anweisung .. manchmal weil es die lesbarkeit bei größeren Projekten deutlich verbessert... wer schonmal in 1-5jahre alten quellcodes ( mehr als ein sbi ) features nachgestrickt hat kennt das da möchte ich nicht in tausenden zeilen ASM stellen suchen um etas zu ändern. in C / C++ geht soetwas recht einfach ..
Moby schrieb: > Leider bist Du auf einen Praktiker aus Leidenschaft gestoßen, der sich > damit für vielfältigen eigenen Bedarf schon zulange beschäftigt. Vielfältigen eigenen Bedarf? Bisher hast du nur immer von deiner LED erzählt. Was du sonst noch so in Assembler geschrieben hast, davon liest man kein Wort. (Wobei das Wort Praktiker ja sowieso ein gerne gebrauchter Euphemismus für Leute ist, die ihre Projekte ohne wirklichen Durchblick hinfrickeln...)
husten schrieb: > wer schonmal in 1-5jahre alten quellcodes ( mehr als ein sbi ) > features nachgestrickt hat kennt das > da möchte ich nicht in tausenden zeilen ASM stellen suchen um etas zu > ändern. > in C / C++ geht soetwas recht einfach .. Aber auch nur wenn es reichlich kommentiert ist... husten schrieb: > und hat demnach auch keine erfahrung mit der industrieellen entwicklung > .. evtl wo sogar mehrere leute an einem Projekt sitzen und software > schreiben sollen. > denn spätestens da .. ist C/C++ Auch wieder ausreichend kommentiert. Wir haben in unseren Projekten ein 70 zu 30 Anteil, also 70% Code und mindestens 30% Prozent Kommentare. Niemanden interessiert es da besonders kurzen Code zu sehen, aber alle wollen wissen warum etwas gerade so geschrieben ist und was es genau bewirkt. cplusplusser schrieb: > Optimierungen. Wenn die Randbedingung von "genügend Zeit, Speicher > knapp" auf "so schnell wie möglich, reichlich Speicher" wechselt, dann > schreibt Moby seinen Code garantiert komplett neu. Und das hat mit C++ was genau zu tun ? Kann man mit plain C auch. C++ und Hardware haben genau nichts miteinander zu tun - weder Vor- noch Nachteile im Vergleich zu plain C. Um noch einmal deinen Beispiel zu nehmen: Die Post wird auch keinen LKW nehmen um einen Brief zuzustellen, nur weil der Postbote älter als LKW ist, keine 8-Gang Schaltung, Navi und Radio hat.
Auch auf die Gefahr hin, daß die von cplusplusser gesuchten Designkonzepte hier irgendwann völlig verdeckt werden ;-) ... Ahab schrieb: > Wogegen m(d)eine Technik (wie du sie oben beschrieben hast, "IP-Stack") > ist vorhandenes nicht zweimal zu erfinden wenn es günstig genutzt werden kann (zählt zum Thema Effizienz bei der Problemlösung). Wie das Innenleben angeflanschter Hardware ausschaut ist dann absolut zweitrangig. Daß komplexe Programme mit vielerlei Datenstrukturen anders als mit Asm anzupacken sind bestreitet auch niemand. husten schrieb: > damit bleiben nur die total unnötigen 32bitter übrig ... Wo ist das Problem, wenn die Leistung wirklich erforderlich ist? Die Stückzahlen vermehrte Softwarekosten wieder reinholen? Das ist weit weg vom Thema, C++ in jeder Situation anwenden zu wollen. husten schrieb: > und hat demnach auch keine erfahrung mit der industrieellen entwicklung > .. evtl wo sogar mehrere leute an einem Projekt sitzen und software > schreiben sollen. > denn spätestens da .. ist C/C++ Ja! Ja doch! Dann nutzt doch C++ ! Das ist aber wieder weit weg vom Thema, C++ in jeder Situation anwenden zu wollen. husten schrieb: > weil es die lesbarkeit bei größeren Projekten Ja! Ja doch! Größere Projekte! husten schrieb: > da möchte ich nicht in tausenden zeilen ASM stellen suchen Ich kann dazu nur feststellen: Asm hat hinsichtlich der Dokumentierbarkeit keinerlei Nachteile. Es ist auch da die Frage wie man ein Projekt aufbaut. Prädestiniert ist Asm aber für kleinere Sachen. Sachen aber, die in die Millionen gehen! cplusplusser schrieb: > die ihre Projekte ohne wirklichen Durchblick > hinfrickeln Danke. Und Dir fehlt der Durchblick, was Dir hier einige Gegenspieler ans Herz gelegt haben. Nimmst vieles nicht zur Kenntnis. Hast gar nicht verstanden, was Dir das Beispiel mit der Blinkschaltung sagen soll oder willst es eben nicht. Besser wäre wirklich W.S. schrieb: > Schlaf mal drüber, ehe du in die Tasten haust. Tut mir langsam leid, daß ich andauernd kaltes Wasser in Deine heiße C++ Begeisterung gieße.
Marc Vesely schrieb: > husten schrieb: >> wer schonmal in 1-5jahre alten quellcodes ( mehr als ein sbi ) >> features nachgestrickt hat kennt das >> da möchte ich nicht in tausenden zeilen ASM stellen suchen um etas zu >> ändern. >> in C / C++ geht soetwas recht einfach .. > > Aber auch nur wenn es reichlich kommentiert ist... > > husten schrieb: >> und hat demnach auch keine erfahrung mit der industrieellen entwicklung >> .. evtl wo sogar mehrere leute an einem Projekt sitzen und software >> schreiben sollen. >> denn spätestens da .. ist C/C++ > > Auch wieder ausreichend kommentiert. Wir haben in unseren Projekten ein > 70 zu 30 Anteil, also 70% Code und mindestens 30% Prozent Kommentare. > Niemanden interessiert es da besonders kurzen Code zu sehen, aber alle > wollen wissen warum etwas gerade so geschrieben ist und was es genau > bewirkt. das ist auch eine starke abhängigkeit vopm "C(C++" stil ... selbst schon erlebt ... meine kollegen schreiben alles in zig "states" und unterteilen jedes noch so kleine fitzel in "states" oder "events" ich mag funktionszeiger und verschachtele dadurch alles mögliche als callback funktion... im groben und ganzen isses aber egal ... wenn die variablen/funktionen halbwegs brauchbare namen haben. wenn man mit ebenso cryptischen namen anfängt oder nur mit i,k,l... x,y,z um sich wirft ... nunja ... das erschwert die lesbarkeit ebenso muss man ja nicht alles komprimieren dafür gibts dann IOCC ^^ http://www0.us.ioccc.org/2013/cable2/cable2.c
Marc Vesely schrieb: > C++ und Hardware haben genau nichts miteinander zu tun - weder Vor- > noch Nachteile im Vergleich zu plain C. Nach diesem Thread noch sowas zu behaupten, finde ich eine schlichte Frechheit. Immerhin wurden genügend Beispiele gebracht, wo C++ auch für Mikrocontroller eine gute Option ist und wo man auch die Hardware-Ebene noch beherrscht. Mag sein, dass man C++ nicht mag oder für seine Projekte Overkill findet, ok. Moby schrieb: > Hast gar nicht > verstanden, was Dir das Beispiel mit der Blinkschaltung sagen soll oder > willst es eben nicht. Besser wäre wirklich Mit einem Trivialfall kann man die Welt nicht erklären, das merkst du aber irgendwie nicht. Wenn ich mir zudem ansehe, wer eher meine und wer eher deine Position teilt, dann ist für mich eigentlich alles klar :-)
cplusplusser schrieb: > Nach diesem Thread noch sowas zu behaupten, finde ich eine schlichte > Frechheit. Immerhin wurden genügend Beispiele gebracht, wo C++ auch für Bitte um ein einziges Beispiel wo C++ beim Hardwarezugriff Vorteile gegenuber plain C bringt.
Marc Vesely schrieb: > Bitte um ein einziges Beispiel wo C++ beim Hardwarezugriff Vorteile > gegenuber plain C bringt. inline (ist bei gcc z.B. auch mit C möglich, aber eben nicht portabel - in C++ im Standard)
Marc Vesely schrieb: > Bitte um ein einziges Beispiel wo C++ beim Hardwarezugriff Vorteile > gegenuber plain C bringt. Und dann bitte ein einziges Beispiel, wie man mit einer Spülmaschine nach dem Verzehr einer einzelnen Pizza das Geschirr schneller sauber hat als wenn man von Hand spült.
Wobei der Hauptvorteil von C++ natürlich nicht darin liegt, besseren Code zu erzeugen, sondern besseren/strukturierteren/wartbareren/... Quelltext ermöglicht, im Bestfall ohne Nachteile bzgl. Effizienz. Insofern ist "kein besserer Code" noch kein Argument gegen C++.
Marc Vesely schrieb: > cplusplusser schrieb: >> Nach diesem Thread noch sowas zu behaupten, finde ich eine schlichte >> Frechheit. Immerhin wurden genügend Beispiele gebracht, wo C++ auch für > > Bitte um ein einziges Beispiel wo C++ beim Hardwarezugriff Vorteile > gegenuber plain C bringt.
1 | class ScopedInterruptGuard {
|
2 | public: |
3 | ScopedInterruptGuard() |
4 | {
|
5 | reg = SREG; |
6 | cli(); |
7 | } |
8 | ~ScopdedInterruptGuard() |
9 | {
|
10 | SREG = reg; |
11 | } |
12 | private: |
13 | std::uint8_t reg; |
14 | }; |
15 | |
16 | […] |
17 | {
|
18 | // atomic block |
19 | ScopedInterruptGuard atomic; |
20 | […] |
21 | } |
Klaus Wachtler schrieb: > Insofern ist "kein besserer Code" noch kein Argument gegen C++. Ich habe nichts gegen C++, aber... cplusplusser schrieb: > Wo ich aber an meine Grenzen komme: Etwas hardwarenahes zu schreiben und > trotzdem der C++-Philosphie treu zu bleiben. Was für Philosophie ? Hardwarenah heisst vor allem, dass der C++ Code nicht einmal zwischen M8 und M32 portabel ist, mit XMEGA und Tiny will ich gar nicht erst anfangen. Also ist das ganze Gelabber von C++ und Hardwarenah oder Portabel von Anfang an Unsinn. Weder Assembler, noch C und erst Recht der C++ sind auf Hardwareebene portabel, Schluss, Ende. Also, C++ dort benutzen, wo es wirklich Sinn hat und natürlich hat da niemand etwas dagegen, weder gegen C++ noch gegen seine Anwendung. Aber eine höhere Sprache mit Gewalt in Bereiche zwingen, wofür die überhaupt nicht gedacht war und dann auch noch lauthals verkünden: Ich habe das Rad neu erfunden, mein C++ Code macht fehlerlos das, wofür es gar nicht gedacht war. Dass man dasselbe auch in plain C oder sogar noch besser in Assembler schreiben könnte, ist ja unwichtig. Natürlich kommt kein normaler Mensch auf die Idee, irgendetwas kompliziertes im Assembler zu schreiben, warum ist für TO der umgekehrte Fall normal ? Und dann denke ich verkehrt...
Marc Vesely schrieb: >> class ScopedInterruptGuard { > > Vorteil gegenüber plain C ? Viel besser lesbar. Sofort klar, was passiert. Der Guard wird automatisch wieder entfernt. Kein Risiko eines Resource Leaks. Finde ich ein sehr schönes Beispiel! Man kann genau das schreiben, was man auch denkt, nämlich: "Dieser Codeabschnitt muss von einem Guard geschützt werden."
Marc Vesely schrieb: > Hardwarenah heisst vor allem, dass der C++ Code nicht einmal zwischen > M8 und M32 portabel ist, mit XMEGA und Tiny will ich gar nicht erst > anfangen. > > Also ist das ganze Gelabber von C++ und Hardwarenah oder Portabel von > Anfang an Unsinn. > > Weder Assembler, noch C und erst Recht der C++ sind auf Hardwareebene > portabel, Schluss, Ende. Das ist einfach quatsch. Das Beispiel mit dem Guard zeigt es doch schon: In C++ kannst du diesen Guard als Template für jeden Prozessortyp, den du brauchst, spezialisieren. Im restlichen Code hingegen kannst du den Guard immer auf die genau gleiche komfortable Art und Weise verwenden.
cplusplusser schrieb: > In C++ kannst du diesen Guard als Template für jeden Prozessortyp, den > du brauchst, spezialisieren. LOL.
cplusplusser schrieb: > Finde ich ein sehr schönes Beispiel! Ich komme auch damit gut klar:
1 | ATOMIC_BLOCK(ATOMIC_FORCEON) |
2 | {
|
3 | ...
|
4 | }
|
apr schrieb: > gegenuber plain C bringt. > class ScopedInterruptGuard { > public: > ScopedInterruptGuard() > { > reg = SREG; > ... > // atomic block > ScopedInterruptGuard atomic; > […] > } Schönes Beispiel. So was nehme ich auch immer wieder gern in Threads oder Task die untereinander über Mutexe verriegelt sind. Die Methoden an beliebiger Stelle mit return verlassen zu können ohne sich ums Aufräumen kümmern zu müssen hat schon seinen Charme.
Marc Vesely schrieb: > cplusplusser schrieb: >> In C++ kannst du diesen Guard als Template für jeden Prozessortyp, den >> du brauchst, spezialisieren. > > LOL. Soso. Dann erzähl doch mal, wie du sowas portierbar löst.
Ralf G. schrieb: > ATOMIC_BLOCK(ATOMIC_FORCEON) Das mag für dieses eine Beispiel zutreffen. Aber auch nur genau dafür. Es ging hier um eine beispielhafte Technik und nicht mehr. Ich glaube nicht das das Beispiel dazu dienen sollte C++ als die überlegene Sprach raus zu stellen. Wenn du das vergleichst solltest du aber auch die #ifdef-Orgie aus der atmic.h in den Vergleich einbeziehen.
cplusplusser schrieb: >>> In C++ kannst du diesen Guard als Template für jeden Prozessortyp, den >>> du brauchst, spezialisieren. >> >> LOL. > > Soso. Dann erzähl doch mal, wie du sowas portierbar löst. LOL. Sage ich doch die ganze Zeit, dass so etwas Hardwarenahes eben nicht portierbar ist.
Der guard ist zwar schön und gut. Aber hardwarenah ist er nicht wirklich. Die Funktionen disable_int, getSREG und derSREG sind das. Und wie du selbst sagst, die müssen neu geschrieben werden. Dass c++ funktioniert bestreitet niemand nur eben nicht so wie es sich hier manche wünschen.
temp schrieb: > die #ifdef-Orgie Gut, die #ifdef-Orgie ist jetzt etwas länger, als die Guard-Klasse. Ralf G. schrieb: > cplusplusser schrieb: >> Finde ich ein sehr schönes Beispiel! Darauf hatte ich mich bezogen.
:
Bearbeitet durch User
Ralf G. schrieb: > cplusplusser schrieb: >> Finde ich ein sehr schönes Beispiel! > > Ich komme auch damit gut klar: ATOMIC_BLOCK(ATOMIC_FORCEON) > { > ... > } ... was aber kein plain C ist, sondern eine gcc extension
1 | #define ATOMIC_FORCEON uint8_t sreg_save \
|
2 | __attribute__((__cleanup__(__iSeiParam))) = 0
|
Marc Vesely schrieb: > Also ist das ganze Gelabber von C++ und Hardwarenah oder Portabel von > Anfang an Unsinn. > > Weder Assembler, noch C und erst Recht der C++ sind auf Hardwareebene > portabel, Schluss, Ende. in dem sinne ... muss man recht geben das ist wohl wahr ... wenn man das allein auf die µC interne peripherie begrenzt ist das 1: meist nie portabel 2: muss man eh immer neu machen ( siehe "BSP" ) allein die register vom AVR unterscheiden sich teils doch schon ... der eine TIMSK der andere TIMSK1 usw ... sicher kann man sowas mit präprozessoranweisungen abfangen .. aber je mehr µC typen dazukommen desto verwirrender im grunde ist das aber möglich ... wenn man aber wie weiter oben gesagt eh eine echte applikation laufen hat, ist es egal ob man die Hardwarenahen I/Os in ASM, C oder C++ schreibt man wird sich für das entscheiden was man eh am besten kann bzw sich nach dem rest richten... bzw inline ASM schreiben
Marc Vesely schrieb: > cplusplusser schrieb: >>>> In C++ kannst du diesen Guard als Template für jeden Prozessortyp, den >>>> du brauchst, spezialisieren. >>> >>> LOL. >> >> Soso. Dann erzähl doch mal, wie du sowas portierbar löst. > > LOL. > Sage ich doch die ganze Zeit, dass so etwas Hardwarenahes eben > nicht portierbar ist. Natürlich ist der direkte Hardwarezugriff nicht portierbar. Genau deshalb baut sich ja jeder vernünftige Programmierer eine Abstraktion über der Hardware-Schicht. Und mit C++ kann man das, wie gezeigt wurde, sehr elegant lösen. Aber du schreibst vermutlich lieber den gesamten Code neu.
husten schrieb: > wenn man aber wie weiter oben gesagt eh eine echte applikation laufen > hat, ist es egal ob man die Hardwarenahen I/Os in ASM, C oder C++ > schreibt > man wird sich für das entscheiden was man eh am besten kann bzw sich > nach dem rest richten... bzw inline ASM schreiben Und genau das wäre der größte Fehler den man machen kann um seinen code portabel zu halten. Wichtig ist es, die Hardware von der Software zu trennen und das geht am besten durch kleine hardwarenahe c Funktionen, die auf jedem Controller den gleichen definierten Namen und die gleiche Funktion haben. Z.b. Ein i/o pin setzen. Ähnlich wie bei einem Betriebssystem wird dadurch unabhängig von der Hardware eine gleiche basis geschaffen. Der code bleibt portierbar und was der Compiler davon inlined oder nicht kann eigentlich egal sein.
Als erfahrener Programmierer finde ich, dass sich C# am besten für uCs eignet. Alles hübsch portierbar, super effizient. Bald gibts C##, dass ist dann einfach noch besser. Natürlich auch für Mikrocontroller.
gcc-extension schrieb: > ... was aber kein plain C ist, sondern eine gcc extension Da ist mir wohl ['sei()'], 'cli()' und 'SREG' in der C++-Standard-Bibliothek glatt durch die Lappen gegangen. apr schrieb: > reg = SREG; > cli();
Ralf G. schrieb: > Da ist mir wohl ['sei()'], 'cli()' und 'SREG' in der > C++-Standard-Bibliothek glatt durch die Lappen gegangen. Ja, ich muss wohl dieselben Lappen benutzt haben.
Marc Vesely schrieb: > Ralf G. schrieb: >> Da ist mir wohl ['sei()'], 'cli()' und 'SREG' in der >> C++-Standard-Bibliothek glatt durch die Lappen gegangen. > > Ja, ich muss wohl dieselben Lappen benutzt haben. Also bitte... sei() und cli() als SREG |= 0x80 bzw. SREG &= ~0x80 zu implementieren, ist wohl noch schaffbar? (jeweils angepasst an den verwendeten controller) Und SREG ist ja nun nichts anderes als DDRn - ein define.
1 | #ifndef SREG
|
2 | # if __AVR_ARCH__ >= 100
|
3 | # define SREG _SFR_MEM8(0x3F)
|
4 | # else
|
5 | # define SREG _SFR_IO8(0x3F)
|
6 | # endif
|
7 | #endif
|
Und nun?
gcc-extension schrieb: > Und nun? Und nun mach mal dasselbe für verschiedene Register, Bitnamen, alle XMEGAs, verschiedene MEGAs, alle TINYs, usw...
Okay, als Abschluss: gcc-extension schrieb: > ... was aber kein plain C ist, sondern eine gcc extension