The USE of C++ | Videocast

[@DDLucario]

Gute Sache, bitte mehr mit dem Gast. Sehr insightful.

[@sepppl]

Habe in meinem Studium das Programmieren mit C und C++ gelernt und liebe die Sprache.

[@till8413]

C++ ist auch meine lieblingsProgrammiersprache (auch meine erste gewesen). Ich hab damit lange programmiert und dann vor nem halben Jahr Rust kennengelernt. Besonders die Multithreadingsafety von Rust gefällt mir. In C++ kann ich entweder feinkörnig sein und alles individuell in mutexes umzingeln, diese vielen mutexes zu locken/unlocken zieht dann an der Perfomance. Gehe ich aber den anderen Weg und benutze grobkörnigere mutexe, kann es schnell vorkommen dass es eine crossreference gibt - und man hat zwei threads die gleichzeitig auf die gleiche variable zugreift. Rust löst dieses Problem: ich benutzte grobkörnige mutexe und durch dass Ownership modell muss mir keine sorge machen, dass es da eine crossreference gibt. Wenn ich also den Mutex über einer variable locke, dann locke ich gedanklich quasi den mutex auch über alle membervariablen rekursiv.

[@jochinq3116]

In Python habe ich früher dann mit asyncio gearbeitet um bestimmte IO Tasks zu synchronisieren, wird allerdings bei komplexen Programmen schwierig den Überblick zu bewahren.

[@Hofer2304]

Ich wäre an einem C++-Kurs interessiert. Ja, ich weiß, du hast ihn schon, aber was ich vermisse, ist eine Syntaxüberprüfung im Editor, die Verwendung eines Linters, eines Profilers, eines Debuggers, welche Konsequenzen hat es, wenn ich beim Kompilieren die temporären Dateien durch Pipes ersetze, wie kann ich die Verwendung bestimmter Optionen erzwingen, wie ersetzt man die Standardlibrary durch eine sicherere, kleinerere, schnellerere Library, wie verwendet man die Dokumentation? Wie zeichnet man einfache Grafiken, etwa für den Mathematikunterricht, in C++?

[@wasgehtsiedasan1920]

Hatte heute meine denke dritte c++ Vorlesung und ein Großteil meiner Abneigung ist Neugier gewichen Danke dafür

[@theintjengineer]

Mehr mit dem Cast👌🏽. Also, ich habe schon mit C++20 angefangen und 85% der Probleme, über die, die Leute reden, betrifft ältere Standards. Also, mit C++20 und neuerem kann man sich immer noch alles weg schießen, kein Thema, aber man kann auch sauber und sicher programmieren, wenn man will. Und das wird nur noch besser mit C++23.

[@thorsten9211]

Wirklich gut! Komme selbst aus der Branche. Ich glaube was Einsteigern sehr gut helfen würde in den embedded Bereich zu schnuppern sind einfache Tutorials wie man klassische Sensorik z.b. GPS (GNSS) Sensoren von ublox ansteuert. Diese Sensoren sind günstig, haben aber alle Stolpersteine, die einen abhalten können. Interfacespezifikationen, mehrere Protokolle, externe Bibliotheken oder auch die möglichkeit selbst ein Interface zu schreiben ohne alle Funktionalitäten abdecken zu müssen. Mit dem Raspberry Pi Zero2 und beim einfachen Sensor ist man bei 25 Euro. Deine Tutorials sind sehr gut und du beginnst eben Anfang und das unterscheidet sie von anderen Videos über die man stolpert. Beste Grüße

[@spikeohm6988]

Ich bin auch noch mit Vorliebe bei C++... Schönes Video😁

[@JHxxUniverse]

Super informativ, schön die Seiten von verschiedenen Technologien zu hören, wirklich cooles Interview, gerne mehr von diesem Format und verschiedene Technologien ;}

[@Manfred_Z]

ein fantastisches Interview. Sehr interessant zuzuhören. Mit dem Gast könnte man mehrere Folgen machen,

[@MegaBigjou]

Sehr interessanter Input, mehr davon wäre sicherlich von großem Nutzen!

[@galotta8475]

Danke für das Video. Wirklich sehr interessant. Vor 15 Jahren wurde ich im Mathestudium mit C++ konfrontiert. Damals war es way too much. Heutzutage, als angehender Game Designer der hauptsächlich in C# programmiert, finde die "Geschwätzigkeit" der C-Familie als sehr angenehm.

[@Timm2003]

