C ist feindselig

  • Hallo,

    er hat ja grundsätzlich recht - nur ist das ja nix neues.

    Rust wird bei Mozilla ja genau dafür entwickelt worden. AFAIK ist der MP4 Headerparser im Firefox schon in Rust umgesetzt und der CSS-Parser folgt bald. Rust ist so was wie "C in modern". Hat man dann inzwischen wohl auch beim GNOME-Projekt erkannt ;)

    Gruß, noisefloor

  • Ach was!
    C/C++ ist halt nix für Weicheier und Warmduscher :lol: :lol:

    Ich bin sogar der Meinung, dass C/C++ das Verständnis für's Programmieren fördert: Man muss verstehen, was man tut!

    Aber damit bin ich vermutlich recht allein, alle wollen nur ein "Schnell" - "Klick" - "Boom" - FERTICH !! :wallbash:

    Performance ? (egal)
    Rescourenverbrauch ? (egal)
    Wartbarkeit? (egal)

    WFM!! ("Works for me").

    :auslachen: So, und nun werft Steine ! :lol:

  • Halllo,

    Zitat

    Ich bin sogar der Meinung, dass C/C++ das Verständnis für's Programmieren fördert: Man muss verstehen, was man tut!


    Das ist ja der Punkt: Obwohl es C/C++ seit Jahrzehnten gibt, gibt es immer noch und wieder kritischen Sicherheitslücken aufgrund von Buffer Overflows und ähnlichen. Was ja dann im Umkehrschluss so viel heißt wie, dass die Anzahl der Leute, die verstehen, was sie tun, eher gering ist *SCNR*

    [quote]Aber damit bin ich vermutlich recht allein, alle wollen nur ein "Schnell" - "Klick" - "Boom" - FERTICH !!
    Dann ist Rust aber definitiv auch die falsch Sprache. Viel Erreichen mit wenig Code ist doch.... ICON! *duckundweg*

    Gruß, noisefloor

  • Zitat von "Zentris" pid='293424' dateline='1501491886'

    Ich bin sogar der Meinung, dass C/C++ das Verständnis für's Programmieren fördert: Man muss verstehen, was man tut!

    Nein, bei Pascal muss man verstehen, was man tut. Bei C muss man verstehen, was der Compiler tut. Und der tut manchmal komische Sachen. Zum Beispiel Variablen anscheinend grundlos in andere Typen wandlen. Weshalb man dann wieder rumcasten muss.

    Code
    char c1;
        c1 = ~0x80;
        if (c1 == ~0x80) {
            printf("true");
        } else {
           printf("false");
        }

    True oder false?

  • Zitat von "noisefloor" pid='293437' dateline='1501497306'


    Was ja dann im Umkehrschluss so viel heißt wie, dass die Anzahl der Leute, die verstehen, was sie tun, eher gering ist *SCNR*

    Ähm.... wo bitte kann ich das unterschreiben????

    Ich habe ja derzeit berufsbedingt viel mit "altem" Code zu tun (10-15 Jahre, C++ und Perl)... naja, was soll ich sagen...

    Da sind Fehler drin, die seit Jahren nicht gefunden werden... (Ich soll die jetzt finden - *lach*)...
    Und somit muss ich mich in den Code reinknien... was ich da so sehe... nun ja...

    Ich bin ja eher der Typ, der "tricky code" vermeidet und ggf. 3 Codezeilen mehr in Kauf nimmt, nur um den Code wartbar und erklärender zu halten...
    Aber bei manchen Codestellen hab ich den Eindruck, dass der Urheber froh war, das das "Zeug" lief... ("fass das bloß nicht mehr an, geht jetzt!!!!")
    Von solchen "Leichen" wie fehlerhafte Beschaffung/Freigabe von Memory und nicht abgeräumte Pointer abgesehen...

    Nun, Rust muss beweisen, dass es das bessere C++ ist.
    Im Prinzip hab ich da kein Problem mit...

    Hab mich gestern mal hingesetzt und mein erstes "Hallo Welt" in Rust getestet.
    Was mir auffiel: Das Binary ist ca. 3 (!!!!!) MB groß .... für ein "Hallo Welt"... :wallbash:

    Ähm... nun ja, aber das schrieb ich ja schon in meinem 1. Post... :angel:

  • Hallo,

    Zitat

    Nun, Rust muss beweisen, dass es das bessere C++ ist.

    .
    Genau. _Persönlich_ sehe ich das aber auf absehbare Zeit nicht. Um Rust wurde ja ein ähnlicher Hype gemacht wie um Go (beide sind war fast zur gleichen Zeit entstanden), nur hat Go schon die "kritische" Masse erreicht und ist im Mainstream angekommen, während Rust noch auf dem Weg ist. Wenn es je im Mainstream ankommt. Aktuell sieht es IMHO mehr danach aus, dass Rust eher für Sachen wie Parser o.ä. genutzt wird wird, aber nicht für "allgemeine Programmierung (wie C/C++, Python, Go, ...) sondern eher als "extension language" für bestimmte Fälle, wie auch z.B. auch Lua.

    Time will tell :)

    Gruß, noisefloor

  • Zitat von "Timm Thaler" pid='293439' dateline='1501498812'

    Nein, bei Pascal muss man verstehen, was man tut. Bei C muss man verstehen, was der Compiler tut. Und der tut manchmal komische Sachen. Zum Beispiel Variablen anscheinend grundlos in andere Typen wandlen. Weshalb man dann wieder rumcasten muss.

    Code
    char c1;
        c1 = ~0x80;
        if (c1 == ~0x80) {
            printf("true");
        } else {
           printf("false");
        }

    True oder false?

    Nun ja, mal etwas aufgepeppt:

    Ergebnis:

    Code
    c1 nach def: 7f
    0x80  32Bit: ffffff7f
    false

    Warum?
    c1 ist ein char (8bit)
    0x80 ist ein Hexwert mit 32bit (auch wenn es den Anschein hat, dass es nur 8bit sind).

    Die Zuweisung des 32Bit-Wertes 0x80 zu einem Char (der nur 8 Bit speichern kann) ruft ein implizites Cast auf.

    Beim Vergleich wird allerdings kein impliziter Cast aufgerufen und damit wird ein 8Bit-Wert mit einem 32Bit-Wert verglichen...
    Sinnigerweise sollte das zumindest eine Warnung wert sein...

  • Zitat von "Zentris" pid='293480' dateline='1501522033'

    Beim Vergleich wird allerdings kein impliziter Cast aufgerufen und damit wird ein 8Bit-Wert mit einem 32Bit-Wert verglichen...

    Och menno! Musstest Du das so schnell verraten. Üblicherweise kommt nämlich erstmal die falsche Erklärung, dass char ein signed ist, welches mit einem unsigned verglichen wird. Was aber hier Rille ist, weil ~ eine Bitoperation ist. Und nur beweist, dass die Leute eben nicht verstehen, was der Compiler macht.

    Witzigerweise funktioniert das auch auf dem Arduino. Völlig logisch, dass man auf einem 8-Bitter erstmal alles in 16 Bit castet, was nicht bei Drei auf den Bäumen ist.

  • Dann ist es wohl nicht mehr weit bis es heisst

    Zitat von "Dijkstra"

    C/C++ is considered harmful

    :lol:

    C/C++ ist mittlerweile betagt und es ist kein Wunder dass man die Unzulänglichkeiten mit neuen Sprachen beheben will. Auch bei Java wird mit Kotlin derselbe weg versucht. groovy war auch schon ein Versuch.

    Primaere Schwaechen von C/C++ sind dass es keinen eigenstaenigen String Typ gibt, ein Garbagecollector fehlt und irrwitzige Pointerarithmetik moeglich ist. In die Luecke stoesst Rust wie auch golang berechtigt.

    Zitat von "Zentris"

    C/C++ ist halt nix für Weicheier und Warmduscher

    Das erinnert mich an einen Werbespruch: Sind sie zu stark - bist Du zu schwach :D

  • Hallo Zentris & Dreamshader,

    Zitat von "dreamshader" pid='293429' dateline='1501494995'


    Servus Zen,

    wie sagt man so schön? "Nein, Du bist nicht allein ..." ;)


    Ihr seid beide nicht allein - ich bin mit Euch!

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Zitat von "noisefloor" pid='293453' dateline='1501502715'


    Hallo,

    .
    Genau. _Persönlich_ sehe ich das aber auf absehbare Zeit nicht. Um Rust wurde ja ein ähnlicher Hype gemacht wie um Go (beide sind war fast zur gleichen Zeit entstanden), nur hat Go schon die "kritische" Masse erreicht und ist im Mainstream angekommen, während Rust noch auf dem Weg ist. Wenn es je im Mainstream ankommt. Aktuell sieht es IMHO mehr danach aus, dass Rust eher für Sachen wie Parser o.ä. genutzt wird wird, aber nicht für "allgemeine Programmierung (wie C/C++, Python, Go, ...) sondern eher als "extension language" für bestimmte Fälle, wie auch z.B. auch Lua.

    Time will tell :)

    Gruß, noisefloor

    Rust stopft halt (ähnlich wie Go) eine bestimmte Lücke, die beim hardwarenahen Programmieren auftritt und von Sprachen wie C nicht gefüllt werden können. Stichwort: Sicheres "Nebenläufiges Programmieren". Scheinbar (Quelle: Hörensagen) legt Rust auch einen Fokus darauf, typische Fehlerchen von C-Programmen gar nicht erst entstehen zu lassen. Und es stimmt ja auch: C-Compiler können Dinge tun, die selbst Fortgeschrittene auf ihren Gebieten nicht bedacht haben^^.

    Das im Golem-Artikel erwähnte "Ownership"-Prinzip finde ich da sehr interessant. Es ist erstmal ungewohnt, aber unglaublich speichereffizient und zwingt den Programmierer, sich weitere Gedanken beim Programmieren zu machen. Ich kann mir kaum vorstellen dass das Prinzip neu ist... Aber warum höre ich von der Methode das erste Mal in Rust, über 40 Jahre nachdem C entwickelt wurde?^^

  • Servus,

    Zitat von "framp" pid='293483' dateline='1501525280'


    ... irrwitzige Pointerarithmetik moeglich ist. ...


    das, finde ich, ist überhaupt das genialste schlechthin ;)

    Zitat von "Astorek86" pid='293485' dateline='1501525929'


    ... aber unglaublich speichereffizient ...

    Ach? Sag' bloss ... ;)

    Zitat von "Zentris" pid='293442' dateline='1501499140'


    ...
    Hab mich gestern mal hingesetzt und mein erstes "Hallo Welt" in Rust getestet.
    Was mir auffiel: Das Binary ist ca. 3 (!!!!!) MB groß .... für ein "Hallo Welt"... :wallbash:
    ...

    cheers,
    -ds-

  • Hallo noisefloor,

    Zitat von "noisefloor" pid='293437' dateline='1501497306'


    Viel Erreichen mit wenig Code ist doch.... ICON! *duckundweg*


    In dem Buch steht sinngemäß, dass man in Icon rund 1/3 weniger Code gegenüber C/C++ benötigt, um eine Aufgabenstellung gleichwertig zu lösen.

    Ich setze da noch einen drauf: Wenn man konsequent Icon-style programmiert, dann erreicht man dies durch 25 bis 33% des C/C++ Codeumfangs.

    Allerdings ist der Icon-Code dann für Außenstehende nicht sonderlich verständlich.

    Außerdem - und darin sehe ich eine besondere Stärke dieser Programmiersprache - gibt es keine Elemente wie Zeiger (auf nil), das implizite Memory-Management verhindert Speicherlecks. Selbst heftige Laufzeitfehler kann man abfangen und z.B. Divisionen durch 0 zum Scheitern der Division mindern (ohne auf den Divisor 0 prüfen zu müssen).


    Die Schwächen von C sind ja hinlänglich bekannt. Experten können wundersame Betriebssysteme entwickeln - aber Normalprogrammierer müssen unverhältnismäßig viel Erfahrungen sammeln, bevor ein selbstgeschriebener Langläufer kein Speicherleck aufweist.

    Bei einigen anderen Programmiersprachen ist der Spagat nicht so groß.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (4. August 2017 um 21:21)

  • Zitat von "Zentris" pid='293442' dateline='1501499140'

    ...Was mir auffiel: Das Binary ist ca. 3 (!!!!!) MB groß .... für ein "Hallo Welt"... :wallbash: ...


    Das Image ist 1.5M gross bei go. Habe es eben mal geprüft. Aber bei heutigen Plattengroessen ist das kein Qualitaetskriterium mehr. Fehlerrobustheit & Wartungsfaehigkeit sind welche.

  • Zitat von "dreamshader" pid='293486' dateline='1501526273'

    das [irrwitzige Pointerarithmetik], finde ich, ist überhaupt das genialste schlechthin ;)

    Den folgenden Mitgliedern gefällt Zentris's dreamshaders Beitrag:

    NSA, CIA, BND, GCHQ, FSB, und 59 weiteren Viren-, Trojaner- und Backdoorprogrammierern

    Einmal editiert, zuletzt von Timm Thaler (1. August 2017 um 00:32)

  • Ähm ... der war von mir, nicht von Zen ;)
    Trotzdem liebe ich pointer-Operationen :thumbs1:

    //EDIT:

    Zitat von "framp" pid='293488' dateline='1501527308'


    ... ist das kein Qualitaetskriterium mehr. Fehlerrobustheit & Wartungsfaehigkeit sind welche.


    Nur dass der eine Code schon fünfmal gelaufen ist, während der andere noch lädt ;)
    Ausserdem war ja die Rede von Effizienz ...

    cu,
    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!