std::auto_ptr vs. smart pointer aus boost::smart_ptr

[volkard]

HumeSikkins schrieb:

kingruedi schrieb:

das hängt von der Situation ab. Generell kann man das nicht beantworten.
...

Wenn ich den OP richtig verstanden habe, geht es hier nicht um "generell" sondern nur um std::auto_ptr vs. boost::smart_ptr.

und genau darüber läßt sich keine generelle aussage treffen. es hängt immer davon ab, was man damit machen will.
als merkregel kann man sagen: je praktischer, desto teurer.
klar könnte man alles mit refcounting smart pointers vollhauen. man bräuchte nie mehr rohe zeiger und auto_ptr auch nicht mehr. aber ob das wirklich ideal ist? ich zweifle daran.
zu konkreten problemen kann man aussagen zu machen versuchen, ob da ein gewisser pointertyp reicht und notwendig ist. reicht er nicht, muß ein dickerer her. ist er nicht notwendig, sollte ein dünnerer her.

[HumeSikkins]

volkard schrieb:

HumeSikkins schrieb:

kingruedi schrieb:

das hängt von der Situation ab. Generell kann man das nicht beantworten.
...

Wenn ich den OP richtig verstanden habe, geht es hier nicht um "generell" sondern nur um std::auto_ptr vs. boost::smart_ptr.

und genau darüber läßt sich keine generelle aussage treffen. es hängt immer davon ab, was man damit machen will.

Wenn man das so sieht, dann darf man überhaupt keine Merkregeln ausgeben und Bücher wie "Effective C++" oder ähnlich wären wertlos. Schließlich gibt es immer Situationen in denen der im Allgemeinen nicht empfohlene Weg genau der Richtige ist.
Ist sehe das allerdings anders. Imo sollte man erstmal gehen lernen, bevor man sich gleich an einen 100m Sprint macht.
Sätze wie: "Im Allgemeinen sollte man std::vector einem built-in-Array vorziehen." "Im Allgemeinen sollte man std::auto_ptr vergessen und stattdessen die SmartPtr von boost einsetzen (es gibt ja nicht nur shared_ptr. Auch scoped_ptr reicht oft genug)." halte ich für durchaus angemessen.

Btw: Wer nicht zumindest weiß wo er den
Colvin-Gibbons-Trick erklärt findet und dass es mindestens drei verschiedene (und inkompatible) std::auto_ptr-Implementationen gibt, der sollte imo std::auto_ptr überhaupt nicht benutzen.

klar könnte man alles mit refcounting smart pointers vollhauen. man bräuchte nie mehr rohe zeiger und auto_ptr auch nicht mehr. aber ob das wirklich ideal ist? ich zweifle daran.

Es ging hier nicht darum alle rohen Zeiger durch refcounted Smart-Pointer zu ersetzen (eine Sache die imo auf Denkfaulheit/Designprobleme hinweist). Es ging um den Verzicht von auto_ptr. Die Dinger sind imo einfach kaputt.
Der Punkt ist RAII und dazu brauche ich keine auto_ptr.

[SideWinder]

volkards neue Revolution hat begonnen

MfG SideWinder

[Gast]

Und meine auch. Ich geh jetzt zum C++ Standard Komitee und setze Garbage Collection durch. Dann brauchen wir auch keine boost-pointer mehr.

[SideWinder]

Bist du von bösen Geistern besessen

MfG SideWinder

[Gast]

Jau, ich bin INFIZIERT.

[volkard]

Optimizer schrieb:

Und meine auch. Ich geh jetzt zum C++ Standard Komitee und setze Garbage Collection durch. Dann brauchen wir auch keine boost-pointer mehr.

genau das hab ich gerade auf http://www.c-plusplus.net/forum/viewtopic.php?t=81610&start=10 vorhergesagt.

[Gast]

achso lol, ich dachte, du hast zuerst das hier gelesen.

[Artchi]

Optimizer schrieb:

Und meine auch. Ich geh jetzt zum C++ Standard Komitee und setze Garbage Collection durch. Dann brauchen wir auch keine boost-pointer mehr.

Brauchst du nicht mehr, macht schon MS für dich: C++/CLI. Ist bald ISO-Standard, wenn alles gut geht. Werden sie nächstes Jahr jedenfalls einreichen.

[operator void]

