auto_ptr was ist vorzuziehen

leo aka qsch

hab hier mal eine kurze Frage aus einem Buch:

gegeben ist die Anweisung

auto_ptr< std::string > ps(new std::string("Daniel"));

ps.get()->assign( "Danny" );
ps->assign( "Danny" );

die frage ist: was unterscheidet die beiden folgenden Aufrufe von assign()? welcher is vorzuziehen?

meiner Meinung wuerde ich die 2te Anweisung verwenden, da sie eigentlich schneller sein sollte und im Prinzip fueren ja beide Anweisungen zum selben Ergebniss.

sehe ich das richtig?

2.)

ein std::string auf dem heap macht NULL sinn.

Bashar

Technisch kein Unterschied IMHO, operator-> wirkt hier genauso wie get(), beide geben den verwalteten Pointer zurück.
Von der Lesbarkeit her ist natürlich 2) vorzuziehen.

leo aka qsch

das ist ein bsp aus einem buch,
es ist nur so gewaehlt worden weil ein auto_ptr ja nur ein Objekt auf dem Heap verwalten kann
und in diesem bsp der indirkete Zugriff auf ein Objekt per auto_ptr veranschaulicht wird

@bashar:
ich dachte mir weil bei der ersten Anweisung auch noch der Funktionsaufruf von get() dazukommt, insofern dieser nicht inline ist.

Bashar

leo aka qsch schrieb:

@bashar:
ich dachte mir weil bei der ersten Anweisung auch noch der Funktionsaufruf von get() dazukommt, insofern dieser nicht inline ist.

1. ist auto_ptr::operator-> auch ein Funktionsaufruf, da überladen
2. du kannst, sofern keine böswilligen Compiler oder ausgeschaltete Optimierungen dem im Wege stehen, 100% davon ausgehen, dass sowohl get als auch operator-> inline expandiert werden.

kartoffelsack

-> ist vorzuziehen. Man sollte, wo es geht, die pointer-Syntax verwenden (bessere Austauschbarkeit mit Pointern oder anderen auto_ptr-Implementierungen die ziehmlich sicher ein -> haben, aber evtl. kein get()).

ein std::string auf dem heap macht NULL sinn.

Wieso nicht?

fällt dir eine situation ein wo es sinn macht? mir nicht.

peterchen

ein std::string auf dem heap macht NULL sinn.

doch, z.B. für Referenzzählung.

der Standard gibt leider keine Performance-Garantie für die Kopie (was ja sinnvoll ist), somit weißt du nicht on dein std::string jedesmal kopiert wird.

Natürlich ist das pervers, wenn der std::string intern auch nochmal referenzgezählt wird. Aber was hilft da? ([deckung] CString z.B....)

Aber was hilft da?

besserer compiler oder bessere stl implementierung. aber bitte keine dummen hacks im eigenen code.

peterchen

besserer compiler

Wie soll mich ein Compiler vor der String-Kopie retten?
Selbst mit RVO bist du doch ständig angebremst.

oder bessere stl implementierung

Eine referenzgezählte Implementation ist nicht immer besser.

Ein gutes Interface muß die Balance zwischen Bequemlichkeit und notwendiger Performance finden. Das ist einfacher, wenn man performancegarantien bekommt - irgendeine. Mit den Freiheiten der STL ist das ein bißchen schwieriger.

Aber zum Thema: operator-> agiert wie get()->
operator-> ist aber bequemer, kann es sei denn T ist keine Struktur. Ich denke, deshalb werde beide Varianten angeboten.

Außerdem finde ich, das auto_ptr verboten werden sollte

string auf dem Heap macht dann Sinn, wenns auch bei allem anderen Sinn macht - wenn es den Scope, in dem es erstellt wurde, überleben soll, also in allen dynamischen Datenstrukturen. Oder, wenn du zur Compilezeit nicht weißt, wie viele strings du brauchst. Zum Beispiel.