3. auto_ptr verstaendnis problem

auto_ptr verstaendnis problem

  • E

    heiho

    also

    ich hab eine klasse mit nem auto_ptr darin

    class AA
{
    std::auto_ptr<BB> BBclass;
};

    diese will ich in einer funktion ein wert zuweisen, da weiss ich nicht ob das so ueberhaupt zulaessig ist

    void AA::blub()
{
    BBclass = std::auto_ptr<BB>(new BB);
    BBclass->DoSomething();
}

    BBclass soll die ganze zeit verfuegbar sein bis ich BBclass.release() aufruf oder das programm beendet
    anders weiss ich keine methode wie ich speicher zuweisen kann, alle versuche wurden mit errors quittiert
    (kann keine zeigen im moment)
    es funktioniert so, aber ich vermute so langsam das es "durch zufall" funktioniert da der speicher noch nicht ueberschrieben wurde

    macht man das so ?

    (hab seit heute auch boost am laufen, moechte aber erstma auto_ptr verstehen bevor ich andere benutz)

    0
  • S

    Hi,

    warum verwendest Du überhaupt auto_ptr ?
    Geht doch auch "normal" (BTW: release() sollte eine Funktion von AA sein) :

    class AA {
    BB* BBclass;
public:
   AA() : BBclass(0) {}
   void blub() {
      if(!BBclass) BBclass = new BB;
      BBclass->DoSomething();
   }
   releaseBBclass() { delete BBclass; }
   ~AA() { releaseBBclass(); }
};

    Gruß,

    Simon2.

    0
  • C
    Mod

    Mr Evil schrieb:

    BBclass soll die ganze zeit verfuegbar sein bis ich BBclass.release() aufruf oder das programm beendet

    Jede Veränderung eines auto_ptr (außer release und swap) führt dazu, dass das Objekt, auf das zuvor verwiesen wurde, gelöscht wird.

    BBclass.reset(new BB);
BBclass = std::auto_ptr<BB>(new BB);
BBclass.reset(std::auto_ptr<BB>(new BB).release());

    @Simon2: auto_ptr hat keinen operator! ( !p.get() ist die Lösung) und der Konstruktor, der rohe Pointer nimmt, ist explicit.

    0
  • E

    mit new und delete hatte ich es bisher, nur es gibt zu viele ausstiegsmoeglichkeiten, sei es gewollt oder ungewollt
    auf jeden fall wollte ich einen intelligenten zeiger welcher sich selber um die bereinigung kuemmert (die zerstoerung finden dynamisch zur laufzeit statt, der user bestimmt, destruktor reicht nicht)

    @camper
    eine zuweisung findet nur einmal statt, amsonsten nur zerstoerung oder eine neue generierung nach voran gegangener zerstoerung
    so wie ich deinen code verstehe machs ichs ja bisher schon richtig

    member in klasse
    std::auto_ptr<BB> bbclass;

    eine erstellung sobald gewuenscht
    BBclass = std::auto_ptr<BB>(new BB);

    zerstoerung wenn gewuenscht
    BBclass.release();

    erneute erzeugung sobald gewuenscht
    BBclass = std::auto_ptr<BB>(new BB);
    .
    .
    .

    0
  • C
    Mod 

    BBclass.release();

    leert den Pointer, zerstört aber nicht das Objekt. für die Zerstörung ist reset da:

    BBclass.reset();
    0
  • E

    ja meinte ich ja, schreibe den ganzen beitrag ausn kopf, hab grad den code nicht zur verfuegung,
    wollte nur schnell gewissheit bevor ich morgen mit bloedsinn weitermach

    danke

    0
  • C

    Mr Evil schrieb:

    mit new und delete hatte ich es bisher, nur es gibt zu viele ausstiegsmoeglichkeiten, sei es gewollt oder ungewollt
    auf jeden fall wollte ich einen intelligenten zeiger welcher sich selber um die bereinigung kuemmert (die zerstoerung finden dynamisch zur laufzeit statt, der user bestimmt, destruktor reicht nicht)

    Dafür gibt es doch die Destruktoren - egal auf welchem Weg* der Scope des Objekts verlassen wird, der Compiler ruft auch seinen Destruktor auf (und der sollte sich im Ernstfall um die Bereinigung kümmern).
    (aber denk dabei an die "Rule of Three" - du benötigst idR entweder Copy-Ctor, operator= UND Dtor oder gar keine dieser Methoden)

    * nur bei setjmp()/longjmp() bin ich mir nicht sicher - aber welcher [i]vernünftige C++ Programmierer verwendet das schon?

    0
  • L

    CStoll schrieb:

    (aber denk dabei an die "Rule of Three" - du benötigst idR entweder Copy-Ctor, operator= UND Dtor oder gar keine dieser Methoden)

    Gerade die kann man sich doch sparen wenn man einen passenden Smartpointer benutzt (ok, für auto_ptr sollte die Klasse wenigstens unkopierbar sein). Ich denke um nichts anderes geht es Mr Evil hier, oder?

    Ich benutze übrigens regelmäßig Scoped oder Shared Pointer in Klassen, weil ich keine Lust habe einen Destruktor zu implementieren, der sie löscht 😉

    0
  • A

    auto_ptr ist eh im nächsten C++Standard deprecated.

    0
  • E

    genau

    ich hab es ja wie bereits erwaehnt bisher alles mit nem standard new und delete implementiert,
    aber ich hab zZt keine lust mich um die bereinigung gedanken machen zu muessen
    auto_ptr war der erste ansatz, da es halt bereits im standard ist
    als naechstes denk ich benutz ich die smart pointer von boost

    0
  • S

    Mr Evil schrieb:

    ...
    aber ich hab zZt keine lust mich um die bereinigung gedanken machen zu muessen...

    Das würde ich aber in jeden Fall tun. Auch ohne "new/delete" spielt es schon eine wesentliche Rolle, wem ein Objekt denn eigentlich "gehört". Denn auch nur der sollte idealerweise am Objekt "rumändern".
    Es gibt zwar auch das Konzept: Jeder, der einen Pointer auf das Objekt in der Hand hat, kann damit machen, was er will", aber das führt schnell ins Chaos.

    Gruß,

    Simon2.

    0
  • ?

    Artchi schrieb:

    auto_ptr ist eh im nächsten C++Standard deprecated.

    Was soll man dan verwenden?
    Den boost::scoped_ptr?

    Gruß,
    *Cpp-Anfänger*

    0
  • ?

    Aber der ist ja Noncopyable...

    Nur noch shared_ptr?

    0
Anmelden zum Antworten