Cool, der Videocast war hilfreich, ich verwende C++ selber, mag die Sprache sehr (verwende sie allerdings noch nicht unfassbar lange), hab letztens erst von Sprachstandards etc. mitbekommen (verwende zurzeit 17). Würde mir persönlich bei C++ mehr standard-libraries wünschen... Mein Stil wäre beim Code Beispiel (ca. Minute 14) der 2.te gewesen, die for-each Schleife kenne ich allerdings nur, da meine IDE (CLion) es vorgeschlagen hat. Was auto angeht vetrete ich die selbe Meinung wie er. Finde es cool wenn man mal abstrakter über die Programmierung bzw. die Sprache spricht, freue mich auf die nächsten Videocasts.

[@alexanderseizinger7243]

Was meinst du genau mit "wenn man mal astrakter über die Programmierung bzw. die Sprache spricht"

[@Timm2003]

@@alexanderseizinger7243 Ich meine damit, dass man nicht z.B. "Das ist ein if statement und das macht das und das." sagt sondern mal über code schnipsel redet, wer mit wie viel wissen das wie machen würde und welche optionen man hat. Grade so Sachen die allgemein zur Programmiersprache (z.b. standards wie c++ 17 etc.) werden meiner Meinung nach nicht häufig genug betrachtet.

[@alexanderseizinger7243]

@@Timm2003 The Morpheus liest hier ja mit, vielleicht lädt er mich mal wieder ein ;)

[@Timm2003]

@@alexanderseizinger7243 Schau ich mir dann auf jeden Fall wieder an. 👍

[@gforcefabi]

Ich hab C++ in der Berufsschule gelernt und entwickle nun IoT device’s damit und das als Systemintegratior

[@Ph34rNoB33r]

Mit C++ kann man sich leicht das Bein weg schießen, bei Java braucht man dafür den Passierschein A38. Weiß jetzt nicht, was ich besser finde.

[@QueryTuner]

Sehr interessantes Gespräch. Ich sehe im Maker-Bereich (Arduino, ESP8266, ESP32, ATMEGA) oft nur C . Ist C für diese Micro-Controller besser geeignet als C++ ? Oder ist das halt nur weil es alle so machen ?

[@LS-cb7lg]

Grund dafür sind Compiler- und Librarysupport (Stichwort Toolchain). C ist eben nochmal etwas älter und verändert sich langsamer als C++, weswegen oft die Programmierer dafür opten

[@alexanderseizinger7243]

Bin kein Compilerbau-Experte aber ein Grund liegt sicherlich darin, dass es viel einfacher ist/weniger Aufwand kostet einen C-Compiler zu entwickeln (da C verglichen zu C++ einen viel geringeren Sprachumfang hat)

[@LS-cb7lg]

@@alexanderseizinger7243 Ja, das ist korrekt. C++ ist deutlich schwerer zu parsen, speziell was Templates angeht. Du kannst mal nach "the most vexing parse c++" suchen, das ist ein Talk der cppcon der darüber redet.

[@user-lp4to6dl3c]

Arduino Libraries sind imho alle C++. Worin die Arduino Sketches geschrieben werden, weiss ich nicht.Aber da das meiste in was C geschrieben ist, auch von einem C++ Compiler übersetzt werden kann, denke ich mal ebenfalls C++. Die Support Libraries für die meisten Mikrocontroller sind in C, da man damit sowohl die reinen C User als auch die C++ Crew erreicht.

[@VISION-IT]

Super interessantes Video ! Was wären Anfänger, Fortgeschrittende u. Pro Projekte?

[@QueryTuner]

An welchem Computer-Spiel hat er denn mitgearbeitet ?

[@PhalzuBG]

Sehr interessanter talk! Werde aber dennoch team Rust bleiben :3

[@TheBadCode]

Meine Erfahrung ist, egal für welche Programmiersprache man sich entscheidet, sobald man eine Programmiersprache beherrscht, wird man in echten Projekten mit abstrakten Problemen und Konzepten konfrontiert und die Momente, in denen man entspannt und locker Lösungen programmiert, machen nicht den Großteil der Arbeitszeit aus. Noch stressiger wird es wenn man dabei die eher weniger geeignete Programmiersprache gewählt hat. Dann quält man sich unnötigerweise auch noch damit. Ich würde C++ nur freiwillig lernen wenn ich entweder dafür gut bezahlt werde oder wenn ich, warum auch immer, der Ansicht bin dass es die ideale Sprache für mein Projekt ist.

