Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Tizen-Betriebssystem: "Könnte der…

Mit C++ wäre das nicht passiert

  1. Thema

Neues Thema Ansicht wechseln


  1. Mit C++ wäre das nicht passiert

    Autor: HansiHinterseher 05.04.17 - 10:43

    Ich kann heute nicht verstehen, warum noch plain C programmiert wird? Heute ist es doch nun wirklich kein Problem mehr richtiges C++ anzuwenden, sowohl vom Know How als auch vom von der Hardware. Das sind doch keine Geräte mit 64 Byte RAM oder so, sondern Geräte mit Multi-Core-CPUs und mind. 0,5 Gbyte RAM.

    Historische Systeme wie Unix, NT oder Linux, die entwickelt wurden als C++ und andere Sprachen noch in den Kinderschuhen steckte oder noch gar nicht existierte... kann ich verstehen das C Code verwendet wird. Ist völlig normal.

    Aber wenn ich frisch auf der grünen Wiese ein neues System entwickle, werde ich mich nach Tools umschauen, die mich beim Memery-management unterstützen, so weit es geht.

  2. Re: Mit C++ wäre das nicht passiert

    Autor: MoonShade 05.04.17 - 12:29

    > Aber wenn ich frisch auf der grünen Wiese ein neues System entwickle, werde ich mich nach Tools umschauen, die mich beim Memery-management unterstützen, so weit es geht.

    Also Rust?

  3. Re: Mit C++ wäre das nicht passiert

    Autor: sre 05.04.17 - 12:42

    Wenn ich heute "irgendwas" für Linux programmiere was auch tats. mit dem System interagieren soll, so komme ich nicht darum herum an bestimmten stellen mit C-Interfaces zu agieren.
    Selbiges gilt für einen großen Teils von verfügbaren Linux/Unix libs.

    Abgesehen davon bin vehement gegen die Meinung eine andere Sprache würden einen schlechten Programmierer besser machen.
    Solche Probleme wie bei Tizen enstehen nicht durch eine anfällige Programmiersprache sondern durch falsche Prioritäten bei der Entwicklung und schlechte Ausbildung der Entwickler.

    Moderne Sprachen wie z.B. Rust helfen guten Programmieren dabei, weniger versehentliche Fehler bei der Entwicklung zu machen.
    Ein schlechter Entwickler wird auch in Rust schlechten Code schreiben.

  4. Re: Mit C++ wäre das nicht passiert

    Autor: /mecki78 05.04.17 - 13:02

    HansiHinterseher schrieb:
    --------------------------------------------------------------------------------
    > Ich kann heute nicht verstehen, warum noch plain C programmiert wird?

    Weil C++ alle Probleme von C geerbt hat und diese mit Objekten und dynamischen Dispatch nur auf ein neues Level hebt und oben drauf noch eigenen, weitere Probleme mit sich bringt. C++ wollte es allen Recht machen, wirklich allen, und hat es damit am Ende aber niemanden recht gemacht.

    C++ z.B. hat ja kein anderes Memory Management als C, es hat weder Reference Counting, noch Garbage Collection, noch ist das Memory Management automatisch. Natürlich kannst du das alles mit C++ machen... aber das kannst du auch alles mit normalen C machen, du musst es nur implementieren.

    C++ ist wie wenn du über einen Trabi ein Ferrari Chassis drüber stülpst. Im ersten Schritt sieht alles toll, stylisch und modern aus, aber wenn du damit fährst dann wirst du merken, letztlich steckt doch nur ein Trabi unten drunter, von den man mal mehr und mal weniger sieht.

    Und der wichtigste Teil des Betriebssystem ist immer noch der Kernel und spätestens hier hast du eine Henne-Ei-Problem: C++ braucht eine Runtime. Diese Runtime verlangt dem System viel ab und braucht daher viele Systemaufrufe, damit sie funktionieren kann. Dieses Systemaufrufe muss eine Library zu Verfügung stellen, die dafür sehr viele Systemfunktionen vom Kernel braucht. Wie soll man also einen Kernel in C++ schreiben, wenn C++ einen Kernel braucht um überhaupt zu funktionieren und der Kernel aber C++ braucht um diese Funktion anbieten zu können? Das geht nicht. Irgendwer muss diese Funktionen ohne C++ anbieten, damit überhaupt C++ möglich ist.

    C hingegen braucht fast nichts vom System, C ist eigentlich nichts weiter als ein etwas high-leveligeres, CPU-neutrales Assembler. Und wenn ich C sage, dann meine ich nicht C mit einer glibc Library oder einer POSIX Library, nein, ich meine C nach ISO Standard mit nur den im ISO Standard aufgeführten Funktionen. Denn Library Funktionen gibt es im Kernel nicht, da gibt es nur Standard C und das was der Kernel selber anderen Teilen im Kernel zu Verfügung stellt.

    /Mecki

  5. Re: Mit C++ wäre das nicht passiert

    Autor: grorg 05.04.17 - 13:13

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > C++ z.B. hat ja kein anderes Memory Management als C, es hat weder
    > Reference Counting, noch Garbage Collection, noch ist das Memory Management
    > automatisch.

    Was ist mit RAII?

  6. Re: Mit C++ wäre das nicht passiert

    Autor: HansiHinterseher 05.04.17 - 13:25

    /mecki78 schrieb:
    > C++ z.B. hat ja kein anderes Memory Management als C, es hat weder
    > Reference Counting, noch Garbage Collection, noch ist das Memory Management
    > automatisch.

    Naürlich hat C++ Reference Counting seit 2011 im ISO-C++ Standard und wird von jedem ernsthaften Compiler (MS C++, GCC und was es noch so gibt) unterstützt!

    http://en.cppreference.com/w/cpp/memory/shared_ptr

    Und natürlich macht man Speicher-Reservierung schon seit ISO-C++ 1998 nicht mit malloc, realloc u.ä. C-Funktionen, sondern mit Standard-Containern wie std::array und std::vector, die einen Buffer-Overrun und -Underrun verhindern können (Checked Ranges mit Exceptions):

    http://en.cppreference.com/w/cpp/header/array
    http://en.cppreference.com/w/cpp/header/vector

    Es gibt keinen Grund C-Funktionen in seinen eigenen C++ Programmen zu benutzen. Klar, wenn eine fremde API nur C-Funktionen anbietet, muss man diese _benutzen_. Aber selbst diese kann man vorher mit RAII so kapseln, das einem nichts verloren geht.

    Mit war aber schon beim Schreiben meines Beitrags klar, das die Nicht-C++-Kenner mit falschen Informationen meinen Beitrag torpedieren wird. Und man wieder alle Mythen um C++ gerade biegen muss.



    1 mal bearbeitet, zuletzt am 05.04.17 13:29 durch HansiHinterseher.

  7. Re: Mit C++ wäre das nicht passiert

    Autor: MrTridac 05.04.17 - 13:27

    Es ist unsinn auf Konzepten oder alternativen Sprachen herumzureiten, als wenn es eine gäbe welche den Programmierer besser macht.

    Egal wieviel der Compiler oder das Runtime-Env. selbst macht, schlechte Programmierer schreiben schlechte Programme. Punkt!

    Gute Programmierer schreiben auch in BASIC gute Programme.

    A good craftsman doesn't blame the tools!

  8. Re: Mit C++ wäre das nicht passiert

    Autor: /mecki78 05.04.17 - 13:51

    grorg schrieb:
    --------------------------------------------------------------------------------
    > Was ist mit RAII?

    RAII ist eine Notwendigkeit, die sich aus Exceptions ergibt. Es ist unmöglich Exceptions sauber zu implementieren ohne irgend eine Form von automischer Resourcenfreigabe. Und wenn man die dann sowieso schon hat, dann lässt sich diese natürlich auch anderweitig verwenden im Code (also auch dort, wo gar keine Exceptions vorkommen).

    Da C keine Exceptions kennt, auch kein vergleichbares Konstrukt, ergab sich keine Notwendigkeit dafür. In C erschlägst du derartiges in der Regel händisch:

    https://vilimpoc.org/research/raii-in-c/

    Wobei du je nach Compiler und Library auch andere Optionen hast. Nutzt du z.B. den GCC (oder eine kompatiblen Compiler), dann kannst du das Clean Up Attribute nutzen:



    Wenn du das laufen lässt (sehe gerade da fehlt ein "return 0;" am Ende, naja, war nicht mein Code), bekommst du folgende Ausgabe:

    before scope
    variable (42) goes out of scope
    after scope
    http://codepad.org/MVisE0h6

    Oder aber du nutzt alloca(), wenn die C Library dir das bietet. Ist wie malloc(), aber der Speicher wird auf den Stack angelegt und verschwindet damit automatisch, wenn die aktuelle Funktion endet.

    Ja, sowohl alloca() als auch das Attribute sind nicht teil vom ISO-C Standard, aber zeig mir doch mal einen Betriebssystemkern, der mit einem aktuellen ISO-C Standard Compiler baut; ich kenne keinen. Alle benötigen bestimmte Funktionen, die nur bestimmte Compiler bieten.

    /Mecki

  9. Re: Mit C++ wäre das nicht passiert

    Autor: brainslayer 05.04.17 - 13:58

    auch wenn heutige systeme mehr resourcen haben so bleiben c programme gegenüber c++ halt dennoch resourcensparender und performanter. so kann man noch mehr rausholen. natürlich muss man bei c bisschen mehr nachdenken, aber es ist auch einfacher zu lesen und nach zu vollziehen. als linux programmiert wurde gabs c++ schon lange. es wurde sich bewußt dagegen entschieden. in den damaligen zeiten kann ich mich sehr gut erinnern das borland gerne mal fehlerhaften code erzeugt hatte. der programmierer macht alles richtig und die fehler baut der compiler ein. dieses risiko besteht heute immer noch und ist bei klassischem c erheblich geringer. da hat der programmierer noch kontrolle und desswegen werde ich für meinen teil dabei bleiben.

  10. Re: Mit C++ wäre das nicht passiert

    Autor: /mecki78 05.04.17 - 14:18

    HansiHinterseher schrieb:
    --------------------------------------------------------------------------------
    > Naürlich hat C++ Reference Counting seit 2011 im ISO-C++ Standard und wird
    > von jedem ernsthaften Compiler (MS C++, GCC und was es noch so gibt)
    > unterstützt!

    Shared Pointers sind ein explizites Konstrukt, das es genauso für C gibt. Es ist dort zwar nicht Teil des C standards, aber es dürfte an die 100 fertige Libraries geben, die genau das auch in C ermöglichen. Es gibt sogar fertige Libraries für echtes Garbage Collecting in C, nur mal so am Rande.

    Wenn jemand von Reference Counting als Teil der Sprache spricht, dann meint er damit etwas anderes, dann meint automatisches Reference Counting, sprich, eines wovon der Programmierer gar nichts merkt und das fester Teil der Sprache ist und automatisch für alle Resourcen gilt. Beispielt: Perl oder Swift.

    > Und natürlich macht man Speicher-Reservierung schon seit ISO-C++ 1998 nicht
    > mit malloc, realloc u.ä. C-Funktionen,

    Doch, das macht man eben schon. Vielleicht machst du das nicht, aber gerade wenn es um Performance geht (und Überraschung, nirgendwo geht es mehr um Performance als bei einem Betriebssystemcode für mobile Geräte), dann macht man das sogar ganz besonders. Denn wenn während es für eine Anwendung keinen Rolle spielen mag ob etwas 1 ns oder 2 ns dauert, macht das bei einem Betriebssystemkern einen gewaltigen Unterschied für die Gesamtperformance des Systems.

    Und wenn man Speicherzugriffe schützen will, dann geht das auch in C, man muss sich dann halt nur eine entsprechendes Objekt basteln und Zugriffe über entsprechende Funktionen abwickeln, bzw. auch das gibt es schon in 100-facher Ausführyung fix und fertig. Gegen Underflows oder Overflows kann sogar fast jeder C Compiler heute schützen, aber technisch bedingt nicht vor beiden gleichzeitig (und es kostet dich jedes mal 4 KB Speicher pro geschützter Allozierung)

    Du gehst von grundfalschen Voraussetzungen aus. Du glaubst

    1) Nur weil eine Sprache etwas bietet, wird das auch unter Garantie benutzt.

    2) Nur weil eine Sprache etwas nicht von Haus aus bietet, ist das mit dieser Sprache auch gar nicht möglich.

    Dabei gibt es C++ Compiler (bzw. eigentlich sind das ja mehr Translators) die aus C++ normalen C Code machen, der sich dann so mit fast jeden C Compiler normal bauen lässt, funktional aber äquivalent ist. Ergo kannst du fast alles, dass du mit C++ machen kannst auch in C machen. Und wenn die Entwickler das aber in C nicht machen, dann nur deswegen, weil sie das nicht machen wollen und dann ist es völlig illusorisch anzunehmen, sie würden das alles machen, nur weil man sie jetzt dazu nötigt C++ zu nutzen.

    Wenn du z.B. C komplett speichersicher bekommen möchtest und Speicher keine sehr begrenzte Resource ist (also deine App ruhig etwas mehr davon verbrauchen darf), dann fährst du am besten mit C und einer GC Library. Memory Leaks sind damit unmöglich und jede nicht mehr benutzte Resource wird unter Garantie irgendwann mal aufgeräumt. Es kostet auch nicht viel Performance wie man meint, aber technisch bedingt sind diese GCs sehr konservativ, sprich, sie werden nie etwas entfernen, das noch gebraucht wird, aber sie können nie garantieren alles zu entfernen, das nicht mehr gebraucht wird (keine false negatives, aber sehr viele false postives). D.h. Resourcen können viel länger belegt bleiben als nötig und die App wird garantiert zu jederzeit mehr Speicher verbrauchen als ohne GC. Beides ist natürlich für einen Systemkern nicht tragbar.

    /Mecki

  11. Re: Mit C++ wäre das nicht passiert

    Autor: /mecki78 05.04.17 - 14:42

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > so kann man noch mehr rausholen.

    Was gerade bei einem Systemkern nicht ganz unwichtig ist ;-)
    Wenn z.B. ein System in der Lage sein soll einen 1 GBit/s Link auszulasten, dann muss es mindestens alle 12 μS ein Paket auf die Leitung geben. Da macht es dann durchaus einen Unterschied, ob es 10 μS oder 14 μS dauert ein Paket zu verarbeiten, denn im letzten Fall kann der Link nie ausgelastet werden und das wäre die Schuld des Betriebssystems.

    > in den damaligen zeiten kann ich mich sehr gut erinnern das
    > borland gerne mal fehlerhaften code erzeugt hatte.

    Was daran lag, dass der Standard einfach zu komplex war. Alles was die Welt haben wollte waren Objekte, damit man in C so programmieren kann, wie in Java. Aber niemand dürfte es passender formuliert haben als Alan Kay, quasi den Vater der modernen OO Programmierung. Dieser hat mal gesagt, auf C++ angesprochen:

    Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.

    Im Grunde hätte es gereicht C structs eine Vererbung zu geben (wow, damit wäre schon so viel gegangen!), Interfaces zu definieren, die quasi ein C struct erfüllen kann (es muss dann alle die Felder bieten, die das Interface vorschreibt, in der gleichen Reihenfolge), Zugriffsrechte (public, protected, private) und die Möglichkeit mitzubekommen wenn eine Variable den Scope verlässt (was ja die meisten Compiler sogar können und als Erweiterung bieten). Nur mit diesen 4 Dingen wäre schon fast alles weiter umsetzbar gewesen, den Rest hätten dann Libraries von Drittanbieter schaffen können. Weitere Sprachekonstrukte, eine neue Standardlibrary oder eine komplexe, dynamische Runtime, nichts davon hätte es wirklich gebraucht, aber wie gesagt, man wollte es halt gleich allen Recht machen und das geht meistens nie gut.

    Mein Lieblingszitat von Allen Kay ist BTW:
    If you don't fail at least 90 percent of the time, you're not aiming high enough.
    ;-)

    /Mecki

  12. Re: Mit C++ wäre das nicht passiert

    Autor: hroessler 05.04.17 - 15:53

    Achso, mit C++ kann niemand schlechten Code schreiben? Wirklich nicht? Warum implementiert dann die Welt nicht in C++?

    Nicht die Programmiersprache ist das Problem, sondern der, der damit programmiert!

    greetz
    hroessler

  13. Re: Mit C++ wäre das nicht passiert

    Autor: HansiHinterseher 05.04.17 - 16:06

    Ja, natürlich ist auch das Know-How des Programmierers gefragt. ABER, wenn du jemandem ein schlechtes Tool gibst, wird auch ein guter Programmierer damit mehr Fehler machen. Weil der Mensch nicht unfehlbar ist!

    Aber du kannst einem guten Programmierer trotzdem mit besseren Tools besser arbeiten lassen. Das eine schließt das andere nicht aus.

    Weil sonst frage ich mich: warum machen die guten Programmierer nicht einfach Assembler? Warum überhaupt das bessere Tool C (verglichen mit ASM)? Eben, weil sie dann noch weniger Fehler machen können.

    Denn am Ende hängt JEDEM kommerziellen Programmierer die Zeit und Kosten im Nacken. Nur ein Hobby-Programmierer kann sich den Spaß erlauben ewig Code zu kontrollieren, anstatt ein besseres Tool zu benutzuen.

    Und C++ bietet nunmal mehr Unterstützung als C, und C mehr als ASM, und ASM mehr als Maschinencode, und Maschinencode mehr als Lochkarten...

    Nach deinem Argument müssten alle guten Programmierer noch Lochkarten stanzen. Die brauchen keine besseren Tools um fehlerfrei zu programmieren.



    1 mal bearbeitet, zuletzt am 05.04.17 16:08 durch HansiHinterseher.

  14. Re: Mit C++ wäre das nicht passiert

    Autor: altneu 05.04.17 - 19:34

    /mecki78 schrieb:

    > Wenn du z.B. C komplett speichersicher bekommen möchtest und Speicher keine
    > sehr begrenzte Resource ist (also deine App ruhig etwas mehr davon
    > verbrauchen darf), dann fährst du am besten mit C und einer GC Library.

    Ich hab da keine Ahnung, hätte aber gerne welche. Was wäre da als Library die erste Wahl? Ich hab gerade mal https://www.hboehm.info/gc/ ergooglet und auf StackOverflow "not thread safe" gelesen. Scheitern relativ unbekannten Lösungen nicht meistens totzdem irgendwie? Das, an dem ich so experimentiere, braucht nie viel Speicher. Kommt man damit eventuell troztdem oder vermehrt mit "undefined behaviour" in Kontakt? Ich meine, ich hab neulich wieder mit erase() unwissend eine ganze STL deque zerstört... Wenn man immer alles richtig macht, geht [beliebige Sprache] immer...

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Dataport, verschiedene Standorte
  2. über Kienbaum Consultants International GmbH, Stuttgart
  3. LOTTO Hessen GmbH, Wiesbaden
  4. MACH AG, Berlin, Lübeck

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. mit Gutschein: NBBX570
  3. 99,00€
  4. 279,90€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Change-Management: Die Zeiten, sie, äh, ändern sich
