Dinkum STL und auto_ptr

gh

Hallo,
der neue C++ Builder wird ja mit der Dinkum STL ausgeliefert.
Ich habe mir mal gedacht, wenn du viel STL benutzt bist du komatible.
Scheint ein Denkfehler gewesen zu sein.
Hier ein Beispiel was mit dem Builder 6.0 funktionert, der Builder 2006 aber nicht übersetzt.

std::auto_ptr<int> create()
{ std::auto_ptr<int> a(new int());
  return a;
}
//---------------------------------------------------------------------------
void load()
{ std::auto_ptr<int> b = create(); //das geht
  std::auto_ptr<int> c = create();
  b = c; //das geht
  b = create();
  //[C++ Fehler] Keine Übereinstimmung für 'std::auto_ptr<int>::operator = <_Other>(std::auto_ptr<int>)' gefunden
}

Kann mir jemand erklären was das soll, oder bin ich zu blöd zum programmieren?

Danke!

Werner Salomon

Hallo gh,

Der Online-Comeau-Compiler und der VC8 übersetzen es auch; und ersterer behauptet nahezu Standard-kompatibel zu sein.
Vielleicht liegt es an der nicht const Referenz, den der auto_ptr im assignment-Operator erwartet.

template<class X> class auto_ptr {
public:
// 20.4.5.1 construct/copy/destroy:
auto_ptr& operator=( auto_ptr& ); // <-- das Source-Objekt wird bei Copy verändert

Versuch' mal statt

std::auto_ptr<int> create()
{ std::auto_ptr<int> a(new int());
  return a;
}

besser

std::auto_ptr_ref< int > create()
{ 
    return std::auto_ptr< int >( new int() );
}

Der Standard sagt:
20.4.5 Class template auto_ptr
Template auto_ptr_ref holds a reference to an auto_ptr. It is used by the auto_ptr conversions
to allow auto_ptr objects to be passed to and returned from functions.

.. aber der Comeau übersetzt es dann nicht mehr; VC8 schon .. das ist eine Stelle an C++, die ich noch nicht so recht verstanden habe, aber einige Compiler-Bauer wohl auch nicht.

Gruß
Werner

camper

das dürfte ein fehler in der dinkumware stl sein. er existiert u.a. auch in vc++7.1 - allerdings erlaubt dieser compiler, dass temporaries an non-const referenzen gebunden werden können, er beeinflusst damit korrekten code nicht.

Werner Salomon schrieb:

Hallo gh,

Der Online-Comeau-Compiler und der VC8 übersetzen es auch; und ersterer behauptet nahezu Standard-kompatibel zu sein.
Vielleicht liegt es an der nicht const Referenz, den der auto_ptr im assignment-Operator erwartet.
template<class X> class auto_ptr {
public:
// 20.4.5.1 construct/copy/destroy:
auto_ptr& operator=( auto_ptr& ); // <-- das Source-Objekt wird bei Copy verändert
Versuch' mal statt
std::auto_ptr<int> create()
{ std::auto_ptr<int> a(new int());
  return a;
}
besser
std::auto_ptr_ref< int > create()
{ 
    return std::auto_ptr< int >( new int() );
}
Der Standard sagt:
20.4.5 Class template auto_ptr
Template auto_ptr_ref holds a reference to an auto_ptr. It is used by the auto_ptr conversions
to allow auto_ptr objects to be passed to and returned from functions.

.. aber der Comeau übersetzt es dann nicht mehr; VC8 schon .. das ist eine Stelle an C++, die ich noch nicht so recht verstanden habe, aber einige Compiler-Bauer wohl auch nicht.

Gruß
Werner

auto_ptr's op= ist überladen:

auto_ptr& operator=(auto_ptr_ref<X> r) throw();

ausserdem besitzt auto_ptr eine conversions-operator für auto_ptr_ref. da dieser operator eine memberfunktion ist, kann er mit rvalues verwendet werden (da der operator non-const ist, wird er nicht mit const auto_ptr funktionieren, wie es sein soll) - es ist diese hintertür, die auto_ptr überhaupt erst praktikabel macht. der ursprünglich gezeigte code ist korrekt. der vorschlag mit auto_ptr_ref als rückgabetyp ist eine sackgasse - letzlich ist auto_ptr_ref ein implementations detail von auto_ptr, das sich nur deshalb im namensraum std (in C++03) befindet, weil sonst die die konvertierung von auto_ptr<X> nach auto_ptr<Y> mit rvalues nicht funktionieren könnte.

gh

Vielen Dank,
ich habe auch lange überlegt, was an dem Code falsch sein könnte und kam nur zu dem Schluss, dass hier die STL spinnt. Aber man weiß ja nie. Man hat oft genug einfach nur ein Brett vorm Kopf.
Mein Selbstvertrauen ist wieder hergestellt.

Ein Rückgabe als Referenz ist nicht möglich, da dann die Verantwortung des Zeigers in der Funktion bleibt. Das ist nicht gewollt.

Gruß gh