smartpointer (auto_ptr) Vs normaler Pointer

volkard

kwaart schrieb:

Genau dieses letzte Umschreiben leuchtet mir nicht ein. Warum sollte ich der Klasse nochmal explizit einen Destructor spendieren, der den Pointer löscht, statt diese Aufgabe mit z. B. einem scoped_ptr eben genau diesem zu überlassen? Der scoped_ptr ist einmal implementiert und nimmt mir diese Arbeit doch gerade ab. Zumal es ja auch noch möglich wäre, dass ich im Konstruktor nach dem Allokieren von point weitere Operationen durchführen muss, die Exceptions werfen könnten (oder ist sowas in deinen Augen für Konstruktoren schon ein absolutes Tabu?). Dann müsste ich diese auch noch abfangen und im Konstruktor in dem Fall ebenfalls delete schreiben. Alles Aufwand, den mir scoped_ptr gerade abnimmt.

ich dachte, die klasse, die weitere initialisierungen macht, besitzt einen InputPoint als attribut.

otze

class InputPoint{
    private:
        BaseInputPoint* point;
    public;
        InputPoint(){
            point = CreateInputPoint();
        }
        ~InputPoint(){
            DestroyInputPoint(point);
        }
};

hier fänd ich nen smart_ptr besser, dem man nen eigenen dtor spendieren kann(shared_ptr oder noch speziellere).

volkard

otze schrieb:

class InputPoint{
    private:
        BaseInputPoint* point;
    public;
        InputPoint(){
            point = CreateInputPoint();
        }
        ~InputPoint(){
            DestroyInputPoint(point);
        }
};
hier fänd ich nen smart_ptr besser, dem man nen eigenen dtor spendieren kann(shared_ptr oder noch speziellere).

wird dabei der smartpointer zufällig doppelt so groß? und wie langsam wird er? und dann greife ich auf manche attribute mit . zu und auf manche mit -> und das nur, weil ich unbedingt nen smartpointer nehmen wollte. seltsame welt. warum können wir nicht einfach smartpointers meiden und nur nehmen, wenn sie unabdingbar sind?

otze

volkard schrieb:

wird dabei der smartpointer zufällig doppelt so groß? und wie langsam wird er? und dann greife ich auf manche attribute mit . zu und auf manche mit -> und das nur, weil ich unbedingt nen smartpointer nehmen wollte. seltsame welt. warum können wir nicht einfach smartpointers meiden und nur nehmen, wenn sie unabdingbar sind?

nö, doppelt so groß muss er net werden, geht ja alles mit templates. und du brauchst kein attribut auf das du mit . zugreifen musst.

volkard

otze schrieb:

nö, doppelt so groß muss er net werden, geht ja alles mit templates.

ich hab wohl meinen spieltrieb verloren und muß nicht mehr alles mit templates machen.

und du brauchst kein attribut auf das du mit . zugreifen musst.

jo, wenn man entsprechende klassen baut, kann man immer statt

vector<size_t> sizes

einfach

Attribute<vector<size_t> > sizes

schreiben. das hat den vorteil, daß man konsequent sizes->push_back(...) schreiben darf, egal ob das ding hinter einem zeiger liegt oder in einem Attribute. außerdem kann man furchtbar gut pimpln mit sowas.

otze

volkard schrieb:

und du brauchst kein attribut auf das du mit . zugreifen musst.

jo, wenn man entsprechende klassen baut, kann man immer statt
vector<size_t> sizes
einfach
Attribute<vector<size_t> > sizes
schreiben. das hat den vorteil, daß man konsequent sizes->push_back(...) schreiben darf, egal ob das ding hinter einem zeiger liegt oder in einem Attribute. außerdem kann man furchtbar gut pimpln mit sowas.

oh, das meisnt du. ich dachte du meinst, dass man einerseits mit op-> des smart_ptr auf werte zugreifen kann, und mit op. auf werte des smart_ptr selber.

So wie du das gemeint hast, ist das aber auch kein problem. denn sinniger weise kann ein smart_ptr nur dort eingesetzt werden, wo ein zeiger benutzt wird. Das ist sozusagen die notwendige bedingung für die verwendung eines smart_ptr. Und ja pimpln kann man damit wirklich fein(dann aber mit nem null kosten scoped_ptr)