[@alcar32sharif]

11:06 Bestes Beispiel für das Chaos was wir C++ nennen. Ich denke wir können uns darauf einigen, dass es sich hierbei nicht um ein optimales Sprachdesign handelt. Dieses Chaos ist aus meiner Sicht nicht nützlich.

[@cyberpanda8813]

C++ ist nach wie vor mega, gerade die neuen Varianten, wer braucht da schon Rust? (Ich sehe schon alle Rust Liebhaber am haten)

[@TheMorpheusTutorials]

Why not both? 🤷

[@mrysexe]

es soll Menschen geben, die Rust Syntax besser finden 🤷‍♂

[@lizenz5046]

Vielen Dank fuer diesen Videocast. Allerdings moechte ich doch an der Variante mit der Lambdaexpression etwas maekeln. Die Division darin ist falsch. Erst das Ergebnis von accumulate() wuerde durch die Anzahl geteilt werden. So wie in der zuvor gezeigten altmodischen Schleife. Die Verwendung der Lambdaexpression muss nicht fuer Verwirrung sorgen, wenn man ihr einen passenderen Namen gibt. Zum Beispiel "sum" in diesem Fall. Ich sehe, dass es darum ging, die Verwendung von einer Lambdaexpression zu zeigen, aber in diesem simplen Fall war es nicht notwendig. Es ist die Defaultfunktion von accumulate, die Werte zu summieren.

[@DerHerrLatz]

Strong Types als Lieblingsfeatures von C++. Ich schmeiß mich weg. Zählt das überhaupt als Sprachfeature?

[@DrEibein-Elektrokackemusiker]

Jaaa, C++!

[@theintjengineer]

Ranges und accum-reduce wuerde das Beispiel noch kleiner und schoener machen haha

[@Jan-gt5jv]

Hi, ich finde euer Gespräch sehr schön und stimme auch mit den meisten Punkten deines Gastes überein. Aber beim Thema "Man kann die meisten STL Algorithmen im Embedded nicht benutzen" muss ich jetzt dann doch widersprechen. Und ich rede jetzt auch nur von Bare-Metal-Embedded. Also ohne Betriebssystem. Dann kann man entweder std::array als Container verwenden. Oder ab C++17 auch PMR verwenden. Da gibt es dann die dynamischen Container mit einem statischen Speicher im Hintergrund. Ich möchte das Wissen deines Gastes jetzt gar nicht klein reden oder angreifen. Er weiß wovon er redet. Aber er hat genauso wie jeder C++ Entwickler einfach noch Wissenslücken, die ich hiermit gerne so freundlich, wie es nur gelesen werden kann, schließen möchte.

[@alexanderseizinger7243]

Da es nicht Thema des Videos war wollte da nicht zu sehr ins Detail gehen. Ein Level präziser haben die Einschränkungen mit Folgendem zu tun - Dynamische Speicherverwaltung ist nur ein Aspekt und wie angedeutet gibt es dafür durchaus (teilweise) Lösungen. - Der Umgang mit Exception-Handling (inwiefern das ein Problem dastellt hängt stark vom eingesetzten Safety Konzept ab) - Die (fehlende) formale Qualifizierung / Zertifizierung der Container/Algorithmen Nicht davon ist pauschal unlösbar, aus meiner Erfahrung wird aber häufig der Weg gewählt, auf STL oder wesentliche Teile davon zu verzichten.

[@Jan-gt5jv]

@@alexanderseizinger7243 Danke schön für deine Antwort. Mir ging es nur um den Punkt der dynamischen Speicherverwaltung im Embedded. Dass der Umgang mit Exceptions und die fehlende Qualifizierung der Container bei Safety ein Problem ist, stimme ich dir zu. Ich wollte nur auf den Punkt aufmerksam machen, dass die generelle Aussage "STL Container und STL Algorithmen können nicht im Embedded Umfeld genutzt werden" einfach nicht mehr stimmt. Das hast du so nicht gesagt, aber es lässt sich leicht so verstehen und an diesem Punkt habe ich schon oft die alten C Entwickler kommen sehen, die dann der Meinung sind, dass man damn C++ für Embedded gar nicht braucht, sondern lieber gleich bei C bleibt. Nochmal ich sage nicht, dass du das gesagt hast und ich möchte dir auch nicht unterstellen, dass du so denkst. Ich wollte nur für genau solche Diskussionen mit C Entwicklern das Wissen weiter verbreiten, dass die STL dieses Problem schon behoben hat.