Change-Management
Die Zeiten, sie, äh, ändern sich

Einen Change zu wollen, gehört heute zum guten Ton in der Unternehmensführung. Doch ein erzwungener Wandel in der Firmenkultur löst oft keine Probleme und schafft sogar neue.
Ein Erfahrungsbericht von Marvin Engel

  1. IT-Jobs Der Amtsschimmel wiehert jetzt agil
  2. MINT Werden Frauen überfördert?
  3. Recruiting Wenn das eigene Wachstum zur Herausforderung wird

Gemini Man: Überflüssiges Klonexperiment
Gemini Man
Überflüssiges Klonexperiment

Am 3. Oktober kommt mit Gemini Man ein ambitioniertes Projekt in die deutschen Kinos: Mit HFR-Projektion in 60 Bildern pro Sekunde und Will Smith, der gegen sein digital verjüngtes Ebenbild kämpft, betreibt der Actionfilm technisch viel Aufwand. Das Seherlebnis ist jedoch bestenfalls komisch.
Von Daniel Pook

  1. Filmkritik Apollo 11 Echte Mondlandung als packende Kinozeitreise

SSD-Kompendium: AHCI, M.2, NVMe, PCIe, Sata, U.2 - ein Überblick
SSD-Kompendium
AHCI, M.2, NVMe, PCIe, Sata, U.2 - ein Überblick