volkard

otze schrieb:

Und ja pimpln kann man damit wirklich fein(dann aber mit nem null kosten scoped_ptr)

noch feiner (im sinne von nullkosten), wenn zum pimpln kein new/delete benutzt werden müßte. das macht so eine Attribute-klasse vielleicht so, daß im release-modus innen ein echtes objekt steht (und mehr wird inkludiert und das compilieren dauert ewig) und im debug-modus nur ein zeiger.

volkard

otze schrieb:

So wie du das gemeint hast, ist das aber auch kein problem. denn sinniger weise kann ein smart_ptr nur dort eingesetzt werden, wo ein zeiger benutzt wird. Das ist sozusagen die notwendige bedingung für die verwendung eines smart_ptr.

dieser BaseInputPoint* ist nur ein zeiger wegen der polymorphie! er ist nicht ein zeiger, weil das der anwendungslogik entsprechen würde. er ist nicht sowas wie

class Mensch{
   Mensch* vater;
   Mensch* mutter;
};

, wo sinnigerweise das objekt andere objekte "kennt", sondern hier besitzt es das andere objekt ganz heftig. also ist layering angesagt, schlichtes attribut. das ermögliche ich mit meiner kleinen klasse. zeigereien sind hier nur störendes implementierungsdetail.
das wird sich natürlich ändern, wenn wir anfangen, generell nur mit -> auf attribute zuzugreifen. den plan hab ich 1990 schonmal verfolgt und er wurde nix, aber wenn ich mich recht erinnere, nur wegen dummer compiler. müßte mal das problem beleuchten, wie man initialisiererliste und so gescheit hinkriegt.

otze

dieser BaseInputPoint* ist nur ein zeiger wegen der polymorphie! er ist nicht ein zeiger, weil das der anwendungslogik entsprechen würde.

dagegen sag ich auch nichts. Wenn er kein zeiger wäre(und das ist er nur dann, wenn es unbedingt nötig ist), müsste man sich in keiner form fragen, ob da ein smart_ptr angebracht währe.
Diesen malus der sprache, dass man unbedingt mit op-> auf alles zugreifen muss, was mit new angelegt wurde, kann man nur schlecht einem Objekt zu lasten legen, das versucht einen teil des problems(nämlich das löschen) zu beheben.

um nochmal daus einem deiner letzten posts zu zitieren:

und dann greife ich auf manche attribute mit . zu und auf manche mit -> und das nur, weil ich unbedingt nen smartpointer nehmen wollte.

Nein. du greifst nur an der stelle mit op-> zu, wo du immer mit op-> zugreifen würdest. Nämlich dort, wo es einen zeiger gibt. Wenn du keinen zeiger hast, brauchst du dir nicht zu überlegen, ob du einen smart_ptr brauchst. Der smart_ptr ändert das verhalten, aber nicht die syntax.

das wird sich natürlich ändern, wenn wir anfangen, generell nur mit -> auf attribute zuzugreifen. den plan hab ich 1990 schonmal verfolgt und er wurde nix, aber wenn ich mich recht erinnere, nur wegen dummer compiler. müßte mal das problem beleuchten, wie man initialisiererliste und so gescheit hinkriegt.

du suchst wahrscheinlich eher die überladbarkeit des (op.) . Er drückt nämlich am besten das besitzverhältnis aus. Dann würde man mit op-> nurnoch auf objekte zugreifen die man "kennt", und mit op. nurnoch auf Objekte die man hat.

Um das mal auf smart_ptr zu übertragen, wär das wahrscheinlich die perfekte verbesserung für scoped_ptr und auto_ptr, denn die drücken ein unheimlich starkes besitzverhältnis aus(einmal mit übertragbarkeit, einmal ohne). Der shared_ptr/intrusive_ptr würde dann wieder das ausdrücken, was er eigentlich ist. eine "kennt" beziehung.

phlox81

Wird das jetzt hier zu Pimp my Smartpointer ? :p