1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Linux: Vom einfachen…
  6. T…

Lösung: ...

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


  1. Re: Lösung: ...

    Autor: sebi2k1 21.10.21 - 09:39

    BangerzZ schrieb:
    --------------------------------------------------------------------------------
    > sebi2k1 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Es gibt sehr gute Gründe warum die erfolgreichsten System (Windows,
    > Linux,
    > > QNX und sogar FreeRTOS) allesamt in C geschrieben sind.
    >
    > Sind halt alle stein alt. Und C hat sich nun mal in diesem Sektor
    > festgesetzt.
    Und warum hat es sich festgesetzt? Schonmal auf ner Embedded Kiste mit 128kb RAM FreeRTOS portiert? Oder auf einen 80MHz Prozessor ein Linux in 2MB Flash? Ich schon, und da muss du erstmal eine Alternative finden. Allein die STL sprengt schon den Flash-Bedarf.

    > Klassisches: "Das haben wir schon immer so gemacht."
    Das hat damit nichts zu tun. Dir fehlt nur Problembewusstsein und entsprechende Alternativen. Es gibt sehr interessante Ansätze mit Fuchsia und auch Rust. Die müssen sich aber beweisen und die werden sehr wohl ernsthaft verfolgt. Ob es Alternativen zu Linux & Co werden entscheidest nicht du sondern ökonomische oder technische Zwänge.

  2. Re: Lösung: ...

    Autor: sebi2k1 21.10.21 - 09:43

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > > Klassisches: "Das haben wir schon immer so gemacht."
    >
    > Nicht unbedingt deswegen, sondern weil solche Lowlevel-Frickler halt ein
    > Lowlevel-Mindset haben. Und dazu passt C++ eben nicht. Würden die auf der
    > Lowlevel- und Highlevel-Ebene denken können, dann kämen denen vielleicht
    > auch C++ in den Sinn.
    Sehr engstirnige Betrachtung. Das die LowLevel Frickler sehr gute Gründe haben für diese Entscheidungen kommt dir nicht in Sinn.

    Deine High-Level denke stößt dann an seine Grenze wenn die Umgebung keine GB-weise RAM hat.

  3. Re: Lösung: ...

    Autor: sebi2k1 21.10.21 - 09:51

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > > Ist ja schön wenn du in Thread A den shared_ptr löscht aber
    > > wenn es in Thread B nicht geschützt wurde bringt es nichts.
    >
    > Das passiert eben nicht weil shared_ptr<> einen Referenzzähler auf dem Heap
    > hat.
    Na wenn er den auf dem Heap hat. Und den Zugriff darauf schütze ich wie?

    > > Es gibt sehr gute Gründe warum die erfolgreichsten System (Windows,
    > > Linux, QNX und sogar FreeRTOS) allesamt in C geschrieben sind.
    >
    > Ja, ein idiotisches Mindset. C++ wäre an der Stelle eine meilenweit
    > überlegene Sprache.
    Du hast ein sehr naives Mindsets, vielleicht arbeitest du mal in dieser Domain, mal schauen ob C++ dann immer noch dein Favorite ist. Aber nicht vergessen, im Kernel-Space darfst dir erstmal selber eine eigene STL schreiben, und dein iostream für Ausgaben auch. Ach und Speicher allozieren darfst dann auch eigene Allokatoren schreiben, aber nicht vergessen den richtigen zu wählen wenn du gerade Speicher brauchst während du nen Spinlock hältst.

    Ich hab schon Device-Driver unter Windows mit einem C++ Wrapper geschrieben, das war ein riesen Katastrophe weil C++ im UserSpace überhaupt nichts mit C++ im Kernel-Space zu tun hat.

  4. Re: Lösung: ...

    Autor: ultim 21.10.21 - 10:28

    > Es gibt sehr gute Gründe warum die erfolgreichsten System (Windows, Linux, QNX und sogar FreeRTOS) allesamt in C geschrieben sind.

    Manche Gründe sind gut, haben aber sicher nichts mit Thread Safety zu tun. Die Gründe unterscheiden sich je nach Projekt, fallen aber in eine oder mehrere von diesen Kategorien:
    - Manchmal einfach mal historisch aber sonst keinen guten Grund
    - Manchmal ist der Aufwand zu hoch verglichen mit dem Projekt, weil man eben grosse Teile vom STL nachprogrammieren müsste
    - Manchmal darf man überhaupt nicht Speicher dynamisch allozieren. Dann ist oft die Verwendung vom STL oft hin auch wenn man sie im Kernelspace nachprogrammieren würde
    - Manchmal glauben Leute falsch dass C++ einen höheren CPU/Speicheraufwand haben würde. Das stimmt aber nicht solang man virtuelle Methoden und Exceptions vermeidet. und Templates nur vorsichtig einsetzt.
    - Manchmal gibt es kein C++ Compiler für das Target
    - Manchmal gibt es schon ein C++ Compiler, ist aber nicht geprüft/auditiert/zugelassen für wegen dem wesentlich komplexeren Compilerlogik. Bei Autos, Flugzeugen, und anderen sicherheitskritischen Systemen.

    Manche von diesen Problemen gibt es allerdings für Rust auch und am Ende bleibt (leider) nur C für viele eingebettete Projekte.

  5. Re: Lösung: ...

    Autor: Wuestenschiff 21.10.21 - 10:29

    Natürlich ist Rust in deisem Punkt c++ überlegen, die Frage war jedoch warum C++ besser sei als C

  6. Re: Lösung: ...

    Autor: ultim 21.10.21 - 10:37

    RicoBrassers schrieb:
    --------------------------------------------------------------------------------
    > ultim schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Und wenn man ein paar Spielregeln einhält ist das Fernhalten von
    > Speicherfehlern in modernem C++ einfach.
    >
    > Ich denke mal, dass das ja die Crux an der Sache ist.
    > Wenn man sich an ein paar Spielregeln hält, könnte das vermutlich auch in C
    > möglich sein.
    >
    > Die Problematik ist doch dabei, dass man diese ganzen Spielregeln dabei im
    > Kopf haben muss - und manchmal vergisst man halt, sich an jeden Punkt zu
    > erinnern. Irren ist nunmal menschlich.
    >

    Na ja, bei C sind aber die Regel viel mehr und komplexer und bringen weniger. Der Punkt ist ja bei modernem C++ (wenn man es überhaupt einsetzen darf, siehe voriges Post) sind diese Regel einfach und wenig genug um im Kopf halten zu können. Heisst natürlich nicht dass sie nicht einmal gelernt werden müssen.

    Das grössere Problem mit C++ ist Legacy-Kod und Legacy-Leute. Da müsste man einfach zu viel umschreiben und zu viele Leute umschulen. Diese Problem gibt es allerdings auch wenn man eine komplett neue Sprache wie Rust einsetzt, mit den zusätzlichen Problemen, dass dort teilweise auch noch das Tooling fehlt und das Community-Knowledge auch nicht vorhanden ist.

  7. Re: Lösung: ...

    Autor: BlackSuit 21.10.21 - 10:41

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > Wuestenschiff schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Du kannst in modernen c++ speicher fehlerfrei arbeiten. Du darfst
    > einfach
    > > nur RAI verwenden und Smartpointer benutzen. Rust hat noch ein pasr
    > > garantien mehr aber Dpeicherfehler kriegst du weg mit )modetnem) c++
    >
    > Das ist genau die Denkweise die uns seit Jahrzehnten zurückhält. Was ist
    > denn das überhaupt für ein schwaches Argument?
    >
    > > Du kannst in modernen c++ speicher fehlerfrei arbeiten.
    >
    > Ja man "kann". Hier liegt doch genau der Fehler! Ich "kann" auch in C
    > fehlerfrei arbeiten – ich darf nur keine Fehler machen. Es geht in
    > der Angelegenheit nicht um die Frage ob man fehlerfrei arbeiten "kann"
    > sondern ob man fehlerfrei arbeiten "MUSS".
    >
    > In dieser Argumentation klingt es ja fast so als sei es ausgeschlossen in C
    > fehlerfrei zu arbeiten und die Neuerung von "modernem" C++ ist nun, dass
    > man es endlich "kann". Nein, das ist von vorne bis hinten falsch aber
    > leider eine gängige Meinung die immer und immer wieder seit Jahren
    > verbreitet wird.
    >
    > Wir müssen als Programmiergemeinschaft endlich mal von dieser falschen
    > Annahme weg. Vor allem aber "wenn ich nur genug Tools auf das Problem werfe
    > (Asan, Msan, UBsan, Valgrind ... ) dann gehen die Probleme schon weg" ...
    > nein tun sie nicht.
    >
    > Das haben nun schon Microsoft, Google und Mozilla erkannt und haben
    > ziemlich ähnliche Zahlen was die Problemstellung anbelangt. Es sind ca. 70%
    > der sicherheitskritischen Lücken auf fehlerhaftes Speichermanagement zurück
    > zu führen und dass seit vielen Jahren unverändert auch MIT Einführung von
    > "modernem" C++. Wer glaubt "modernes" C++ sei die Lösung ist Teil des
    > Problems. Besonders muss man hier ein gewisses Gatekeeping hervorheben das
    > von selbsternannten Gurus einhergeht. Diese säuseln nämlich daher, dass es
    > nur "genug schlaue" Programmierer braucht um das Problem aus der Welt zu
    > schaffen. Als würden diese nie Fehler machen.
    >
    > Die ganze Situation ist wirklich festgefahren an Personen die meinen, dass
    > dieses Problem allein durch starken Willen und Disziplin zu lösen sei und
    > nicht durch mathematisch korrekte Automatisierung. Das fühlt sich
    > stellenweise so an wie Technikverweigerer die mit falschen Argumenten
    > versuchen ihren Job zu verteidigen der droht automatisiert zu werden.
    >
    > ja es fühlt sich furchtbar schlecht an, wenn plötzlich ein Student mit
    > wenig Erfahrung genauso sicheren Code schreiben kann wie Ich der 20 Jahre
    > durch den Schützengraben namens C gegangen ist und die typische
    > "Anfängerfehler" nicht mehr macht, weil man selber durch seine eigenen
    > Narben erinnert wird. Da wird das eigene Ego nämlich erheblich angegriffen
    > wenn jemand neues ohne diese Narben daherkommt und einfach von diese
    > "schlimmen" Zeiten nichts mehr mit bekommt, weil für diese Person C/C++
    > einfach der Vergangenheit angehört – wohl verdient.
    >
    > Wer Interesse an der Meinung eines Microsoft Mitarbeiters zu dem Thema hat,
    > kann sich gerne mal diesen Talk dazu ansehen
    >
    > www.youtube.com
    >
    > msrc-blog.microsoft.com
    > www.zdnet.com
    > www.chromium.org
    > security.googleblog.com
    > www.zdnet.com


    Es ist immer die gleiche Argumentation, egal ob bei (Speicher-)sicherheit oder dem hauseigenen verkorksten Framework: Ja der Senior mit 20 Jahre Erfahrung kann im Zweifel auch mit Assembler sicher und produktiv programmieren - wenn er ausgeschlafen, voll konzentriert, ungestört und mit dem richtigen Koffeinpegel versehen ist. Nur kann und wird das nicht der Maßstab sein. Google hat die übersimplifizierte Programmiersprache Go entwickelt, weil selbst ein Konzern wie Google, nicht genug perfekte "schlaue" Entwickler hat sondern lauter junge Leute direkt vom College.

  8. Re: Lösung: ...

    Autor: ultim 21.10.21 - 10:46

    Wuestenschiff schrieb:
    --------------------------------------------------------------------------------
    > Du kannst in modernen c++ speicher fehlerfrei arbeiten. Du darfst einfach
    > nur RAI verwenden und Smartpointer benutzen. Rust hat noch ein pasr
    > garantien mehr aber Dpeicherfehler kriegst du weg mit )modetnem) c++

    Na, so einfach ist es nicht. Ich plädiere zwar dafür dass man in modernem C++ heutzutage ohne Speicherfehler entwickeln kann, du brauchst aber schon mehr als "nur RAII und shared_prt". Du brauchst dazu mehr Feautres von der Sprache und mehr Features auch vom STL. In diesen Diskussionen wird von den meisten C++ Leuten aber immer nur shared_ptr als Voraussetzung/Lösung gebracht, und da ist kein wunder wenn man Rust-Leute nicht überzeugen kann. shared_ptr reicht nämlich tatsächlich weit nicht. Ausserdem wenn dann sowie eher unique_ptr als shared_ptr.

  9. Oh je

    Autor: nohoschi 21.10.21 - 11:30

    Wichtig ist, dass man die Anleitung und Handbücher liest und versteht. Und dann ordentlich mit bedacht arbeiten. Damit lassen sich Fehler nicht vermeiden und sie tun mir immer weh, aber sie sind immer die Gelegenheit zum Lernen.

    C gehört nicht in das Museum. Es ist eine kompakte Allzweckprogrammiersprache, welche auf Grund der hohen Flexiblität und hardwarenähe gerne in der Systemprogrammierung eingesetzt wird. Wir werden C noch viele Jahrzehnte einsetzen. Früher war jedoch eine Absicherung gegen falsche Nutzung von Speicher technisch nicht möglich, dass hat sich grundlegend geändert. Moderne Compiler wie GCC und LLVM können bei der Kompilierung entsprechende Prüfungen einbauen, welche dann bei einem Test zur Laufzeit anschlagen:

    gcc -fsanitiaze=address

    Da sollte so normal sein wie "-g" für das Debuggen. Fall das nicht geht auf Grund spezieller Situation (Embedded), gibt es immer noch Valgrind. Und ja. C++ setzt mit RIAA und Smartpointer (Referenzzählung und sichere Speicherverwaltung) wirklich gute Dinge um - das erlaubt Effizenz und Sicherheit. Spezielle Sprachfeatures und komplexe Dinge wie Template-Metaprogrammierung sollte man nicht einsetzen, außer man will sich etwas beweisen.

    Die Garbagecollection von Java und C# erlaubt ohne viel technisches Wissen und Vorsicht dennoch stabile Programme zu schreiben. Es hat schon seinen Grund warum im Geschäftsumfeld gerne Java oder C# verwendet wird, die Mängel und Probleme die dabei enstehen, können oft mit mehr Hardware verdeckt werden. Auffällig ist, dass immer mehr vermeintlich hilfreiche Technik eingesetzt wird, DI mit Spring (XML), Hibernate und Annotations erschweren die Wartung und sind auch wenig verständlich. Wenn der Quellcode nicht die Wahrheit ist, wird Wartung schwer. Leider habe ich das Gefühl, dass viele das Einsetzen um professionell zu wirken. Die Anwendung sollen auch in zehn oder zwanzig Jahren funktionieren und da ist sowas nicht hilfreich.

    Rust sieht für mich interessant aus und wie eine mögliche Ergänzung von C und C++. Habe ich aber noch nie eingesetzt. Rust scheint wohl relativ sichere Programmierung und Effizenz zu vereinigen.

    Ärgerlich sind Hypes und die Aufräumarbeiten, die man dann Jahre später damit hat. Von daher ist mehr Ruhe und Bedacht wirklich hilfreich.

  10. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 12:11

    > Damit trifft das gleiche auf C++ zu. Ich muss shared_ptr<> manuell
    > verwenden. ...

    Nein, shared_ptr<> ist ja eben kein manueller Weg.

    > Wenn ich das Vergesse (genauso wie ein vergessen kann an der
    > richtigen Stelle ein free zu machen) bekomme ich eben Fehler.

    Die Sache ist, dass C keine Sprachmittel an die Hand gibt mit denen man sowas so komfortabel dem Entwickler vorgeben könnte wie C++ es tut. C++ tut das und das wird auch so genutzt (auch wenn shared_ptr<> teilweise verkehrt genutzt wird und für mehrfach-Referenzierungen aus einem Thread genutzt wird).

    > C++ ist in der Hinsicht ähnlich schwach wie C.

    Ganz sicher nicht, sondern meilenweit überlegen.

    > Davon abgesehen kann ich mit den "smart" Pointern immer noch genug
    > Fehler machen ...

    Aber sehr viel weniger als in C.

  11. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 12:13

    >> Nicht unbedingt deswegen, sondern weil solche Lowlevel-Frickler halt ein
    >> Lowlevel-Mindset haben. Und dazu passt C++ eben nicht. Würden die auf
    >> der Lowlevel- und Highlevel-Ebene denken können, dann kämen denen
    >> vielleicht> auch C++ in den Sinn.

    > Sehr engstirnige Betrachtung. Das die LowLevel Frickler sehr gute Gründe
    > haben für diese Entscheidungen kommt dir nicht in Sinn.

    Dann nenn mal diese guten Gründe.
    Die gibt es nämlich nicht.

    > Deine High-Level denke stößt dann an seine Grenze wenn die Umgebung keine
    > GB-weise RAM hat.

    Das ist dummes Zeug. Software mit Abstraktion ist nicht größer.

  12. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 12:17

    > Du hast ein sehr naives Mindsets, vielleicht arbeitest du mal in dieser
    > Domain, mal schauen ob C++ dann immer noch dein Favorite ist. Aber
    > nicht vergessen, im Kernel-Space darfst dir erstmal selber eine eigene
    > STL schreiben, ...

    Man könnte die STL fast durchweg benutzen wenn man den Klassen spezielle Allokatoren gibt.

    > ... und dein iostream für Ausgaben auch.

    Nö, nur cout, cin etc. Aber ansich macht man ja im Kernel eh nahezu keine direkten Ausgaben.

    > Ach und Speicher allozieren darfst dann auch eigene Allokatoren schreiben, ...

    Ja, einmal und dann nie wieder.

    > ... aber nicht vergessen den richtigen zu wählen wenn du gerade Speicher
    > brauchst während du nen Spinlock hältst.

    Dann definiert man sich mit using verschiedene Container die an verschiedene Allokatoren gebunden sind und die man zu entsprechenden Zeitpunkten nutzt.
    Während man nen Spinlock hält allokiert man eigentlich nie was.

    > Ich hab schon Device-Driver unter Windows mit einem C++ Wrapper
    > geschrieben, das war ein riesen Katastrophe weil C++ im UserSpace
    > überhaupt nichts mit C++ im Kernel-Space zu tun hat.

    Ich glaub dir kein Wort.

  13. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 12:21

    > - Manchmal ist der Aufwand zu hoch verglichen mit dem Projekt,
    > weil man eben grosse Teile vom STL nachprogrammieren müsste

    Eben nicht - die STL müsste nur mit anderen Allokator-Parametern versehen werden.

    > - Manchmal darf man überhaupt nicht Speicher dynamisch allozieren.
    > Dann ist oft die Verwendung vom STL oft hin auch wenn man sie im
    > Kernelspace nachprogrammieren würde

    Was ist denn das für ein idiotischer Punkt.
    Wenn ich keinen Speicher allokieren darf, z.B. in einem Interrpupt-Handler, dann kann ich den Interrupt-Handler dennoch in C++ entwickeln.

    > - Manchmal glauben Leute falsch dass C++ einen höheren CPU/Speicheraufwand
    > haben würde. Das stimmt aber nicht solang man virtuelle Methoden und
    > Exceptions vermeidet. und Templates nur vorsichtig einsetzt.

    LOL, virtuelle Methoden brauchen ein bzw. bei Merhfach-Vererbung mehrere VMT-Pointer pro Objekt. Und, dass Exceptions ne Menge Tabellen und Unwind-Code für das table-driven EH generieren ist eigentlich komplett egal, denn das ist ja so gut wie immer toter Code da der nur beim Speicher- oder I/O-Kollaps zum Zuge kommt.

  14. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 12:22

    > Es ist immer die gleiche Argumentation, egal ob bei (Speicher-)sicherheit
    > oder dem hauseigenen verkorksten Framework: Ja der Senior mit 20 Jahre
    > Erfahrung kann im Zweifel auch mit Assembler sicher und produktiv
    > programmieren - ...

    Mini-Projekte, ja, aber bei mittleren oder großen Projekten - ausgeschlossen.

  15. Re: Oh je

    Autor: spiegelneuron 21.10.21 - 12:33

    > Wichtig ist, dass man die Anleitung und Handbücher liest und versteht.
    > Und dann ordentlich mit bedacht arbeiten. Damit lassen sich Fehler
    > nicht vermeiden und sie tun mir immer weh, aber sie sind immer die
    > Gelegenheit zum Lernen.

    Was für eine idiotische Einstellung. Lieber direkt eine leistungsfähigere Sprache nehmen, dann hat man den ganzen Ärger nicht.

    > C gehört nicht in das Museum. Es ist eine kompakte Allzweck-
    > programmiersprache, ...

    Nein, allzweck ist C schon mal gar nicht und es gibt auch keine Allzeck-Programmiersprache.
    C ist für Systemsoftware gedacht.

    > Wir werden C noch viele Jahrzehnte einsetzen. Früher war jedoch eine
    > Absicherung gegen falsche Nutzung von Speicher technisch nicht möglich,
    > dass hat sich grundlegend geändert.

    Ja, klaaar, deswegen passieren Fehler wie in dem Artikel beschrieben noch immer.

    > Moderne Compiler wie GCC und LLVM können bei der Kompilierung entsprechende
    > Prüfungen einbauen, welche dann bei einem Test zur Laufzeit anschlagen:
    > gcc -fsanitiaze=address

    Das erkennt aber weder use after free noch out of bounds zuverlässig, sondern überwiegend nur in Ausnahmefälen.

    > C++ setzt mit RIAA und Smartpointer (Referenzzählung und sichere
    > Speicherverwaltung) wirklich gute Dinge um - das erlaubt Effizenz
    > und Sicherheit. Spezielle Sprachfeatures und komplexe Dinge wie
    > Template-Metaprogrammierung sollte man nicht einsetzen, außer
    > man will sich etwas beweisen.

    Mein Gott, mit wem diskutier ich hier ?
    Was für ein Quatscch. Gerade Templates führen zu einem Bruchteil des Codes und zu Größenordnungen mehr Wartbarkeit.

    > Die Garbagecollection von Java und C# erlaubt ohne viel technisches
    > Wissen und Vorsicht dennoch stabile Programme zu schreiben. ...

    Und schlägt einen konservativen Memory-Allocator in der Performance bei einem Drei- bis Vierfachen an Speicher-Verbrauch (lt. Chris Lattner, der hats im Rahmen der Swift-Entwicklung untersucht). Und einen fortschrittlichen wie mimqalloc - no way.

    > Auffällig ist, dass immer mehr vermeintlich hilfreiche Technik
    > eingesetzt wird, DI mit Spring (XML), Hibernate und Annotations
    > erschweren die Wartung und sind auch wenig verständlich.

    Erstens ist das nicht schwerer verständlich als das was man sonst manuell machen würde.
    Zweitens gehts hier um Sprachen zur Systemprogrammierung.

  16. Re: Lösung: ...

    Autor: BlackSuit 21.10.21 - 12:46

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > > Es ist immer die gleiche Argumentation, egal ob bei
    > (Speicher-)sicherheit
    > > oder dem hauseigenen verkorksten Framework: Ja der Senior mit 20 Jahre
    > > Erfahrung kann im Zweifel auch mit Assembler sicher und produktiv
    > > programmieren - ...
    >
    > Mini-Projekte, ja, aber bei mittleren oder großen Projekten -
    > ausgeschlossen.

    Du hättest den Absatz zu Ende lesen sollen.

  17. Re: Lösung: ...

    Autor: ultim 21.10.21 - 12:51

    Du redest anscheinend nicht vom Erfahrung sondern von Theorie.

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > > - Manchmal ist der Aufwand zu hoch verglichen mit dem Projekt,
    > > weil man eben grosse Teile vom STL nachprogrammieren müsste
    >
    > Eben nicht - die STL müsste nur mit anderen Allokator-Parametern versehen
    > werden.

    Und woher allozieren diese cusotm Allocators den Speicher? Es geht hier nicht darum ob du ein Heap vom OS verwendest oder selbst allozierte Puffer, es geht darum, dass man in vielen eingebetteten Projekten überhaupt keine Allokatoren verwenden darf, weil man über sie nicht deterministisch argumentieren kann, und es sind nur statisch zur Kompilierzeit angelegte Objekte erlaubt. Das darfst du natürlich nicht umgehen indem du statisch ein Puffer anlegst und dein Allokator von dort arbeitet, dann hast du nämlich den ganzen Punkt von der Restriktion nicht verstanden.

    >
    > > - Manchmal darf man überhaupt nicht Speicher dynamisch allozieren.
    > > Dann ist oft die Verwendung vom STL oft hin auch wenn man sie im
    > > Kernelspace nachprogrammieren würde
    >
    > Was ist denn das für ein idiotischer Punkt.
    > Wenn ich keinen Speicher allokieren darf, z.B. in einem Interrpupt-Handler,
    > dann kann ich den Interrupt-Handler dennoch in C++ entwickeln.
    >

    Was hat das mit Interrupthändler zu tun? Es geht darum, dass einige Sachen im STL intern Speicher dynamisch allozieren, oder du das selbst machen musst um vernünftig mit dem Feature zu arbeiten. Und das ist oft nicht erlaubt siehe vorigen Punkt. Ich rede nicht von einem Windows oder Linux, sondern von embedded und real-time Systemen.

    > > - Manchmal glauben Leute falsch dass C++ einen höheren
    > CPU/Speicheraufwand
    > > haben würde. Das stimmt aber nicht solang man virtuelle Methoden und
    > > Exceptions vermeidet. und Templates nur vorsichtig einsetzt.
    >
    > LOL, virtuelle Methoden brauchen ein bzw. bei Merhfach-Vererbung mehrere
    > VMT-Pointer pro Objekt. Und, dass Exceptions ne Menge Tabellen und
    > Unwind-Code für das table-driven EH generieren ist eigentlich komplett
    > egal, denn das ist ja so gut wie immer toter Code da der nur beim Speicher-
    > oder I/O-Kollaps zum Zuge kommt.

    Ja das brauchen virtuelle Methoden, und eben deshalb vermeidet man in einigen Projekten Vererbung zum Beispiel. Verstehe nicht woher das LOL kommt, außer du hast nicht viel Erfahrung in der Embedded Industry. Und ich gebe zu, ich habe keine Ahnung was du mit den Exception Tables sagen willst. Ist eben ein Overhead was man sich ausserhalb von Desktop und Servern oft nicht leisten kann.

    Allerdings, wenn du meine Beiträge liest würdest du sehen dass ich pro-C++ bin verglichen mit C, und zB das Hype um Rust völlig übertrieben finde, auch wenn Rust an bestimmten stellen natürlich auch seine Vorteile hat. Das heisst aber nicht, dass C++ unkonditionell für alle Projekte geeignet ist. Genauso wie C oder Rust auch nicht. Es gibt kein Tool oder Sprache unter diesen die das andere komplett und 100% ablösen kann.

  18. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 13:03

    >> Mini-Projekte, ja, aber bei mittleren oder großen Projekten -
    >> ausgeschlossen.

    > Du hättest den Absatz zu Ende lesen sollen.

    Hab ich, aber auch bei optimalen geistigen Parametern, also einem ausgeschlafenen Menschen mit IQ200 und Konzentrationsvermögen von 8h am Tag geht das nicht.

  19. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 13:11

    > Und woher allozieren diese cusotm Allocators den Speicher? Es geht
    > hier nicht darum ob du ein Heap vom OS verwendest oder selbst
    > allozierte Puffer, es geht darum, dass man in vielen eingebetteten
    > Projekten überhaupt keine Allokatoren verwenden darf, weil man
    > über sie nicht deterministisch argumentieren kann, und es sind
    > nur statisch zur Kompilierzeit angelegte Objekte erlaubt. ...

    I.d.R. geht das aber im Kernel und da wo es nicht geht kommt man auch mit C++ zurecht.


    > Was hat das mit Interrupthändler zu tun? ...

    Weil man aus bestimmten Pools nicht allokieren darf wenn auf dem Kern auf dem man gerade arbeitet der Scheduler abgeschaltet ist oder innerhalb eines Interrupts eben gar nicht.

    > Es geht darum, dass einige Sachen im STL intern Speicher dynamisch
    > allozieren, oder du das selbst machen musst um vernünftig mit dem
    > Feature zu arbeiten.

    Das funktioniert meistens auch im Kernel so wie man es benötigt.

    > Und das ist oft nicht erlaubt siehe vorigen Punkt.

    Das ist selten nicht erlaubt (s.O.).

    > Ich rede nicht von einem Windows oder Linux,
    > sondern von embedded und real-time Systemen.

    Ach, und deswegen kann man sowas nicht in C++ programmieren ?
    Is ja interessant.

    > Ja das brauchen virtuelle Methoden, und eben deshalb
    > vermeidet man in einigen Projekten Vererbung zum Beispiel.

    Das phantasierst Du dir jetzt um kompetent zu wirken zurecht bzw. das gibt es nicht.
    Ein VMT-Pointer pro Objekt hat noch niemanden gestört.

    > Verstehe nicht woher das LOL kommt, außer du hast nicht viel
    > Erfahrung in der Embedded Industry.

    Ich bin promovierter Informatiker (GH) und weiß wovon ich rede.
    Du hattest mit Embedded sicher noch nie was am Hut.

    > Und ich gebe zu, ich habe keine Ahnung was du mit den Exception
    > Tables sagen willst. Ist eben ein Overhead was man sich ausserhalb
    > von Desktop und Servern oft nicht leisten kann.

    Der Witz an Exceptions ist ja, dass eben bzgl. der Performance nur der Fall, dass eben keine fliegt zählt. Wenn ein Speicher- oder I/O-Kollaps passiert, dann kann der Overhead ja beliebig sein weil man in der Situation keine Ansprüche an die Performance hat. Aber wenn eben keine fliegt, dann ist der Overhead von Exceptions bei table-driven Exceptions so gut wie Null. Mach das mal mit händischen Auswerten von Rückgabe-Codes ...

    > Das heisst aber nicht, dass C++ unkonditionell für alle Projekte geeignet ist.

    Eigentlich überall dort wo C programmiert wird.

    > Genauso wie C oder Rust auch nicht. Es gibt kein Tool oder Sprache
    > unter diesen die das andere komplett und 100% ablösen kann.

    C++ kann C ablösen und Rust kann beide ablösen.

  20. Re: Lösung: ...

    Autor: BlackSuit 21.10.21 - 13:12

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > >> Mini-Projekte, ja, aber bei mittleren oder großen Projekten -
    > >> ausgeschlossen.
    >
    > > Du hättest den Absatz zu Ende lesen sollen.
    >
    > Hab ich, aber auch bei optimalen geistigen Parametern, also einem
    > ausgeschlafenen Menschen mit IQ200 und Konzentrationsvermögen von 8h am Tag
    > geht das nicht.

    Ja gut den Sarkasmus habe ich wohl nicht deutlich genug gemacht. Es ist sollte klar sein, daß die notwendigen geistigen Parameter eigentlich nie auftreten und damit auch der angesprochene Senior Super Entwickler nur in der Fantasie einiger von sich selbst sehr überzeugter Entwickler existiert.

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

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. IT Security Manager - Home Connect PKI (m/f/d)
    BSH Hausgeräte GmbH, München
  2. Junior BI Data Scientist (m/f/d)
    DMG MORI Management GmbH, Bielefeld
  3. IT-Techniker / Supporter / Administrator (m/w/d)
    Kassenärztliche Vereinigung Bremen, Bremen
  4. Senior Referent IT / Security Engineer (m/w/d)
    L-Bank, Karlsruhe

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u.a. Resident Evil 7 für 7,77€, Tribes of Midgard 11,99€)
  2. (u.a. Haushaltsgeräte von Kitchenaid)
  3. 111,21€ (Vergleichspreis 146,96€)
  4. (u.a. Patriot 8GB DDR5-4800 für 89€, Toshiba 18GB SATA für 279€) bei Mindfactory


Haben wir etwas übersehen?

E-Mail an news@golem.de