klassen design mit auto_ptr + boost::shared_ptr

camper

in accept() wird ein objekt auf dem stack erstellt, danach ein objekt auf dem free store, welches eine kopie des objekts auf dem stack ist. der zeiger auf letzteres objekt kommt in einen auto_ptr, dann wird das stack-objekt zerstört, dann der auto_ptr zurückgegeben (was eine kopie implziert, die der compiler auslassen darf und sicher auch wird). dieser auto_ptr wird dann benutzt, um den shared_ptr zu initialisieren, was geht, weil shared_ptr für eben diesen zweck einen entsprechenden konstruktor hat. dann wird der auto_ptr weggeworfen, allerdings ist er schon durch den ctor von shared_ptr geleert worden, so dass das keine probleme macht.

nunja, je nachdem wie shared_ptr konstruiert ist. der auto_ptr hält jeweils nur eine aktuelle referenz und macht alle anderen ungültig. beim shared_ptr werden alle referenzen gemerkt. macht vielleicht bei dem beispiel schon sinn, das so anzuordnen?

cu

hi!
hab was übersehen bei dem konstrukt;-)
schaut noch so in der art aus....könnte da der vector schuld sein an dem boost::shared_ptr, man kann keinen auto_ptr in nen vector packen z.b. weils nicht copy constructable ist oder wie war das?

cu

class Base 
{ 
public:        
    Base(int foo_): foo(foo_) {}

    std::auto_ptr<Base> accept() const 
    { 
        int foo = 3; 

        return std::auto_ptr<Base>(new Base(foo)); 
    }

private:
    int foo;   
}; 

class Holder 
{ 
private: 
    boost::shared_ptr<Base> ptrbase_; 
public: 
    Holder(std::auto_ptr<Base>& ptrbase) 
        : ptrbase_(ptrbase) 
    { 
    } 
    boost::shared_ptr<Base>& getspBase() 
    { 
        return ptrbase_; 
    } 
}; 

Holder h(m_Base.accept()); 
m_Holders.push_back(h);

camper

das ist ein guter grund. bei auto_ptr sind original und kopie nicht equivalent - und das ist eine der voraussetzungen, den stl container an T stellen.

bei nem boost::shared_ptr sind dann orginale und kopien gleich oder wie?

wolltest du sagen das auto_ptr keinen copy constructur hat? und das ist eine der voraussetzungen, den stl container an T stellen, was meinst du?

cu

auto_ptr dürfen nicht für Arrays verwendet werden:

// NIEMALS NIE NIE GUT!
int main()
{ 
auto_ptr<char> Auto(new char[20]);
}

auto_ptr dürfen nicht als Elemente von STL-Containern verwendet werden:
STL-Containerelemente müssen häufig kopiert werden (z.B. beim Einfügen, Sortieren usw.). Aus diesem Grund erwartet man von ihnen, dass Kopie und Original äquivalent sind. Dies trifft auf auto_ptr aber nicht zu, da durch die Besitzübertragung das Original zurückgesetzt wird und nach dem Kopiervorgang auf NULL zeigt.

Standardkonformen Implementationen verweigern das Anlegen von STL-Containern mit auto_ptr bereits zur Compilezeit. Leider gibt es aber einige Implementationen (z.B. die des VCs von Microsoft) die dies erlauben. Dies ist nicht standard, nicht portable und niemals eine gute Idee.

Beim Kopieren eines auto_ptr findet immer ein Besitztransfer statt:

// Print fungiert als Senke! 
void Print(auto_ptr<int> pInt)
{
cout << *pInt << endl;
}

int main()
{ 
auto_ptr<int> Antwort(new int(42));
Print(Antwort);
// KAWUMM! Antwort hat sein Objekt längst verloren.
*Antwort = 14;
}

HumeSikkins

@cplusplus.
Wenn du einen Text Wort für Wort übernimmst, meinst du nicht, dass es dann sinnvoll wäre die Quelle zu nennen?

aso, ja sorry;-)

das is von http://fara.cs.uni-potsdam.de/~kaufmann/?page=GenCppFaqs&faq=auto_ptr#Answ wer noch weiter lesen will;-)

cu

SideWinder

Glaubt ihr, cplusplus weiß wer der Autor dieser Homepage ist?

MfG SideWinder

ja ich find die page e ganz nett! schreibst mal paar neue artikel wieder HumeSikkins, letztes mal hattest doch was hier im forum gepostet zu Policies!?

weiss doch jeder das es HumeSikkins ist;-)

cu