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.
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.
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:
> 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.
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:>
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.
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.
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
voidsetLED()
in C implemetiere oder eine ganze Klasse mit
1
classmycontroller
2
{
3
...
4
publicvoidsetLED()
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.
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
LCDmyLCD;
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.
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.
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):
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.
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.
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 ..
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?
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
intmain(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.
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.
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.
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 istMoby 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 "
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
>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?
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++ absolutirrelevant. 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 ...
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!
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 ;-)
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?
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
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.
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.
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.
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 ;-)
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
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?
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.
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.
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.
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
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.
Marc Vesely schrieb:> Und nun mach mal dasselbe für verschiedene Register, Bitnamen,> alle XMEGAs, verschiedene MEGAs, alle TINYs, usw...
Wenn du eine Library für verschiedene AVRs schreibst, dann lässt sich
das wohl kaum vermeiden. Oder wie würdest du es angehen?
cplusplusser schrieb:> Marc Vesely schrieb:>> Und nun mach mal dasselbe für verschiedene Register, Bitnamen,>> alle XMEGAs, verschiedene MEGAs, alle TINYs, usw...>> Wenn du eine Library für verschiedene AVRs schreibst, dann lässt sich> das wohl kaum vermeiden. Oder wie würdest du es angehen?
Eben, wo ist HIER der unterschied zwischen C, C++ und ASM oder
irgendeiner anderen Sprache?
gcc-extension schrieb:> Eben, wo ist HIER der unterschied zwischen C, C++ und ASM oder> irgendeiner anderen Sprache?
Eben. Auf der untersten Ebene musst du diese "Wrapper" sowieso von Hand
erstellen, egal ob mit C, C++ oder Assembler. Wenn du dir aber mal einen
C oder C++ Wrapper gebaut hast, so kannst du danach auf einer höheren
Abstraktionsebene dein Programm aufbauen.
Gerade bei "größeren" eingebetteten Systemen (ARM, PowerPC) oder der
Verwendung von Peripheriebausteinen hat der höhere Abstraktions- und
Wiederverwendungsgrad von C++ seine Vorteile.
Wenn man seine Klassenhierarchie z.B. für I2C-Bausteine sauber aufgebaut
hat, ist die Wartung oder das Hinzufügen neuer Bausteine recht leicht,
kann man doch dann auf bewährte Grundlagen aufbauen und muß nicht
jedesmal bei Null anfangen.
Wenn ich z.B. eine Basisklasse I2CGeraet habe, welche ich nur mit der
Adresse initialisieren muß und welche mir Methoden für
(Endianess-abhängige) Datentransfers von/zu Registern verschiedener
Weite (Templates!) anbietet, dann ist die Implementierung einer
konkreten Bausteinunterstützung schon bedeutend leichter.
Habe ich dann noch abgeleitete Basisklassen für z.B. GPIO-Chips, dann
habe ich z.B. den Einzelbitzugriff auch schon für alle Ableitungen
implementiert.
Verwende ich abstrakte Schnittstellen z.B. für Temperatursensoren, dann
kann ich über diese Schnittstelle eine Liste von allen
Temperatursensoren unabhängig vom Bussystem (I2C, SPI, integriert)
aufbauen und diese einheitlich abfragen.
Zu guter Letzt bieten mir Ausnahmen die Möglichkeit, konkrete
Fehlermeldungen "aus den Tiefen des System" nach oben zu bringen und
individuell darauf zu reagieren - welche Ebene dies betrifft, ist damit
offengelassen.
Eine Fehlermeldung wie "Ausgabefehler beim Schreiben auf den DAC
"dac_ort": Ausgabefehler beim Schreiben auf das I2C-Gerät "Selektor2"
(Typ: Selektor ..., Adresse 0x2E, Bus i2cbus3)" hilft beim Zusammenbau
und der Wartung mehr als ein ErrorCode EA-Fehler.
Aber auch auf kleinen AVR's kann man von der Kapselung profitieren.
Mittels der neuen constexpr-Konstruktoren könnte man ohne jegliche
Makroberechnung z.B. die Initialisierung für die Baudratenregister
berechnen und so eine Schreibweise anbieten:
SerialConnection ser1(9600,Parity::none,StopBit::none);
ser1 << "Hallo, Welt!" << endl;
Mir war im Verlauf folgende Formulierung aufgefallen:
>Aber schau, als freier Bastler arbeitet man anders. Nämlich absolut>lösungszentriert. Da ist zum einen der schnellste Weg wichtig.
Was bedeutet der schnellste Weg?
Ich habe jetzt mein erstes Hardwarenahes Projekt in C++ auf einem stm32
laufen und mache ausgiebig gebrauch von Interfaces in Zusammenhang mit
Polymorphy. Hintergrund ist, dass es in dem Design "Piplines" gibt, in
die sich Berechnungsmodule "einhängen" lassen. Diese Module hören alle
auf das selbe Interface und werden daher auch über eine Variable von
diesem Interfacetyp behandelt.
Warum?
Weil ich erstmal einen Satz an grundlegenden Modulen implementiert habe
und noch nicht weiß, was zukünftige können sollen. Durch den
Polymorphismuss ist das aber egal. Natürlich hat das ausdenken des
Konzeptes länger gedauert, als einen Satz Module fix runter zu
programmieren. Aber zukünftig spart es Zeit, weil Plug and Play und ich
muss bestehendes nicht anfassen und wieder debuggen.
Ich will nicht behaupten, dass sich das nicht auch in C machen lässt.
Bin nicht der ultra Crack, der genau weiß, was alles mit
Funktionspointern machbar ist. So gesehen bin ich an einer "C-Version"
des oben Beschriebenen interessiert.
Eine Sache, die immer sinnvoll ist, ist ein File zu haben (z.B. Board.h)
in dem alles oder möglichst viel definiert wird, was mit der Hardware zu
tun hat und diese Zeilen dann über Macros greifbar zu machen.
In der eigentlichen Applikation tauchen dann diese Makros auf, die am
besten alle, Alle, ALLE in dieser Board.h zu finden sind und dort bei
Portierung ZENTRAL angepasst werden können.
Die Guardklasse war nur ein konkretes Beispiel für etwas, was C++ sehr
gut kann: Ressourcen verwalten. Aber ich sehe schon, euch gefällt das
Beispiel nicht. Wie wäre dann so etwas:
Das Problem wird sein: wer C++ haßt, der wird noch nicht mal verstehen
was er da sieht. Was soll er also dazu sagen. Wie soll er die Eleganz
deine "BlockGuard"-Klasse verstehen. Wo er doch noch die PUSHs und POPs
ausbalanciert, wenn noch ein Register für eine kleine Erweiterung einer
Berechnung braucht. Sogar bei nur Blinken muß man sich mit
1
#include<avr/io.h>
2
#include<util/delay.h>
3
4
#define LEDPIN PINB
5
#define LEDDDR DDRB
6
#define LEDBIT 4
7
8
intmain(){
9
LEDDDR|=(1<<LEDBIT);
10
11
while(1){
12
LEDPIN=(1<<LEDBIT);
13
_delay_ms(500);
14
}
15
}
keine Gedanken über viel kleine Details machen, daß ich nie auf die Idee
käme, dazu ASM zu benutzen. Warum auch? Wo reichen Performance und Platz
nicht aus. Nur werde in es keinem ausreden, der sich unbedingt quälen
will. Ok, ist nur C, aber eben kein ASM mehr.
Mit C++ Templates kann man schön so Dinge wie Ring-Puffer bauen,
Elementtyp konfigurierbar, Länge konfigurierbar, Länge bestimmt
automatisch den Typ der In/Out-"Ptr", diese benutzen ein Modulo Template
für den automatischen Wrap around bei Operator ++, Ausgaben in Streams,
die Kommandos ala ANSI (gotoxy, up, down, left, right, clear, home)
verstehen und als Templateparameter die Uart- oder die 16x2 LCD Klasse
mitbekommen.
Usw, usw. Wer nicht versteht was ich schreibe, der wird auch nicht
wissen, wozu das gut ist!
Bastler schrieb:> Usw, usw. Wer nicht versteht was ich schreibe, der wird auch nicht> wissen, wozu das gut ist!
Richtig.
Der Mist wird immer komplizierter, je mehr "abstrahiert" wird. Das ist
DAS, was ich verstehe.
apr schrieb:> Die Guardklasse war nur ein konkretes Beispiel für etwas, was C++ sehr> gut kann: Ressourcen verwalten. Aber ich sehe schon, euch gefällt das> Beispiel nicht. Wie wäre dann so etwas:> [code]> struct CNT1 {> static constexpr volatile uint8_t &low() { return TCNT1L; }> static constexpr volatile uint8_t &hi() { return TCNT1H; }> };>> template<class Trait>> class Access16Bit
Aha.
Dasselbe in Assembler:
1
;*ErstmalsehenumwelcheRegisteressichhandelt...
2
.macroStore;Register,Address
3
.if@0>0x3F
4
sts@0,@1
5
.else
6
out@0,@1
7
.endif
8
.endmacro
9
10
.macroLoad;Register,Address
11
.if@1>0x3F
12
lds@0,@1
13
.else
14
in@0,@1
15
.endif
16
.endmacro
17
18
;*JetztkommendieTemplates...
19
.macroGet16bit
20
LOADMacReg,@0H
21
mov@1H,MacReg
22
LOADMacReg,@0L
23
mov@1L,MacReg
24
.endmacro
25
26
.macroPut16bit
27
ldiMacReg,High(@1)
28
STORE@0H,MacReg
29
ldiMacReg,Low(@1)
30
STORE@0L,MacReg
31
.endmacro
32
33
34
;*Unddannimmain...
35
36
Get16bitTCNT1,Z
37
Put16bitTCNT1,0x1234
Schätze, ungefähr 10:1 Effizienz mindestens.
Bin natürlich nicht gegen C++, aber bitte nur dort, wo es auch Sinn
hat.
Bastler schrieb:> Usw, usw. Wer nicht versteht was ich schreibe, der wird auch nicht> wissen, wozu das gut ist!
Wie wäre es, wenn du erst mal selber etwas mehr über C++ lernst ?
Das C Beispiel war dazu da, zu zeigen, daß auch (oder gerade)
einfachstes besser in Hochsprachen gemacht wird. Und richtig! meine DCOM
Programme mit der Active Template Lib liegen schon mehr als 10 Jahre
zurück, Geld verdien ich heute mit ganz anderen Sprachen und als Hobby
bastle ich eben an den Dingen, die ich oben beschrieben hab. Nur
verstehen tut's nicht jeder. Stand da auch schon. Im übrigen: zofft euch
mit euch selbst!
apr schrieb:> jo. Access16Bit<CNT1> tcnt1;> tcnt1 = 0x1122;> ldi r24,lo8(17)> out 0x2d,r24> ldi r24,lo8(34)> out 0x2c,r24> uint16_t foo = tcnt1;> in r24,0x2c> in r18,0x2d
LOL.
Und jetzt mach das mal mit OCR1A und OCR1B.
Ich brauche nur zu schreiben:
Put16bit OCR1A, 0x1234
Oder:
Get16bit OCR1B, Y
Und Ihr, C++ Gurus ?
Marc Vesely schrieb:> Schätze, ungefähr 10:1 Effizienz mindestens.
10:1 Effizienz gemessen nach was? Man kann davon ausgehen, dass der
Compiler das genau so gut optimiert, wie du es in Assembler schreiben
kannst. Lesbarer ist es auch nicht, eher weniger. Flexibler schon gar
nicht.
Unwissender schrieb:> LOL.> Und jetzt mach das mal mit OCR1A und OCR1B.>> Ich brauche nur zu schreiben:> Put16bit OCR1A, 0x1234> Oder:> Get16bit OCR1B, Y>> Und Ihr, C++ Gurus ?
Hier interessiert sich auch niemand (ausser Moby) dafür, Trivialaufgaben
mit möglichst wenig Code zu erledigen. Es ging von Anfang an darum, wie
man mit C++ eine gute Abstraktion über die Hardware legen kann. Zunächst
ist das immer mit mehr Schreibarbeit und mehr Komplexität verbunden.
P. M. schrieb:> Hier interessiert sich auch niemand (ausser Moby) dafür, Trivialaufgaben> mit möglichst wenig Code zu erledigen.
... und noch für sehr viel mehr. Da wird dann erst richtig Code gespart
und man kommt weiter mit nem AVR statt ARM über die Runden. Das ist
einem überzeugten OOPlogen natürlich schlecht zu vermitteln...
> ist das immer mit mehr Schreibarbeit und mehr Komplexität verbunden.
Richtig! Ich wünsch Euch, Ihr habt nach Projektende trotzdem noch das
Gefühl, es hat sich gelohnt. Nicht den intellektuelle Spaß, die
Effizienz meine ich ;-)
apr schrieb:> Die Guardklasse war nur ein konkretes Beispiel für etwas, was C++ sehr> gut kann: Ressourcen verwalten. Aber ich sehe schon, euch gefällt das> Beispiel nicht.
Ich glaube eher, es wurde nicht verstanden, um was es eigentlich geht.
Ralf G. schrieb:> 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();
Es geht doch hier gar nicht um das SREG selbst, sondern vielmehr um die
Art, wie es verwaltet wird. Das SREG ist da nur ein Beispiel.
Prinzipiell läßt sich jede beliebige Ressource auf die gleiche Weise
handhaben. Einen vergleichbaren Automatismus gibt es in C nicht, deshalb
wurde im GCC die unportable Krücke mit dem ATOMIC_BLOCK eingebaut.
Mir scheint, in gewisser Weise durch die Namensgebung des Threads
provoziert wird C++ verstärkt von Seiten der Initialisierung und des
"Wertabholens" betrachtet. Je nachdem was man macht, ist das aber nur
der kleinste Teil.
Bei dem was ich aktuell mache halte ich C++ für sinvoll. Letztlich lese
ich nur ein paar Analogwerte ein und frage ein paar digitale Pins ab.
Das was ich damit mache findet in Zeitfenstern statt, in denen sich der
µC hochgradig langweilt.
Wenn ich dabei währe und müsste schnell laufende Filter/Regelungen
entwerfen, sähe die Welt vielleicht anders aus. Da den
"Entscheidungsthreshold" zu finden, brauchts mehr als meine Erfahrung...
robin schrieb:> 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.
ja .. in dem sinne meinte ich das ja auch ...
die applikation sollte von eigentlichen I/O losgelöst sein ...
ich habe dazu funktionszeiger im einsatz... zum setzen oder löschen
rufen die eine callbackfunktion auf. das ist der selbe weg wie eine
funktion für setzen/löschen global zu definieren.
nur das ich bei der init eben diesen *FP mit angebe .. was dann in der
funktion steht ... also ein einfaches PORT |=(1<<1); oder etwas
komplexeres weil mehrere register beshrieben werden müssen ist dabei
egal
ich brauche aber die set/get funktionen nicht global bekantgeben...
und kann so je nach aufgabe auch einen wrapper schreiben der eine
zwischenschicht darstellt ..
ja ich weiß .. sowas geht über ein simples sbi.. hinnaus :-(
aber so komm ich prima klar
ich brauche je nach µc nur eine hand voll set/get funktionen ( quasi BSP
)
dann läuft die software
Moby schrieb:> ... und noch für sehr viel mehr. Da wird dann erst richtig Code gespart> und man kommt weiter mit nem AVR statt ARM über die Runden.
Das ist ja genau der Punkt, der bereits widerlegt wurde: C++ generiert
gar nicht grösseren Binärcode.
P. M. schrieb:> Hier interessiert sich auch niemand (ausser Moby) dafür, Trivialaufgaben> mit möglichst wenig Code zu erledigen. Es ging von Anfang an darum, wie> man mit C++ eine gute Abstraktion über die Hardware legen kann. Zunächst> ist das immer mit mehr Schreibarbeit und mehr Komplexität verbunden.
Es ging mir eher darum, zu zeigen wie sinnlos das Ganze ist.
Ich programmiere nur noch selten in Assembler und für Hardware wird
bei mir sowieso eine Library benutzt.
Da ich zufälligerweise einen PC habe und auf diesem auch zufällig
VS2010 installiert ist, hatte ich auch die Gelegenheit mit C++ etwas
mehr als 'hello world' zu produzieren.
Dann kam ich auf die komische Idee, die XML files von ATMEL zu nutzen
um gewisse Hardwarefunktionen nicht mehr von Hand schreiben zu müssen.
Und dazu habe ich C++ ausprobiert und siehe da - es funktionierte.
Jetzt läuft auf dem PC einen Programm mit etwa 2MB aber mit SQL,
grafischer Oberfläche, da kann man Prozessortyp, Geschwindigkeit,
benötigte Timer, ADC, SPI, USART etc. schön auswählen, die
dazugehörigen Register werden auch komischerweise alle angezeigt.
Eine andere komische Idee von mir war, per Click auszuwählen, ob ein
komplettes Programmgerüst oder nur eine Funktion erzeugt werden sollte.
Und am komischsten fand ich die Idee, dass man mit noch einem Click
auswählen kann, ob das Ganze als Library-Function geht oder ob nur ein
Code-Snippet erzeugt werden sollte.
Jetzt kann ich mit ein paar clicks für irgendeinen X-beliebigen AVR
ein Programm erzeugen mit allem was dazugehört, also mit #includes,
Init_xxx(), ISR, main() und vor allem die ganzen #define und #ifdefs
werden richtig in eine Def_xxx.h reingeschrieben. Sogar die Kommentare
gehen automatisch rein.
Was auch sehr komisch ist:
Ich brauche diesen Prozessortyp gar nicht mal zu kennen - alles
nötige steht in XML files, man muss nur wissen wie das alles zu
verwenden ist.
Dass C++ auch auf uC geht, steht ausser Frage, nur sollte man
C++ das machen lassen, wofür der auch geschrieben wurde.
Die ganze PiPaPo Arbeit mit der Hardware kann man viel besser
irgendwo anders (auf dem PC) erledigen. Auch sind die Möglichkeiten
einen dummen Fehler mit falscher Bitbezeichnung oder so zu machen,
damit (fast) ausgeschlossen.
Rüdiger Knörig schrieb:> Verwende ich abstrakte Schnittstellen z.B. für Temperatursensoren, dann> kann ich über diese Schnittstelle eine Liste von allen> Temperatursensoren unabhängig vom Bussystem (I2C, SPI, integriert)> aufbauen und diese einheitlich abfragen.
Ja, nur geht das auch in plain C (fast) genauso einfach. Und wrapper
dazu schreibt der Programm auf dem PC (fast) von alleine.
Nur ist es eben unnötige Arbeit, da ist mit C++ natürlich das Leben
viel einfacher.
Es ist in etwa so wie mit CAN und verschiedenen Layers.
Kein normaler Mensch fährt CAN mit bitbanging.
Warum sollte C++ das tun ?
Marc Vesely schrieb:> Es ging mir eher darum, zu zeigen wie sinnlos das Ganze ist.> Ich programmiere nur noch selten in Assembler und für Hardware wird> bei mir sowieso eine Library benutzt.
Sinnlos ist es nur für den, der es, weil er die Vorteile nicht kennt,
nicht benutzt.
Und ein Vorteil von Libraries als Template-Sammlung (da braucht man aber
leider C++) ist, daß man (notfalls per LTO) eine über-Alles-Optimierung
bekommt.
Wieviele Versionen von Library gibt es denn für die verschiedenen AVR's.
Für jeden eine, oder eine, die zur Laufzeit entscheidet ob der Port im
IO- oder MEM-Bereich liegt.
ASM hab ich benutzt, als es keine bezahlbaren Compiler gab. Anfangs
gab's noch nicht mal Assembler in bezahlbar, da wurde eben
hand-assembliert. C seit ich welche für umme bekommen konnte (was die
Hersteller nicht immer so geplant hatten) und C++ seit das Vorteile
bringt.
andersdenkender schrieb:> Wieviele Versionen von Library gibt es denn für die verschiedenen AVR's.> Für jeden eine, oder eine, die zur Laufzeit entscheidet ob der Port im> IO- oder MEM-Bereich liegt.
Wie gesagt, steht alles in XML:
Marc Vesely schrieb:> Dass C++ auch auf uC geht, steht ausser Frage, nur sollte man> C++ das machen lassen, wofür der auch geschrieben wurde.> Die ganze PiPaPo Arbeit mit der Hardware kann man viel besser> irgendwo anders (auf dem PC) erledigen.
Und genau das tut der Compiler auf dem PC für dich, wenn du z.B.
Templates verwendest.
So lange man keine virutelle Vererbung und keine verrückten Sachen aus
std verwendet, kann man jedes C++-Programm straight-forward in ein
C-Programm verwandeln. Von dort aus gehts wiederum einfach nach
Assembler. Macht natürlich netterweise alles der Compiler für dich. Da
es so einfach ist, hat er auch keine Mühe, daraus genau so guten Code zu
erzeugen, als wäre es C. Und ein gut optimertes C-Compilat schlägt man
von Hand in Assembler nicht so schnell.
Hat also nur Vorteile: Der Programmierer kann in hoher Abstraktion
denken und schreiben, während der Compiler dafür sorgt, dass es in ein
hocheffizientes Programm umgesetzt wird.
Noch am Rande: C++ wurde im Gegensatz zu anderen höheren
Programmiersprachen ja auch gezielt für eine hocheffiziente low-level
Implementierung designt. Und zwar damals auf Rechnern, die heute nicht
mal mit einem AVR mithalten können.
Rolf Magnus schrieb:> deshalb> wurde im GCC die unportable Krücke mit dem ATOMIC_BLOCK eingebaut.
Ah ja. Ein Beitrag zum Thema Portabilität der Hochsprache.
P. M. schrieb:> Und ein gut optimertes C-Compilat schlägt man> von Hand in Assembler nicht so schnell.
Entschuldigung, Unfug. Wenn man nur halbwegs gut die Möglichkeiten
"seines" Controllers nutzt und in Asm halbwegs fit ist! Aber: Bei
Programmen ab einer gewissen Größenordnung mag die Konzentration des
Programmierers nachlassen ;-)
Irgendwer schrieb:> Da könnte einem schon der Verdacht> kommen das beim Thema Optimierung zumindest beim gcc noch einiges an> Luft für Verbesserungen vorhanden ist.
Schau einer an. Aber man kann ja immer noch ein paar Hundert bis Tausend
Euro in einen "ordentlichen" Compiler stecken, ich weiß schon. Der läuft
dann natürlich auch konfigurations- und fehlerfrei und weiß für seine
Optimierungen stets intelligent den Code-Sinn zu interpretieren.
Marc Vesely schrieb:> Dass C++ auch auf uC geht, steht ausser Frage,Christian Berger schrieb:> Also mir wäre noch nie ein Fall untergekommen, wo man einen µC in C++> programmiert hätte
Dazu wär wirklich mal eine Umfrage interessant.
Meine Vermutung: Sie würde für C++ vernichtend ausfallen.
P. M. schrieb:> Hat also nur Vorteile: Der Programmierer kann in hoher Abstraktion> denken und schreiben,P. M. schrieb:> Das ist ja genau der Punkt, der bereits widerlegt wurde: C++ generiert> gar nicht grösseren Binärcode.
In abstrakter Theorie vielleicht. In der Praxis liegt der Teufel stets
im Detail. Bei richtiger Initialisierung aller Register, mindestens
halboptimaler Nutzung der Peripherie, Interruptsystem, Event-Netzwerk,
1:1 Umsetzung der Funktionalität und vorgesehener, schon lang (selbst)
optimierter I/O-Methoden nie und nimmer! Aber gut, das kann der pure C++
Programmierer wohl gar nicht wissen. Ist zu sehr auf abstraktes Denken
festgelegt. Hochfliegend mit einer gewissen unscharfen Übersicht über
die Landschaft, aber ohne (hardwarenahen) Bodenkontakt und in steter
Absturzgefahr ;-)
Ret schrieb:> C++> Protagonisten verführen regelrecht gewollt oder ungewollt mit ihrem> fortwährenden Betonen ihrer "Überlegenheitskultur" gegenüber anderen> Programmiersprachen andere dazu, sich auch in C++ zu probieren. Der Ball> wird dann prompt gerne aufgenommen. Man will schließlich auch irgendwie> zur "C++ Elite" dazugehören. Dann aber stechen die Nebenwirkungen und> Begleiterscheinungen aus dem (C++)-Beipackzettel beim Probanden immer> mehr durch. Ergebnis: Dass gerade daraus dann vielleicht umso mehr> fehlerhafte und gar nicht immer so Effizient wie behauptet Programme> erwachsen, weil kaum einer dieses Thema richtig beherrscht, steht dem> ganzen schönen Thema C++ hässlich gegenüber, wird aber gerne unter den> Teppich gekehrt, weil die Wenigsten freiwillig und offen zugeben, dass> sie ihr C++ eben nicht so richtig oder bisweilen sogar gar nicht> beherrschen. REAL werden dann eher die gewohnten C-Programme> geschrieben, durch den C++ Compiler geschickt und heraus kommt sowas wie> .. C+.
Soviel zum psychologischen Aspekt der Sache.
Christian Berger schrieb:> Irgendwie bestätigt das mich in meinem Glauben, dass es auf der Welt> vielleicht 100 Leute gibt, die C++ wirklich können.
Und mich in meinem, wie empfehlenswert es sein muß, die viele Zeit
aufzubringen dieses C++ "Baumaterial" in Perfektion zu erlernen ;-)
Möchte auch mal einen Vergleich bringen: Mit viereckigen Steinen lassen
sich zweifellos große und komplizierteste Gebäude bauen. Warum aber
haben die Steine wohl so eine einfache Form?
A. K. schrieb:> Ich finde C++ eine ziemlich grässliche Konstruktion - übrigens von> Anfang an seit der Lektüre des ersten Stroustrup. Kann nicht anders> sein, da schon C schaurig geraten ist und nie für die Dimension gedacht> war, in der es heute eingesetzt wird. Aber das ist Philosophie auf der> Wiese. Das Zeug ist nun einmal da.
... und muß wohl nun auf Teufel komm raus genutzt werden. Aber nicht vom
freien Bastler ;-)
Alle Zitate übrigens vom Nachbarthread
Beitrag "Was ein C++-"Guru" so ueber Geschwindigkeit erzaehlt."
der die unkomplizierte, effiziente Anwendung von C++ in der Praxis
wunderbar beleuchtet ;-)
Ich hab das Gefühl, hinter vorgehaltener Hand weiß auch der Letzte
hier, wie schlecht C++ in der Gesamtheit aller Details seiner Anwendung
(gerade bei hardwarenahen Sachen) für einfache bis mittelkomplexe
Projekte geeignet ist. Hört doch endlich auf, den einfachen ehrlichen
Programmierer mit diesem "Zeug" an der Nase herumzuführen. Danke.
Moby schrieb:> Alle Zitate übrigens vom Nachbarthread> Beitrag "Was ein C++-"Guru" so ueber Geschwindigkeit erzaehlt."> der die unkomplizierte, effiziente Anwendung von C++ in der Praxis> wunderbar beleuchtet ;-)
Der Thread hat nichts, aber auch garnichts mit C++ zu tun (davon
abgesehn dass der TO im Titel C++ anstatt C verwendet).
Da du ihn hier trotzdem verlinkt zeigt dass, das du ihn garnicht gelesen
hast (sonst wüsstest du dass es dort um plain C geht).
Fazit: du bist garnicht an einer durch Argumenten fundierten Diskussion
interessiert.
Marc Vesely schrieb:> Wie gesagt, steht alles in XML
Könntest du mal den xml teil von einem hardwaremodul, z.b. Timer1
posten? Bin gerade unterwegs und konnte auf die schnelle nichts finden.
Aber was da noch so alles drin steht hat mich doch neugierig gemacht.
Moby schrieb:> Ich hab das Gefühl, hinter vorgehaltener Hand weiß auch der Letzte> hier, wie schlecht C++ in der Gesamtheit aller Details seiner Anwendung> (gerade bei hardwarenahen Sachen) für einfache bis mittelkomplexe> Projekte geeignet ist
Hier geht es auch nicht um "einfache bis mittelkomplexe" Projekte,
sondern um Projekte von einer Grösse, wo man sich auch Gedanken um
Abstraktionen auf höherer Ebene machen muss. Ich für meinen Teil mache
das bereits bei einfachen Projekten: Zuerst die Struktur verstehen, dann
eine Software-Architektur planen, dann umsetzen. Hat am Anfang einen
gewissen Overhead, dafür funktioniert es meistens dann prächtig und ist
extrem flexibel. Gewisse Leute mögen diesen Ansatz nicht, da man zuerst
vielleicht 2 Stunden bis 2 Wochen "nichts" produziert. Ich hingegen
hasse es, wenn jede Modifikation Handarbeit im gesamten Programm
bedeutet.
le x. schrieb:> Der Thread hat nichts, aber auch garnichts mit C++
Komisch. In jedem Zitat kommt C++ vor ...
le x. schrieb:> das du ihn garnicht gelesen> hast
Stimmt. Die Zitate sind blind herausgepickt.
cplusplusser schrieb:> Hier geht es auch nicht um "einfache bis mittelkomplexe" Projekte,> sondern um Projekte von einer Grösse, wo man sich auch Gedanken um> Abstraktionen auf höherer Ebene machen muss.
Warum hast Du das nicht gleich gesagt? Wo immer diese Sphäre auch
anfangen mag. OK- dann trennen wir uns an dieser Stelle in Frieden. Aber
nicht den Überblick verlieren ;-)
Moby schrieb:> Komisch. In jedem Zitat kommt C++ vor ...
Ja, hier hast du recht. Das ist echt komisch.
Im ganzen Thread geht es nur um plain-C, und ob man besser mittels Index
oder Zeiger ein Array kopiert.
Da C (fast) eine Teilmenge von C++ ist könnte man nun argumentieren dass
alles, was C ist, auch C++ ist.
Aber wir wollen uns ja hier nicht in Spitzfindigkeiten verlieren.
Moby schrieb:> cplusplusser schrieb:>> Hier geht es auch nicht um "einfache bis mittelkomplexe" Projekte,>> sondern um Projekte von einer Grösse, wo man sich auch Gedanken um>> Abstraktionen auf höherer Ebene machen muss.>> Warum hast Du das nicht gleich gesagt? Wo immer diese Sphäre auch> anfangen mag. OK- dann trennen wir uns an dieser Stelle in Frieden. Aber> nicht den Überblick verlieren ;-)
Was soll der Quatsch? In jedem zweiten Posting versucht man dir zu
erklären, dass die Welt nicht nur aus deinem LED-Beispiel besteht und du
konterst damit, es sei ein völlig allgemeingültiges Beispiel. Und jetzt
bist du völlig überrascht, dass es hier um eher etwas grössere Projekte
geht?!?
robin schrieb:> Könntest du mal den xml teil von einem hardwaremodul, z.b. Timer1> posten? Bin gerade unterwegs und konnte auf die schnelle nichts finden.> Aber was da noch so alles drin steht hat mich doch neugierig gemacht.
Steht so ziemlich alles drin, nur eben verteilt im ganzen XML.
Ich hab dir hier etwas handisch und wahllos rausgeschnitten, es ist
einfach zu viel, um alles so rauszusuchen.
Im Prinzip nimmt man zuerst die IO_MODULEs, merkt sich die MODULE_LIST
und klappert dann einen nach dem anderen ab.
Unwissender schrieb:> Und jetzt mach das mal mit OCR1A und OCR1B.>> Ich brauche nur zu schreiben:> Put16bit OCR1A, 0x1234> Oder:> Get16bit OCR1B, Y>> Und Ihr, C++ Gurus ?
Marc Vesely schrieb:> Und in plain C:> ocr1a = 0x1234;> uint16_t y = ocr1a;>> Was ist deiner Meinung nach kürzer und übersichtlicher?
Na wenn der C Compiler das korrekt erzeugt, ist die gesamte Klasse
unnütz, nicht wahr.
Es hat keinen Sinn, den Nutzen von C++ anhand von Trivialbeispielen zu
zeigen. Da wird man immer verlieren. Eher sollte die
Assembler/C-Fraktion mal zeigen, wie sie eine grössere Library
implementiert und dann schauen wir mal, ob das in C++ nicht ein
"bisschen" übersichtlicher und genau so performant geht.
da muss man nur die ASM-FP-Macro-Bibliotek rausholen und schon kann man
das auch. sqrt() und sin() liefern ja double, da kann man dann schon
8er-Pakete Register händisch verwalten. das bringt's ;-)
BTW, wenn ich wemand zwingen würde, das in AVR-ASM zu machen, dann würde
ich mir auf alle Fälle vom GCC ein "ASM-Template" oder auch .lss-File
erzeugen lassen. Oder ich verwend die Zeit darauf den Anforderer in die
richtige Richtung zu schubsen.
le x. schrieb:> Moby schrieb:>> Alle Zitate übrigens vom Nachbarthread>> Beitrag "Was ein C++-"Guru" so ueber Geschwindigkeit erzaehlt.">> der die unkomplizierte, effiziente Anwendung von C++ in der Praxis>> wunderbar beleuchtet ;-)>> Der Thread hat nichts, aber auch garnichts mit C++ zu tun (davon> abgesehn dass der TO im Titel C++ anstatt C verwendet).> Da du ihn hier trotzdem verlinkt zeigt dass, das du ihn garnicht gelesen> hast (sonst wüsstest du dass es dort um plain C geht).>> Fazit: du bist garnicht an einer durch Argumenten fundierten Diskussion> interessiert.
Von C++ hat er doch keinen blassen Schimmer, wie soll er das dann
überhaupt auseinander halten? Wahrscheinlich kann er nicht mal C (zu
komplex, ist immer sein Argument ;) ). Und erzählt dann irgendwas was er
mal so beiläufig aufgeschnappt hat. Insofern kann er an dieser
Diskussion eigentlich nicht teilnehmen.
andersdenkender schrieb:> sqrt() und sin() liefern ja double
Ich sprach von Festkommazahlen.
Durch Überladen von Operatoren kann man sich Berechnungen hinschreiben
wie von ganzen Zahlen oder Gleitkommazahlen gewohnt, in Wirklichkeit
rackern im Hintergrund templates.
Das ist ein Vorteil von C++, an den man mit ASM oder C nicht herankommt.
Selbst in C sehen Berechnungen mit Festkommazahlen ziemlich wüst aus.
Siehe auch Beitrag "Festkommazahlen mit C++"
andersdenkender schrieb:> da muss man nur die ASM-FP-Macro-Bibliotek rausholen und schon kann man> das auch. sqrt() und sin() liefern ja double, da kann man dann schon> 8er-Pakete Register händisch verwalten. das bringt's ;-)
Festkommazahlen? Komplexe Zahlen? Oder wenn man einfach mal eine
spezielle Arithmetik braucht? Es behauptet ja niemand, dass man sowas
mit Assembler nicht gebacken bekommt. Aber du kannst auch nicht
abstreiten, dass die C++-Variante mit Operatorüberladung einfach viel
lesbarer und eleganter daherkommt. Und ein guter Compiler setzt das auch
so um, dass keine Ineffizienz entsteht. Ganz abgesehen davon, dass man
in vielen Fällen gar nicht so auf dem Zahnfleisch läuft, dass man jede
Instruktion zählen muss. Wenn du jede Sekunde einen Sensor auslesen, den
Wert nach einer eher aufwändigen Formel umrechnen und auf ein Display
ausgeben musst, dann hat selbst ein kleiner AVR unendlich
Leistungsreserven und du bist glücklich, die Formel intuitiv
aufschreiben zu können.
> BTW, wenn ich wemand zwingen würde, das in AVR-ASM zu machen, dann würde> ich mir auf alle Fälle vom GCC ein "ASM-Template" oder auch .lss-File> erzeugen lassen. Oder ich verwend die Zeit darauf den Anforderer in die> richtige Richtung zu schubsen.
Ich weiss gar nicht recht, welchen Standpunkt du jetzt vertrittst, aber
wir sind uns wohl einig, dass spätestens hier C++ weniger kompliziert
ist als die Assembler-Lösung?
Klaus Wachtler schrieb:> Durch Überladen von Operatoren kann man sich Berechnungen hinschreiben> wie von ganzen Zahlen oder Gleitkommazahlen gewohnt, in Wirklichkeit> rackern im Hintergrund templates.
Und in Wirklichkeit sorgt das dafür, dass man die Wirklichkeit nicht
mehr sieht. Wenn man nur lange genug raus ist oder in fremden Code
einsteigen muss, bleibt von dem eigentlichen Vorteil nichts mehr übrig.
Ich kann dem exzessiven Überladen von Operatoren überhaupt nichts
abgewinnen. Eine Funktion mit einem aussagekräftigen Namen ist häufig
klar im Vorteil.
Wenn man massenweise Templates verwendet und hinterher erst mal im
Listing nachsehen muss was denn nun dabei rausgekommen ist, wird es
albern. Auf dem PC spielt das heute keine Rolle mehr, aber auf einem
Controller schon.
andersdenkender schrieb:> da muss man nur die ASM-FP-Macro-Bibliotek rausholen und schon kann man> das auch. sqrt() und sin() liefern ja double, da kann man dann schon> 8er-Pakete Register händisch verwalten. das bringt's ;-)P. M. schrieb:> Ich weiss gar nicht recht, welchen Standpunkt du jetzt vertrittst, aber> wir sind uns wohl einig, dass spätestens hier C++ weniger kompliziert> ist als die Assembler-Lösung?
Ich bin hoffentlich nicht der Einzige, der die Ironie in diesen Zeilen
des andersdenkende erkannt hat.
zu Templates und Operator Overloading:
Einmal schreiben (und debuggen) und danach den Compiler die
Routinearbeit machen lassen.
temp schrieb:> Klaus Wachtler schrieb:>> Durch Überladen von Operatoren kann man sich Berechnungen hinschreiben>> wie von ganzen Zahlen oder Gleitkommazahlen gewohnt, in Wirklichkeit>> rackern im Hintergrund templates.>> Und in Wirklichkeit sorgt das dafür, dass man die Wirklichkeit nicht> mehr sieht. Wenn man nur lange genug raus ist oder in fremden Code> einsteigen muss, bleibt von dem eigentlichen Vorteil nichts mehr übrig.> Ich kann dem exzessiven Überladen von Operatoren überhaupt nichts> abgewinnen.
Das Überladen von Operatoren ist dann sinnvoll und überhaupt nicht
verwirrend, wenn dabei die ursprüngliche Bedeutung des Operators
erhalten bleibt.
Ein überladener '+'-Operator sollte also wie das Original immer noch
eine Addition ausführen, nur mit anderen Datentypen, also statt int
oder double bspw. complex oder fixedpoint. Das obige Beispiel von
Klaus stellt somit eine gute Verwendung der Überladung dar.
Denn
1
y=a*b*x+c;
ist einfach um ein Vielfaches besser lesbar als
1
y=fixadd(fixmul(fixmul(a,b),x),c);
Schlecht und verwirrend wäre es hingegen, wenn der '+'-Operator statt
der Summe das Produkt aus zwei Zahlen berechnen würde, was zu einer
völlig falschen Wahrnehmung des Ausdrucks
1
a+b
führte.
Hier sollte – wie an vielen anderen Stellen in der Softwarentwicklung
auch – das Prinzip der geringsten Verwunderung beherzigt werden.
Stroustrup selbst geht da leider mit schlechtem Beispiel voran und
überlädt die Bitshift-Operatoren << und >> mit Funktionen für die
Ein-/ausgabe. Diese haben nicht nur überhaupt nichts mit Bitschieberei
zu tun, sondern weisen zudem noch Nebeneffekte auf. Außerdem liegen die
Operatoren – als Ein-/Ausgabeoperatoren eingesetzt – in der Operator-
rangfolge zu weit oben. So etwas ist einfach Murks, der nur deswegen
akzeptiert wird, weil man sich inzwischen daran gewöhnt hat.
Leider erlaubt C++ nicht die Definiton neuer Operatoren, mit denen
solche Probleme auf saubere Art und Weise beseitigt werden könnten.
Bastler schrieb:> zu Templates und Operator Overloading:> Einmal schreiben (und debuggen) und danach den Compiler die> Routinearbeit machen lassen.
Ja,ja. das Ringbufferbeispiel wird immer gern genommen. Soweit ok. Das
Modulo finde ich schon wieder grenzwertig. Entweder ich mache dann einen
schönen langen sprechenden Variablennamen ala IchBinEinModulo5 oder ich
muss mit Kommentaren dafür sorgen, dass ich immer weiss dass die
Variable x beim ++ nach 5 eine 0 macht. Und alle anderen Konstrukte
dürfen auch nicht falsch zählen. Was macht dann ein x=x+1? Und warum
verhält es sich anders als das ++? Ne, bei aller Liebe. Irgendwo gibt's
ne Grenze. Irgendwann wird es Krampf.
Danke oben für das Beispiel mit >> und <<. Genau dieser Schwachsinn ist
es, der dafür Sorge getragen hat, dass printf und Konsorten die Zeiten
unbeschadet überlebt haben. Das was in der C++ std-Lib an
Stringverarbeitung (auch und vor allem in Versionen ohne! dynamischen
Speicher) vorhanden ist, ist ja wohl nicht der Rede wert.
Ich finde C++ Entwicklung für uC hat nur ein einziges echtes Problem:
Portierbarkeit zwischen unterschiedlichen Compilern. Es gibt exotische
Compiler, es gibt alte Compiler (die man manchmal nutzen muss) - alle
verstehen C aber manche nicht alle C++ Features oder gar nur ein
rudimentäres C++ Subset. C++ Code welcher die Features des neusten
Standards nutzt ist damit erstmal enorm schlecht wiederzuverwenden. Nach
Leidvollen Erfahrungen mit TI (nur C++ Subset) und altem Gcc (kein
Placement-New) setze ich zwar auf objektorientierte Denke aber
implementiere sie meist in C. Wer schonmal große gewachsene Projekte vor
sich hatte weiß, dass "mal eben vorher auf die neuste Compilerversion
updaten" schon ein separates Projekt für sich sein kann und nicht immer
als Lösung in Frage kommt.
Es geht um weiter nichts als um ein 1024 Byte langes Array anzulegen und
zu füllen. Einmal mit den c++ std::vectoren und zum anderen in der von C
gewohnten Art und Weise. Der Code lief im Simulator von Crossworks auf
einem STM32F334. Folgende Ergebnisse im Debugmodus:
1
std::vectorsysticks=86432
2
c-arraysysticks=12352
3
4
undjetztimReleasemode:
5
6
std::vectorsysticks=8253
7
c-arraysysticks=4153
Soviel erst mal zur Effizienz. Bemerkenswert ist auch die über 10fache
Zeit im Verhältnis Debug/Release. Bei der C-Methode ist das mit der
3fachen Zeit nicht ganz so schlimm. Eine Aussage stelle ich deshalb mal
in den Raum: Ein übliches Cortex Mx Programm hat in C++ im Debugmodus
zeitlich mit der Wirklichkeit nicht mehr viel zu tun wenn die std::lib
im Spiel ist. Das erleichtert die Fehlersuchen nicht gerade. Da würde
dann helfen nur gezielte Bereiche des Programms mit Debuginfos zu
versehen. Kontraproduktiv ist dabei in C++, dass viel Programmcode aus
den Headern erzeugt wird.
Jetzt können die Argumente kommen, die Variante mit dem std::vector wäre
viel sicherer. Auch das ist ein Trugschluss. Ein kleiner Fehler wie:
1
for(intn=0;n<=1024;n++)
2
anstelle
3
for(intn=0;n<1024;n++)
hat in der traditionellen Variante das Schreiben über den allocierten
Bereich zur Folge. Mit all seinen bekannten Konsequenzen. Die C++
Variante ist aber auch nicht besser. In dem Moment wo das 1025te
push_back kommt, werden mal eben 2048Byte Speicher dynamisch zusätzlich
zu den bereits allocierten 1024 angefordert. Danach wird umkopiert und
dann erst der Block mit den 1024Byte frei gegeben. Das dauert zwar nur
ein paar 100ns aber ob der Block zu diesem Zeitpunkt dann noch frei ist?
Der Entwickler ging ja eigentlich davon aus nur max. 1024Byte zu
brauchen. Gerade bei größeren Projekten mit einem RTOS kann das genauso
zu unerwarteten Ergebnissen führen. Auf einem PC sind diese
Betrachtungen nicht nötig, aber auf einem Controller mit begrenzten RAM
kann das kriegsentscheident sein.
temp schrieb:> Ein übliches Cortex Mx Programm hat in C++ im Debugmodus> zeitlich mit der Wirklichkeit nicht mehr viel zu tun wenn die std::lib> im Spiel ist.
Das ist ja ausgemachter Blödsinn.
Es stimmt nur, wenn der Programmierer keinen Plan hat, was er tut.
So wie du den std::vector missbrauchst, müsstest du es in C mit einem
frei allokierten Feld vergleichen, das bei jedem Durchlauf mit realloc()
um ein Element verlängert wird.
Klaus Wachtler schrieb:> So wie du den std::vector missbrauchst, müsstest du es in C mit einem> frei allokierten Feld vergleichen, das bei jedem Durchlauf mit realloc()> um ein Element verlängert.
Das ist so nicht richtig. Mit .reserve wurde der Bereich angelegt um
genau das zu vermeiden.
Klaus Wachtler schrieb:> So wie du den std::vector missbrauchst, müsstest du es in C mit einem> frei allokierten Feld vergleichen, das bei jedem Durchlauf mit realloc()> um ein Element verlängert.
Danke!
Der Vergleich von temp hinkt natürlich ohne Ende!
Mal davon abgesehn dass man die C++ Sprachfeatures auch ohne STL nutzen
kann.
Templates, echtes OOP, Überladungen usw. stehen auch ohne STL zur
Verfügung.
le x. schrieb:> Mal davon abgesehn dass man die C++ Sprachfeatures auch ohne STL nutzen> kann.> Templates, echtes OOP, Überladungen usw. stehen auch ohne STL zur> Verfügung.
Und um gleich mal dem 0815 Argument "lolol, dann kannst ja gleich C
nehmen wennst die Hälfte von C++ nicht benutzen darfst" den Wind aus den
Segeln zu nehmen:
In C hat man sich ja auch dran gewohnt nicht alle Standardfunktionen zu
benutzen. Regelmäsig wird hier ja von sprintf, sscanf usw gewarnt.
Dann sollte man fairerweise auch bei C++ akzeptieren, dass es
ressourcenintensive Funktionen gibt, auf die man aber oft verzichten
kann.
le x. schrieb:>> So wie du den std::vector missbrauchst, müsstest du es in C mit einem>> frei allokierten Feld vergleichen, das bei jedem Durchlauf mit realloc()>> um ein Element verlängert.
das war bereits widerlegt!
>> Danke!> Der Vergleich von temp hinkt natürlich ohne Ende!>
Also ich bin ja lernfähig. Wenn ich das Beispiel oben so umbaue:
1
u8Arr.resize(1024);
2
for(intn=0;n<1024;n++)
3
u8Arr[n]=n;
sehen die Verhältnisse so aus:
debug:
std::vector systicks=42184
c-array systicks=12352
release:
std::vector systicks=5413
c-array systicks=4153
> Mal davon abgesehn dass man die C++ Sprachfeatures auch ohne STL nutzen> kann.> Templates, echtes OOP, Überladungen usw. stehen auch ohne STL zur> Verfügung.
Stimmt genau. Benutze ich auch alles. Bis auf die STL. Als ich vor
24Jahren mit C++ angefangen habe gab es da noch nichts was einem
Standard entsprach. Also hat man sich für das was heute die STL abdeckt
eigenen Code geschrieben. Wenn sowas erst mal firmenweit etabliert ist,
guckt man nur hin und wieder über den Tellerrand. Wenn sich da keine
wirklich gravierenden Vorteile ergeben lohnt sich die Mühe nicht.
Moby schrieb:> Rolf Magnus schrieb:>> deshalb>> wurde im GCC die unportable Krücke mit dem ATOMIC_BLOCK eingebaut.>> Ah ja. Ein Beitrag zum Thema Portabilität der Hochsprache.
Ah ja. Manchmal ist es OOP, manchmal C++, manchmal Hochsprachen
allgemein. Ist für dich offenbar alles derselbe Topf. Du sitzt dagegen
weiter auf deinem Assembler-Teller, über dessen Rand du nicht
hinauszuschauen vermagst. Ich schrieb ja schon, daß dein angeblich so
toll passendes Beispiel auch prima dazu dienen kann, µCs insgesamt für
überflüssig zu erklären. Das zeigt ja schon, wie repräsentativ dieses
ist.
> P. M. schrieb:>> Und ein gut optimertes C-Compilat schlägt man>> von Hand in Assembler nicht so schnell.>> Entschuldigung, Unfug. Wenn man nur halbwegs gut die Möglichkeiten> "seines" Controllers nutzt und in Asm halbwegs fit ist!
Und wenn es sich um einen AVR handelt. Es gibt kaum eine andere
Architektur, die in Assembler so simpel zu programmieren ist.
> Irgendwer schrieb:>> Da könnte einem schon der Verdacht>> kommen das beim Thema Optimierung zumindest beim gcc noch einiges an>> Luft für Verbesserungen vorhanden ist.>> Schau einer an. Aber man kann ja immer noch ein paar Hundert bis Tausend> Euro in einen "ordentlichen" Compiler stecken, ich weiß schon.
Alternativ findet man sich einfach damit ab, daß das Programm nicht so
schnell wie möglich, sondern nur so schnell wie nötig läuft und damit
halt einfach etwas weniger seiner Zeit in Idle-Schleifen rumkreist. Ich
kann aus meiner Erfahrung heraus sagen, daß nur ein sehr geringer
Prozentsatz des gesamten Code wirklich so zeitkritisch ist, daß es auf
jeden einzelnen Taktzyklus ankommt, und das gilt auch für µCs.
> In der Praxis liegt der Teufel stets im Detail. Bei richtiger> Initialisierung aller Register, mindestens > halboptimaler Nutzung der> Peripherie, Interruptsystem, Event-Netzwerk, 1:1 Umsetzung der> Funktionalität und vorgesehener, schon lang (selbst) optimierter> I/O-Methoden nie und nimmer!
Weißt du das aus Erfahrung oder ist das einfach nur eine unbelegte
Behauptung? Wie groß ist der Unterschied denn in der Praxis, und wie oft
wäre der in deinen Projekten schon relevant gewesen?
> Hört doch endlich auf, den einfachen ehrlichen Programmierer mit diesem> "Zeug" an der Nase herumzuführen. Danke.
Du solltest dafür aber auch damit aufhören, deine persönliche Meinung
als allgemeingültige Fakten hinzustellen. Mich würde stark wundern, wenn
du jemals auf einem AVR in C++ programmiert hättest, und somit sind
deine Behauptungen allesamt nichtig, da sie nur auf Vorurteilen beruhen
und nicht auf Fakten.
le x. schrieb:> Moby schrieb:>> Komisch. In jedem Zitat kommt C++ vor ...>> Ja, hier hast du recht. Das ist echt komisch.> Im ganzen Thread geht es nur um plain-C, und ob man besser mittels Index> oder Zeiger ein Array kopiert.
Die gleiche Frage könnte man übrigens auch auf Basis von Assembler
stellen.
Yalu X. schrieb:> Stroustrup selbst geht da leider mit schlechtem Beispiel voran und> überlädt die Bitshift-Operatoren << und >> mit Funktionen für die> Ein-/ausgabe.
Das ist allerdings richtig. Ich habe da auch schon die Meinung gehört,
<< und >> seien in C++ die Stream-Operatoren, mit denen man halt auch
Bitshift machen kann. Eigentlich ist es aber genau anders rum.
Teilweise wird auch die Meinung vertreten, daß der Operator-Missbrauch
schon beim operator+ für Strings beginnt, da die Strings ja nicht
addiert, sondern konkateniert werden. Wer aber wirklich mal sehen will,
welchen Unfug man mit Operator-Überladung so treiben kann, sollte sich
mal boost::spirit anschauen. Siehe
http://de.wikipedia.org/wiki/Spirit_(Parser)Nachtmann schrieb:> C++ Code welcher die Features des neusten Standards nutzt ist damit> erstmal enorm schlecht wiederzuverwenden.
Als ob das bei C anders wäre. Selbst Microsoft kriegt es nicht gebacken,
C auf dem Stand von 1999 vernünftig zu unterstützen. Und gerade auch im
µC-Umfeld sieht es nicht wirklich besser aus, obwohl speziell für diesen
Bereich manche der "neueren" C-Features besonders praktisch sind.
Rolf Magnus schrieb:> Du sitzt dagegen> weiter auf deinem Assembler-Teller
... der gerade alles nötige und nichts überflüssiges zur Realisierung
klassischer, hardwarenaher 8-Bit Controllersteuerungen enthält!
Wär aber natürlich albern und für den MC-Interessierten komisch, würde
sein Interesse nicht darüber hinaus in die Hochsprache bis hin zu
'modernem' OOP gehen. Die Erkenntnisse, die man dabei für erwähntes
Einsatzgebiet gewinnen kann sind aber -wie lang und breit dargestellt-
nicht berauschend, um es mal freundlich zu formulieren. Ich habe stets
die Frage im Hinterkopf: Geht das beim angestrebten Ergebnis nicht
einfacher? Kürzer? Schneller?
Am besten wäre ja überhaupt intelligentere Controller-Hardware. Bis die
mal kommt programmiert man eben klassisch genau das was nötig ist-
natürlich und seehr richtig von Dir festgestellt, auf einem simpel
programmierbaren AVR , der für obige Zwecke, gerade in Asm, mehr als
ausreichend ist.
Rolf Magnus schrieb:> dein angeblich so> toll passendes Beispiel auch prima dazu dienen kann, µCs insgesamt für> überflüssig zu erklären.
Wenn man es mit Gewalt missverstehen will schon.
Ansonsten nimmt man ganz einfach zur Kenntnis, daß die unmittelbare
Ansprache der Hardware mit einfachen Instruktionen in jeder Hinsicht das
einfachste und beste ist.
Rolf Magnus schrieb:> Alternativ findet man sich einfach damit ab, daß das Programm nicht so> schnell wie möglich, sondern nur so schnell wie nötig läuft
... dann mal eben nur die Hardware von AVR auf ARM aufzurüsten ist ;-)
> und damit> halt einfach etwas weniger seiner Zeit in Idle-Schleifen rumkreist.
... oder weniger im energiesparenden Sleep-Mode !
Rolf Magnus schrieb:> deine persönliche Meinung> als allgemeingültige Fakten hinzustellen. Mich würde stark wundern, wenn> du jemals auf einem AVR in C++ programmiert hättest,
man muß C++ nicht beherrschen um zu erkennen, daß es für den genannten
Einsatz Krampf ist. Eine 'persönliche' Meinung ist das ja nun auch
nicht. Schaun wir mal. Wenn bald jeder C++ auf 8-Bittern einsetzt, der
große Durchbruch kommt, sehen wir weiter ;-)
> man muß C++ nicht beherrschen um zu erkennen, daß es für den genannten> Einsatz Krampf ist.
Wie willst Du Dir ohne Ahnung ein Urteil erlauben. Das ist dann
bestenfalls ein Vorurteil.
Moby schrieb:> Ich habe stets> die Frage im Hinterkopf: Geht das beim angestrebten Ergebnis nicht> einfacher? Kürzer? Schneller?
Du entscheidest dich willkürlich a priori für das Optimierungsziel
"Einfacher - Kürzer - Schneller". Es gibt auch andere Optimierungsziele:
Lesbarkeit, Flexibilität, Portierbarkeit, Modularität, usw. Ein seriöser
Programmierer wird zunächst seine Aufgabe gut durchdenken und dann
entscheiden, welche Optimierungsziele im vorliegenden Fall besonders
wichtig sind und für welche er nicht viel Effort investieren muss.
In sehr vielen Mikrocontroller-Projekten ist z.B. die Performance selbst
eines Billigst-Controllers mehr als ausreichend. Dann muss man doch um
Himmels Willen nicht die Performance optimieren, sondern achtet lieber
auf lesbaren, portierbaren Code aus flexibel auswechselbaren Modulen. In
anderen Situationen kommt es auf jeden Takt an, dann ist natürlich ein
gut vorsichtig gebautes Assembler-Programm das Mass der Dinge. Dafür
sind diese Programme meist recht überschaubar und eine
Portierung/Erweiterung sowieso gar keine Option.
Also: Wer pauschal auf Assembler und gegen C++ pocht, der hat nur eine
Sichtweise verstanden.
Moby schrieb:> Rolf Magnus schrieb:>> dein angeblich so>> toll passendes Beispiel auch prima dazu dienen kann, µCs insgesamt für>> überflüssig zu erklären.>> Wenn man es mit Gewalt missverstehen will schon.
Es ist einfach nur eine genauso unsinnige Nutzung des Beispiels wie
deine. Du versuchst hier auch nur mit Gewalt, einen Fall zu finden, in
dem C++ nix bringt. Und ich sage eben, daß für den selben Fall ein µC
sowieso nicht sinnvoll ist, egal in welcher Sprache der programmiert
ist.
Das ist, als ob du dich für die generelle Nutzung von Fahrrädern statt
Autos aussprichst, und als Beispiel die 20m-Fahrt zum Nachbarhaus
nennst. Die ist mit dem Auto ziemlich unsinnig, aber mit dem Fahrrad
auch.
> Ansonsten nimmt man ganz einfach zur Kenntnis, daß die unmittelbare> Ansprache der Hardware mit einfachen Instruktionen in jeder Hinsicht das> einfachste und beste ist.
Ebenfalls hinzunehmen ist aber, daß auch ein µC-Programm nicht
ausschließlich aus der unmittelbaren Ansprache der Hardware besteht. Ich
sehe nur zwei Fälle, in denen das anders ist: Trivialprogramme wie dein
Beispiel, die nur aus dem einen Hardwarezugriff bestehen und Programme,
bei denen man nicht sauber zwischen low-level-HW-Zugriffen und der
eigentlichen Funktion getrennt hat. Beides kommt zumindest bei mir im
Alltag nicht vor. Und genau deshalb ist dein Beispiel nicht
praxisrelevant.
> Rolf Magnus schrieb:>> deine persönliche Meinung>> als allgemeingültige Fakten hinzustellen. Mich würde stark wundern, wenn>> du jemals auf einem AVR in C++ programmiert hättest,>> man muß C++ nicht beherrschen um zu erkennen, daß es für den genannten> Einsatz Krampf ist.
Doch, genau das muß man. Es ist zwar heute weit verbreitet, daß jeder
sich für einen Experten zu allen möglichen Themen hält, auch ohne Ahnung
davon zu haben, aber das ist eben falsch.
Die Semantik von resize ist im Defaultzustand ist nunmal, dass die
Objekte ersteinmal default-konstruiert werden, wenn man keine weiteren
Parameter angibt. Somit werden die int's in diesem vector mit 0
initialisiert, wenn Du resize aufrufst. Das hat auch seinen Grund, weil
man im allgemeinen sonst keine Objekte dadrin speichern könnte.
Du kannst aber einen "NoInit-Allokator" beigeben. Dann wird sich der
Overhead auf das einmalige Setzen der Größeninformation und den
Standardkonstruktor reduzierst, weil Du die Größe nicht gleich mitgibst.
Moby schrieb:> man muß C++ nicht beherrschen um zu erkennen, daß es für den genannten> Einsatz Krampf ist.
Falsch. C++ lernt man im Gegensatz zu den meisten anderen
Programmiersprachen auch als geübter Programmierer nicht an einem
Nachmittag. Um C++ richtig einsetzen zu können, muss man die Sprache
wirklich verstehen. C++ ist nicht einfach C mit Klassen und Templates.
Es ist auch nicht Java mit Pointers. C++ ist letztlich nicht nur eine
Programmiersprache, sondern ein richtiggehendes Programmierframework. Um
zu beurteilen, wo man es einsetzen kann, sollte man es schon recht gut
beherrschen. Nur weil du zweimal an einer Flugshow warst, kannst du ja
auch nicht beurteilen, ob eine bestimmte Aufgabe mit einem Hubschrauber
zu schaffen ist.
Sehr interessant! Man kann also sagen, mindestens Klassen, Namespaces,
Inlining, Operator overloading, Konstruktoren/Destruktoren und
Referenzen erzeugen keinerlei Einbussen in der Effizienz. Templates,
wenn richtig und nicht übertrieben verwendet, ebenfalls nicht.
Überraschend finde ich den relativ hohen Overhead für die STL.
Allerdings bezieht sich das hauptsächlich auf die Code-Grösse.
P. M. schrieb:> Sehr interessant! Man kann also sagen, mindestens Klassen, Namespaces,> Inlining, Operator overloading, Konstruktoren/Destruktoren und> Referenzen erzeugen keinerlei Einbussen in der Effizienz.
Stimmt meistens, wenn man es richtig macht - aber nicht pauschal.
P. M. schrieb:> Überraschend finde ich den relativ hohen Overhead für die STL.
Ist auch nicht pauschal richtig.
Overhead wovon verglichen womit?
Overhead hat man, wenn man ein Feld fester Größe in C mit einer
dynamischen Struktur in C++ vergleicht, aber der Vergleich ist Unsinn.
Vergleicht man dagegen feste Felder in C gegen ebensolche in C++ oder
ähnlich flexible und effiziente Lösungen in beiden Sprachen,
verschwindet der Overhead auch schnell wieder.
Klaus Wachtler schrieb:> Overhead wovon verglichen womit?
Ja eben. Man muss wissen, was man will und was man braucht. Das ist wohl
letztlich der Kern der ganzen Diskussion. Die Assembler-Fraktion hier
liegt nicht falsch, wenn sie behauptet, man würde so immer noch die
kürzesten und effizientesten Programme hinkriegen. Der Fehler liegt aber
darin, dass dies meistens gar nicht die wichtigste Zielvorgabe ist.
Die Verwendung von STL-Modulen mag rechenmässig relativ teuer sein
gegenüber händisch hardgecodeten problemspezifischen Pendants. Dafür
bieten sie den Vorteil, dass man auf hohe Qualität vertrauen und
getesteten Code verwenden kann und dank der Standardisierung viel an
Lesbarkeit und Portabilität gewinnt. In den meisten Fällen überwiegt
diese Vorgabe gegenüber den Anforderungen an die Geschwindigkeit.
P. M. schrieb:> Die Assembler-Fraktion hier> liegt nicht falsch, wenn sie behauptet, man würde so immer noch die> kürzesten und effizientesten Programme hinkriegen.
Außerhalb von Trivialkram nicht einmal das. Den Compiler schlagen die in
aller Regel nicht.
P. M. schrieb:> In sehr vielen Mikrocontroller-Projekten ist z.B. die Performance selbst> eines Billigst-Controllers mehr als ausreichend.
Da rennst Du bei mir offene Türen ein ;-)
P. M. schrieb:> Es gibt auch andere Optimierungsziele:> Lesbarkeit, Flexibilität, Portierbarkeit, Modularität
... die in der Klasse klassischer 8-Bit Steuerungen allesamt auch mit
Asm Code realisierbar sind (wenn denn keine wichtigen Gründe
entgegenstehen seine Controller-Schiene zu verlassen).
P. M. schrieb:> C++ lernt man im Gegensatz zu den meisten anderen> Programmiersprachen auch als geübter Programmierer nicht an einem> Nachmittag.
Warum ist es nur so unverständlich, daß Komplexität auch ein zentrales
Argument gegen eine Programmiersprache sein kann ?
P. M. schrieb:> Wer pauschal auf Assembler und gegen C++ pocht, der hat nur eine> Sichtweise verstanden.
Nix pauschal. Ich sage nur: Bitteschön die passende Sichtweise für den
konkreten Anwendungsfall.
asdfasdf schrieb:> Wie willst Du Dir ohne Ahnung ein Urteil erlauben. Das ist dann> bestenfalls ein Vorurteil.
Etwas anderes als darauf herumzureiten, daß man sich jetzt nicht zum C++
Expertenkreis (100 Leute ;-) zählen darf bleibt ja nun nicht... Sicher
ist, den Aufwand dazuzugehören werde ich für einfache
Controllersteuerungen, die wenige Messwerte einlesen, verarbeiten,
Ausgaben machen bzw. in eine Steuerung umsetzen niemals treiben!
Moby schrieb:> asdfasdf schrieb:>> Wie willst Du Dir ohne Ahnung ein Urteil erlauben. Das ist dann>> bestenfalls ein Vorurteil.>> Etwas anderes als darauf herumzureiten, daß man sich jetzt nicht zum C++> Expertenkreis (100 Leute ;-) zählen darf bleibt ja nun nicht...
Doch: Du kannst dir auch einfach Aussagen zu Dingen, die du nicht
kennst, verkneifen.
> Sicher ist, den Aufwand dazuzugehören werde ich für einfache> Controllersteuerungen, die wenige Messwerte einlesen, verarbeiten,> Ausgaben machen bzw. in eine Steuerung umsetzen niemals treiben!
Niemand verlangt von dir, C++ zu lernen. Aber wenn du hier dazu schon
was schreibst, dann wird auch erwartet, daß du das auf Basis des
entsprechenden Wissens tust.
Rolf Magnus schrieb:> Doch: Du kannst dir auch einfach Aussagen zu Dingen, die du nicht> kennst, verkneifen.
Ich sag ja Rolf, es bleibt nichts anderes...
In der Sache selbst kann man C++ eben nicht für jeden Anwendungsfall
predigen und Du kannst davon ausgehen, daß dieser Satz hier und heute
nicht zum letzten Mal geschrieben steht ;-)
Moby schrieb:> In der Sache selbst kann man C++ eben nicht für jeden Anwendungsfall> predigen
Das tut hier niemand, außer in deiner Vorstellung.
Im Gegenteil: du bist der einzige, der hier immer seine beschränkte
Sicht allen anderen aufdrückt.
Moby schrieb:> und Du kannst davon ausgehen, daß dieser Satz hier und heute> nicht zum letzten Mal geschrieben steht ;-)
Danke für die Warnung, aber daß du von deinem bornierten Getrolle
abrückst, hofft eh keiner mehr.
Danke dafür, daß du einen Thread, der zumindest für anderemal
interessant war, platt quasselst.
Moby schrieb:> P. M. schrieb:>> Wer pauschal auf Assembler und gegen C++ pocht, der hat nur eine>> Sichtweise verstanden.>> Nix pauschal. Ich sage nur: Bitteschön die passende Sichtweise für den> konkreten Anwendungsfall.
Eigentlich behauptest du ziemlich offensiv, dass C++ auf 8-Bittern Fehl
am Platz ist. Von Betrachtung des "konkreten Anwendungsfalls" kann bei
dir keine Rede sein. Von Betrachtung verschiedener Prioritäten in einem
Softwareprojekt schon gar nicht. Für dich ist völlig klar, dass auf
einem 8-Bitter die Recheneffizienz das Mass aller Dinge ist. Aspekte wie
Lesbarkeit, Portierbarkeit, Flexibilität, Modularisierung usw. zählen
für dich nicht.
Klaus Wachtler schrieb:> du bist der einzige
versuchen zu isolieren,
> der hier immer seine beschränkte Sicht> deinem bornierten Getrolle
vesuchen zu disqualifizieren,
> der zumindest für anderemal> interessant war, platt quasselst.
versuchen festzulegen was 'interessant zu sein hat'
Klaus Wachtler schrieb:> Ja gut, einen Dildo kann man leicht in ASM programmieren :-)
versuchen lächerlich zu machen
... sind nun mal alles keine recht überzeugenden Antworten, lieber
Klaus. Aber ich verstehe, daß sonst nichts anderes bleibt, die geradezu
ideologische C++ Anwendung hier mit herablassendem Experten-Gestus
durchzudrücken.
P. M. schrieb:> Es gilt übrigens> als sehr unfreundlich, ein Posting Satz für Satz zu zitieren und zu> kontern.
Quatsch. Das behaupten nur so Typen wie du.
Es ist die einzige Möglichkeit, eine sinnvolle Diskussion zu führen.
P. M. schrieb:> Eigentlich behauptest du ziemlich offensiv, dass C++ auf 8-Bittern Fehl> am Platz ist. Von Betrachtung des "konkreten Anwendungsfalls" kann bei> dir keine Rede sein.
Der konkrete Anwendungsfall ist die klassischen 8-Bit
Controllersteuerungen, die
> wenige Messwerte einlesen, verarbeiten,> Ausgaben machen bzw. in eine Steuerung umsetzen
Möglicherweise wird das ja erst durch tausendfache Wiederholung zur
Kenntnis genommen ;-)
P. M. schrieb:> Für dich ist völlig klar, dass auf> einem 8-Bitter die Recheneffizienz das Mass aller Dinge ist.
Für mich ist völlig klar, daß Maß aller Dinge die Minimierung des
Aufwands für eine gegebene Anwendung ist. Die Minimierung von Rechenzeit
und Platzbedarf tragen dazu bei, indem sie die Hardware-Anforderungen
minimieren.
> Aspekte wie> Lesbarkeit, Portierbarkeit, Flexibilität, Modularisierung usw. zählen> für dich nicht.
Wer sagt das? Wo steht das? Ich sagte, auch in Asm ist das möglich wenn
man auf seiner Controller-Schiene bleiben kann. Zu letzterem tragen
wiederum die Minimierung der Hardware-Anforderungen bei. So schließt
sich ein Kreis, ein Gesamtkonzept, das aufgeht wenn alle Teile
zueinander passen.
Ich hatte Dir im letzten Beitrag aber auch eine Frage gestellt.
Warum möchtest Du sie nicht beantworten?
Das Thema hier ist aber wie man es in C++ machen kan und nicht welche
Gründe es gibt, es zu lassen. Ich mische mich auch nicht ein, wenn ASM-,
BASCOM-, Luna-, etc. Freunde ihre Probleme wälzen. Danke für dein
hoffentlich zu findendes Verständnis.
ach.. wo sind wir denn jetzt gelandet?
P. M. schrieb:> Ein seriöser> Programmierer wird zunächst seine Aufgabe gut durchdenken und dann> entscheiden, welche..
Es ist immer wieder ärgerlich, derartige Prämissen als Argumente lesen
zu müssen.
Man schaue sich nur mal in diesem Forum um: Da gibt es haufenweise
Beiträge, wo Leute, die sich selbst für Programmierer halten, ihre
Vorhaben überhaupt nicht gut durchdenken, sondern ihre Ideen im
Geradausgalopp erschlagen wollen.
Beispiele? Aber ja doch:
LED0.ON = Key1.Pressed;
So ähnlich konnte man es jüngst hier lesen - als Ziel für die Verwendung
von C++. Ich wage die Behauptung, daß es sich bei solchen Programmierern
um mindestens die Hälfte aller Programmierer handelt. "Ein seriöser
Programmierer wird.." - nein, dies ist lediglich hehres Wunschdenken und
NICHT Realität.
Aber kommen wir direkt zu C++ zurück:
Könnte mir mal jemand am konkreten Beispiel dieses Threades erklären,
was man denn mit den über C hinausreichenden Mitteln von C++ z.B.
innerhalb eines geräteseitigen VCP-Treibers für den USB-Core eines µC,
oder für das Benutzen des TimerTicks oder für das Handling des SDIO
Cores oder der diversen Counter/Timer denn besser als mit purem C
erledigen kann?
Ich meine wirklich BESSER_ und nicht _FORMALISTISCHER.
Moby schrieb:> Warum ist es nur so unverständlich, daß Komplexität auch ein zentrales> Argument gegen eine Programmiersprache sein kann ?
Darauf gibt es eine sehr einfache Antwort: Weil die Einsicht nicht zum
Selbstverständnis paßt.
Leute, die irgend eine Programmiersprache endlich erlernt haben (je
schwieriger desto besser), sind stolz darauf und sehen mit innerer
Geringschätzung auf den Rest der Welt.
Sie gehören endlich dazu! - also zum Kreis der Erleuchteten (resp.
haben endlich den erhofften Stallgeruch) - und wenn jemand ihnen sagt,
daß er genau DIESE Programmiersprache für schlecht weil zu komplex hält,
dann übersetzt das Selbstverständnis eines solchen Menschen das in "der
ist ein Außenseiter und bloß zu doof". Man schaue z.B. mal in den
FPGA/VHDL-Bereich. Der strotzt von solchen Beispielen. Aber auch in
genau DIESEM Thread kann man das auch x-mal lesen: "Bevor du nicht C++
Guru bist, ignoriere ich deine Sicht der Dinge". Genau DAS ist die
Scheuklappe.
W.S.
Gerne hätte auch jemand erklärt, in welchem konkreten Fall "richtiges"
C++, also jenes, das irgendwelche "nicht C" Features benutzt, auf MCs
Vorteile bringt. Nur leider sind potentielle Autoren ob dem massiven
"geht nicht" Geschreis einiger weniger verschreckt worden. Oder habe
schlicht besseres zu tun als sich anpöbeln zu lassen. Schade! Wäre
sicher interessant geworden.
Bastler schrieb:> schlicht besseres zu tun als sich anpöbeln zu lassen
Anpöbeln nenn ich sowas:
Masl schrieb:> Never discuss with an Idiot...
An meine Adresse wohlgemerkt.
Jemand der tatsächlich den Vorteil von C++ allgemeingültig für
hardwarenahen Zugriff am einfachen Beispiel vorzutragen weiß wird sich
kaum abschrecken lassen. Allein, auf den warte ich hier immer noch ;-(
Moby schrieb:> P. M. schrieb:>> Für dich ist völlig klar, dass auf>> einem 8-Bitter die Recheneffizienz das Mass aller Dinge ist.>> Für mich ist völlig klar, daß Maß aller Dinge die Minimierung des> Aufwands für eine gegebene Anwendung ist. Die Minimierung von Rechenzeit> und Platzbedarf tragen dazu bei, indem sie die Hardware-Anforderungen> minimieren.
Uu setzt die Prämisse, dass die Minimierung von Rechenzeit und
Platzbedarf immer eine wichtige Zielvorgabe ist. Aber das ist falsch.
So lange man nicht gerade dämlich-verschwenderisch mit den Resourcen
umgeht - und das tut C++ nicht - ist der Rechenaufwand oft völlig egal.
Gerade bei "klassischen 8-Bit-Steuerungen" ist das oft der Fall. Wenn
ich zwei, drei Sensoren auslesen muss, zwei, drei Relais schalten,
zweimal PWM habe, ein paar Taster und ein Display ansteuern muss und das
ganze im Sekundentakt passieren kann, dann habe ich selbst auf einem
kleinen AVR endlos Leistungsreserven. Da ist mir viel wichtiger, eine
Abstraktion zu haben, welche das Zusammenspiel der vielen Komponenten
flexibel, modular und lesbar abbildet. Und das geht nunmal mit einer
höheren Programmiersprache viel besser als in Assembler.
Wie gesagt: Die Kritik an deiner Haltung ist, dass du nicht anerkennen
kannst, dass es sehr viele Situationen gibt, wo man gerne etwas
Rechenpower zugunsten von Lesbarkeit, Modularität, Flexibilität,
Portierung usw. verschenkt.
Moby schrieb:> Jemand der tatsächlich den Vorteil von C++ allgemeingültig für> hardwarenahen Zugriff am einfachen Beispiel vorzutragen weiß wird sich> kaum abschrecken lassen. Allein, auf den warte ich hier immer noch ;-(
Es gab mehrere Beispiele, wie man in C++ etwas low-level implementieren
kann und danach über eine praktische Abstraktion ansprechen. Du hingegen
konntest bislang kein Beispiel oberhalb eines Trivialfalles zeigen, wo
man mit Assembler glücklicher wird als mit C/C++.
Bastler schrieb:> Nur leider sind potentielle Autoren ob dem massiven> "geht nicht" Geschreis einiger weniger verschreckt worden.
Das sehe ich nicht so. Hättest du nicht geschrieben "geht nicht",
sondern "macht keinen Sinn", dann könnte ich dir zustimmen.
Also, mal ganz simpel: Das, was über einfaches C bei C++ hinausgeht,
besteht im Wesentlichen aus der objektorientierten Erweiterung von C.
Ja, es ist noch ein bissel anderes in der Büchse, aber das lassen wir
erstmal. Hier wurde argumentiert, daß es für die Lesbarkeit vorteilhaft
sei, Hardware zunächst in zugehörige Objekte zu verwandeln oder
einzuwickeln (man nenne es wie man will), um es danach (zitat) "und
danach über eine praktische Abstraktion ansprechen" eben
objektorientiert ansprechen zu können.
Angeblich sei dies besser lesbar oder programmtechnisch vorteilhaft.
Das zweifle ich hier mal ganz massiv an. Ob man beispielsweise schreibt
PORT4CLR = (1<<Relais1);
oder
Relais1.State = 0;
ist wirklich Geschmackssache. Der Unterschied ist, daß in ersterem Falle
die Sache mit nur einem direkten Befehl erledigt ist, im zweiten Falle
aber ganz anders funktioniert: Dort muß es ein Objekt Relais1 geben,
dieses Objekt muß Eigenschaften haben und diese Eigenschaften müssen
mittels der Methoden des Objektes geändert werden. Es braucht daher im
zweiten Falle immer eines Methodenaufrufes des Objektes und das ist
tatsächlich aufwendiger, als die Sache direkt zu erledigen. Also 1:0 für
plain C. Aber es geht weiter: Objekte existieren nicht per se, sie
müssen als Instanziierungen von Klassen bzw. Objekttypen erstmal
hervorgebracht werden und das bedeutet, sie müssen per Konstruktor
erzeugt werden, was zuinnerst wieder ein Unterprogrammaufruf ist - und
wenn man keine Möglichkeit hat, so etwas zur Übersetzungszeit
vollständig erledigt zu kriegen, dann ist dafür niccht nur Laufzeit und
Programmspeicher nötig, sondern auch RAM, in welchem die Instanz
aufgebaut wird.
Ist so etwas angemessen? Nein. Die Hardware in einem µC ist vorhanden.
Sie muß zwar eingerichtet werden, aber sie ist eben nur EINMAL
vorhanden. Der Sinn von Klassen und Objekt-instanziierungen ist
hingegen, daß man mit einem einzigen Modell eine Vielzahl von
gleichartigen Objekten gleichen Verhaltens erzeugen kann - und das ist
nur für reine Softwaredinge sinnvoll, nicht hingegen für Hardware. Die
ist gegeben. Ein sinnvolles Beispiel wären z.B. Punkte auf einem
Display: Sowas kann dutzende Male auftreten, die Eigenschaften können
von winzig bis groß oder von rot bis lila gehen und die Methoden vom
SichZeichnen bis zum Farbändern oder Position ändern usw. gehen. Dafür
sind objektorientierte Ansätze gut. Aber eben NICHT für den einen
Treiber, der die serielle Schnittstelle bedient.
W.S.
Moby schrieb:> Anpöbeln nenn ich sowas:>> Masl schrieb:>> Never discuss with an Idiot...
Aber Moby, das Thema hatten wir beide doch auch schon mal.
Wer vollkommen unzugänglich für jede Art der Kommunikation ist und als
einzige Reaktion auf wirklich jedes Argument seine eigenen Ansichten
wiederholt, der ist im klinischen Sinne betrachtet, ja, etwas platt
ausgedrückt, ein Idiot.
Im dem Sinne als das diese arme Kreatur unfähig ist noch den Input
seiner Umwelt aufzunehmen UND zu verarbeiten.
Die Reaktionen lassen zwar noch auf einen Verarbeitungsprozess
schliessen, aber das wahnhafte überwiegt und reisst alles an sich.
Zum Leidwesen ihrer Umwelt sind diese armen Wesen dann oft sehr
mitteilungsbedürftig und wollen auf biegen und brechen auch andere von
Ihrem Wahn überzeugen.
Das Internet hat da für beide Seiten einen großen Vorteil.
Wir können Dich einfach ausblenden, auch wenn das nicht immer leicht ist
und müssen nicht befürchten das Du uns plötzlich anfällst und die Kehle
durchbeisst.
Du hast ein Publikum, was Dir ganz offensichtlich viel bedeutet, und
kannst Deine Thesen verbreiten ohne Dir ständig über die Schulter
schauen zu müssen ob die Männer in weiss um die Ecke kommen.
In dem Sinne sei nicht gekränkt wenn man Dich Idiot nennt.
Du tust ja im Endeffekt nichts anderes mit den Menschen die andere
Meinungen und Erfahrungen vertreten.
Ich persönlich finde Dich recht unterhaltsam.
Wenigstens kannst Du einigermassen fomulieren, wenn sich der Inhalt auch
nie ändert. Das ist mehr als manch anderer hier zustande bringt.
Je kruder Deine Ansichten umso verklausulierter Deine Texte, aber auch
das ist nichts unbekanntes bei wahnhaften Persönlichkeiten.
Weiter so, auch wenns manchmal wehtut.
Stimmt! Die Ports B, C, D (oder auch A..G) sind nur einmal vorhanden,
genau wie Uart0 und Uart1 und die Timer sind ja auch einzeln mehrere.
Die erwähnte Vielzahl beginnt bei der Zahl Zwei. Und die Templates, um
die es hier eigentlich geht, sind sowas wie der C-Preprozessor, nur
typ-sicher und mit viel mehr Möglichkeiten. Und Klasses ohne Instanz
gehen gar nicht, also wird's fett. Zumindest falls man keine Vorstellung
hat, was auch angeblich so schlechte Compiler wie GCC daraus machen. Der
wird ja gerade per Zitat von Linus "gedisst", in dem dieser einen Bug im
x86-64 Backend als hernimmt, um sich auszukotzen.
Bastler schrieb:> Die Ports B, C, D (oder auch A..G) sind nur einmal vorhanden
Richtig. Jeder Port ist nur einmal vorhanden - und die Ports
unterscheiden sich fast IMMER massiv voneinander, insbesondere in dem,
was grad implementiert ist, welche Bits gerade vorhanden sind,
anderweitig belegt sind und so weiter. Schau mal in so ein
Hardware-Manual zu einem konkreten µC, da wirst du es sehen können. Es
heißt zwar "PortX,Y,Z" aber es sind überhaupt nicht gleiche Objekte.
W.S.
W.S. schrieb:> Angeblich sei dies besser lesbar oder programmtechnisch vorteilhaft.>> Das zweifle ich hier mal ganz massiv an. Ob man beispielsweise schreibt> PORT4CLR = (1<<Relais1);>> oder> Relais1.State = 0;
Der Unterschied ist (bzw. könnte sein):
PORT3CLR = (1 << Relais1); // gültig, aber falsch
Relais1.State = 0; // das tut was man sich darunter vorstellt.
C++ kann einfach helfen exakt solche Fehler zu vermeiden. Natürlich kann
man das auch in C machen, keine Frage.
W.S. schrieb:> aber es sind überhaupt nicht gleiche Objekte.
Nein, aber sie sind ähnlich. Vermutlich wird jedes der 87 GPIO Pins grob
etwas können wie: Input, Output, Pull-Up, Pull-Down… Das manche dann
noch andere Dinge können, steht auf einem anderen Blatt – Aber: genau
das kann OOP verhältnismäßig gut. Ein interrupt fähiger Pin ist halt
immer noch ein GPIO Pin. Und ein UART ist halt erstmal ein UART – mir
doch egal, was da drunter hängt. Ob das nun eine USB Seriell CDC ist
oder eine RS232 Schnittstelle oder ein RS485 Wandler ist mir oft egal.
Sprich die Objekte müssen nicht gleich sein. Sie müssen sich nur
entsprechend eines Aspektes gleich verhalten.
Moby schrieb:> wenige Messwerte einlesen, verarbeiten,> Ausgaben machen bzw. in eine Steuerung umsetzen
Sieh dir mal eine typische Anwendung für einen 8bitter (ATMega169) an.
z.B. Heizungsregler HR20. Temperatursensor, Stromsensor, Drehgeber, ein
paar Tasten und eine Lichtschranke sowie das Display. Da gibt's auch
eine OpenSource Alternativsoftware dafür.
http://openhr20.sourceforge.net Und jetzt möchte ich wirklich mal wissen
ob es auf der ganzen Welt noch einen einzigen Idioten gibt der sowas in
Assembler macht.
@Moby:
Falls du sowas in lesbarem Assembler gebacken kriegst, nehme ich den
Idioten zurück und behaupte das Gegenteil.
temp schrieb:> Moby schrieb:>> wenige Messwerte einlesen, verarbeiten,>> Ausgaben machen bzw. in eine Steuerung umsetzen>> Sieh dir mal eine typische Anwendung für einen 8bitter (ATMega169) an.> z.B. Heizungsregler HR20. Temperatursensor, Stromsensor, Drehgeber, ein> paar Tasten und eine Lichtschranke sowie das Display. Da gibt's auch> eine OpenSource Alternativsoftware dafür.> http://openhr20.sourceforge.net Und jetzt möchte ich wirklich mal wissen> ob es auf der ganzen Welt noch einen einzigen Idioten gibt der sowas in> Assembler macht.
Offensichtlich hat Moby noch nicht viel gemacht in der Richtung. Ist
zwar kein C++, sondern C, aber ein weiteres Beispiel, dass man so leicht
nicht in Assembler hätte hinkriegen können habe ich auch noch:
https://github.com/emsec/ChameleonMini/tree/master/Firmware/Chameleon-Mini
P. M. schrieb:> So lange man nicht gerade dämlich-verschwenderisch mit den Resourcen> umgeht - und das tut C++ nicht - ist der Rechenaufwand oft völlig egal.> Gerade bei "klassischen 8-Bit-Steuerungen" ist das oft der Fall.
WENN die Kapazitäten des verwendeten (und nicht speziell für viel Code
ausgesuchten) Controllers das hergeben, wenn das Energiebudget keine
Rolle spielt, wenn die entsprechende Entwicklungsumgebung parat steht-
und der ausgebildete und motivierte C++ Entwickler davor,
...hast Du immer noch nicht die Frage beantwortet, warum es zur
Programmierung einfacher 8-Bit Steuerungen gegenüber der 1:1
Funktion-codierenden Asm/C Programmierung zwingend von Vorteil ist,
P. M. schrieb:> eine> Abstraktion zu haben, welche das Zusammenspiel der vielen Komponenten> flexibel, modular und lesbar abbildet.
Zur Beantwortung meiner anderen Frage bist Du wohl auch nicht in der
Lage, aber ich kann mir vorstellen warum ,-)
P. M. schrieb:> Die Kritik an deiner Haltung ist, dass du nicht anerkennen> kannst, dass es sehr viele Situationen gibt, wo man gerne etwas> Rechenpower zugunsten von Lesbarkeit, Modularität, Flexibilität,> Portierung usw. verschenkt.
Die mag es geben. Das habe ich für komplexere, ggf.
controllerhardware-übergreifende Projekte nicht abgestritten.
P. M. schrieb:> konntest bislang kein Beispiel oberhalb eines Trivialfalles zeigen, wo> man mit Assembler glücklicher wird
Der Trivialfall steht für eine unüberschaubare Anzahl von Fällen.
Ob ich 1 oder 100 Eingänge abfrage, 1 oder 100 Ausgänge schalte, 1 oder
100 Messwerte auslese und verarbeite oder viele serielle Verbindungen
unterhalte- das hardwarenahe Prinzip der simplen direkten
Registeransprache bleibt dasselbe. Stehen alle Routinen zur Verfügung
(passend selbst-erstellt und nicht von irgend einem Compiler geschenkt)
ist die Programmierung der Abläufe in Asm einfach.
Michael Knoelke schrieb:> ...
Aber Michael, wenn Du so unerhört viel Mühe aufwendest, für soviel
kunstvoll verpackte Unterstellungen und Beleidigungen fern jeder
fachlichen Aussage zum Thema, dann muß der Frust wirklich tief sitzen.
Lässt tief blicken. Donnerwetter.
apr schrieb:> C++ kann einfach helfen exakt solche Fehler zu vermeiden.
... die sich ja nur aus den vielerlei hochsprachigen Schreibweisen und
Ausdrucksmöglichkeiten ergeben. Sbi PORTA,0 und gut ist- aber warum
einfach wenns auch kompliziert geht?
temp schrieb:> nehme ich den> Idioten zurück
Der ist mir herzlich wurscht.
Aber so einen Heizungsregler mit ein paar der genannten Komponenten hab
ich z.B. auch in Betrieb, natürlich in Asm programmiert ;-)
apr schrieb:>> Der Unterschied ist (bzw. könnte sein):> PORT3CLR = (1 << Relais1); // gültig, aber falsch>> Relais1.State = 0; // das tut was man sich darunter vorstellt.>> C++ kann einfach helfen exakt solche Fehler zu vermeiden. Natürlich kann> man das auch in C machen, keine Frage.>
Sorry, wieso "gültig, aber falsch" und wieso "das tut was man sich
darunter vorstellt"? Ich verstehe nicht, wie man das ohne weitere
Hintergrundinformationen (Schaltplan und MikroController Typ) bewerten
kann. Oder muss man hier mehr das
>"(bzw. könnte sein)"
betonen? Aber dann ist der Beitrag doch ziemlich "dünn".
Ob was tut oder nicht, steht für die einem
a) im Schaltplan,
b) in der Spezifikation des Mikro-Controller
c) in der Spezifikation der Programmiersprachen
d) und in der Spezifikation der API
und für die anderen im Tutorial Ihrer Plattform.
Wenn die einen keinen Fehler gemacht haben, ist es auch "nicht falsch",
und wenn die Plattform nicht genügend gut getestet ist, tut das andere
auch nicht was man sich darunter vorstellt.
Aber das hat nicht mit C / C++ zu tun.
Moby schrieb:> ... die sich ja nur aus den vielerlei hochsprachigen Schreibweisen und> Ausdrucksmöglichkeiten ergeben. Sbi PORTA,0 und gut ist- aber warum> einfach wenns auch kompliziert geht?
Nein, die ergeben sich aus dem Problem, dass man zwei anstatt einem
Namen übergeben muss.
Achim K. schrieb:> Sorry, wieso "gültig, aber falsch" und wieso "das tut was man sich> darunter vorstellt"? Ich verstehe nicht, wie man das ohne weitere> Hintergrundinformationen (Schaltplan und MikroController Typ) bewerten> kann. Oder muss man hier mehr das>>"(bzw. könnte sein)"> betonen? Aber dann ist der Beitrag doch ziemlich "dünn".
Genauso wie alle anderen hier ;)
Es ging mir schlicht darum: Damit so eine typische Bitspielerei das tut
was man dachte dass es tut, muss in dem Konstrukt:
PORT_DEFINITION |= 1 << PIN_NUMMER
beide zusammenpassen. Tun sie das nicht passieren im Zweifelsfall Dinge
und es ist ein Fehler der leicht zu übersehen ist. Während dagegen ein:
motor.run_forward(); gegen ein bomb.explode() irgendwie für mich als
Mensch leichter unterscheitbar ist. Während sbi PORTA,0 oder sbi PORTB,0
schnell mal übersehen wird. Und auch ein sbi MOTOR_PORT,MOTOR_PIN ist
leichter mit sbi BOMB_PORT,MOTOR_PIN verwechselt.
Mein "(könnte sein)" sollte einfach nur Bedeuten, dass ich z.B. mit C++
dafür sorgen kann, dass ein Relais_Pin keinem LED Pin zugewiesen werden
kann – nicht mehr und nicht weniger.
>> Ob was tut oder nicht, steht für die einem> a) im Schaltplan,> b) in der Spezifikation des Mikro-Controller> c) in der Spezifikation der Programmiersprachen> d) und in der Spezifikation der API> und für die anderen im Tutorial Ihrer Plattform.
Klar. Aber es ist unwahrscheinlich, dass Port3 und Port4 einfach
parallel geschalten sind. Deswegen meinte ich es, sei ein Fehler. Ich
hoffe du kannst mir diese freie Interpretation des Beispieles verzeihen.
>> Wenn die einen keinen Fehler gemacht haben, ist es auch "nicht falsch",> und wenn die Plattform nicht genügend gut getestet ist, tut das andere> auch nicht was man sich darunter vorstellt.>> Aber das hat nicht mit C / C++ zu tun.
apr schrieb:> Klar. Aber es ist unwahrscheinlich, dass Port3 und Port4 einfach> parallel geschalten sind. Deswegen meinte ich es, sei ein Fehler. Ich> hoffe du kannst mir diese freie Interpretation des Beispieles verzeihen.>
OK, jetzt verstehe ich was Du meintest.
Mit den sprechenden symbolischen Namen hast Du natürlich recht, die
Vereinfachen das Verstehen von Programmen (wie mein Beitrag oben
ungewollt ja auch gezeigt hat :-) ).
Hallo,
ein paar Punkte hat Rainer Grimm auf der Meeting C++ 2013 mit Fokus auf
C++11 zusammengefasst.
Ein Buch, dass sich mit dem Thema beschäftig kenne ich leider nicht, ich
denke aber man kommt recht weit, wenn man einfach mal überlegt, wie das
eine oder andere C++ feature implementiert ist. Daraus kann man dann
ableiten welchen Ressourcenbedarf das feature hat. strikte Typisierung,
namespaces haben z.B. überhaupt keine Laufzeitkosten, RTTI, dynamic
memory allocation und exceptions haben sehr hohe Laufzeitkosten.
Notfalls mal die Annahmen anhand des map files oder compiler genierten
assemblers überprüfen.
mfg Torsten
Thread beobachten
Seitenaufteilung abschalten