Forum: Mikrocontroller und Digitale Elektronik Richtiges C++ hardwarenah


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von cplusplusser (Gast)


Lesenswert?

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.)

von greg (Gast)


Lesenswert?

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.

von OldMan (Gast)


Lesenswert?

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.

von Motek (Gast)


Lesenswert?

> So richtig an der Hardware ist man bei C++ nicht wirklich.

Das ist leeres Geschwätz. Kann man leicht merken, da du nicht konkret 
wirst.

von Scelumbro (Gast)


Lesenswert?

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.

von P. M. (o-o)


Lesenswert?

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.

von OldMan (Gast)


Lesenswert?

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 ;-)

von kopfkratzer (Gast)


Lesenswert?

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 ?

von Stefan ⛄ F. (stefanus)


Lesenswert?

> 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.

von cplusplusser (Gast)


Lesenswert?

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.

von ARDuino (Gast)


Lesenswert?

Viele Arduino Bibliotheken sind in C++ geschrieben.

Beispiel:
https://code.google.com/p/xbee-arduino/source/browse/XBee.cpp

von jaja (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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.

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

cplusplusser schrieb:
> weit, weit, weit mehr als nur kapseln und vererben... Wenn es Richtung
> Hardware geht, dann beginnen sich die Abstraktionsfeatures langsam mit
> der expliziten Kontrolle und Performance zu beissen. Da möchte ich eben
> mehr wissen.
 Entweder oder.
 Beides zusammen wird wohl kaum gehen. Was man früher in DOS machen
 könnte geht mit Windows oder Linux eben nicht mehr.
 Hardwarebezogene Libraries wären vielleicht eine Möglichkeit, aber
 die müsste man sich selbst erstellen und das kann man auch in C.
 C++ bedeutet enormes Overhead an code und genau das will man bei uC
 nicht.
 Und wenn man nicht Kernel oder Embedded benutzt, was soll dann
 C++ mehr bieten ? Warum uberhaupt bei uC benutzen ?

Scelumbro schrieb:
> Speicherplatzkosten. Gelegentlich wird an einem Atmega ein Beispiel
> gezeigt, aber der großteil ist sehr allgemein gehalten.
 Vielleicht ist C++ für ARM geeignet, aber bestimmt nicht für ATMEGA
 oder so. Wer die wirklichen Vorteile von C++ nutzen will, hat in der
 uC-Welt nichts verloren.
 Du willst doch nicht im Ernst behaupten, dass du weisst, was diese
 Zeile genau macht, wieviel Code, Speicher, Stack usw. gebraucht wird:
1
   public int getDigitalLsb(int sample) {
2
      return this.getProcessedPacketBytes()[this.getStartIndex() + 3 + this.getSampleWidth() * sample + 1];
3
   }

> Insbesondere werden viele Templates verwendet. Dadurch das alle
> Informationen zur Compilezeit bekannt sind, kann sehr kompakter Code
> erzeugt werden.
 Der in plain C noch kompakter wäre, von Assembler gar nicht zu reden.

cplusplusser schrieb:
> Und hier spricht auch niemand von einem kleinen Roboter mit
> einem Atmega, sondern von wirklich komplexen Softwares, die gleichzeitig
> die Hardware extrem ausreizen müssen.
 Und dann gleich in C++ ?
 Ein Beispiel, bitte.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Marc Vesely schrieb:
> C++ bedeutet enormes Overhead an code

Wenn man C++ nicht verstanden hat. Sonst stimmt das einfach nicht.

von tictactoe (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

Marc Vesely schrieb:

>  Du willst doch nicht im Ernst behaupten, dass du weisst, was diese
>  Zeile genau macht, wieviel Code, Speicher, Stack usw. gebraucht wird:
>
1
>    public int getDigitalLsb(int sample) {
2
>       return this.getProcessedPacketBytes()[this.getStartIndex() + 3 + 
3
> this.getSampleWidth() * sample + 1];
4
>    }
5
>

Ich seh an dieser Stelle nichts, was jetzt irgendwie speziell C++ wäre, 
ausser ein paar syntaktischen Dingen. Diese Codestelle würde in C auch 
nicht grossartig anders aussehen.

> Wer die wirklichen Vorteile von C++ nutzen will, hat
> in der uC-Welt nichts verloren.

Auf kleinen µC kann man einige Dinge nicht wirklich ausreizen. 
Zustimmung.
Aber es ist nicht so, dass man überhaupt nichts von C++ zu seinem 
Vorteil benutzen kann.

: Bearbeitet durch User
von cplusplusser (Gast)


Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

cplusplusser schrieb:
> Marc Vesely schrieb:
>> Und dann gleich in C++ ?
>>  Ein Beispiel, bitte.
>
> Wie geschrieben wurde: GUI-Library, Multiphysik-Simulation, Compiler,
> Mathe-Library, Game Engine, usw.

Geht auch noch banaler. Eine simple Kommunikationsbasisklasse mit 
Ausgabeoperationen wie zb print. Davon hergeleitet dann zb eine Klasse 
für LCD oder UART. Und schon kann man ein Programm recht einfach von 
UART auf LCD, zumindest in den Basisdingen umstellen. Oder auch SPI oder 
I2C.

Die Arduino Leute ziehen das gar nicht schlecht auf. Das einzige 
'Problem' sind die weit unten sitzenden Funktionalitäten für 
digitalWrite und digitalRead. Da die einen Haufen Sonderfälle 
berücksichtigen, sind sie relativ langsam. Da müsste man sich ein 
anderes Konzept überlegen, wie man den einzelnen Klassen die zu 
benutzenden Pins unterjubeln kann, ohne dem Compiler die 
Optimierungsmöglichkeiten zu nehmen.

: Bearbeitet durch User
von greg (Gast)


Lesenswert?

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.

von Daniel A. (daniel-a)


Lesenswert?

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.

von gnuopfer (Gast)


Lesenswert?

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).

von drama (Gast)


Lesenswert?

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.

von FelixW (Gast)


Lesenswert?

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

von Tom (Gast)


Lesenswert?

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.

von drama (Gast)


Lesenswert?

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)