[@weirdwordcombo]

Ich kann in allen modernen Sprachen, die ich kenne, wahlweise objektorientiert, funktional oder prozedual schreiben. Abgesehen davon kann ich code auch auf zig Weisen in modernen Sprachen schreiben. Und das lambda Beispiel sieht ja überkompliziert aus im Vergleich zu z.b. C# oder Javascript, absolut nicht zeitgemäß. Da merkt man dass man einfach alles in C++ reinkloppt, bloß damit es diese und jene Features hat. Die einzige Freiheit die C++ bietet, ist die Effizienz und Hardwarenähe, doch die kommt nicht kostenlos daher und wird auch nicht bei jeder Anwendung gebraucht. Ein bisschen eine eigene Bubbel hat er sich glaub ich aufgebaut.

[@SYCHR0N]

Die Vergleiche, wie man sich mit Programmiersprachen in den Fuß schießen kann, sind gut :) C++: You shoot yourself in sombody else's foot :)

[@erichpoly4434]

Erst Py , nebenbei die anderen Konzept Sprache lesen und verstehen. Und nicht alles glauben was das steht.

[@simitron1]

Ich finde etwas schade das der gast nicht wirklich viel erfahrung in anderen sprachen hat, weil all diese argumente nicht in kontext gesetzt wurden, diese aber keine Alleinstellungsmerkmal oder so darstellen. Spannend hätte ich gefunden warum z.B. kein Rust oder Zig oder so benutzt wird oder ob das nur daran liegt, weil legacy code vorhanden ist. Außerdem finde ich das argument man kann dinge sehr unterschiedlich machen als etwas positives dar zu stellen etwas fragwürdig, schließlich sollte man es um wartbarkeit zu erhalten sowieso eingrenzen und wenn die Sprache es bereits begrenzt macht das die Entwicklung für alle beteiligten langfristig einfacher, zumindest nach meiner erfahrung: C++ und Rust

[@TheBadCode]

Unterschiedliche Lösungsmöglichkeiten können als etwas positives betrachtet werden weil sie eben nicht alle gleich sind. Die Flexibilität bedeutet häufig dass man es im Detail anders machen kann und dadurch ist man generell mächtiger was die möglichen Lösungen angeht. Diese Flexibilität geht auf Kosten der Wartbarkeit und einer höheren Komplexität bzw. Fehleranfälligkeit. Ich finde die Analogie mit einem Felskletterer amüsant: Rust ist anspruchvolles klettern an einer Feldwand mit einer Absicherung für den Fall der Fälle. C++ ist das selbe ohne diese Absicherung (wobei man sie optional aufrüsten kann). Man kann bei beiden fatale Fehler machen und abstürzen aber bei Rust ist es deutlich schwieriger abzustürzen. Und Python ist ein mechanischer Aufzug das entlang der Felswand verläuft xD Kann auch abstürzen aber ist nochmal viel unwahrscheinlicher.

[@elpenny81]

Warum kein Rust oder Zig? Zig ist von der Spezifikation noch gar nicht finalisiert. Diese Sprache ist für den professionellen Einsatz noch nicht geeignet. Rust: Es gibt kaum Entwickler, die Rust wirklich können. Rust ist nicht wirklich leicht zu erlernen. Mitarbeiter in diese Richtung zu schulen, ist entsprechend aufwendig. Da ist dann die Frage, ob sich das für Unternehmen wirklich lohnt. Zudem sind die meisten SDKs für Embedded Controller in C oder C++ geschrieben.

[@simitron1]

@@elpenny81 Zig klar, verstehe ich, fände ich nur rein aus konzeptioneller sich interessant also was müsste es noch können/wie müsste es noch sein. Bei Rust finde ich den Punkt schon da aber nicht so stark. Ich habe im bereich embedded software gearbeitet und dort auf Grund der schlechten Software qualität die die meist frisch von der Hochschule kommenden Entwickler geleistet haben alles auf Rust aufgebaut. Das lernen von Rust hat natürlich eine Zeit gedauert, das hätte es aber auch C++ ordentlich zu lernen. Kann natürlich je nach Hoschschule oder Vorqualifikation anders sein, also natürlich nicht generell anwendbar

[@disakek5438]

Was ist das überhaupt und wieso kompiliert das bitteschön. (6:13) - Der Moment wenn man den Code in einer Nacht geschrieben hat und sich dann wundert das er irgendwie weniger Fehler hat als man denkt.xD