Krishty hat geschrieben:Meine Vermutung wäre, dass sich der Compiler nicht zwischen den beiden entscheiden kann (weil nicht eins von beiden explicit deklariert ist) und deshalb nur kompiliert, wenn du ihm auch befielst, den Konstruktor statt des Operators zu wählen – wie in (2) und (3) – und dass die Fehlermeldung des Compilers sehr unglücklich formuliert ist.
danke für die ausführliche antwort! DAS klingt in der tat plausibel. wobei ich mich da dann auch wieder frage, was den compiler daran hindert, sich für eine der beiden methoden zu entscheiden. sowas wird doch prinzipiell öfter vorkommen, dass sowohl ein copy-constructor als auch ein konvertierungsoperator die letzen endes gewünschte konvertierung herbeiführen könnten. was sagt der standard dazu?
Krishty hat geschrieben:Und außerdem, dass implizite Konvertierungen (gerade bei solchen Klassen) verabscheuenswert sind, aber das ist ja nichts Neues.
naja, implizite konvertierungen können schon ziemlichen nonsensquelltext akzeptieren, und etwas erzeugen, was der programmierer nie im sinne hatte. allerdings hätte ich mir gerade hier bei so einer proxy/wrapper-klasse gewünscht, dass viele implizite konvertierungen verfügbar sind. wenn ich nur mit pointer arbeite, kann ich die ja auch einander polymorph zuweisen, und dann erwarte ich das auch von auto_ptr.
Krishty hat geschrieben:Da VC 2008 keine rvalue-References unterstützt, kann es dennoch passieren, dass du auf die in StackOverflow beschriebene Problematik mit rvlaue-reference-to-nonconst-reference reinfällst. Wenn du nicht auf C++0x umsteigen möchtest, ist (2) tatsächlich die einzige standardkonforme Lösung.
ui, DAS wiederrum ist interessant: mir war klar, dass VC 2008 sowas nicht kennt, und dass das hier aber eigentlich entsteht. also im klartext: (3) funktioniert zwar, ist aber völlig am standard vorbei und müsste eigentlich von meinem compiler angemeckert werden. (?)
Krishty hat geschrieben:Darüber hinaus: auto_ptr unterstützt nur Single-Ownership, d.h. nach dem Aufruf deiner Funktion wird der originale Zeiger geleert und unwiederbringlich verloren sein, hoffentlich ist dir das klar!
äh, ja=). deswegen habe ich ihn ja eingesetzt. das beispiel ist völlig künstlich, konkret habe ich eine containerklasse, die objekte enthalten kann, die von einer bestimmten basisklasse abstammen. das ganze soll also polymorph sein. obendrein soll der container die in ihm enthaltenen objekte ownen bzw den besitz der ihm übergeben objekte übernehmen.
kimmi hat geschrieben:Na ja, den auto_ptr nimmt man ja gerade, um die Ownership in "verantwortungsvolle" Hände zu übergeben. Und die vermittelte Sicherheit kann gerade in einem solchen Szenario recht trügerisch sein weil fehleranfälilg.
Oder anders formuliert: wenn ein erfahrender Entwickler ( nicht ich ) mehr als einen Tag Arbeit in das Konstrukt versenkt, ist das Ganze eher zweifelhaft. Man kann beim Einsatz von Thirdparty-Libs oder anderen Randbedingungen so etwas nicht immer garantieren.
hm, willst du mir damit suggerieren, dass ich den einsatz von auto_ptr nochmal überdenken sollte? was habe ich den für alternativen für einen container, der die enthaltenen/ihm gegebenen objekte ownen soll?