von kopfkratzer (Gast)


Lesenswert?

Stefan us schrieb:
>> Objektorientiert zu programmieren bedeutet eine passende
>> Schnittstelle mit z.B. Setter/Getter zu implementieren
>> und den Rest so zu kapseln das man ohne Probleme davon
>> erben kann und es immer noch geht.
>
> Da bin ich aber ganz anderer Meinung. Objektorientiert programmieren
> bedeutet für mich, dass Daten und zugehöriger Code zusammenhängend
> strukturiert werden. Das kann man auch in C tun.
>
> C++ unterstützt objektorientierte Programmierung.

Ach Leuts man kann sogar in Assembler "strukturiert" programmieren ...
Nur wird's dann bei Vererbung und Kapselung etwas "kritischer" ...
Ob ich nun
1
void setLED()
in C implemetiere oder eine ganze Klasse mit
1
class mycontroller
2
{
3
...
4
public void setLED()
5
...
6
}
baue bleibt sich erstmal gleich.
Nur wenn ich dann das Programm erweitern will ...

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

cplusplusser schrieb:
> Möglichkeiten für Optimierung hat der Compiler. Und mal ganz ehrlich:
> Was man mit mit Templates in wenigen Zeilen erledigt, dafür sitzt du
> eine ganze Woche vor deinem Assembler-Programm.

 Stimmt.
 Aber das ist es eben, was ich versuche, klarzumachen.
 Wenige Zeilen, ja. Aber vielleicht 2KB Code und
 1ms Ausführungszeit.
 Weiss man ja nie genau. Und wenn ich jedesmal durch generierten Code
 gehen muss, um zu sehen, was da aus wenigen Zeilen geworden ist...
 Im Assembler ist eine Zeile immer eine Zeile.

: Bearbeitet durch User
von Karl H. (kbuchegg)


Lesenswert?

gnuopfer schrieb:
> Karl Heinz schrieb:
>> Ich seh an dieser Stelle nichts, was jetzt irgendwie speziell C++ wäre,
>> ausser ein paar syntaktischen Dingen. Diese Codestelle würde in C auch
>> nicht grossartig anders aussehen.
>
> Der daraus entstehende Code aber schon.


 Bei dem Code Snippet? Unwahrscheinlich.

> Allein durch die VTABLES gibts
> in C++ bei fast allen Funktionsaufrufen eine Indirektion mehr.

So ein Quatsch. Nur dann, wenn ich Polymorphie auch tatsächlich benutze, 
geht der Call indirekt. Aber das hab ich in C auch, wenn ich Polymorphie 
durch Funktionspointer nachbilde.
Benutze ich keine polymorphen Zeiger, dann kostet mich auch ein 
Funktionsaufruf nichts zusätzlich. Selbst dann nicht, wenn die Funktion 
an und für sich virtuell ist. Denn der Compiler kennt dann ja den 
Runtime-Type und kann die Funktion direkt aufrufen. Das eine 
'Optimierung' zu nennen ist schon fast eine Frechheit, verglichen mit 
dem was C++ Compiler sonst noch so alles an Optimierungen drauf haben. 
Das ist trivial und keine Optimierung.

Ein
1
 LCD myLCD;
2
3
 myLCD.write( "Hallo World" );

