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: oleid 22.10.21 - 09:38

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > > Ne, sicher nicht, aber was hat denn überhaupt der allocator mit der
    > > Programmiersprache zu tun?
    >
    > Die Standardbibliothek inkl. ihrer Container gehört zur Sprache.
    >
    > > Die Aussage ist eher: wenn der systemallokator langsam
    > > zu langsam ist, warum ist er denn schnell genug für c++?
    >
    > Das ist Ansichtssache ob der schnell genug ist. Manche Leute wechseln den
    > gg. TCMalloc, jemalloc oder mimalloc aus.

    Richtig, du hast mein Argument verstanden. Bei Rust machst du das genau so. Warum disqualifiziert sich Rust jetzt?


    > > Ja, in Benchmarks die bei gewissen nutzungspattern relevant sind.
    >
    > Nein, auch in praktischen Benchmarks. Lies die entsprechenden Papers.

    Natürlich liest man die papers, aber die sind nicht gerade neu und glibc ist auch nicht stehen geblieben.

    Zudem: praktische Benchmarks sind äußerst anwendungsspezifisch. Was ich halt schrieb.

  2. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 09:41

    > Hast du auch mal Belege für die ganzen wilden Behauptungen?
    > Zwar sagt der C Standard "The free function causes the space pointed
    > to by ptr to be deallocated, that is, made available for further allocation.

    Eben, und das definiert das was ich sagte.

    > " verbietet bei § 7.22.3 aber nirgends die einfache Ich-Geb-nur-raus-bis
    > -zum-ende Speicherverwaltung wie z.B. auch free RTOS es wahlweise anbietet.
    > Und ja freestanding vs hosted sagt dazu auch nix.

    Nein, obige Regel sagt indirekt: wenn ich einen Block von x reserviert und wieder freigegeben habe, dann muss der Block mit x Größe danach wieder zuverlässig allokierbar sein.

  3. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 09:45

    > Richtig, du hast mein Argument verstanden. Bei Rust machst du das genau so.
    > Warum disqualifiziert sich Rust jetzt?

    Weil die aus nicht nachvollziehbaren Gründen auf den system-allocator gewechselt sind.

    > Natürlich liest man die papers, aber die sind nicht gerade neu ...

    So ein Quatsch. mimalloc ist weniger als 1 Jahr alt.

    > ... und glibc ist auch nicht stehen geblieben.

    Du redest von Dingen von denen Du nichts genaues weißt. Die Sache ist einfach, dass der glibc-Allokator aus Gründen des Speicher-Sparens relativ konservativ ist und dementsprechend die Performance mittelmäßig ist.

    > Zudem: praktische Benchmarks sind äußerst anwendungsspezifisch.
    > Was ich halt schrieb.

    Lies z.B. mal was zu mimalloc: https://github.com/microsoft/mimalloc
    Der glibc-Allocator schneidet da als einer der schlechteren ab.

  4. Re: Lösung: ...

    Autor: Superlokkus 22.10.21 - 09:57

    Klar ist deine Interpretation nicht völlig abwegig, aber so wie ich den C-Standard und C++ Standard kenne würden die das doch nochmal explizit irgendwo schreiben, so im Sinne von (ständiges allocen und deacllocen muss ohne out of memory Möglich sein, solange die Summe < der Kapazitätsgrenze liet) oder hätte mal dealloc irgendwo genauer definiert.

    Solche Vorgaben macht aber weder C noch C++, und ich schätze aus gutem und üblichen Grund: soll die Implementierung doch selbst entscheiden und das beste für sich raussuchen. In einigen Fällen ist dieses naive Speicherverwaltung ja durchaus legitim und auch andere allgemein anerkannt legitime Speicherverwaltungen haben ja defragmentierung, da würde ein free/"dealloc" leider noch gar nicht zwangsweise zur einer möglichen Wiederverwendung führen. Das einzige was ich da als Anforderung seitens C sehe ist, das der ausgegebene Speicher disjunkt sein muss und alignment bla bla.

  5. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 10:11

    > Klar ist deine Interpretation nicht völlig abwegig, ...

    Die ist nicht abwegig, zwingend.

    > ... aber so wie ich den C-Standard und C++ Standard kenne würden die
    > das doch nochmal explizit irgendwo schreiben, so im Sinne von (ständiges
    > allocen und deacllocen muss ohne out of memory Möglich sein, solange
    > die Summe < der Kapazitätsgrenze liet) oder hätte mal dealloc irgendwo
    > genauer definiert.

    Nein, das würden die nicht da reinschreiben weil es eine Fragmentierung gibt. Theoretisch ist es ja möglich, dass einzelne Blöcke intern weiter zerstückelt werden (was aber kein Allokator macht).

    > In einigen Fällen ist dieses naive Speicherverwaltung ja durchaus legitim ...

    Aber eben nicht erlaubt.

    > und auch andere allgemein anerkannt legitime Speicherverwaltungen
    > haben ja defragmentierung, da würde ein free/"dealloc" leider noch
    > gar nicht zwangsweise zur einer möglichen Wiederverwendung führen.

    Nein, das macht kein Allokator, dass Blöcke verschmolzen werden, denn wenn man trennt und wieder verschmelzt hat man nachher ein Fragmentierungs-Problem das zu viel unbenutzten Speicher hinterlässt.

    Das einzige was ich da als Anforderung seitens C
    > sehe ist, das der ausgegebene Speicher disjunkt sein muss und alignment bla
    > bla.

  6. Re: Lösung: ...

    Autor: Superlokkus 22.10.21 - 10:20

    Sorry aber ich kann nicht nachvollziehen wie du nur aus dem Nachsatz das free freeen soll schließt das Speicherfragmentierung zwar erlaubt, einfache Speicherverwaltung aber verboten sein soll.

    Vielleicht habe ich einfach heute/gestern meine "Ich missverstehe die ganze Zeit den C oder C++ Standard" Tage so wie hier stackoverflow.comquestions 69644782/extern-c-before-or-after-library-header-includes/69645206?noredirect=1#comment123152932_69645206 .

    Es ist halt leider schon manchmal vorgekommen das bei solchen language lawyer fragen lustiges zustande kam oder es gar klare Standard Defects gab.



    1 mal bearbeitet, zuletzt am 22.10.21 10:32 durch Superlokkus.

  7. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 10:31

    > Sorry aber ich kann nicht nachvollziehen wie du nur aus dem Nachsatz
    > das free freeen soll schließt das Speicherfragmentierung zwar erlaubt,
    > einfache Speicherverwaltung aber verboten sein soll.

    Hab ich nicht geschrieben.

  8. Re: Lösung: ...

    Autor: Superlokkus 22.10.21 - 10:35

    Würden wir doch beide jedes mal einen Euro bekommen, wenn Entwickler den C oder C++ Standard missverstehen oder übersehen. Wie beim Edit meiner letzten Nachricht noch nachgetragen, ich bin mir überhaupt nicht mehr sicher, will SO aber nicht mit noch mehr language-lawyering Fragen nerven im Moment.

  9. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 10:38

    > Würden wir doch beide jedes mal einen Euro bekommen, wenn
    > Entwickler den C oder C++ Standard missverstehen oder übersehen. ...

    Meinentwegen gibt es Dinge die vielleicht schwieriger zu verstehen oder unklar sind, aber an der Stelle sicher nicht.

  10. Re: Lösung: ...

    Autor: Superlokkus 22.10.21 - 11:01

    Weiß nicht, heuristisch gesehen halte ich C oder C++ Standard Interpretationen eher für falsch die aus Aussagen tendenziell mehr Verpflichtungen der Implementierung ableiten als die Interpretationen die fast schon postkonstruktivistisch sagen "nein es macht nur das was da steht, was auch immer das ist". Auch wie gesagt mein Problem ist das da nur deallocated steht, aber nirgends C, zumidnest hab' ich das nicht auf die schnelle gefunden, definiert was deallocated bedeutdet. Und allein wie ich finde das Beispiel Byte vs. Octet zeigt wie oft vermeintlich in der Entwickler gemeinschaft genau verstandene Begriffe tatsächlich doch problematischer sind, als man auf den ersten Blick denkt.

  11. Re: Lösung: ...

    Autor: ultim 22.10.21 - 12:05

    > > Ausserdem bei Speicher- oder I/O-Kollaps gibt es sicher keine
    > > Exceptions weil diese müssten vom OS geworfen werden und
    > > es gibt fast kein OS das sowas wirft.
    >
    > Mit was für einem Anfänger red ich hier eigentlich ?
    > Schon mal was von bad_alloc gehört ? Wird das etwa vom Betriebssystem
    > geworfen ?

    LOL, ich kann nichts dafür wenn du unsachliche selbsterfundene Begriffe wie "Speicherkollaps" verwendest, da muss man raten was du meinst. Jetzt weiss ich ein Out Of Memory Fehler gehört bei dir zu deinem erfundenen Speicherkollaps-Begriff. Das habe ich tatsächlich nicht angenommen (ich habe gedacht du redest eher über Sachen wie ein Null-Pointer Dereference oder Page Faults), liegt aber nur an deiner irreführenden Rede über die Sache.

    >
    > > Fairerweise muss man sagen von den meisten CPUs gibt es auch
    > > sog. "Exceptions" die wie du sagst zB bei Speicher-Problemen
    > > geworfen werden können, ...
    >
    > Das sind Traps und die dienen völlig anderen Zwecken als Exceptions.
    >

    Danke dass du mich bestätigst. Habe ich doch zuerst dir gesagt das sind nicht worüber wir hier reden weil das sind was anderes als die Software / C++ Exceptions. Allerdings nach deinem "Kollaps"-Ding willst du plötzlich so genau werden mit Traps vs. Exceptions, LOL. Dann lasse ich dich wissen, ein "Exception" im Kontext des CPU wird meistens als Synonym zu "Trap" verwendet... aber danke für die "Korrektur" :D

    > > Auch falsch. Natürlich können auch C++ Exceptions auch über C-Routinen
    > > propagieren!
    >
    > NEIN, das geht bei table-driven EH nicht mehr weil die Rücksprungadressen
    > im C-Code keine Exception-Tabellen haben.
    Und wo ist der Gegenspruch zu meiner Aussage? Ich sagte doch sie können über C-Routinen propagieren WENN die Implementierung stimmt. Es freut mich dass du noch andere EH-Mechanismen kennst die das nicht können, sowas würde man aber nicht wählen, weil es eben die Softwarezuverlässigkeit verschlimmert, weil man dann soetwas beschissenes was du als nächstes schilderst mit exception_ptrs selbst machen muss,

    > > Und natürlich würde man sowas mit mit dem Weiterleiten von
    > exception_ptrs
    > > in C-code wie du schilderst generell nicht machen, weil dazu müsstest du
    > > den C-Code unter eigener Kontrolle haben.
    >
    > Sachmal, was für einem N00b diskutier ich hier eigentlich ? Hast Du
    > eigentlich verstanden was ich schrieb ?
    > Ich beschrieb die Situation, dass ich eine C-Funktion aufrufe die einen
    > C++-Callback in meinem eigenen Code schrieb der dann eine Exception wirft.
    > Die fange ich dann auf unterster Ebene in meinem Callback-Code, merke mir
    > die exception_ptr und (ggf. in einer thread_local Variable die vom Callback
    > und dem C-aufrufenden C++-Code geteilt wird) und werte den dann nach
    > Rückkehr aus der C-Funktion aus und mache ein rethrow_exception - alles
    > eine recht saubere Sache.

    Nein, DU hast es nicht kapiert! Der Vorteil von Exceptions verglichen mit jedes Mal Returnwerte zu checken ist, dass das Exception automatisch weiter zum Caller nach oben propagiert wo es (hoffentlich einmal) behandelt wird und du kannst nicht vergessen in den zig Funktionen bis dahin das Exception zu checken und zu weiterleiten. Wenn du an jeder Grenze zwischen C und C++-Code genau das manuell machen musst, dann ist das genauso Fehleranfällig als würdest du Returnwerte checken, nur mit dem zusätzlichen Space/Time-Overhead (je nach Implementierung) von Exceptions. Ja, sehr klug und "sauber"! Ich sage nicht dass das nicht machbar ist, nur als Profi macht man sowas eben nicht ausser es ist absolut notwendig, zB weil man so eine sch**sse EH-Implementieurng im Compiler hat wie du vorstellst.

    > Mit was für einem Anfänger red ich hier eigentlich ?
    Da kommt wieder eine Anschuldigung von dir. Die Wahrheit ist aber, dein starker Bias zu Desktop/x86-Annahmen und das komplette Ignorieren vom Embedded-Bereich, deine ungenaue Begriffsverwendung und Erklärungen, deine Unfähigkeit vorzustellen, dass es in vielen Anwendungen nicht unbedingt das Performance an der ersten Stelle steht sondern Sachen wie Zuverlässigkeit oder die Binärgrösse, deine Glaube, dass C-Kod nur selten C++-Kod aufruft, dein Prahlen mit einem Doktortitel und hoffen dass du dadurch eine Diskussion gewinnen kannst (oder überhaupt musst), usw., zeigen alle, dass in der Wirklichkeit du wahrscheinlich eher unerfahren bist, und lassen sogar an deiner Fähigkeit zweifeln überhaupt eine Doktorarbeit schreiben zu können.



    1 mal bearbeitet, zuletzt am 22.10.21 12:07 durch ultim.

  12. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 12:51

    > Weiß nicht, heuristisch gesehen halte ich C oder C++ Standard
    > Interpretationen eher für falsch ...

    An dem was wir da diskutierten bzgl. des Punkts um den es da ging gibts nichts zu interpretieren.

  13. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 13:05

    > LOL, ich kann nichts dafür wenn du unsachliche selbsterfundene Begriffe
    > wie "Speicherkollaps" verwendest, da muss man raten was du meinst.

    Wenn ich einerseits von Exceptions, andererseits vom Speicherkollaps rede, dann muss man nur mal 2s Eins und Eins zusammenzählen und dann weiß man was gemeint ist.

    > Jetzt weiss ich ein Out Of Memory Fehler gehört bei dir zu deinem erfundenen
    > Speicherkollaps-Begriff.

    Der Begriff ist nicht selten gebraucht und ergibt sich hier aus dem Zusammenhang wie gesagt von allein.

    > Das habe ich tatsächlich nicht angenommen (ich habe gedacht du redest
    > eher über Sachen wie ein Null-Pointer Dereference oder Page Faults), ...

    Das kann man ausschließen, denn dazu gibt es keine C++-Exceptions.

    > .. liegt aber nur an deiner irreführenden Rede über die Sache.

    Ne, daran, dass Du aufm Schlauch gestanden hast.

    > ... Dann lasse ich dich wissen, ein "Exception" im Kontext
    > des CPU wird meistens als Synonym zu "Trap" verwendet... ...

    Das ist eher selten, dass man den Begriff Exception so verwendet.

    > Und wo ist der Gegenspruch zu meiner Aussage? Ich sagte doch sie
    > können über C-Routinen propagieren WENN die Implementierung stimmt.

    Nein, eben nicht. C generiert keine solchen Tabellen sowie auch keine Unwind-Ketten im Stack (außer Win32/x86 SEH, aber das macht ja noch kein Unrolling im Sinne des Aufrufens von Destrukturen weil es die halt in C nicht gibt) weil es unnötig Overhead wäre oder keiner sowas wünscht oder erwarten darf (wieso soll C auch Stack-Unwinding können, wo man in C keine Ausnahmen werfen und fangen kann ...).

    > Es freut mich dass du noch andere EH-Mechanismen kennst die das
    > nicht können, ...

    Du kennst wohl keine der beiden Möglichkeiten in ihrer Implementation, sonst würdest Du nicht oben meinen, C könne das auch mit unterstützen (obwohl C sowas gar nicht abfangen kann - alles klar, ne ?).

    > ... sowas würde man aber nicht wählen, weil es eben die Software-
    > zuverlässigkeit verschlimmert, weil man dann soetwas beschissenes
    > was du als nächstes schilderst mit exception_ptrs selbst machen
    > muss, ...

    Das ist trivial und schnell implementiert. Die Zuverlässigkeit schränkt das nicht ein.

    > Nein, DU hast es nicht kapiert! Der Vorteil von Exceptions verglichen mit
    > jedes Mal Returnwerte zu checken ist, dass das Exception automatisch weiter
    > zum Caller nach oben propagiert wo es (hoffentlich einmal) behandelt wird
    > und du kannst nicht vergessen in den zig Funktionen bis dahin das Exception
    > zu checken und zu weiterleiten. Wenn du an jeder Grenze zwischen C und
    > C++-Code genau das manuell machen musst, dann ist das genauso
    > Fehleranfällig als würdest du Returnwerte checken, ...

    Nein, es ist nicht genauso, sondern weniger fehleranfällig, denn es gibt ja i.d.R. bis zum Auffangen oberhalb der C-Funktion und beim Weiterleiten darunter weitere Stackframes um deren Unrolling ich mich nicht kümmern muss wenn die RAII-konform sind.


    > nur mit dem zusätzlichen Space/Time-Overhead (je nach Implementierung)
    > von Exceptions. Ja, sehr klug und "sauber"! Ich sage nicht dass das
    > nicht machbar ist, nur als Profi macht man sowas eben nicht ausser
    > es ist absolut notwendig, zB weil man so eine sch**sse EH-Imple-
    > mentieurng im Compiler hat wie du vorstellst.

    Äh, was ? Das was ich beschrieben habe ist bei beiden möglichen Implementationen von C++-Exceptios nötig da C kein Unrolling von Stackframes unterstüzt und da C-Code ohnehin ggf. noch Resourcen hält die nicht in irgendwelchen Unwind-Handlern stehen (und auch nicht stehen können).
    Dir fehlt einfach Grundlagenwissen, wie Exceptions intern fuktionieren.

    > Da kommt wieder eine Anschuldigung von dir. Die Wahrheit ist aber, dein
    > starker Bias zu Desktop/x86-Annahmen und das komplette Ignorieren vom
    > Embedded-Bereich, ...

    Von denen Du meinst, dass Du Ahnung hast. Was aber auszuschließen ist da Du meinst, dass Exceptions im Emedded-Bereich nicht gehen - ich habe begründet, warum das doch geht.
    D.h. Du hast ganz sicher nie was mit Embedded-Entwicklung zu tun gehabt. Ich auch nicht, aber ich hab das im zumindest konzeptuellerweise Haptstudium gehabt und daher sicher mehr Plan davon als Du der aus reinen Ahnungen heraus rumfaselt.

    > ... oder die Binärgrösse, deine Glaube, dass C-Kod nur selten C++-Kod aufruft, ...

    Wo hab ich das gesagt ? Tatsächlich habe ich gesagt, dass C-Code selten C++Callbacks macht wobei der C++-Callback Exceptions wirft, das ist alles. Lesen will gelernt sein.

    > ..., dass in der Wirklichkeit du wahrscheinlich eher unerfahren bist,
    > und lassen sogar an deiner Fähigkeit zweifeln überhaupt eine Doktorarbeit
    > schreiben zu können.

    Ich hab mit 10 auf einem ZX-Spectrum Assembler programmieren gelernt und mir im Grundschul-Alter dazu selbt Englisch beigebracht. Ich bin fast hochbegabt und habe eine so gute Diplomnote, dass ich von der FH zur GH zum promovieren wechseln konnte, wo ich dann den zweitbest möglichen Promotions-Abschluss gemacht habe. Mach das mal nach, Du Dampfplauderer.



    4 mal bearbeitet, zuletzt am 22.10.21 13:12 durch spiegelneuron.

  14. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 13:45

    Hier, ist doch einfach: https://pastebin.com/zz0vcxnE
    Callback in einem Lambda (das Lambda wird automatisch auf die Calling-Konvention in die ich es als Funktionspointer caste kompiliert, funktioniert bei MSVC schon immer, bei clang-cl seit clang 12) und da packe ich eine Exception in einen exception_ptr. Ziemlich simpel.

  15. Re: Lösung: ...

    Autor: ultim 22.10.21 - 15:10

    Du hast entweder nicht verstanden, nicht gelesen, oder schon vergessen was ich geschrieben habe.

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------

    > Das kann man ausschließen, denn dazu gibt es keine C++-Exceptions.
    Eben deshalb habe ich gesagt, sowas könnte nur das OS werfen. Danke dass du es endlich verstehst.

    > > Und wo ist der Gegenspruch zu meiner Aussage? Ich sagte doch sie
    > > können über C-Routinen propagieren WENN die Implementierung stimmt.
    >
    > Nein, eben nicht. C generiert keine solchen Tabellen sowie auch keine
    > Unwind-Ketten im Stack (außer Win32/x86 SEH, aber das macht ja noch kein
    > Unrolling im Sinne des Aufrufens von Destrukturen weil es die halt in C
    > nicht gibt) weil es unnötig Overhead wäre oder keiner sowas wünscht oder
    > erwarten darf (wieso soll C auch Stack-Unwinding können, wo man in C keine
    > Ausnahmen werfen und fangen kann ...).

    Wer hat hier (ausser dir) über Desktruktoren, oder Unwinding, oder Exceptions werfen oder fangen in C gesprochen bitte? Ich habe sogar explizit gesagt früher im Thread, dass natürlich sowas in C nicht passiert. Trotzdem können Excpetions über C-Routinen *propagieren* (ist das gleiche Wort das ich auch früher verwendet habe - nie geredet über fangen oder Unwinding), damit sie im C++-Aufrufer higher up wieder gefangen werden können. Hast du es endlich verstanden, du promovierter Informatiker?

    > Du kennst wohl keine der beiden Möglichkeiten in ihrer Implementation,
    > sonst würdest Du nicht oben meinen, C könne das auch mit unterstützen
    > (obwohl C sowas gar nicht abfangen kann - alles klar, ne ?).
    >
    Wieder das selbe, siehe einmal weiter oben. Exceptions in C gibt es natürlich nicht, Exceptions können trotzdem über C-Stackframes durchpropagieren - wenn der Compiler das richtige EH-Mechanismus verwendet, ist heute quasi fast schon das standard.

    > Das ist trivial und schnell implementiert. Die Zuverlässigkeit schränkt das
    > nicht ein.
    Es wird nicht die Komplexität in Frage gestellt, sondern das Vertrauen daran dass jeder Programmierer 1) immer richtig erkennt wo das notwendig ist und 2) dass er das nie vergisst manuell zu machen. Ausserdem gibt es exception_ptr nur seit C++11, also viel Glück mit altem Code ;)

    > Nein, es ist nicht genauso, sondern weniger fehleranfällig, denn es gibt ja
    > i.d.R. bis zum Auffangen oberhalb der C-Funktion und beim Weiterleiten
    > darunter weitere Stackframes um deren Unrolling ich mich nicht kümmern muss
    > wenn die RAII-konform sind.
    ... bis du zu einer Callback-Routine kommst wo das vergessen wird.

    > > nur mit dem zusätzlichen Space/Time-Overhead (je nach Implementierung)
    > > von Exceptions. Ja, sehr klug und "sauber"! Ich sage nicht dass das
    > > nicht machbar ist, nur als Profi macht man sowas eben nicht ausser
    > > es ist absolut notwendig, zB weil man so eine sch**sse EH-Imple-
    > > mentieurng im Compiler hat wie du vorstellst.
    >
    > Äh, was ? Das was ich beschrieben habe ist bei beiden möglichen
    > Implementationen von C++-Exceptios nötig da C kein Unrolling von
    > Stackframes unterstüzt und da C-Code ohnehin ggf. noch Resourcen hält die
    > nicht in irgendwelchen Unwind-Handlern stehen (und auch nicht stehen
    > können).
    > Dir fehlt einfach Grundlagenwissen, wie Exceptions intern fuktionieren.
    Mir fehlt Grundwissen? Dir ist anscheinend nicht einmal klar dass Excpetions durch C-Kod propagieren können.

    >
    > > Da kommt wieder eine Anschuldigung von dir. Die Wahrheit ist aber, dein
    > > starker Bias zu Desktop/x86-Annahmen und das komplette Ignorieren vom
    > > Embedded-Bereich, ...
    >
    > Von denen Du meinst, dass Du Ahnung hast. Was aber auszuschließen ist da Du
    > meinst, dass Exceptions im Emedded-Bereich nicht gehen - ich habe
    > begründet, warum das doch geht.

    Habe ich nie gesagt, dass Exceptions in Embedded-Bereich nicht gehen! Zitier mich wenn du kannst du Idiot!
    Ich habe gesagt, exakt zitiert "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."
    D.h. ich habe geschrieben, ein Grund warum manche Leute C statt C++ im Embedded wählen ist, weil sie glauben, C++ wäre mit Overhead verbunden, das ist aber falsch wenn man auf ein paar wenige Sachen aufpasst (u.a. Exceptions ausschaltet).

    D.h. wir haben diese ganze Streitigkeit weil du nicht lesen kannst? Na super. Und dann sagst du mir noch "Lesen will gelernt sein.", LOL die Unverschämtheit.

    > D.h. Du hast ganz sicher nie was mit Embedded-Entwicklung zu tun gehabt.
    > Ich auch nicht, aber ich hab das im zumindest konzeptuellerweise
    > Haptstudium gehabt und daher sicher mehr Plan davon als Du der aus reinen
    > Ahnungen heraus rumfaselt.
    >
    > > ... oder die Binärgrösse, deine Glaube, dass C-Kod nur selten C++-Kod
    > aufruft, ...
    >
    > Wo hab ich das gesagt ? Tatsächlich habe ich gesagt, dass C-Code selten
    > C++Callbacks macht wobei der C++-Callback Exceptions wirft, das ist alles.
    LOL, bitte:
    Den ersten hier: "Doch, das ist so, C++-Code als Callback einer C-Funktion ist selten. "
    Und den Zweiten hier:
    >> ... dir fällt
    >> überhaupt nicht auf oder ein, dass es andere Kriterien und andere Arten
    >> von Overheads auch geben kann, die im Embedded-Bereich ähnlich stark
    >> relevant sind, wie zB. Binärgröße.
    > Das ist der seltene Ausnamefall, dass das so ist.
    Genau ^--- hier in diesem Satz.

    > Lesen will gelernt sein.
    Genau, DU solltest mal lesen lernen, oder nicht mit dir selbst in Widerspruch kommen, oder zumindest daran erinnern, was du eigentlich gesagt hast.



    1 mal bearbeitet, zuletzt am 22.10.21 15:12 durch ultim.

  16. Re: Lösung: ...

    Autor: ultim 22.10.21 - 15:26

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > Ich hab mit 10 auf einem ZX-Spectrum Assembler programmieren gelernt und
    > mir im Grundschul-Alter dazu selbt Englisch beigebracht. Ich bin fast
    > hochbegabt und habe eine so gute Diplomnote, dass ich von der FH zur GH zum
    > promovieren wechseln konnte, wo ich dann den zweitbest möglichen
    > Promotions-Abschluss gemacht habe. Mach das mal nach, Du Dampfplauderer.

    Wieder mit dem Herumprahlen, LOL. Du würdest mir gar nicht glauben wenn ich dir meine Geschichte erzähle, weil du glaubst du wärest so hochbegabt dass niemand was ähnliches oder sogar mehr gemacht hat. Es sollte fast strafbar sein so unbegründet so hochnäsig zu sein wie du.

    > D.h. Du hast ganz sicher nie was mit Embedded-Entwicklung zu tun gehabt. Ich auch nicht,
    > aber ich hab das im zumindest konzeptuellerweise Haptstudium gehabt.
    Siehst, du glaubst du würdest Embedded kennen, während ich das seit 10 Jahren beruflich mache. Die Sache ist, Leute die tatsächlich gut sind kennen was sie in ihrem Feld nicht kennen. Das scheint bei dir überhaupt nicht der Fall zu sein.

  17. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 15:35

    > Trotzdem können Excpetions über C-Routinen *propagieren* ...

    Eben, und das habe ich angesprochen und nicht das, was Du mir oben unterstellt hast. Und genau das funktioniert theoretisch nur in einer Variante, nämlich bei den verketteten Stackframes wie bei Windows / x86, aber dabei würden die Stackframes der C-Funktionen übersprungen, dass die C-Funktionen keine Chance haben, ihre Resourcen aufzuräumen.
    Die andere Variante, nämlich mit table-driven EH funktioniert gar nicht, denn dabei guckt der Unwind-Handler in die TD-EH-tabellen des executable oder der libraries und da eine C-funktion keine solche Tabelle für ihre Rücksprung-Adresseen hat sagt der Unwind-Handler schlicht: terminate().

    > Trotzdem können Excpetions über C-Routinen *propagieren* (ist das gleiche
    > Wort das ich auch früher verwendet habe - nie geredet über fangen oder
    > Unwinding), damit sie im C++-Aufrufer higher up wieder gefangen werden
    > können. Hast du es endlich verstanden, du promovierter Informatiker?

    Verstehst Du eigentlich wie Exceptions intern funktionieren - wohl nicht.

    > Wieder das selbe, siehe einmal weiter oben. Exceptions in C gibt
    > es natürlich nicht, Exceptions können trotzdem über C-Stackframes
    > durchpropagieren - ...

    Nein, in einer Variante ist das wie gesagt inpraktikabel, in der anderen umöglich.
    Ich sag ja: dir fehlt Grundlagen-Wissen.


    > Es wird nicht die Komplexität in Frage gestellt, sondern das Vertrauen
    > daran dass jeder Programmierer 1) immer richtig erkennt wo das notwendig
    > ist und 2) dass er das nie vergisst manuell zu machen. ..

    Da braucht man keine Sorgen haben, dass das jemand verkehrt macht, denn das ist trivial.

    > Ausserdem gibt es exception_ptr nur seit C++11, also viel Glück mit altem Code ;)

    Ist seit 10 Jahren Standard. Und C++11 hat den größten Sprung in der C++-Geschichte gemacht, dass niemand auf dessen Neuerungen verzichtet.

    >> Nein, es ist nicht genauso, sondern weniger fehleranfällig, denn es
    >> gibt ja i.d.R. bis zum Auffangen oberhalb der C-Funktion und beim
    >> Weiterleiten darunter weitere Stackframes um deren Unrolling ich
    >> mich nicht kümmern muss wenn die RAII-konform sind.

    > ... bis du zu einer Callback-Routine kommst wo das vergessen wird.

    Du nimmst wohl an, alle Entwickler seien so schlecht wie Du. C++ setzt sehr hohe Anforderungen an den Entwicklern bzw. ist die mit Sicherheit komplexeste Sprache. Wer C++ einigermaßen versteht, für den sind das Kinkerlitzchen.

    > Mir fehlt Grundwissen? Dir ist anscheinend nicht einmal klar dass
    > Excpetions durch C-Kod propagieren können.

    Das ist wie gesagt falsch.

    > D.h. ich habe geschrieben, ein Grund warum manche Leute C statt
    > C++ im Embedded wählen ist, weil sie glauben, C++ wäre mit Overhead
    > verbunden, ...

    Was ja bei geworfenen Exceptions richtig ist bzw. die Kosten sind enorm (10.000+ Takte für eine geworfene Exception auf einer CPU mit hoher IPC sind nicht ungwöhnlich). Aber das ist eben egal.

    >> Wo hab ich das gesagt ? Tatsächlich habe ich gesagt, dass C-Code selten
    >> C++Callbacks macht wobei der C++-Callback Exceptions wirft, das ist
    >> alles.

    > LOL, bitte:
    > Den ersten hier: "Doch, das ist so, C++-Code als Callback einer C-Funktion
    > ist selten."

    Willst Du hier Tautologien zitieren ? Das bedeutet doch das selbe.

    Bitte lern mal verstehen wie exception-handling intern funktioniert und, dasss C-Funktionen das bei der klassischen Funktionsweise nicht sauber bzw. praktikabel unterstützen können bzw. bei table-driven EH gar nicht.
    Wenn Du weiter so ein Unsinn redest, dann schreib ich auf die Schnelle mal ein kleines Projekt wo ich ein eigenes C++-Callback habe (noinline nicht vergessen bzw. globale Optimierung aus damit der C-Thunk nicht wegoptimiert wird), das von einer C-Fuktion aufgerufen wird und, das eine Exception generiert.

  18. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 15:36

    > Wieder mit dem Herumprahlen, LOL. Du würdest mir gar nicht glauben
    > wenn ich dir meine Geschichte erzähle, ...

    Passt ja nicht zu deinem "Sachverstand".

    > Siehst, du glaubst du würdest Embedded kennen, während ich das
    > seit 10 Jahren beruflich mache. ...

    Ja, und Astronaut bist Du nebenberuflich.

  19. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 15:45

    So, pass mal auf, Du Spezialist:

    Das C++-File das den Callback-Thunk aufruft und den C++-Callback enthält:
    https://pastebin.com/ihY64sGk
    Der C Callback-Thunk:
    https://pastebin.com/vFdbFNH1

    Und was passiert:
    Keine Ausgabe weil terminate() aufgerufen wird, was meinen Terminate-Handler aufruft der "terminate" ausgibt.
    Interprozedurale / globale Optimierung hab ich ausschalten müssen, denn der hat mir doch glatt das noinline ignoriert, dass das das Callback am Thunk vorbei direkt ausgeführt wurde.



    4 mal bearbeitet, zuletzt am 22.10.21 15:51 durch spiegelneuron.

  20. Re: Lösung: ...

    Autor: Kein Kostverächter 22.10.21 - 16:05

    Natürlich ist shared_ptr ein manueller Weg. Kein Compiler wird meckern, wenn du den shared_ptr nicht benutzt. Dass Smartpointer einzusetzen sind, ist eine Regel des Projektleiters. Ob man sich daran hält, erkennt man nur im Code-Review.
    Genauso wie dangling pointer usw. erst zur Laufzeit auffallen, oder eben im Code-Review jemand ein gutes Auge hat.
    Auf letzteres kann man sich aber nicht verlassen, denn selbst der bester Reviewer findet nicht alles.
    Rust dagegen kompiliert bei solchen Fehlern einfach nicht. Die Ownership-Regeln sind eingebaut, man kann sich nur umgehen, wenn man den Programmteil, wo es passiert, als explizit unsafe deklariert. Das vereinfacht das Code-Review massiv: Nur in solchen Programmteilen muss man noch auf mögliche Speicherfehler achten, im restlichen Tell der Software muss man nur noch prüfen, ob sie fachlich korrekt umgesetzt, d.h. tut was sie soll. Das spart eine Menge Zeit und Nerven.

    Bis die Tage,

    KK

    ----------------------------------------------------------
    Mach dir deine eigenen Götter, und unterlasse es, dich mit einer schnöden Religion zu beflecken.
    (Epikur, griech. Phil., 341-270 v.Chr.)
    ----------------------------------------------------------
    We provide AI Blockchain Cloud (ABC) enabled applications bringing Enterprise level synergies to vertically integrated business processes.

  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. Spezialist für IT-Sicherheit (m/w/d)
    ekom21 - KGRZ Hessen, Gießen, Darmstadt, Kassel
  2. Product Designer UX/UI (m/f/d)
    ToolTime GmbH, Berlin
  3. Senior Product Model Designer (m/w/d)
    Vodafone GmbH, Eschborn
  4. IT-Spezialist als Software-Entwickler (m/w/d)
    McPaper AG, Berlin

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 120,95€ (Vergleichspreis 146,99€)
  2. 94,90€ (Bestpreis)
  3. 299,87€ (Bestpreis) bei Mindfactory
  4. 129,99€ (Release 25. März)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Kosmologie: Die Raumzeit ist kein Gummituch!