HumeSikkins schrieb:

• Sources: auto_ptr<T> producesT();

In dem Fall ist ein auto_ptr aber trotz allem sehr praktisch. Denn was einmal in einem shared_ptr ist, kommt nie wieder raus. Einen auto_ptr kann in alles andere zurück-umwandeln, wenn Bedarf besteht. Beispielsweise reicht hier weiterhin ein scoped_ptr als einziger Member:

class BasicFooImpl;

class Foo
{
    boost::scoped_ptr<BasicFooImpl> pimpl;
public:
    ...
};

std::auto_ptr<BasicFooImpl> factory();

Wobei ich aber noch eine Frage hätte. Theoretisch muss für auto_ptr<T> der Typ T wie für alle std-templates vollständig definiert sein, oder?

[Gast]

Artchi schrieb:

Optimizer schrieb:

Und meine auch. Ich geh jetzt zum C++ Standard Komitee und setze Garbage Collection durch. Dann brauchen wir auch keine boost-pointer mehr.

Brauchst du nicht mehr, macht schon MS für dich: C++/CLI. Ist bald ISO-Standard, wenn alles gut geht. Werden sie nächstes Jahr jedenfalls einreichen.

Jop, allerdings möchte ich noch nicht auf das .Net Framework setzen, solange das kein Heinz installiert hat. Dass man irgendwann mal guten Gewissens darauf setzen kann (für die Windows Programmierung), steht nicht in Frage, aber zur Zeit schaut es noch nicht so gut aus.

[SideWinder]

?

Wird einfach mit deiner SW mitgeliefert - DirectX liefern ja auch immer die Spielehersteller und niemals die MS-Download-Page.

MfG SideWinder

[Gast]

Tja, meine Software wird nicht vermarktet (soooo gut ist mein Game dann doch wieder nicht ).
Das Haupthinderniss ist ja IMHO, dass sich das Framework keiner installieren will, bzw. sowieso schon keiner gewillt ist, sich wegen meinem Müll das .Net Framework zu ziehen.

[SideWinder]

Also ich hab dotNET 1.1 installiert, und wenns sein muss installiert es auch jeder. Wäre ja wie wenn sich die Leute dafür entscheiden für Doom3 kein DirectX9 zu installieren - "Nein das will ich nicht, soll der Depp die GDI benützen :p"

MfG SideWinder

[Gast]

Ja so läuft's aber seltsamerweise. Jedes nicht .Net Drecksprogramm bringt seine 20 dll's mit, die in der Registry eingetragen werden und ins Systemverzeichnis kopiert werden, wo gleich mal andere Versionen dieser dll kommentarlos ersetzt werden, bis gar nichts mehr läuft, aber das wird toleriert, kommt ja so ein schöner Setup-Bildschirm, der wird schon alles richtig machen.
Aber wenns darum geht, das .Net Framework zu installieren, was auch nur ne Sammlung von Bibliotheken und Diensten ist (und so nebenbei die zukünftige System API), wird rumgememmt, "ne des spioniert mir alles aus", "Microsoft will die Weltherrschaft", was auch immer.

Mei, wir leben in ner Welt, wo lauter DAUs keine Ahnung haben was gut ist und im selben Moment, wie sie sich weigern, irgendnen Dreck wieder installieren, der alles im System verstellt.
Kann man nicht ändern. Naja wenigstens hab ich's jetzt endgültig geschafft, den Thread Off-Topic werden zu lassen. Auch was wert.

[Artchi]

Was hat den C++/CLI mit Windows zu tun? Klar, MS selbst supportet nur Windows. Aber .NET gibts auch von Novel, weil .NET (die Basis) halt auch schon ISO-Standard ist. C++/CLI ist halt eine weitere Sprache und ich möchte behaupten, wir C++-Fans können MS dafür nur danken das sie C++ einen so hohen Stellenwert geben.

.NET ist unter Windows mit zwei Klicks installiert. Unter Linux und Unix von Novell wird es bestimmt auch so sein? Habe Mono noch nie installiert, aber dürfte doch auch nicht so schwer sein?

[HumeSikkins]

operator void schrieb:

Wobei ich aber noch eine Frage hätte. Theoretisch muss für auto_ptr<T> der Typ T wie für alle std-templates vollständig definiert sein, oder?