ist genauso effizient wie die Entsprechung in C. Selbst dann wenn LCD 
von einer Klasse Characterdevice hergeleitet ist und der Member write 
virtual ist.

: Bearbeitet durch User
von Karl H. (kbuchegg)


Lesenswert?

Marc Vesely schrieb:
> cplusplusser schrieb:
>> Möglichkeiten für Optimierung hat der Compiler. Und mal ganz ehrlich:
>> Was man mit mit Templates in wenigen Zeilen erledigt, dafür sitzt du
>> eine ganze Woche vor deinem Assembler-Programm.
>
>  Stimmt.
>  Aber das ist es eben, was ich versuche, klarzumachen.
>  Wenige Zeilen, ja. Aber vielleicht 2KB Code und
>  1ms Ausführungszeit.

Eben nicht.
Das versuchen dir die Leute klar zu machen.

Dieses Märchen ist und bleibt ein Märchen.

Ganz im Gegenteil ist es oft so, dass C++ Compiler kleineren Code 
generieren, als ein entsprechender C Compiler aus einem funktional 
gleichwertigem C Code machen kann. OK, es reisst sich nicht viel und 
genau so oft sind die beiden gleich auf. Aber signifikant schlechteren 
Code generiert ein C++ Compiler nur höchst selten.

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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 ?

von Buchsammler (Gast)


Lesenswert?

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.

von Markus (Gast)


Lesenswert?

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

von Daniel A. (daniel-a)


Lesenswert?

Marc Vesely schrieb:
> public int getDigitalLsb(int sample) {
>   return this.getProcessedPacketBytes()[this.getStartIndex() + 3 +
> this.getSampleWidth() * sample + 1];
> }

kopfkratzer schrieb:
> class mycontroller
> {
> ...
> public void setLED()
> ...
> }

Warum wird hier Java-code geposted, wenn es um c++ geht? In c++ müsste 
es so aussehen (, zumindest wenn public und this keine makros sind):
1
public:
2
  inline int getDigitalLsb(const int sample) {
3
    return this->getProcessedPacketBytes()[this->getStartIndex() + 3 + this->getSampleWidth() * sample + 1];
4
  }
1
class mycontroller {
2
  public:
3
    void setLED();
4
}

von Moby (Gast)


Lesenswert?

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 ...

von Thomas H. (Firma: CIA) (apostel13)


Lesenswert?

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.

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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 ?

von Peter D. (peda)


Lesenswert?

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.

von gnuopfer (Gast)


Lesenswert?

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.

von stefanus (Gast)


Lesenswert?

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.

von Daniel V. (danvet)


Lesenswert?

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.

von Εrnst B. (ernst)


Lesenswert?

stefanus schrieb:
> Apropos Java: Gibt es eigentlich einen Java Compiler, der Maschinencode
> erzeugt (also ohne VM auskommt)? Das wäre vielleicht eine Alternative
> für die Leute, denen C++ zu kompliziert ist.

z.B. den gcj, der bei der GCC dabei ist.

Könnte sich vielleicht sogar mit dem AVR-Backend koppeln lassen?
Fehlt halt die gesamte Lib / Classpath aussenrum.


Problem: C++ kann man ganz ohne dynamische Speicherverwaltung nutzen. 
Also ohne malloc/free/new/delete. Muss halt auf einige Sprachkonstrukte 
verzichten.

Bei Java ist das denke ich sprachbedingt garnicht möglich. Objekte 
müssen immer auf den Heap, und können nicht am Stack angelegt werden.

: Bearbeitet durch User
von cplusplusser (Gast)


Lesenswert?

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.

von Daniel V. (danvet)


Lesenswert?

cplusplusser schrieb:
> Daniel V. schrieb:
>> Einfach mal ausprobieren. Da der TO offensichtlich Assembler "spricht"
>> ist das doch eine einfache Übung. Mal so richtig mit C++ ranklotzen und
>> schauen was der Compiler übersetzt.
>
> Darum gehts eigentlich gar nicht. In meinem Fall ist es eher so, dass
> ich ein grosses Framework auf hoher Abstraktionsebene habe. Sowas
> schreibt kein Mensch in Assembler. Gleichzeitig muss gewährleistet sein,
> dass es auf Maschinenebene extrem performant ausgeführt wird. Und hier
> kann man nicht einfach kritische Code-Abschnitte direkt in Assembler
> schreiben. Es muss z.B. darauf geachtet werden, dass höher abstrahierte
> Datentypen so aufgebaut werden, dass sie maschineneffizient umgesetzt
> werden, z.B. Stichworte sind Alignment, Bitoperationen, Call by
> Value/Reference, Move-Operationen, usw.

