Diamond of death



  • EOutOfResources schrieb:

    314159265358979 schrieb:

    Der DOD kommt quasi nie vor. Der ist nur eine Erfindung von Java-Programmierern, die MI nicht kapieren und ne Ausrede dagegen suchen.

    In der STD kommt er vor...

    Dort machts auch Sinn und erzeugt keine Probleme wie von Javanern prophezeit.



  • 314159265358979 schrieb:

    EOutOfResources schrieb:

    314159265358979 schrieb:

    Der DOD kommt quasi nie vor. Der ist nur eine Erfindung von Java-Programmierern, die MI nicht kapieren und ne Ausrede dagegen suchen.

    In der STD kommt er vor...

    Dort machts auch Sinn und erzeugt keine Probleme wie von Javanern prophezeit.

    Achwatt.
    Dann lies mal da:

    http://connect.microsoft.com/VisualStudio/feedback/details/98861/2005-crt-memory-leaks-std-basic-iostream-affects-std-stringstream-std-fstream-probably-others
    http://connect.microsoft.com/VisualStudio/feedback/details/518512/memory-leak-in-ostream-init
    http://us.generation-nt.com/answer/basic-ios-init-multiple-call-standard-conform-help-10015222.html?page=4

    usw.



  • Tritt komischerweise nur bei Microdoof auf - wieso wundert mich das jetzt nicht.

    Nein, "keine Probleme" war vielleicht etwas voreilig, aber aus logischer Sicht ergibts für mich Sinn. Für dich etwa nicht? Wie würdest du das machen? 🙂



  • Tritt komischerweise nur bei Microdoof auf - wieso wundert mich das jetzt nicht.

    Es wundert dich nicht, weil du doof bist. Sorry, aber das ist typisches dummes anti-MS gebashe.

    MS verwendet eine (auf MSVC angepasste) Version der Dinkumware.
    Hast du den 3. Link verfolgt/gelesen? Speziell das Kommentar von P.J. Plauger (Dinkumware)?

    314159265358979 schrieb:

    Wie würdest du das machen? 🙂

    Ich müsste mich mit dem Thema etwas genauer befassen um dazu mehr sagen zu können. Das ganze "Konstruktor der nix tut + init() Funktion die man aber nur 1x aufrufen darf + virtual inheritance" Konstrukt erscheint mir allerdings reichlich plem.



  • hustbaer schrieb:

    Tritt komischerweise nur bei Microdoof auf - wieso wundert mich das jetzt nicht.

    Es wundert dich nicht, weil du doof bist. Sorry, aber das ist typisches dummes anti-MS gebashe.

    Das ist jetzt falsch rübergekommen - das war eigentlich sarkastisch gemeint 🤡
    Nein, so genau hab ich mir das alles nicht angesehen, werde ich nun aber tun, während ich mir überlege, ob es Sinn macht, beim nächsten Contest was mit Quaternionen zu machen :p



  • EOutOfResources schrieb:

    314159265358979 schrieb:

    Der DOD kommt quasi nie vor. Der ist nur eine Erfindung von Java-Programmierern, die MI nicht kapieren und ne Ausrede dagegen suchen.

    In der STD kommt er vor...

    und total unnötig. Das Konzept von Streams in denen man 2 voneinander unabhängige Lese- und Schreibzeiger hat ist einfach für den Po.

    Ansonstne kommt der DOD nur bei schlechtem Bibliotheksdesign vor.

    Softwareplaner: "Oh, lass uns mal unser Hauptinterface von QObject ableiten"
    (3 Monate später): "Du willst deine Klasse auch von QGLWidget ableiten? ne, das geht nicht. DOD."



  • otze schrieb:

    Softwareplaner: "Oh, lass uns mal unser Hauptinterface von QObject ableiten"
    (3 Monate später): "Du willst deine Klasse auch von QGLWidget ableiten? ne, das geht nicht. DOD."

    😃



  • Achja, @314159265358979:
    Nachdem du selbst noch nix entwickelt hast, kannst du zwar die Beobachtung anstellen dass der DOD selten vorkommt, aber nicht sagen warum.
    Deine Vermutung scheint zu sein, dass es so selten Fälle gibt, wo der DOD überhaupt vorkommen könnte.
    Ich würde eher behaupten dass man den DOD in fertiger Software so selten sieht, weil man sich damit einfach diverse Probleme/Nachteile einhandelt.



  • hustbaer schrieb:

    Nachdem du selbst noch nix entwickelt hast

    Ist bei mir eigentlich nur Motivationsmangel. Wie haltet ihr immer so lange durch bei euren Projekten?

    hustbaer schrieb:

    kannst du zwar die Beobachtung anstellen dass der DOD selten vorkommt

    Ich habe um ehrlich zu sein noch nirgens einen DOD gesehen, außer bei den IO-Streams.

    hustbaer schrieb:

    aber nicht sagen warum.

    Ich kann nur Vermuten. Dass der DOD Probleme erzeugt, liegt auf der Hand.

    hustbaer schrieb:

    Deine Vermutung scheint zu sein, dass es so selten Fälle gibt, wo der DOD überhaupt vorkommen könnte.

    Ist dem nicht so?

    hustbaer schrieb:

    Ich würde eher behaupten dass man den DOD in fertiger Software so selten sieht, weil man sich damit einfach diverse Probleme/Nachteile einhandelt.

    Das ist wohl auch war.



  • Ich habe hier anscheinend eine Grundsatzdiskussion losgetreten. 🙂
    Aber wen es interessiert, hier mal mein Grund, auf das von mir verhasste Konzept zurückzugreifen: Ich möchte für eine Schnittstelle Interfaces anbieten, die wirklich rein abstrakt sind. Diese Interfaces werden mit Objekten durch eine Factory bestückt und an den Kunden weitergereicht. Wenn ich jetzt eine Basisklasse für Interfaces schreiben will (um Funktionalität nicht kopieren zu müssen), muss ich von dieser sowohl beim Interface als auch bei der Implementierung ableiten.

    Basisinterface

    / \

    Interface Basisimplementierung

    \ /

    Interfaceimplementierung

    Ich bin selber wie gesagt absolut kein Fan von MI, aber habe mich auf diese Struktur geeinigt.

    PS: .. und bin soeben auf ein erstes Problem dabei gestoßen, was mir wahrscheinlich die Struktur zerschießt. Wenn ich versuche, einen Pointer auf das Interface zu löschen, laufe ich im Debug in einen Heap error. Kann es daran liegen, dass er die Basisimplementierung nicht richtig mitkriegt? Wie sieht es generell bei MI aus, wenn ich auf eine der mehreren Basisklassen caste und diese versuche zu löschen?

    PPS: Ein virtueller Destruktor ist schon ne feine Sache. 🙂


Anmelden zum Antworten