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

[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.

[Gast]

Gut, dafür gibt es ja auch Mittel und Wege. Ich habe ja auch keine Memory Leaks und kann das auch sicherstellen. Vielleicht hätte ich schreiben sollen "automatisch sicherer", obwohl "sicherer" bestimmt nicht falsch ist.
Leaks sind ja auch nicht die einzige Gefahr von manueller Speicherverwaltung. Ist mir ehrlich gesagt schon ab und zu mal passiert, dass ich Objekte gelöscht hab, die woanders noch referenziert wurden. Da setz ich mich dann hin und viiiieeel Zeit geht drauf, bis mir ein gutes System eingefallen ist, wie und wann ich den Speicher am besten freigebe.

[Shade Of Mine]

Optimizer schrieb:

Da setz ich mich dann hin und viiiieeel Zeit geht drauf, bis mir ein gutes System eingefallen ist, wie und wann ich den Speicher am besten freigebe.

In diesen ganz seltenen Situationen kann man ja Refcounting machen.
Und nur deshalb (weil man uU einmal in so eine situation kommen koennte (mir ist dies noch nicht passiert)) einen GC fordern? naja...

Erklaer mal lieber warum man in C++ einen GC braucht? Bisher sind alle Argumente von dir abgeschmettert worden faellt noch etwas besseres ein?

[Gast]

Refcounting ist keine Garantie für gar nichts (siehe oben). btw, ich bin nicht der Meinung, dass man für C++ einen GC "braucht". "Brauchen" tut man sowieso überhaupt keinen...
Oder ich würde zumindest für C++ keinen wollen. Die Diskussion war auch ursprünglich überhaupt nicht auf C++ bezogen, sondern auf Arten der Resourcenverwaltung allgemein.
Ich bin auch wie Hume der Meinung, dass wenn es sich nicht gerade um triviale Resourcen wie RAM handelt, ein GC nicht viel bringt (außer eine Rettung in letzter Not, über finalizer, guter Stil ist das sicher nicht).
Das Eigentliche, was mich ein bisschen verwirrt ist eine anscheinend vorherrschende generelle Abneigung gegen Laufzeitumgebungen (insbesondere auch unter den Endkunden, siehe ursprüngliche Diskussion über Verbreitung des .Net Frameworks). Für C++ will ich gar keine haben, managed C++ gefällt mir auch kein Stück. Aber darum gings ja auch nicht wirklich.

Bisher sind alle Argumente von dir abgeschmettert worden

Meinst du meine Argumente für garbage collection? wo sind die abgeschmettert worden? Refcounting ist kein Ersatz, scope-Destruktoren schon gleich gar nicht. Die einzigen Gegenargumente, die mir aufgefallen sind, waren, man hätte ja dies und das, aber ich habe glaub ich ausreichend begründet, warum dies und das kein Ersatz ist.

[volkard]

Optimizer schrieb:

die mir aufgefallen sind, waren, man hätte ja dies und das, aber ich habe glaub ich ausreichend begründet, warum dies und das kein Ersatz ist.

mir ist als begründung nur aufgefallen "aber manche machen dauernd löcher und der gc würde manchmal per finalizer mir was retten".
die meisten können nicht mal c++, sollten wir nicht besser basic nehmen, weil mehr leute es können?
falls wir uns drauf einigen können, nicht die leute, die c++ nicht können, zum maß zuz nehmen, warum nicht gleich auch drauf einigen, nicht die leute zu nehmen, die c++ kaum können?

[Gast]

Ok, einigen wir uns darauf, dass kein Programmierer jemals wieder einen Fehler machen soll.

mir ist als begründung nur aufgefallen "aber manche machen dauernd löcher und der gc würde manchmal per finalizer mir was retten".

Sollte eher so gemeint sein: "Was man nicht selber machen muss, kann man auch nicht falsch machen".

[Shade Of Mine]

Optimizer schrieb:

"Was man nicht selber machen muss, kann man auch nicht falsch machen".

Und genau deshalb, hat man RAII.

Da muss man nichtmehr freigeben, weil das automatisch geschieht.

OK, man muss sich merken, dass man RAII verwenden soll - aber dass sollte gerade noch gehen.

[Gast]

Was ist RAII? Das beim Verlassen des scopes der Destruktor aufgerufen wird, oder?
Das kann ich fast nie brauchen. Wenn ich ne Socket-Verbindung aufbaue, dann brauch ich die halt so lange, wie ich sie brauche. Wenn es nicht gerade ein Chat-Client simpelster Art ist, hilft dir das doch kaum. Ich weiss nicht, was du für Erfahrungen gemacht hast, aber bei den meisten meiner Objekte, die relevante Resourcen verwalten, ist die Lebenszeit nicht absehbar -> auf den Heap -> ans delete denken müssen.
Ein GC löst das Problem natürlich genauso wenig, zumindest rechtzeitig gibt der das bestimmt auch nicht frei. Ich sehe für realistisches Anwendungsfälle keinen Weg, da rum zu kommen, dass der Programmierer das selber in die Hand nehmen muss.