Ich habe ja nicht gesagt, dass kritische Codeabschnitte seblst 
geschrieben werden sollen. Aber man kann doch mal nachschauen, was der 
Compiler draus gemacht hat. Und wenn man selbst Assembler "spricht", 
dann kann man auch noch beurteilen, ob der Code so wie er ist 
"effizient" ist. Wenn ja, dann ist gut. Wenn nein, dann kann man sich 
mal damit befassen, warum der Compiler das nicht entsprechend übersetzt 
hat und wie man ihn dazu bekommt, etwas effizienteres zu übersetzen.

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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...

von Εrnst B. (ernst)


Lesenswert?

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.

von Daniel V. (danvet)


Lesenswert?

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...

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

Ε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.

von cplusplusser (Gast)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

von IANAL (Gast)


Lesenswert?

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.

von IANAL (Gast)


Lesenswert?

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 :)

von Rolf Magnus (Gast)


Lesenswert?

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.

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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 ?

von Thomas H. (Firma: CIA) (apostel13)


Lesenswert?

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.

von gnuopfer (Gast)


Lesenswert?

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 !

von Klaus W. (mfgkw)


Lesenswert?

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).

von cplusplusser (Gast)


Lesenswert?

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.

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

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?

von cplusplusser (Gast)


Lesenswert?

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.

von Scelumbro (Gast)


Lesenswert?

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.

von Mladen G. (mgira)


Lesenswert?

Rolf Magnus schrieb:
> Die Meinung, man müsse in C++ zwingend Exceptions nutzen, ist
> erstaunlich weit verbreitet. Selbst Linus Torvalds führt das als einen
> der Hauptgründe auf, warum er gegen C++ im Linux-Kernel ist. Wenn man
> sich die anderen fadenscheinigen Argumente durchliest, bekommt man das
> Gefühl, daß der wahre Grund einfach nur darin liegt, daß er die Sprache
> nicht mag.

Kann man ihm es denn übelnehmen? ;)

http://harmful.cat-v.org/software/c++/linus

Viel Spass noch beim Religionskrieg..

.. duck und weg ..

