1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Verschlüsselung: GPG muss endlich weg

Nachteil von C/C++

Über PC-Games lässt sich am besten ohne nerviges Gedöns oder Flamewar labern! Dafür gibt's den Freiraum!
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Nachteil von C/C++

    Autor: BLi8819 01.02.21 - 18:34

    Es gibt viele bekannte Fehler, die man immer wieder in C/C++ Software findet. Sofern man da keine Software einsetzt, die diese Fehler direkt nach dem Commit prüft und entdeckt, werden Entwickler diese Fehler immer wieder machen.

    Alternativ könnte man auch Sprachen verwenden, die nicht so Fehleranfällig sind. Das würde für viele aber bedeuten neue Paradigmen und Prinzipien zu erlernen.

  2. Re: Nachteil von C/C++

    Autor: bionade24 01.02.21 - 22:14

    BLi8819 schrieb:
    --------------------------------------------------------------------------------
    > Es gibt viele bekannte Fehler, die man immer wieder in C/C++ Software
    > findet. Sofern man da keine Software einsetzt, die diese Fehler direkt nach
    > dem Commit prüft und entdeckt, werden Entwickler diese Fehler immer wieder
    > machen.
    >
    > Alternativ könnte man auch Sprachen verwenden, die nicht so Fehleranfällig
    > sind. Das würde für viele aber bedeuten neue Paradigmen und Prinzipien zu
    > erlernen.

    Ähm... du weißt schon dass es Modern C++ gibt und man nicht immer gleich RiR machen muss?

  3. Re: Nachteil von C/C++

    Autor: OMGle 01.02.21 - 23:05

    Rust

  4. Re: Nachteil von C/C++

    Autor: BLi8819 01.02.21 - 23:40

    Ja, weiß ich. Du brauchst halt auch Entwickler, die modernes C++ implementieren.

  5. Re: Nachteil von C/C++

    Autor: BLi8819 01.02.21 - 23:40

    Wäre eine gute Wahl.

  6. Re: Nachteil von C/C++

    Autor: LoopBack 01.02.21 - 23:57

    libgcrypt unterstützt eine ganze Menge Architekturen und Betriebssysteme, Rust unterstützt nur einen Bruchteil davon. Es braucht solche Basis-Bibliotheken die überall verfügbar ist, für einige Nutzer wäre aber natürlich eine zusätzliche Implementierung in Rust auch keine schlechte Sache.

  7. Re: Nachteil von C/C++

    Autor: Wuestenschiff 02.02.21 - 00:18

    Das ist doch gar zu generell. Natürlich gibt es heute bessere Sprachen als C. Aber wie andere schon gesagt haben ist nichts so portabel wie c.

    In diesemfall ging es aber um Assembler Optinierungen und Sidechannel Security (Datenunabhängige Laufzeiten). Das bieten höher abstrahierte Sprachen nicht an, oder verlieren dann auch viele ihrer garantien. Einfach bei jedem C Artikel dieselben allgemeinplaetze hinschreiben bringt uns nicht weier.

    Und c und c++ sind komplett eigene Sprachen. C++ lässt sich absolut Memory Safe schreiben. Wenn man den will und kann. (Ja bei Rust gibts noch mehr garatien I know)

  8. Re: Nachteil von C/C++

    Autor: Keep The Focus 02.02.21 - 02:59

    was unterstützt Rust denn nicht?

    Rust ist plattformunabhängig - das Konzept "Basisbibliothek" nicht verfügbar gibt es gar nicht

  9. Re: Nachteil von C/C++

    Autor: BeachPrince 02.02.21 - 03:45

    Keep The Focus schrieb:
    --------------------------------------------------------------------------------
    > was unterstützt Rust denn nicht?
    >
    > Rust ist plattformunabhängig - das Konzept "Basisbibliothek" nicht
    > verfügbar gibt es gar nicht

    Wenn man mit den Vertretern von Programmiersprachen redet, verschwinden fast alle vermeintlichen Schwierigkeiten damit schlagartig, zum Beispiel durch schnelles Wegdefinieren.

    Wenn du dich auf Libs in anderen Programmiersprachen verlässt, weil es sie in deiner LIeblingsprogrammiersprache nicht gibt, dann schleppst du dir damit natürlich die Probleme jener Programmiersprachen mit hinein. Tolle geschwätzige Interfaces zu definieren löst ja das Problem nicht.

    Aber ich will dir Rust nicht ausreden: Lass' dich um Gottes Willen nicht abhalten, ein Projekt deiner Wahl in Rust neu zu implementieren. Es muss wahnsinnig einfach sein, also tu es doch.

  10. Re: Nachteil von C/C++

    Autor: amagol 02.02.21 - 06:21

    BeachPrince schrieb:
    --------------------------------------------------------------------------------
    > Wenn du dich auf Libs in anderen Programmiersprachen verlässt, weil es sie
    > in deiner LIeblingsprogrammiersprache nicht gibt, dann schleppst du dir
    > damit natürlich die Probleme jener Programmiersprachen mit hinein. Tolle
    > geschwätzige Interfaces zu definieren löst ja das Problem nicht.

    Naja, es loest das Problem nicht grundsaetzlich, aber das nimmt man halt in Kauf um z.B. eine 3P-Lib zu verwenden. Immerhin kann man im eigenen Code die Features von LIeblingsprogrammiersprache verwenden, und ich bezweifle jetzt mal dass ein relevanter Anteil an Programmierern wirklich Fehler in 3P libraries debuggt und fixt.
    Wenn die Codequalitaet der Library so schlecht ist (oder es sich um eigenen Code handelt) wird sie mit hoher Wahrscheinlichkeit ersetzt oder neu implementiert.

  11. Re: Nachteil von C/C++

    Autor: brainslayer 02.02.21 - 06:27

    BLi8819 schrieb:
    --------------------------------------------------------------------------------
    > Ja, weiß ich. Du brauchst halt auch Entwickler, die modernes C++
    > implementieren.
    gibt viele dinge für die c++ ziemlich ungeeignet ist, weil es den code völlig aufbläht. c++ ist für einen effektiven programmierer platzverschwendung und über alle maßen kompliziert weil es wie gnupgp zuviel funktionalität hat

  12. Re: Nachteil von C/C++

    Autor: BeachPrince 02.02.21 - 06:42

    amagol schrieb:
    --------------------------------------------------------------------------------
    > Wenn die Codequalitaet der Library so schlecht ist (oder es sich um eigenen
    > Code handelt) wird sie mit hoher Wahrscheinlichkeit ersetzt oder neu
    > implementiert.

    Tja, was mir zu dem Thema immer einfällt ist das GStreamer-Framework. Viele Programme wollen gerne Streamen können, haben aber keine Lust, deswegen einen M4V-Decoder zu programmieren. Aber viele Programme ahnen nicht mal, dass sie das GStreamer-Framework einbinden, weil sie bloß eine Funktion irgendeiner Lib verwenden und das damit mit reinziehen.

    Da gibt's verschiedene Kollektionen von GStreamer-Treibern, markanterweise kategorisiert unter "good" (44 Treiber), "bad" (66 Treiber) und "ugly" (6 Treiber).

    Diese Treiber funktionieren alle, sind aber zum Teil so grässlich, dass sie niemand anfassen will. Da zudem niemand die Dateiformate versteht, bleiben sie eben liegen.

    Dass das brandgefährlich sein könnte, weil Pufferunter- oder überlauf, Off-By-1 usw., naja, das nimmt man eben in Kauf.

    [typos]



    1 mal bearbeitet, zuletzt am 02.02.21 06:47 durch BeachPrince.

  13. Re: Nachteil von C/C++

    Autor: Max Level 02.02.21 - 07:20

    > Das ist doch gar zu generell. Natürlich gibt es heute bessere Sprachen als
    > C. Aber wie andere schon gesagt haben ist nichts so portabel wie c.

    Die Frage ist ja immer: Besser in Bezug auf was genau? Ich würde auch immer lieber C# als C benutzen, wenn das irgendwie geht. Aber die Zugriffe auf C-Arrays sind halt (wenn sich das nicht grundlegend geändert hat) aus diversen Gründen sehr viel effizienter als solche auf Managed-Arrays. Das ist bei Standardanwendungen egal, weil jenen, wo man diese Operationen sehr sehr oft durchführt, ergibt das signifikante Laufzeitunterschiede. Man muss halt schauen, was man braucht.

  14. Re: Nachteil von C/C++

    Autor: Steffo 02.02.21 - 08:13

    Wuestenschiff schrieb:
    --------------------------------------------------------------------------------
    > C++ lässt sich absolut Memory
    > Safe schreiben. Wenn man den will und kann. (Ja bei Rust gibts noch mehr
    > garatien I know)

    Du kriegst keine Garantien zur Compilezeit.
    Man kann immer noch auf Referenzen zugreifen, die out of scope gegangen sind. Oder auf gemovte Objekte, die nicht mehr gültig sind.



    1 mal bearbeitet, zuletzt am 02.02.21 08:13 durch Steffo.

  15. Re: Nachteil von C/C++

    Autor: _4ubi_ 02.02.21 - 08:19

    Stimmt zwar. Nutzt man bei C++ aber eine statische Codeanalyse (z.B. clang-analyzer), bekommst all diese Fehler, und viele andere, aufgetischt.

  16. Re: Nachteil von C/C++

    Autor: Wuestenschiff 02.02.21 - 08:29

    Std::Vector ist unwesentlich langsamer als ein array. Wenn dies der Grund ist um C zu verwenden, Nimm C++ oder rust

  17. Re: Nachteil von C/C++

    Autor: _4ubi_ 02.02.21 - 08:50

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > BLi8819 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ja, weiß ich. Du brauchst halt auch Entwickler, die modernes C++
    > > implementieren.
    > gibt viele dinge für die c++ ziemlich ungeeignet ist, weil es den code
    > völlig aufbläht. c++ ist für einen effektiven programmierer
    > platzverschwendung und über alle maßen kompliziert weil es wie gnupgp
    > zuviel funktionalität hat

    Es gibt ziemlich viele Dinge für C++ ideal ist, weil, wenn man es beherrscht, der Code unglaublich effizient ist. C++ ist für einen Programmierer der es beherrscht ein wunderbares Tool mit idealer Funtionalitäten um performante und effiziente Programme zu schreiben. Man kann sogar Programme ohne Nutzung der Shift-Taste schreiben, also ideal für dich.

    SCNR aber deine Aussagen sind einfach leere und dämliche Phrasen.

  18. rPGP / sequoia

    Autor: oleid 02.02.21 - 09:44

    BeachPrince schrieb:
    > Aber ich will dir Rust nicht ausreden: Lass' dich um Gottes Willen nicht
    > abhalten, ein Projekt deiner Wahl in Rust neu zu implementieren. Es muss
    > wahnsinnig einfach sein, also tu es doch.


    Du meinst wie das hier?

    https://crates.io/crates/pgp

    Oder diese Neuimplementierung?

    https://gitlab.com/sequoia-pgp/sequoia



    2 mal bearbeitet, zuletzt am 02.02.21 09:46 durch oleid.

  19. Re: Nachteil von C/C++

    Autor: Steffo 02.02.21 - 11:44

    _4ubi_ schrieb:
    --------------------------------------------------------------------------------
    > Nutzt man bei C++ aber eine statische Codeanalyse (z.B.
    > clang-analyzer), bekommst all diese Fehler, und viele andere, aufgetischt.

    Ich kann dir aus Erfahrung sagen, dass sie viele False-Positives liefern und einige Richtig-Positive hingegen nicht erkennen. Das Projekt hat dann so viele Warnungen (gerade Legacy-Code), sodass du Richtig-Positive-Warnungen schnell übersiehst.

  20. Blah

    Autor: nohoschi 02.02.21 - 13:34

    Das ist eine nichtssagende Generalisierung. Alle Programmiersprachen haben ihre Vorteile und Nachteile und das schließt insbesondere die alten Bytecodesprachen ein. Zweitens entwickeln sich Sprachen und Werkzeuge beständig weiter, insbesondere die Sanitizer bei C und C++. Modernes C++ hat mit Smartpointer, RIAA und Templates effiziente und sichere Features zur High-Level Programmierung.

    Sicherheitsprobleme mit Java und Konsorten gibt es genügend. Wie kommt man darauf, dass es die nicht gibt? Ich wünsche niemand Speicherprobleme mit Java. Wenn das erstmal anfängt ist es die Hölle. Apple hatte gute Gründe stattdessen der Referenzzählung den Vorzug zu gegeben. C# sollte dann der große Wurf von Microsoft werden, dann haben sie uns 2010 nochmal JavaScript verkaufen wollen. Bevor Google mit Go die Ahead-of-Time-Compiler mit Maschinencode wieder gebracht hat. Inzwischen hört man von Go weniger, dafür finde ich Rust interessanter. Währenddessen sind moderne Sanitizer für C/C++ erschienen.

    Es geht nicht darum jedem Hype zu folgen, sondern beständige Werkzeuge zu erkennen und wirklich zu erlernen. Wenn ich daran denke wie lang der XML-Hypetrain war, zum Glück hat uns JSON davon erlöst.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. DMK E-BUSINESS GmbH, Berlin-Potsdam
  2. Dürr AG, Bietigheim-Bissingen
  3. via 3C - Career Consulting Company GmbH, München, Stuttgart, Berlin, Hamburg, Köln (Home-Office)
  4. Allianz Global Benefits GmbH, München, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 47,99€
  2. 1,80€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme