[C++] Spass mit auto_ptr

[FlorianB82]

liebe leute!

folgendes gibt mir rätsel auf:

Code: Alles auswählen

class Base { ... };
class Derived: public Base { ... };

void foo(std::auto_ptr<Base> ptr) { ... }

void test()
{
    std::auto_ptr<Derived> pD;

    foo(pD); // (1)

    std::auto_ptr<Base> pB(pD);
    foo(pB); // (2)

    foo(std::auto_ptr<Base>(pD)); // (3)
}

(1) compiliert nicht, fehlermeldung:
error C2664: 'foo': Konvertierung des Parameters 1 von 'std::auto_ptr<_Ty>' in 'std::auto_ptr<_Ty>' nicht möglich
1> with
1> [
1> _Ty=Derived
1> ]
1> and
1> [
1> _Ty=Base
1> ]
1> Kein benutzerdefinierter Konvertierungsoperator verfügbar, der diese Konvertierung durchführen kann, oder der Operator kann nicht aufgerufen werden

hm, an was liegt das? hier steht eine ganz plausible erklärung, die ich fast anzuerkennen geneigt bin. als workaround wird dort (2) propagiert. das funktioniert auch bei mir.

nur: nach dem dortigen erklärungsschema (implizite konvertierung bei (1) zum zieltyp erzeugt temporary, das ein rvalue ist und somit nicht an den non-const reference parameter des danach nötigen copy-constructors von std::auto_ptr gebunden werden kann), dürfte (3) ja auch nicht funktionieren. nur compiliert das bei mir wiederum ohne probleme! was genau ist dann das drecks-problem des compilers bei (1)??? (ich verwende übrigens MSVC 2008 prof.)

ich bin jetz recht verwirrt, und würde sehr gern die erklärung dafür wissen. evtl hat ja der ein oder andere crack hier (z.b. Krishty?) da eine erklärung für?

greeetz, flo

[Krishty]

Wenn ich schonmal gerufen werde: Ich glaube, dass der Fehler viel banaler ist. Ich habe hier kein VC 2008, aber VC 2010 gibt zusätzlich zu der Fehlermeldung, die du erhälst, per IntelliSense noch die Folgende aus:
IntelliSense: more than one user-defined conversion from "std::auto_ptr<Derived>" to "std::auto_ptr<Base>" applies:
Tatsächlich hat auto_ptr zwei Methoden, die hier aufgerufen werden könnten:
template<class _Other>
  operator auto_ptr<_Other>() _THROW0()
  { // convert to compatible auto_ptr
  return (auto_ptr<_Other>(*this));
  }
und
template<class _Other>
  auto_ptr(auto_ptr<_Other>& _Right) _THROW0()
  : _Myptr(_Right.release())
  { // construct by assuming pointer from _Right
  }
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. Und außerdem, dass implizite Konvertierungen (gerade bei solchen Klassen) verabscheuenswert sind, aber das ist ja nichts Neues.

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.

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!

Gruß, Ky

[kimmi]

Wo wir gerade Krishty hier haben: Autopointer über Dll-Grenzen hinweg ist problematisch, oder? Wenn man über Dll-grenzen hinweg einen reset mit einer gehaltenen validen Instanz durchführt, führte das bei uns zu gelegentlichen Abstürzen, die ich auf den DElete über eine Dll-Grenze hinweg geschoben habe. Ohne diesen besagten Call war das dann kein Problem. Wir hatten hier konkret Probleme damit, daher frage ich.

Gruß Kimmi

[Aramis]

Naja, jede Form von Ownership-Transfer ueber DLL-Grenzen ist gefaehrlich und unbedingt zu vermeiden. Auch wenn man es grundsaetzlich mit der richtigen Laufzeitlib schon zum Laufen bringt - aber im Worstcase darf man dann am Ende die ganze Codebasis fuer so einen Mist re-designen. Also lieber von vornherein sauber machen.

[kimmi]

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.

Gruß Kimmi

[FlorianB82]

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?

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.

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. (?)

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.

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?

[kimmi]

Ein Smartpointer beispielsweise. Da gibt es einige, siehe Boost, um ein Beispiel zu nennen. Allerdings habe ich den konkreten Namem gerade nicht im Kopf. Und es muss garantiert werden, dass der Speicher nicht von einer anderen Dll freigegeben wird. Das ist allerdings eher ein Architektur-Thema.

Gruß Kimmi

[FlorianB82]

Ein Smartpointer beispielsweise. Da gibt es einige, siehe Boost, um ein Beispiel zu nennen. Allerdings habe ich den konkreten Namem gerade nicht im Kopf.

hehe, boost benutze ich ja ohnehin schon in meinem projekt. was boost anbietet: scoped_ptr (sowas wie auto_ptr, nur dass man ihn nicht kopieren kann, er also nur innerhalb seines scopes lebt), shared_ptr (aber der hat dann nicht den alleinigen besitz des referenzierten objektes inne (referenzzählung); brauche ich hier also nicht), und weak_ptr (sowas wie shared_ptr, allerdings zur behebung von problemen bei zyklischen referenzen). also alles drei nicht das, was ich brauche. auto_ptr sollte da schon das richtige sein.

apropos smartpointer: ich würde auch std::auto_ptr als smartpointer bezeichnen. (?)

Und es muss garantiert werden, dass der Speicher nicht von einer anderen Dll freigegeben wird. Das ist allerdings eher ein Architektur-Thema.

ja, das ist klar. aber irgendwelche dll-spielchen habe ich in meinem projekt sowieso nicht. das wird alles zu 2-3 anwendungen gelinkt und gut ist. komplexe objektstrukturen über dll-grenzen hinwegzuschieben ist doch die hölle. dann lieber ein bisschen speicherplatz durch größere anwendungen verschenkt, davon hat man genug.
(sidenote: ich verstehe sowieso nicht, wieso sehr viele leute immer ihre anwendung in 10.000 dlls zerstückeln wollen. unterm strich überwiegen zumeist die nachteile davon...)

edit: mich schlau gemacht über scoped_ptr

[kimmi]

1000 Dlls können zum beipiel helfen, wen du an einem sehr großen projekt arbeitest und mehere Entwickler parallel ihr Zeug probieren wollen -> patchen. Dazu kann man ein Plugin ohne ein neues Executable ausliefern. Und Anbindungen an andere Sprachen geht auch schneller- Und und und. . Und selbstredent hat das auch jede Menge Nachteile.

Gruß Kimmi

[FlorianB82]

hehe, jetz habe ich eine diskussion über dlls losgetreten ;). nein, spass beiseite, das kann ich soweit unterschreiben. natürlich haben dlls auch ihre guten seiten. allerdings finde ich, dass viele leute einfach viel zu früh unnötig ihr projekt in dlls zerstückeln, und sich dann über alle arten von speicherfehlern, merkwürdigem verhalten, undwasweisichnichtwas ärgern...=). aber gut, ich bin ruhig, mir ging es jetz eigentlich mehr um meine smartpointer geschichte, und ob es da noch schönere einfachere möglichkeiten gibt, als das mit auto_ptr zu machen. prinzipiell finde ich den eigentlich äusserst passend, nur frage ich mich, ob das so sinn der sache ist, schon bei polymorphen pointern ganze kopierorgien zwischen den verschiedenen auto_ptr loszutreten... geht das nicht noch anders? irgendwie... schöner?

[Krishty]

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?

Ein Ausdruck muss im Rahmen der Definitionsgrenzen des Standards eindeutig sein. Und nirgends ist vorgeschrieben, dass sich ein Konvertierungsoperator genauso verhalten muss wie ein Kopierkonstruktor (sonst könnte man ihn garnicht von Hand definieren) -- du kannst ja beispielsweise ein terminate() in den Operator schreiben. Dann verhalten sich die beiden eindeutig unterschiedlich. Es wäre katastrophal, wenn man dem Compiler bei sowas freie Wahl lassen würde.

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. (?)