Kosmologie
Die Raumzeit ist kein Gummituch!

Warum das beliebte Modell von den Kugeln im Gummituch in die Irre führt - und wie man es retten kann.
Von Helmut Linde

  1. Indische Regierung Wir haben noch "kein 5G-Netz, was Corona verursachen könnte"

Bundesservice Telekommunikation: Ist eine scheinexistente Behörde für Wikipedia relevant?
Bundesservice Telekommunikation
Ist eine scheinexistente Behörde für Wikipedia relevant?

Die IT-Sicherheitsexpertin Lilith Wittmann hat eine dubiose Bundesbehörde ohne Budget entdeckt. Reicht das für einen Wikipedia-Artikel?

  1. Wikimedia Enterprise Die Wikipedia bekommt ein kommerzielles Angebot

Radeon RX 6500 XT im Test: Die Flaschenhals-Grafikkarte
Radeon RX 6500 XT im Test
Die Flaschenhals-Grafikkarte

Knapp bemessen: Die Radeon RX 6500 XT taugt definitiv für 1080p-Gaming, aber nur wenn bei den Grafikeinstellungen genau hingeschaut wird.
Ein Test von Marc Sauter

  1. RDNA2-Grafik für Laptops AMD legt Radeon RX 6000M in 6 nm auf
  2. Radeon RX 6500 XT AMD hat den ersten 6-nm-Grafikchip
  3. Radeon RX 6600 im Test Die bisher "günstigste" Raytracing-Grafikkarte