Bin gerade C++ am Lernen. Man liest immer wieder es sei nicht möglich Hardwarenah zu programmieren mit C++, bzw. Objektorientiertes Programmieren ist nicht geeignet dafür weil nicht effektiv genug (Geschwindigkeit). Ich weiß das es noch zu früh ist für mich als Anfänger sich über so etwas Gedanken zu machen. Doch mich interessiert es einfach nur.
Treiber werden, soweit ich weiß, in C + Inlineassembler geschrieben wegen der Schnelligkeit.

Ist an der Aussage, C++ ist weniger geeignet, etwas dran?
Ist es die Objektorientierung oder liegt das einfach nur am Grunddesign der Sprache?

MfG

Ist an der Aussage, C++ ist weniger geeignet, etwas dran?

nein. die aussage ist kompletter unfug.

C++ ist eine Erweiterung von C, d.h. man kann nach wie vor für kritische Codeabschnitte C oder Inline-Assembler verwenden. Daher ist die Aussage C++ sei langsamer als C so nicht wirklich sinnig.

Die Verwendung von Vererbung und virtuellen Funktionen (Objektorientierung) kann den Code jedoch ausbremsen. Dies gilt vor allem innerhalb von for oder while Schleifen, bei denen du sehr viele Daten verarbeiten musst.

Auch können Dinge wie Default Ctor, automatisch erzeugter Dtor, Vtable etc. auf manchen Systemem zu Problemem führen wenn der Code in Interrupts genutzt wird -- wenn die der Compiler bzw. Linker in ein "pagable" Segment wirft machts u.U. *boom* wenn der Interrupt darauf zugreifen will.

Wenn man auf solche Dinge aufpasst spricht aber eigentlich nix dagegen C++ auch für low-level Treiber zu verwenden. Und es gibt sogar einige Frameworks z.B. für Windows Treiber die auf C++ aufbauen.

Und inline Assembler wird kaum mehr verwendet -- in den meisten Fällen ist der Compiler besser als selbst gute Programmierer beim Optimieren von Code, bzw. anders gesagt: ein guter Programmierer würde viel zu lange brauchen um den Code so gut zu optimieren. Und bei jeder Änderung müsste er u.U. aufs neue Optimieren - das zahlt sich einfach nicht aus.

z.b. ein treiber fuer eine graphikkarte,
1. du moechtest moeglichst wenig register der graka beschreiben, weil jedes umkonfigurieren zeit kostet, also nur das was sich veraendert hat.
2. du moechtest nich bei jedem parameter vergleichen ob er anders ist als der der gerade aktiv ist, weil du sonst hunderte von vergleichen hast und das auch langsam ist.
3. du moechtest eventuell einen treiber haben der auf linux, windows, apple (mac/c2d) laeuft, also kein assembler/selbstmodifizierender code.

also machst du dir mittels ein paar defines und templates einen riesiegen switch-case bei dem die templates schon zur kompilezeit evaluieren wie sich der gewuenschte status vom momentanem aendert (fuer alle moeglichkeiten) und dann generiert man nur noch den gewuenschten register-schreibe-code.

konkretes beispiel:
alphablend an/aus
alphatest an/auss
zwrite an/aus
ztest an/aus
stencilwrite an/aus
stenciltest an/aus
colorwrite an/aus
backfaceculling an/aus

also 2^8 ausganszustaende und 2^8resultierende, aus diesem switch-case block macht dir der compiler dann ne jumptable mit 65536 eintragen.

das einzige problem ist das bei manchen konstrukten die compiler tod gehen

C++ ist eine Erweiterung von C

Ist diese aussage nicht blödsinn? Sofern wie ich weiß war C++ früher eine Erweiterung von C, aber seit dem C++98 Standard eine eigenständige sprache. Jedenfalls das der C99 Standard nicht in C++ eingeflossen ist, untermauert die falschheit deiner aussage.

Wäre C++ "nur" eine Erweiterung von C, dann müsste C99 doch auch in C++ eingeflossen sein, gell?

Ist diese aussage nicht blödsinn? Sofern wie ich weiß war C++ früher eine Erweiterung von C, aber seit dem C++98 Standard eine eigenständige sprache. Jedenfalls das der C99 Standard nicht in C++ eingeflossen ist, untermauert die falschheit deiner aussage.

Wäre C++ "nur" eine Erweiterung von C, dann müsste C99 doch auch in C++ eingeflossen sein, gell?

Ist diese Aussage nicht Blödsinn?
Wer redet hier von "nur"? Und selbst wenn er davon geredet hätte, bei einer Erweiterung sind Ergänzungen nunmal nicht ausgeschlossen.

Wenn c++ früher mal eine Erweiterung von c++ war, wie kann c++ heute keine Erweiterung mehr sein?
Auch wenn sich c++ bis heute so weit entwickelt hat, dass c++ als eigenständige Sprache betrachtet werden kann, ändert das nichts an c als grundlegenden Unterbau, selbst eventuell vorhandene Ergänzungen bezüglich syntaktischer Regeln ändern nichts daran.

Und was c99 angeht, kenne diesen Standard nicht wirklich, doch die Punkte die ich kenne, sind Anpassungen an c++ Oo

Als Beispiel wären da z.B. die aus c++ bekannten Referenzen, die C++-KOmmentare, verbot des impliziten ints oder überhaupt der Verbot zur Deklaration impliziter Deklarationen und dieser ganze Kram.

Ob man C++ nun als eine Erweiterung von C betrachten will oder nicht ist eine Sache, doch derartig abwegig ist diese Behauptung, als dass man sie einfach als Blödsinn abstempeln könnte, sicherlich nicht.

Die Sachen, die Embedded-Programmierer wirklich erschrecken können, laufen zum Beispiel so ab:

man hat zwei structs mit dazugehörigen funktionen. alles ok. dann bastelt man die um in klassen. alles ok. das compilat wird sogar ein paar bytes kleiner. man macht auch ein paar virtuelle funktionen. auch ok, eine verzweigung je nach typ war notwendig und ob man das jetzt per hand macht, oder virtual benutzt, ist fast egal. das compilat ist noch fein klein. oh, der dtor sollte aber auch virtuell sein. kein prob. und sollte die eine funktion nicht pur virtuell sein? das mach auch auch mal. uih, riesenanschiss vom chef gekriegt, warum ich so bescheuert sei, c++ zu nehmen. compilat hat 280000 bytes statt der 2500 bytes von vorgestern. lag am dummen =0. der compiler hat ne geheime funktion reingefummelt (ein paar bytes dazu), die aufgerufen wird, wenn ich so bescheuert bin, durch wildes gecaste oder aufruf im ctor eine pur virtuelle funktion aufzurufen. die wiederum schmeißt eine exception (exceptionhandling dazu mit 23000 bytes), die fliegt durch bis zu ner funktion, die das programm terminiert. und diese funktion wiederum gibt was nach cerr aus (iostream dazu mit 250000 bytes). was so ein kleines =0 doch ausmachen kann. naja, jetzt hat der chef verboten, jemals wieder c++ zu nehmen und erzählt überall, wie viel besser c doch für embedded systems ist.