: Bearbeitet durch User
von mse2 (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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

von Klaus W. (mfgkw)


Lesenswert?

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.

von Vollzeitkraft (Gast)


Lesenswert?

Hier gibt es ein ziemlich gutes C++ Projekt. Sehr Hardware-nahe, sehr 
performant ( muss es sein für Audioprocessing):

https://github.com/sensorium/Mozzi

von Axel S. (a-za-z0-9)


Lesenswert?

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

von Vollzeitkraft (Gast)


Lesenswert?

>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 ..

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

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

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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.

von Thomas H. (Firma: CIA) (apostel13)


Lesenswert?

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?

von BastiDerBastler (Gast)


Lesenswert?

Selten so viele unschlüssige Argumente gegen C++ (verglichen mit C) auf 
einem Haufen gesehen.
Mit Assembler wär' das nicht passiert!

von Rolf M. (rmagnus)


Lesenswert?

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.

von nicht"Gast" (Gast)


Lesenswert?

Guten Morgen,

Rolf Magnus schrieb:
> Ich verstehe es auch nicht. Man verzichtet auf die Vorteile von
> C++
> komplett, weil man auf einem µC nicht alle Vorteile nutzen kann.
> Sobald die Nutzung von C++ auch nur einen Vortiel bietet, ist es doch
> unsinnig, darauf einfach nur aus Prinzip zu verzichten. Diese
> Entscheidung hat nichts mit Philosophie zu tun, sondern mit praktischem
> Nutzen.

So ist der Idealzustand, sollte man meinen. Aber das Thema ist aus 
irgend welchen unerfindlichen Gründen emotional total aufgeladen.

Kann sein, dass die Leute mal ausprobieren, wie die andere Sprache ist. 
Da es aber doch Unterschiede gibt, die man erst mal lernen muss, tut man 
sich am Anfang schwer.
Anstatt mal in sich zu gehen und die Gründe zu erkennen wird das dann 
auf die Sprache abgewälzt und diese für doof befunden.


Ein schönes Beispiel ist Moby. Das einzige, was er auf einem µC zu 
machen scheint, ist einzelne Port bits zu schalten. Man sieht genau, 
entweder will er nur trollen, oder er hat sich noch nie mit einer 
anderen Sprache beschäftigt (gut, ich tippe auf Troll <*(((><  ).

Moby schrieb:
> Sag mal an, wie Du ein Portbit setzt!
> Wehe, das geht über 'sbi PortA,0' hinaus.

Würde ich übrigens in C++ genau so schreiben wie in C und wie es üblich 
ist. Und Oh, sieh mal, wass der Assembler output draus macht,
1
#include <avr/io.h>
2
int main(void)
3
{
4
    PORTB |= (1 << PB0);
5
}

macht der Compiler ein
1
main:
2
/* prologue: function */
3
/* frame size = 0 */
4
/* stack size = 0 */
5
.L__stack_usage = 0
6
  sbi 56-32,0   ; ,,
7
  ldi r24,lo8(0)   ; ,
8
  ldi r25,hi8(0)   ; ,
9
/* epilogue start */
10
  ret
11
  .size  main, .-main

Ja, ich weiß, dass das Programm nutzlos ist, aber Moby braucht ja nichts 
anderes.

Meine Gegenfrage an der Stelle lautet, wie sieht denn bei dir die 
USB-Stack Implementierung eines CDC Devices auf dem Mega32U4 aus? Kannst 
du das nach einem Jahr noch lesen oder anwenden?

Ein nettes Buch ist übrigens "Weniger schlecht programmieren". Das 
beleuchtet die Dinge mal aus einer anderen Sicht.

PS: An dieser Stelle wollte ich grad schreiben, was man alles schönes 
mit der STL machen kann, z.Bsp einen eigenen Allokator einsetzen um den 
freien Speicher zu verwalten, aber das wird einem sicher wieder als: 
'Das muss man dann so machen, auch wenn man nur einen Portpin setzen 
will' ausgelegt. Deswegen lass ich das einfach.

Der Großteil der C-Leute hier würden statt C++ eh einfach C mit Klassen 
programmieren, wenn sie sich mal dran setzten würden.

So denne, viele Worte, wenig Sinn. Leben und Leben lassen. Gottseidank 
gibt es ja die Möglichkeit, dass auf den µC jeder für sich in seiner 
Lieblingssprache glücklich werden kann. Daher besteht auch nicht die 
Notwendigkeit, mal über seinen Tellerrand zu schauen.

von temp (Gast)


Lesenswert?

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.

von Decius (Gast)


Lesenswert?

Ü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.

von Maude (Gast)


Lesenswert?

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?

von Decius (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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ß!

von cplusplusser (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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.

von BastiDerBastler (Gast)


Lesenswert?

Moby würde seine Freude an Templates haben, wenn er sie verstünde...

von Moby (Gast)


Lesenswert?

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!

von cplusplusser (Gast)


Lesenswert?

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.

von nicht"Gast" (Gast)


Lesenswert?

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 :)

von BastiDerBastler (Gast)


Lesenswert?

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 ;)

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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++.

von BastiDerBastler (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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!

von cplusplusser (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Ahab (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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 ;-)

von cplusplusser (Gast)


Lesenswert?

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.

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

cplusplusser schrieb:
> Na komm, jetzt wirds lächerlich. Auf Funktionen verzichten, nur weil der
> feine Herr Vesely dann vielleicht mal ein Handbuch aufschlagen muss? Und

 Ja, bei solchen Beispielen schon.
 So etwas kann man mit einem Template sehr schön machen, nur sollte man
 es eben nicht mit Blinkpattern tun.
 Andererseits könnte man mit Template und Anwesenheitskontrolle genau
 wissen, ob und wann ich heute zur Arbeit gekommen bin, dementsprechend
 blinken oder Klartext ausgeben.

: Bearbeitet durch User
von Moby (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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?

von Moby (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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.

von Hobby-Theoretiker (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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ß.

von Moby (Gast)


Lesenswert?

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...

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

Frank M. schrieb:
>> Niedriger Aufwand!
>
> Falsch. Siehe oben. Programmiere mal einen STM32 in Assembler. Viel
> Spaß.

 Habe ich doch.
 Timergesteuertes LED blinken.
 Und das war für mich schon der Grund genug eine Ehescheidung zwischen
 ARM und Assembler zu verkünden.

: Bearbeitet durch User
von Moby (Gast)


Lesenswert?

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 ;-)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Moby schrieb:
> Frank M. schrieb:
>> Die Entwicklungszeit dauert mit ASM länger, da schon bei mittelgroßen
>> Programmen mehr Fehler gemacht werden, die dann alle gesucht und
>> gefunden werden wollen.
>
> Sicher. Ab einer gewissen Projektgröße. Von der spreche ich aber hier
> nicht.

Achso. Ich wusste nicht, dass Du Mickey-Mouse-Progrämmchen meinst und 
dass ein AVR-Tiny für Dich und alle Zeit ausreicht.

Auf Deinen Rest gehe ich gar nicht ein. Wir haben offenbar verschiedene 
Vorstellungen davon, wie umfangreich "durchschnittliche" Programme 
tatsächlich sind.

Du redest von Programmen, die man in 30 Minuten hinrotzen kann und ich 
von Software-Projekten, die innerhalb von Wochen/Monaten - teilweise 
Jahren - wachsen... für mich absolut durchschnittlich.

: Bearbeitet durch Moderator
von Scelumbro (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

Von atmega32 auf atmega64 portieren ist auch portieren :-)

von Sven (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

Moby schrieb:
> Man muß nichts "neu" entwickeln und portieren weil man für Millionen
> klassischer 8-Bit Anwendungen locker auf der schön einfachen 8-Bit (AVR
> oder PIC) Schiene bleiben kann.

Moby schrieb:
> Hardwarenahe Dinge bestimmt nicht. Vieles andere was mittelbar mit der
> Hardware zusammenhängt auch nicht. Das Portabilitätsargument spielt
> überhaupt nur dann eine Rolle wenn man wirklich zum
> Controllerarchitektur-Wechsel gezwungen ist

Moby schrieb:
> Der Horizont muß zunächst mal soweit reichen wie es die tatsächlichen
> Bedürfnisse der Anwendung erfordern.

Moby, du bist wieder gleich weit: Du schränkst die Aufgabenstellung 
einfach so lange ein, bis deine Argumente passen.

Im Prinzip hast du wunderschön dargelegt, dass bei wenig komplexen, 
nicht zu portierenden/skalierenden Projekten auf 8 Bit und wenn man 
schon gut C/Assembler kann, mit C++ keine grossen Vorteile zu erwarten 
sind. Alle anderen Fälle hast du ausgeklammert, weil deine Argumentation 
dort nicht passt und C++ folglich Vorteile bringen wird.

von Stefan (Gast)


Lesenswert?

> 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.

von Tobias K. (t_k)


Lesenswert?

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

von Ahab (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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 :)

von Christian B. (casandro)


Lesenswert?

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.

von Tobias K. (t_k)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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++".

von cplusplusser (Gast)


Lesenswert?

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".

von Fitzebutze (Gast)


Lesenswert?

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).

von P. M. (o-o)


Lesenswert?

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...

von Tobias K. (t_k)


Lesenswert?

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

von P. M. (o-o)


Lesenswert?

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.

von Ret (Gast)


Lesenswert?

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 "

von BastiDerBastler (Gast)


Lesenswert?

Jetzt wird der Thread wieder von Leuten gekapert, die verschont bleiben 
wollen davon und trotzdem in den Thread schauen...

von Moby (Gast)


Lesenswert?

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!

von cplusplusser (Gast)


Lesenswert?

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.

von TriHexagon (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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!

von TriHexagon (Gast)


Lesenswert?

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

von Moby (Gast)


Lesenswert?

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.

von Tobias K. (t_k)


Lesenswert?

@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.

von Moby (Gast)


Lesenswert?

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 
;-)

von Tobias K. (t_k)


Lesenswert?

Einigen wir uns auf: "Früher war's anders" ;) Ist halt wie immer die 
Frage, was Du vor hast.

BTT: Das reine manuelle Schreiben von C/ASM-Code hat imho nichts mit 
modernem Softwareengineering zu tun. Dass das trotzdem sehr gut 
funktioniert, steht auf einem anderen Blatt.
Gerüstet für die Zukunft ist man damit aber noch lange nicht, dafür ist 
Silizium zu billig.

Die legitime Frage des TO war ja nun, ob C++ da was beitragen kann. Und 
Yalu warf auch schon die Frage auf, warum keiner die Arduino libs 
dahingehend verbessert.

Grüße,
tk

: Bearbeitet durch User
von Franz (Gast)


Lesenswert?

>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?

von Tobias K. (t_k)


Lesenswert?

WG-Analogie: Ich beschwere mich nicht, dass das Klo dreckig ist. Mir 
reicht das vollkommen.

von chris_ (Gast)


Lesenswert?

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

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

P. M. schrieb:
> Klar mag es sein, dass du in deiner Berufskarriere nichts anderes
> gesehen hast und deine Komfortzone mit C gefunden hast. Zum Glück gibt
> es aber auch Leute, die nach vorne schauen um bessere Konzepte zu
> entwickeln.
 Ich nehme stark an, du hast so ziemlich alles gesehen ?

TriHexagon schrieb:
> welche Eigenheiten diese besitzt. Nein danke. Es gibt einen Grund
> weshalb man heutzutage ausschließlich mit Hochsprachen arbeitet

 Für alle die hier nur das, was die rausgegoogelt haben, wiederholen:

 C++ ist weder für Mikrocontroller gedacht, noch geschrieben worden.
 Wenn es um Hardware geht, ist die Frage: plain C oder C++ absolut
 irrelevant. Einzelne bits setzen, Register mit irgendwelchen Werten
 laden usw. ist bestimmt nicht das, wofür C++ geschrieben wurde.
 Also wird C++ bestenfalls genau dasselbe compilieren wie plain C.

 Damit ist die Frage die der TO (zwecks Selbstdarstellung) gestellt
 hat, schon mal sinnlos.
 Alle die mit irgendwelchen Argumenten für C++ um sich werfen und
 unzählige Vorteile diese Sprache anpreisen, reden in Wirklichkeit
 von Windows oder Linux.

 Und das ist weit, weit entfernt von Mikrocontrollern.

von Bn7850 (Gast)


Lesenswert?


von Bn7850 (Gast)


Lesenswert?


von Fitzebutze (Gast)


Lesenswert?

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!

von W.S. (Gast)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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.

von TriHexagon (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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...

von TriHexagon (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von BastiDerBastler (Gast)


Lesenswert?

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...

von P. M. (o-o)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von P. M. (o-o)


Lesenswert?

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.

von FelixW (Gast)


Lesenswert?

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

von Tobias K. (t_k)


Lesenswert?

...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*

von P. M. (o-o)


Lesenswert?

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.

von Programmiersprachen-Fan (Gast)


Lesenswert?

> 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?

von Moby (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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?

von Moby (Gast)


Lesenswert?

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.

von TriHexagon (Gast)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

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...

von Moby (Gast)


Lesenswert?

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

von Yalu X. (yalu) (Moderator)


Lesenswert?

Sicher kennen inzwischen 99,9% der Diskutanten Mobys Meinung.

Sicher haben inzwischen 99,9% der Diskutanten begriffen, dass es
niemandem, egal mit welchen Argumenten, gelingen wird, Moby von seiner
Meinung abzubringen.

Wer sich zu diesen 99,9% zählt, sollte sich vielleicht einfach wieder
dem eigentlichen Thema des Threads zuwenden und Moby seine Meinung
lassen.  Wenn dieser dann die Diskussion immer noch stört, kann man
weiter sehen ...

: Bearbeitet durch Moderator
von W.S. (Gast)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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!

von Bastler (Gast)


Lesenswert?

Warum müssen sich immer die Täter als Opfer darstellen?
Wenn man ein hier diskutiertes Konzept nicht man, dann geht man eben zum 
nächsten Thread!

von W.S. (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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 ?   ;-)

von Rolf M. (rmagnus)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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.

von Bastler (Gast)


Lesenswert?

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!

von Moby (Gast)


Lesenswert?

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.

von Bastler (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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 ;-)

von Moby (Gast)


Lesenswert?

cplusplusser schrieb:
> Du möchtest mit der simpelsten Programmieraufgabe zeigen, dass

OOP hardwarenah Quatsch ist, ja genau.

von Klaus W. (mfgkw)


Lesenswert?

Das Blinkbeispiel ist eine wunderschöne Parallele zum Wahnsinn, alles 
mit Elektronik zu erschlagen.

Die Archtektur der Wahl ist eine Kerze und eine Schachtel Streichhölzer 
daneben. Wesentlich weniger Umweltbelastung, billig und auch für Leute 
wie Moby intellektuell zu erfassen.

Anzünden, Auspusten, Anzünden, Auspusten...


Nachdem der Thread hier erfolgreich ramponiert ist bleibt für mich nur 
noch die Frage: Ist der Typ wirklich so verbohrt, oder trollt er nur?

: Bearbeitet durch User
von Moby (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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.

von husten (Gast)


Lesenswert?

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

von Daniel A. (daniel-a)


Lesenswert?

husten schrieb:
> Javascript .. mag ich

Ich auch! Besonders die drei scopes und dass es keinen blockscope gibt. 
So kann man andere leicht verwirren :-)

von Rolf M. (rmagnus)


Lesenswert?

Moby schrieb:
> Wo liest Du das heraus?

Aus deinen Postings, die immer nur solche Trivialfälle beschreiben und 
daraus, daß du andere Beispiele mit größeren Programmen geflissentlich 
ignorierst.

> Weil ich die Blinkschaltung als transparentestes Beispiel für den
> Wahnwitz der OOP-Anwendung darauf auswähle?

Ich könnte auch sagen, daß Assembler und ganz allgemein µCs ja völlig 
sinnlos und viel zu komplex sind. Da braucht man die passende Hard- und 
Software am PC, muß sich erst ein Programm schreiben, das assemblieren, 
dann auf den µC brennen u.s.w., und das, obwohl man eine Blinkschaltung 
doch auch ganz ohne sowas einfach mit einem ne555 machen kann. Also 
braucht man diese komplexen und umständlichen µCs gar nicht, denn dieses 
repräsentative Beispiel zeigt eindrucksvoll, daß ohne diese alles viel 
einfacher ist.
Daß OOP vor allem beim Handhaben von komplexen Programmen was bringt, 
wurde ja schon gesagt. Daß C++ nicht nur aus OOP besteht, auch. Das 
trivialstmögliche Programm ist deshalb selbstverständlich vollkommen 
ungeeignet als Beispiel. Natürlich sind µC-Programme nicht so komplex 
wie die auf dem PC, aber in der Regel machen sie dann doch noch deutlich 
mehr als nur eine LED blinken zu lassen. Und mit einem ordentlichen 
Design ist der wirklich hardwarenahe Teil überschaubar und von der 
eigentlichen Funktionialität sauber getrennt.

> Was hier im Kleinen gilt verliert auch in größerem hardwarenahen Rahmen
> keine Gültigkeit.

Doch, natürlich verliert es die. Ein Schäufelchen und ein Eimerchen 
reichen, um eine Sandburg zu bauen. Will ich aber was sinnvolles, wie 
z.B. ein Haus bauen, bekomme ich mit einem Eimer und einer Schaufel zwar 
vielleicht auch irgendwie eine Lehmhütte zusammen, aber ein ordentliches 
Haus wird's halt nicht.
Es sollte doch klar sein, daß Erkenntnisse, die sich aus Trivialfällen 
ergeben, sich nicht einfach so auf die reale Welt übertragen lassen.

: Bearbeitet durch User
von Moby (Gast)


Lesenswert?

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.

von bal (Gast)


Lesenswert?

Moby schrieb:
> ...

Der Typ erinnert mich irgendwie an einen gewissen Kurt.
Fehlt nurnoch die Floskel: "da schwingt überhaupt nichts..."

von Klaus W. (mfgkw)


Lesenswert?

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 
:-)

von Moby (Gast)


Lesenswert?

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.

von Masl (Gast)


Lesenswert?

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...

von Moby (Gast)


Lesenswert?

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 ;-(

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

Moby schrieb:
> Also Klaus, Du enttäuscht mich besonders ;-(

Ich habe in dem Forum zu C++ schon etwas mehr beigetragen als die 
meisten andern, vor allem etwas differenzierter als dein Getrolle.
Liest nur nicht jeder - was mir auch nicht weh tut. Aber dann bitte 
nicht blöd herumtrollen. Vor allem scheinst du mein "OOP-Weltbild" nicht 
zu kennen.

: Bearbeitet durch User
von TriHexagon (Gast)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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 ;-)

von Franz (Gast)


Lesenswert?

>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

von Moby (Gast)


Lesenswert?

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 ;-(

von cplusplusser (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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 ... ;-)

von Moby (Gast)


Lesenswert?

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 ;-)

von Klaus W. (mfgkw)


Lesenswert?

Ja gut, einen Dildo kann man leicht in ASM programmieren :-)

von Moby (Gast)


Lesenswert?

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 ;-)

von Klaus W. (mfgkw)


Lesenswert?

Halt dem Niveau angemessen, den der Thread inzwischen hat.
Er ging ja mal interessant los.

von Klaus W. (mfgkw)


Lesenswert?

PS: Vielleicht ist das ja endlich mal ein Anlass, die letzten n-1 
Beiträge zu entsorgen...

von rs (Gast)


Lesenswert?

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

von cplusplusser (Gast)


Lesenswert?

Moby's Argumentation wurde schon früh im Thread etwas gewagt, aber 
mittlerweile ist das doch nur noch trollig.

von Franz (Gast)


Lesenswert?

Wie schon erwähnt, Hessi James passt ganz gut auf Mobby. Lieber nicht 
mit ihm anlegen:
http://www.youtube.com/watch?v=akfz5Fw-pZI

Entschuldigt, wenn ich jetzt doch eine On-Toppic Frage stelle.
Bei dem geposteten Link
https://github.com/ambrop72/aprinter/tree/master/aprinter/base
wird der Code z.Teil in die Header-Files gesteckt. Geht das? Macht das 
Sinn?

von Tobias K. (t_k)


Lesenswert?

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" ;)

von Moby (Gast)


Lesenswert?

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.

von TriHexagon (Gast)


Lesenswert?

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).

von Tobias K. (t_k)


Lesenswert?

Womit wir übrigens wieder BTT wären: Wenn der Compiler z.B. entscheidet, 
welche Sachen er inlined und welche nicht, dann habe ich abhängig von 
den Randbedingungen wie zB. 'wenig RAM und einigermaßen viel Flash' doch 
eventuell ein Problem, das in diesem Fall von einem C++-Konzept 
induziert wird, oder sehe ich das falsch?

: Bearbeitet durch User
von Klaus W. (mfgkw)


Lesenswert?

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.

von cplusplusser (Gast)


Lesenswert?

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...)

von Moby (Gast)


Lesenswert?

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 ;-)

von Ahab (Gast)


Lesenswert?

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...

von husten (Gast)


Lesenswert?

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 quel