Nicht nur theoretisch. Du brauchst die vollständige Definition von T da sonst der Destruktor von std::auto_ptr undefiniertes Verhalten hat.

@Optimizer
Ein GC hat mit dem Thema nichts zu tun. Ein GC hilft dir herzlich wenig, wenn es dir um deterministische Resourcenfreigabe geht.

Mal lesen: http://blogs.msdn.com/hsutter/

Ansonsten wäre es schön, wenn du deine Hass-Tiraden auf einen anderen Thread (am Besten im OT-Forum) konzentrieren könntest.

[operator void]

HumeSikkins schrieb:

Nicht nur theoretisch. Du brauchst die vollständige Definition von T da sonst der Destruktor von std::auto_ptr undefiniertes Verhalten hat.

Stimmt. Naja, mir wäre es lieber, das Aufrufen von factory() würde dann in Dateien, in denen der Destruktur nicht definiert ist, zu einem Compilerfehler führen (boost::safe_delete machts vor ;)) - das würde (nochmal in meinem konkreten Fall) die Compilezeiten minimal reduzieren, aber da gibt's wirklich Schlimmeres

[Gast]

HumeSikkins schrieb:

@Optimizer
Ein GC hat mit dem Thema nichts zu tun. Ein GC hilft dir herzlich wenig, wenn es dir um deterministische Resourcenfreigabe geht.

"Herzlich wenig" heißt nicht "gar nicht". "Nichts damit zu tun", halte ich zumindest für eine kleine Übertreibung. Ein GC kann mir zumindest etwas bieten, was mir kein C++ Destruktor und keine Referenzzählung bieten kann: Eine einigermaßen hohe Wahrscheinlichkeit, dass irgendwann (vielleicht netterweise in absehbarer Zeit) die Resourcen freigegeben werden, über den Objekt-finalizer. Achtung: Ich halte das nicht für eine gute Idee oder gar eine Erleichterung. Es ist lediglich eine zusätzliche Sicherheit, die aber schon mal besser ist als gar nichts.

Amsonsten schaut es überall gleich schlecht aus: Ein Freigeben wichtiger Resourcen zu einem geeigneten Zeitpunk muss der Programmierer verantworten. Ich kann mir keinen Fall vorstellen, wo ich genau für die Dauer eines Scopes eine Socket-Verbindung brauche.
Referenzzählung bringt bei Objekten auf dem Heap IMHO genauso wenig?

Zumindest bei trivialen Resourcen wie Arbeitsspeicher tut ein GC seinen Dienst, und das zuverlässiger als seine Kollegen. Referenzzählung funktioniert spätestens bei zirkulären Abhängigkeiten (die auch über Umwege auftreten können) nicht mehr.
Das denke ich zumindest darüber. Ich lasse mich gerne überzeugen, wenn du mir irgendwie beweisen kannst, dass es dir mit den boost-Pointern gelingt, einen garantiert stattfindenden und rechtzeitigen Aufruf eines Destruktors, von einem Objekt mit unbestimmter Lebenszeit sicherzustellen.
Diese Gedanken sind jetzt ausschließlich auf Sicherheitsaspekten gebaut.

Ansonsten wäre es schön, wenn du deine Hass-Tiraden auf einen anderen Thread (am Besten im OT-Forum) konzentrieren könntest.

So schlimm war es jetzt doch nicht, oder? Ich habe meine Meinung, wie ich denke, einigermaßen frei von negativen Emotionen rübergebracht. Gewiss, sarkastisch war es schon. Aber dies möge man mir bitte verzeihen, da es eh an niemanden persönlich gerichtet war.
btw., die Aussagen (oder Standpunkte), die ich kritisiert habe, existieren wirklich (auch in diesem Forum) und es ist mir unbegreiflich?
"zum Glück ist bei XP das .Net Framework nicht schon dabei" - oh man. Hoffentlich kriegen solche Leute ihr Longhorn dann ohne Framework, also praktisch ohne Systemapi.

[volkard]

Optimizer schrieb:

Zumindest bei trivialen Resourcen wie Arbeitsspeicher tut ein GC seinen Dienst, und das zuverlässiger als seine Kollegen.

hä?
ich hab keine speicherlöcher. so gar nicht. der gc brächte mir null sicherheit. nur den komfort, was nicht machen zu müssen, was mir keine belastung darstellt.