Genau. Auf Warnungslevel 4 und mit deaktivierten MS-Spracherweiterungen habe ich auch im Hinterkopf, dass eine Warnung wegen nicht standardkonformem Verhalten ausgegeben wird.

[FlorianB82]

Ein Ausdruck muss im Rahmen der Definitionsgrenzen des Standards eindeutig sein. Und nirgends ist vorgeschrieben, dass sich ein Konvertierungsoperator genauso verhalten muss wie ein Kopierkonstruktor (sonst könnte man ihn garnicht von Hand definieren) -- du kannst ja beispielsweise ein terminate() in den Operator schreiben. Dann verhalten sich die beiden eindeutig unterschiedlich. Es wäre katastrophal, wenn man dem Compiler bei sowas freie Wahl lassen würde.

ok, klingt sinnvoll. ich hatte z.b. sowas erwartet wie "ziehe immer den konvertierungsoperator dem copyconstructor vor", aber so gehts ja auch ;)

Genau. Auf Warnungslevel 4 und mit deaktivierten MS-Spracherweiterungen habe ich auch im Hinterkopf, dass eine Warnung wegen nicht standardkonformem Verhalten ausgegeben wird.

hach, wie schön. habs gerade ausprobiert, uuuuund: ja nee, is klar, keine warnung, kein nix, das wird einfach gefressen. also darf ich jetz davon ausgehen, dass der msvc2008 compiler:
1) entweder den rückgabewert des konstruktors/konvertierungsoperators als funktionsparameter nicht als ein rvalue ansieht,
2) oder sich einen dreck darum schert, dass dieser rvalue eigentlich nicht an den non-const reference parameter des copyconstructors gebunden werden dürfte.

toll. ich ging eigentlich davon aus, dass mit höchster warnstufe und abgeschalteten microschrott-extensions man standardkonformes verhalten vom compiler erwarten dürfte. ich seh schon, ich darf das am ende nochma durch den gcc jagen...

[Krishty]

Ich habe noch präzise in Erinnerung, dass sowas wie „nonstandard extension used: binding reference to temporary“ unter VC9 sechs Wochen lang die einzige Warnung bei mir war, ich sie wirklich durch nichts wegbekam und dass sie für mich letzten Endes der Auslöser war, auf C++0x umzusteigen. Die Warnung existiert definitiv, aber da ich seit geraumer Zeit nur noch VC10 benutze, kann ich dir nicht sagen, warum sie hier nicht erscheint. Vielleicht liege ich ja auch generell falsch.

[FlorianB82]

so, nachdem ich jetz nochmal nachgeforscht habe und auf die glorreiche idee kam, mal den debugger anzuwerfen, weiss ich auch, was da los ist: das problem, den rvalue an die non-const reference zu binden, tritt gar nicht erst auf=). vielmehr wir noch eine weitere konvertierung zu einem objekt der klasse auto_ptr_ref vollzogen, und aus diesem kann dann per value - und nicht per reference wie bei auto_ptr - ein neues auto_ptr objekt copy-constructed werden. hehe. sehr tricky, das. wenn man da mal mitzählt, wieviele konvertierungen/konstruktionen dafür anfallen, könnte einem glatt schlechtwerden. gut, dass das jetz bei mir keine performancekritische stelle ist...

[Schrompf]

Der auto_ptr aus der std-Lib ist nach meinem Wissen übrigens deprecated. Wegen irgendwelcher Fehlverhalten in Grenzfällen, deren Details ich gerade nicht parat habe. Der boost::shared_ptr ist eigentlich genau das, was Du suchst. Aber das ist wohl Geschmackssache

[Aramis]

wenn man da mal mitzählt, wieviele konvertierungen/konstruktionen dafür anfallen, könnte einem glatt schlechtwerden. gut, dass das jetz bei mir keine performancekritische stelle ist...