Heutige SSDs gibt es in allerhand Formfaktoren mit diversen Anbindungen und Protokollen, selbst der verwendete Speicher ist längst nicht mehr zwingend NAND-Flash. Wir erläutern die Unterschiede und Gemeinsamkeiten der Solid State Drives.
Von Marc Sauter

  1. PM1733 Samsungs PCIe-Gen4-SSD macht die 8 GByte/s voll
  2. PS5018-E18 Phisons PCIe-Gen4-SSD-Controller liefert 7 GByte/s
  3. Ultrastar SN640 Western Digital bringt SSD mit 31 TByte im E1.L-Ruler-Format

  1. H2.City Gold: Caetanobus stellt Brennstoffzellenbus mit Toyota-Technik vor
    H2.City Gold
    Caetanobus stellt Brennstoffzellenbus mit Toyota-Technik vor

    Damit die Luft in Städten besser wird, sollen Busse sauberer werden. Ein neuer Bus aus Portugal mit Brennstoffzellenantrieb emititiert als Abgas nur Wasserdampf.

  2. Ceconomy: Offene Führungskrise bei Media Markt und Saturn
    Ceconomy
    Offene Führungskrise bei Media Markt und Saturn

    Die Diskussion um die mögliche Absetzung von Ceconomy-Chef Jörn Werner sollte eigentlich noch nicht öffentlich werden. Jetzt wissen es alle, und es gibt keinen Nachfolger.

  3. Polizei: Hunde, die nach Datenspeichern schnüffeln
    Polizei
    Hunde, die nach Datenspeichern schnüffeln

    Spürhunde können neben Sprengstoff und Drogen auch Datenspeicher oder Smartphones erschnüffeln. Die Polizei in Nordrhein-Westfalen hat kürzlich ihre frisch ausgebildeten Speicherschnüffler vorgestellt.


  1. 18:18

  2. 18:00

  3. 17:26

  4. 17:07

  5. 16:42

  6. 16:17

  7. 15:56

  8. 15:29