by value ohne copy-constructor



  • wütend schrieb:

    Das enthält höchstens zwei bis drei deletes, genau so viele selbst geschriebene Copy-Konstruktoren - und wo stecken die?

    bisschen viel, meinst du nicht? 😡

    Du scheinst dann ja genau der richtige zu sein der mir erklären kann wie der ultimative Smart Pointer aussieht,der sich also 100%(!) wie ein normaler Pointer verhält aber jegliches Speichermanagement übernimmt.

    Also,wie sieht der aus?
    Oder bist du nur ein Dumm-Schwätzer?
    Lass mal sehen wütend.

    MfG Spacelord



  • Spacelord schrieb:

    wütend schrieb:

    Das enthält höchstens zwei bis drei deletes, genau so viele selbst geschriebene Copy-Konstruktoren - und wo stecken die?

    bisschen viel, meinst du nicht? 😡

    Du scheinst dann ja genau der richtige zu sein der mir erklären kann wie der ultimative Smart Pointer aussieht,der sich also 100%(!) wie ein normaler Pointer verhält aber jegliches Speichermanagement übernimmt.

    Also,wie sieht der aus?
    Oder bist du nur ein Dumm-Schwätzer?
    Lass mal sehen wütend.

    MfG Spacelord

    hi!



  • Sowas dachte ich mir schon....



  • Spacelord sag du doch mal in welcher Situation man noch ein manuelles 'delete' braucht, also wo die STL und Boost Klassen nicht ausreichen.



  • Ich habe bereits erwähnt dass ich mir über die boost smart pointer kein Urteil erlauben kann,habe allerdings auf die Frage(!) ob diese denn wirklich so toll sind keine echte Antwort bekommen.
    Die Standard auto_ptr haben so viele "Unterschiede" zu normalen Pointern dass man ja wohl kaum noch darauf eingehen muss. Ansonsten les dir die Scott Meyer Links durch die ich weiter vorne gepostet hab.

    MfG Spacelord



  • Spacelord schrieb:

    Du scheinst dann ja genau der richtige zu sein der mir erklären kann wie der ultimative Smart Pointer aussieht,der sich also 100%(!) wie ein normaler Pointer verhält aber jegliches Speichermanagement übernimmt.

    ???
    Um genau zu sein würde es mich auch ziemlich wundern, wenn es den gäbe. Zeiger sind doch gerade solche Problemkinder, *weil* man sie für 1000 verschiedene Dinge verwenden kann.
    Natürlich verhält sich ein std::vector<int> nicht in allen Bereichen wie ein int* (offensichtlich kann man mit einem vector nicht auf einen int zeigen, um ihn zu beobachten). Trotzdem ist ein vector speziell für das Halten eines dynamischen Arrays wesentlich komfortabler. Und warum? Weil er darauf spezialisiert ist, während man sich beim rohen Zeiger die jeweils passende Semantik immer und immer wieder neu schreiben muss.
    Genau so sind die Smart Pointer in std und boost auf andere Aspekte von rohen Zeigern spezialisiert. Wo du da einen Nachteil hineininterpretierst, weiß ich nicht.



  • Spacelord schrieb:

    Bietet boost wirklich den generischen eierlegenden Wollmilchsau-Smart Pointer?

    nein, aber andrei alexandrescou hat einen in seinem Buch vorgestellt, der die eierlegende Wollmichsau sein kann-sofern man ihn für jede situation anpasst.

    aber darum geht es garnicht. Wichtig ist, dass es inzwischen für jede standardsituation einen smart_ptr gibt, der sie lösen kann. Auto_ptr war erst der anfang, inzwischen hat sich zum glück auf diesem gebiet viel getan 👍



  • otze schrieb:

    Spacelord schrieb:

    Bietet boost wirklich den generischen eierlegenden Wollmilchsau-Smart Pointer?

    nein, aber andrei alexandrescou hat einen in seinem Buch vorgestellt, der die eierlegende Wollmichsau sein kann-sofern man ihn für jede situation anpasst.

    Gerade dieses "Anpassen" ist das was ich an Smart Pointern nicht so sonderlich mag.Du schneiderst dir einen zurecht der auf ne ganz spezielle Anforderung passt und hast dann aber nen smart_ptr der auf irgendeine Art und Weise "Gefahren" birgt wenn er nicht genau so benutzt wird wie er gedacht ist.Um den dann nach 5 Jahren wieder mal einsetzen zu können musst du dir dann erstmal wieder die Implementierung angucken um diesen Fallen aus dem Weg zu gehen.Wie sich new und delete verhalten weiß jeder.
    Wenn du irgendwo nen Fehler im Code hast der auf nen "falsch" benutzten Smart Pointer zurückzuführen ist,ist dieser IMHO deutlich schwerer zu finden als z.B. nen vergessenes(oder doppeltes)delete.
    Ich behaupte ja garnicht dass ich überhaupt keine Smart Pointer benutze oder dass es keine Situationen gibt in denen es komfortabler und sicherer ist Smart Pointer zu benutzen, aber krampfhaft zu versuchen alles in nen Smartpointer zu quetschen was nach Zeiger aussieht halte ich für fragwürdig.

    MfG Spacelord



  • Gerade dieses "Anpassen" ist das was ich an Smart Pointern nicht so sonderlich mag.Du schneiderst dir einen zurecht der auf ne ganz spezielle Anforderung passt und hast dann aber nen smart_ptr der auf irgendeine Art und Weise "Gefahren" birgt wenn er nicht genau so benutzt wird wie er gedacht ist.

    Jedes sprachmittel zerschiesst dir dein programm, wenn du es nicht richtig einsetzen kannst.

    gegenthese: ein auf ein problem perfekt angepasster pointer führt zu einer erhöhten sicherheit des programms. Da du die fähigkeiten der pointer einstellen kannst, kannst du bestimmte casts verhindern oder zulassen, du kannst threadsicherheit einbauen und sogar bestimmen, wie und wann die gehaltenen objekte zerstört werden müssen(das "wie" ist wichtig, wenn du verdecken willst, wie die objekte erstellt werden, dies ist zb für Fabriken interessant)

    das ganze mal plakativ dargestellt:

    Widget* widget=factory.createWidget();
    

    was weist du über widget?

    boost::shared_ptr<Widget> widget=factory.createWidget();
    

    was weist du über widget?



  • Spacelord schrieb:

    Ich behaupte ja garnicht dass ich überhaupt keine Smart Pointer benutze oder dass es keine Situationen gibt in denen es komfortabler und sicherer ist Smart Pointer zu benutzen, aber krampfhaft zu versuchen alles in nen Smartpointer zu quetschen was nach Zeiger aussieht halte ich für fragwürdig.

    Dann bring doch endlich mal ein Gegenbeispiel.


Anmelden zum Antworten