Bevor du dir darueber Gedanken machst (ich sage nicht dass du es sollst ;-)), solltest du evtl. auch mal einen Blick auf den generierten Maschinencode werfen. Insbesondere „Dummy”-Konvertierungen und Konstruktionen kann der Compiler gut zusammenfalten.

[Krishty]

so, nachdem ich jetz nochmal nachgeforscht habe und auf die glorreiche idee kam, mal den debugger anzuwerfen, weiss ich auch, was da los ist: das problem, den rvalue an die non-const reference zu binden, tritt gar nicht erst auf=). vielmehr wir noch eine weitere konvertierung zu einem objekt der klasse auto_ptr_ref vollzogen, und aus diesem kann dann per value - und nicht per reference wie bei auto_ptr - ein neues auto_ptr objekt copy-constructed werden. hehe. sehr tricky, das.

Tatsächlich, ja ... eigenntlich gängige Routine bei vielen automatischen Containern; hätte mir früher einfallen müssen. Damit tritt das Problem tatsächlich nicht auf; sehr gut. Nur, inwiefern das standardkonform ist, kann ich nicht sagen ...

wenn man da mal mitzählt, wieviele konvertierungen/konstruktionen dafür anfallen, könnte einem glatt schlechtwerden. gut, dass das jetz bei mir keine performancekritische stelle ist...

Ich benutze das gleiche Pattern bei einem meiner Container, und bisher ist mir dadurch nie nennenswerter Overhead entstanden. Das einzige Problem ist, dass der Debugger durch zehn Funktionen hüpft, wenn man von Hand durch einen entsprechenden Aufruf steppt, aber auch das lässt sich unterdrücken.

[FlorianB82]

Der auto_ptr aus der std-Lib ist nach meinem Wissen übrigens deprecated. Wegen irgendwelcher Fehlverhalten in Grenzfällen, deren Details ich gerade nicht parat habe. Der boost::shared_ptr ist eigentlich genau das, was Du suchst. Aber das ist wohl Geschmackssache

im neuen c++ sprachstandard wohl schon, wo es als alternative unique_ptr gibt. da ich aber noch nicht auf den neuen umgestiegen bin, muss ich mich wohl damit anfreunden, was da ist...=(
der boost::shared_ptr kommt leider nicht in frage, da er für shared ownership gedacht ist. ich dagegen brauche nur einen owning smart pointer. klar könnte ich natürlich trotzdem shared_ptr verwenden, aber das wäre dann a) verschwendung und b) sieht man dann auch nicht mehr so schön im quelltext "ah, da wird jetzt der besitz des pointers abgetreten/weitergegeben".

Bevor du dir darueber Gedanken machst (ich sage nicht dass du es sollst ;-)), solltest du evtl. auch mal einen Blick auf den generierten Maschinencode werfen. Insbesondere „Dummy”-Konvertierungen und Konstruktionen kann der Compiler gut zusammenfalten.

das ist wahr. habe ich noch gar nicht gemacht, und ansich sollte das der compiler gut wegbekommen. ich bin da immer so ein wenig paranoid, nachdem man ja hin und wieder mal feststellt (da gabs auch nen paar dinge im jammer thread), dass irgendwelche offensichtlichen optimierungen vom compiler nicht gemacht werden, und stattdessen nen haufen sinnlos code erzeugt wird... =)

Ich benutze das gleiche Pattern bei einem meiner Container, und bisher ist mir dadurch nie nennenswerter Overhead entstanden. Das einzige Problem ist, dass der Debugger durch zehn Funktionen hüpft, wenn man von Hand durch einen entsprechenden Aufruf steppt, aber auch das lässt sich unterdrücken

na, dann bin ich beruhigt. frage: wie unterdrückt man das?

[Krishty]

wie unterdrückt man das?

Das ging irgendwie über die autoexp.dat.

[Helmut]

Aber auch nur in VC6.0. In neueren Versionen darf man sich durch die Registry wühlen. Wo die Keys sind findet man aber schnell, wenn man nach autoexp.dat googelt.