factory + smart pointer

Wer sagt denn, das man boost braucht? shared_ptr gibts im TR1.

HansiHinterseher schrieb:

Wer sagt denn, das man boost braucht? shared_ptr gibts im TR1.

Stimmt.
Aber leider hat momentan nicht jeder einen Compiler der TR1 bereitstellt und solange müssen die Leute auf boost::tr1 zurückgreifen.

ich bin nicht der meinung, dass der client selber entscheiden können sollte ob er einen schlauen oder einen dummen pointer will. wenn die factory smartpointer zurückliefert, dann sichert man damit ein bestimmtes verhalten zu.

dumme pointer könnten z.b. einfach gelöscht werden, obwohl es an anderen stellen noch x referenzen auf das dahinter liegende objekt gibt. der client weiß einfach nicht, wie lange das objekt gültig bleibt. oder ob, wann und wie er es löschen darf, soll oder muss. wenn ich meine bisherigen erfahrungen so betrachte, ist das eine typische fehlerursache.

mit einem smartpointer ist es klar: der letzte macht das licht aus und der provider entscheidet, wie der lichtschalter aussieht. das ist genau das, was ich meistens will.

dass smartpointer evtl. mehr performance kosten, spielt an dieser stelle eigentlich gar keine rolle. die objekte werden ja nicht in einer tour erzeugt und wieder zerstört.

@tachyon: wo genau liegt denn die problemlösung bei deinem workaround? ich verstehe nicht, worauf du hinaus willst. dein code hat das gleiche problem hat wie meiner (base_factory::create() und derived_factory::create() mit nicht kovarianten rückgabetypen).

dass die verwendung von boost als nachteil gewertet wird, ist in diesem fall echt lustig. ich habe mich nach jahrelanger weigerung dazu entschieden, boost dieses mal eine chance zu geben, statt das rad immer wieder neu zu erfinden. und schon beim ersten problem kommt der vorschlag, es doch lieber selbst zu programmieren

asc

fabrikarbeiter schrieb:

dass die verwendung von boost als nachteil gewertet wird, ist in diesem fall echt lustig.

Find ich eher traurig. Boost ist zu einem nicht kleinen Teil von Leuten die im C++ Standardkomitee sitzen beeinflusst wurden. Ich behaupte mal das boost zu den besten C++ Bibliothekssammlungen überhaupt zählt.

Wenn ich mit Strings arbeite verwende ich auch nicht char* sondern std::string, und schreibe keine eigene Umsetzung.

Ich verstehe hier eh nicht warum sich die Leute hier wegen Performance und Overhead aufregen. Wozu gibt es Profiler, wozu gibt es Refactoring, und wo ist bitte die Sicherheit bei dem Ganzen.

Vorzeitige Optimierung ist die Wurzel allen Übels. Warum nicht erst einmal sicheren Code schreiben und dann später die Teile anpassen die tatsächlich ein Flaschenhals in der Anwendung sind. Ich habe inzwischen die Erfahrung in meinen Programmen gemacht, das obwohl ich intensiv mit Smartpointern und ähnlichen Technologien arbeite meine Programme schnell sind. Okay, das liegt natürlich auch an den Anwendungsbereichen. Wenn ich innerhalb kürzester Zeit Abertausende Objekte anlegen muss gibt es besseres - wobei dort dann auch die Frage ist ob nicht replacement new verwendet wird, oder ganz andere Speicherverwaltungsregeln gelten sollten (und spätestens bei Zweiten können nackte Zeiger auch wieder problematisch sein).

cu André

drakon

asc schrieb:

...

Da bin ich absolut deiner Meinung.Meist liegt ein Performanceeinbruch eh nicht dort, wo man am Anfang erst vermuten würde und es ist schlussendlich viel ineffizienter, wenn du durch vorranige Suche und kopfzerbrechen etwas machst, was schlussendlich eh nicht mehr draufankommt, sondern ein völlig anderer Teil Probleme macht.

LordJaxom

Wer meint, Smartpointer machen "auch nur ein delete", dem sei dieser Artikel ans Herz gelegt:
http://www.boost.org/doc/libs/1_35_0/libs/smart_ptr/sp_techniques.html

Mit Shared Pointern kann man theoretisch z.B. full-featured Connectionpooling implementieren. Da ist es aber wenig hilfreich, wenn man dem Aufrufer die Wahl der Verwaltung/Zerstörung überlässt.

asc schrieb:

Ich verstehe hier eh nicht warum sich die Leute hier wegen Performance und Overhead aufregen. Wozu gibt es Profiler, wozu gibt es Refactoring, und wo ist bitte die Sicherheit bei dem Ganzen.

Wenn du damit micht meinst, ich habe nie das Wort Performance erwähnt oder sonstiges in der Richtung.

Mir gehts nur darum, dass der arme Benutzer der Lib sich nicht extra zusätzlich boost draufmachen muss. Bei einer kleinen Lib fänd ichs ziemlich lästig, aber es hängt auch von der Zielgruppe ab.

Der Entwickler kann das wohl am besten entscheiden. Wenn es aber keine Lib wird und es um ein eigenes Projekt geht, dann spricht rein gar nichts gegen boost