D Programmierung

bedeutet das das ich ohne
gc_init(), gc_term() normales new delete verhalten habe und der einzige weg den gc zu umgehen nicht c malloc ist?

bin ich zu bloed die doku zu lesen oder gibts da deffizite?
(moecht nicht wissen wie viele leute es gibt die glauben gc zu haben ihn aber doch nicht haben weil gc_init/term in main fehlt, wenn es sich tatsaechlich so verhaelt das nur so der gc aktiviert wird)

Keine Ahnung. Ich vermute mal dass standardmäßig eine andere main()-Funktion hinzufügt, die dann die nötigen initialisierungen vornimmt. Bei Windows-Programmen heißt das die Start-Funktion WinMain und der Compiler weiß es anscheinend nicht, deswegen muss man die initiierung selbst vornehmen.
Andererseits ich vermute mal dass es Probleme mit Resourcen geben kann, wenn man den gc ausschaltet (innerhalb von main()) bzw. diesen nicht einschaltet (innerhalb von WinMain()). Der Grund könnte in fremden libs (vielleich auch in Phobos) sein, die sich darauf verlassen, dass der GC ihren Speicher freigibt.

Ich habe im Moment keine Zeit und keinen Bock mich damit auseinanderzusetzen. Vielleich in paar Monaten, nach dem Abi...

Benutze die Suche, vielleicht findest du irgendwelche Hinweise. http://www.google.com/search?domains=www.digitalmars.com&q=disable+gc&sitesearch=www.digitalmars.com

daHa schrieb:

findest du es eigentlich nicht bedenklich das du features als grosartig anpreist von denen du nicht mal weisst wie sie tatseachlich funktionieren?

Nein, denn ich weiß ja, wie es funktioniert. Optionale Garbage Collection, mir sagt der Begriff "optional" was und "Garbage Collection" ist mir auch kein Fremdwort. Wie ich das an- und ausschalte muss ich gar nicht wissen, so lange ich nicht selber in D programmiere.
Warum kann ich nicht sagen, dass ich optionale gc gut finde, wenn ich damit schon Erfahrung gemacht habe?

ich finde das ist halt eine gefahr wenn man blind dem was ich als marketing blabla bezeichne folgt, sich nicht ueber die hintergruende informiert und das als das bedenkenlos weiterempfiehlt / selbst verwendet.

Ja das ist ja zur Zeit ganz schön bequem alles nur als Marketing-Geschwafel hinzustellen. Funktioniert aber bei mir nicht, weil ich kaum mal eine Sekunde selber etwas nicht hinterfrage. Außerdem sehe ich auch nicht die große Marktmacht hinter D, die deinen kundigen Augen aber scheinbar nicht entgangen ist. :p

volkard

Optimizer schrieb:

Das Prinzip "wer besitzt dieses Objekt" ist dann eher weniger wichtig, jeder benutzt es einfach so lange, bis er es nicht mehr braucht. Ich denke also, dass ein GC die Modularität in einem Programm schon erhöhen kann, was insgesamt zu einem besseren Design beiträgt.

vielleicht. das beispiel mit dem spiel hat es mir jedenfalls nicht gezeigt.

Umgekehrt würde mich mal genauer interessieren, wie ihr das meint, dass man mit einem GC Designfehler vertuschen kann.

beim spiel haben die einheiten keinen besitzer. deswegen nehme ich einen gc. ich finde das ein tolles design. nach 2 jahren harter arbeit möchte ich dann mal "spielstand speichern" und "spielstand laden" anbieten. zum speichern hätte ich ja sooo gerne pro spieler eine simple liste aller einheiten. ohne die gehe ich ja kaputt beim versuch, alle einheiten aufzugabeln. und voilá, da ist ja auch der sinnvolle besitzer. und voilá(II), das killen geht jetzt ganz harmonisch. wobei dann doch zu überlegen ist, ob refcounting der tolle trick ist, oder ob verzeigerungen wie "MEIN auftrag ist, zu DIR zu laufen" vielleicht bidirektional sein sollten und wenn das ziel stirbt, der hinläufer es von alleine (durch das zerstören seines endpunkts eines automatik-bei-löschen-bescheidsag-zeigerpaares) erfährt. dann würde killen der einheit auch immer löschen des objekts bedeuten, was dem programmieren ganz gut tut. oder halt nur als tot markieren und mit refcounting und tote, auf die keiner mehr zeigt, verschwinden. fagen über fragen, nur würde mir bei so einem spiel niemals ein gc einfallen.

was ist der Unterschied zwischen Refcounting (RC) und einem GC? In beiden Fällen muss man sich ja um die Freigabe nicht kümmern. Nur dass man RC meistens selbst schreiben muss. Was zu dem Fehleranfällig ist.

Ok, ein Grund für RC wäre, dass man nur bestimmte Objekte so (mit RC) verwalten kann und nicht alle, wie bei einem GC der Fall wäre. Jedoch (1) zwingt D den GC nicht auf, (2) ich vermute mal, dass hinter GC auch nichts anderes als RC steht. Oder habe ich falsch verstanden was du sagen wolltest, dass Du also auch gegen RC bist?

Und selbst wenn das wäre, was wäre der Nachteil davon ein Feature in der Sprache mehr zu haben, wenn es einem nicht aufgezwungen wird? Ich sehe da nur Vorteile: Man muss sich nur auf das Problem konzentrieren und solche Sachen, wie Speicherfreigaben, treten in den Hintergrund. Bzw. werden nur dann verlangt, wenn es wirklich notwendig ist.

Auch die Übersichtlichkeit sollte man nicht vernachlässigen. Z.b. bei einem foreach. D verbietet ja einem nicht die for-Schleife zu verwenden.

Das ganze lässt sich natürlich auch auf andere Sprachen übertragen.

daHa

adxin schrieb:

was ist der Unterschied zwischen Refcounting (RC) und einem GC? In beiden Fällen muss man sich ja um die Freigabe nicht kümmern. Nur dass man RC meistens selbst schreiben muss. Was zu dem Fehleranfällig ist.

einer der hpt unterschiede wird wohl sein das bei RC die vernichtung, und der im d'tor stehende code, sofort ausgefuehrt wird.

und ich brauch nicht dem umweg ueber Release meothoden gehen, die dann sehr oft vergessen werden bzw gar nicht eingeprog werden weil den entwicklern selbst nicht klar ist wer das objekt als letzter benutzt.

ausserdem wird ja nicht alles was per new erzeugt wird gerefcounted, zumindest bei mir nicht.
wenns klare verantwortlichkeiten gibt wer was wann erzeugt und vernichtet, und das ist doch recht haeufig der fall, dann is refcount sinnlos.

refcount macht fuer mich zb dann einen sinn wenn ich objecte hab die sich zeiger teilen, zb durch nicht privat machen des copy c'tor usw.

das waer dann der zweite unterschied, ich hab die kontrolle (und verantwortung) wann was passiert, auch das kann mehr erwuenscht als nicht erwuenscht sein.

und, mich stoehrts nicht das ich mich selbst um die dinge kuemmern muss.
speichelecks lassen sich zb mit valgrind festellen, und durch die notwendigkeit eben mich um sowas zu kuemmern ueberleg ich mir auch immer etwas (mehr) ueber das design der anwendung. wer fuer was verantwortlich ist, wer wann was erzeugt/zerstoert, ein verzicht dies durchzudenken kann tatsaechlich zu einem anderen design fuehren, das bsp von volkard im nachhinein ein save/load einzubauen wenn ich objekte wild erzeug ohne das es verantwortliche gibt weil gc alles regelt demonstriert es ja perfekt.

allen begeisterten gc benutzer die nicht von haus aus sagen der gc erledigt alles und sich trotzdem ueber ein paar notwedige design entscheidungen gedanken machen moechte ich hier nix unterstellen, nur, solche leute hab ich viel weniger kennengelernt als solche die einen etwas anderen stil haben.

und auch gar nix gegen gc, ist halt immer eine technologieentscheidung, und die treff ich nicht(nur teilweise ) aus politischen oder religioesen gruenden sondern eben aufgabenbezogen.

der gc ist nicht das killerargument warum man mit einer sprache schnellere ergebnisse erzielt als mit einer anderen.
und ein gc ist auch nicht das allheilmittel gegen diverse probleme.
leider wirds aber oft so dargestellt.
nur, der gc ist nicht das killerargument warum eine sprache besser ist als eine andere.

leider ist das halt exterm so verwendet worden, voallem wie dot net eingefuehrt worden ist.
was da von heut auf morgen schleht geredet wurde mit schein oder vereinfachten argumenten, nunja, marketinggeplapper bezeichne ich das.
dumm nur, wenn das entscheidungstraegern eingetrichtert wird die das frohelich wiederhohlen und glauben und dann erklaehren wie einfach heutzutag das programmieren ist.
was bloedsinn ist, weil die meiste zeit kostet mich eindeutig nicht das speichermanagement.

ich hoff ich hab halbwegs verstaendlich ausgedreuckt was ich mein, mir fehlt ein bissl die zeit (nein, hab kein speicherleck :-), und roman will ich auch keinen schreiben.

daHa schrieb:

wer fuer was verantwortlich ist, wer wann was erzeugt/zerstoert, ein verzicht dies durchzudenken kann tatsaechlich zu einem anderen design fuehren, das bsp von volkard im nachhinein ein save/load einzubauen wenn ich objekte wild erzeug ohne das es verantwortliche gibt weil gc alles regelt demonstriert es ja perfekt.

Das spricht nicht gegen GC, sondern gegen ein unüberdachtes Design.
Außerdem, ein Programm das in Asm geschrieben wird hat auch einen anderen Design als es z.B. in VB hätte.

der gc ist nicht das killerargument warum man mit einer sprache schnellere ergebnisse erzielt als mit einer anderen.
und ein gc ist auch nicht das allheilmittel gegen diverse probleme.
leider wirds aber oft so dargestellt.
nur, der gc ist nicht das killerargument warum eine sprache besser ist als eine andere.

Das würde jeder vernünftige Mensch auch bestätigen. Auch dass das Vorhandensein eines GC eine Programmiersprache nicht zum letzten Müll macht.

daHa

man darf ja auch folgendes nicht vergessen.

in c++ gibts ja auch referenzen.

und pointer verwendet man, bzw zumindest ich auf jeden fall, nur an stellen wo sie unerlaesslich sind., bzw in dem fall un an der stelle wo einen vorteil gegenueber refs gegeben ist.

dh an stellen, wo ich den gc sowieso umgehen bzw deaktivieren muesste wenn ich die selbe funktionalitaet wie mit c++ haben moechte.

somit tu ich mir relativ schwer damit mir vorzustellen wozu ich einen gc brauchen koennte, bzw wo der so enorme vorteil liegen soll.

Helium

Der einzige Nachteil von D ist IMO dass es (noch) keine Standard-Container gibt. Und statt selber welche zu schreiben, bin ich bei C++ geblieben.

DTL (noch nicht offizieller Bestandteil und noch in der Arbeite)

Ich würde vermuten (ohne es zu wissen), dass man in D wie bei C++/CLI eine Unterscheidung zwischen new und gcnew kennt.

Nein.

beim spiel haben die einheiten keinen besitzer. deswegen nehme ich einen gc. ich finde das ein tolles design. nach 2 jahren harter arbeit möchte ich dann mal "spielstand speichern" und "spielstand laden" anbieten. zum speichern hätte ich ja sooo gerne pro spieler eine simple liste aller einheiten. ohne die gehe ich ja kaputt beim versuch, alle einheiten aufzugabeln. und voilá, da ist ja auch der sinnvolle besitzer. und voilá(II), das killen geht jetzt ganz harmonisch. wobei dann doch zu überlegen ist, ob refcounting der tolle trick ist, oder <snip>

Ich muss nochmehr nachdenken? Da wäre ja der GC doch cooler. Was ist so toll daran, dass ich mir noch ein paar Stunden lang Gedanken machen muss, wie wer wann was warum aufräumt?
Das Argument hat mich jetzt echt nicht überzeugt.

was ist der Unterschied zwischen Refcounting (RC) und einem GC?

Das sollte man dann aber schon wissen, wenn man für oder gegen einen GC argumentieren will.

RC kommt nicht mit zirkulären Referenzen klar.

Jester

Helium schrieb:

Ich muss nochmehr nachdenken? Da wäre ja der GC doch cooler. Was ist so toll daran, dass ich mir noch ein paar Stunden lang Gedanken machen muss, wie wer wann was warum aufräumt?
Das Argument hat mich jetzt echt nicht überzeugt.

Du mußt es ja auch lesen.

Du brauchst eine Liste mit allen Einheiten, sozusagen die Einheitenverwaltung. Sonst kannste nicht abspeichern. Diese Datenstruktur mußt Du so oder so aufbauen. Auch der GC nimmt Dir das nicht ab.

Volkard sagt, daß diese Datenstruktur dann auch gleich die Freigabe mitverwalten kann. Damit haste nen eindeutigen Besitzer für die Einheiten und weißt wo das delete hin muß. Damit fällt dieses Argument für den GC deutlich schwächer aus.

Finde ich nicht. Volkard muss immer noch wissen, wann er die Einheit deleted und das kann er nur über Referenzzählung oder Graphenalgorithmen erreichen.

Graphenalgorithmen sind mit Sicherheit das, was Helium angesprochen hat, nämlich krasser Mehraufwand mit insgesamt null Gewinn. Der GC hat die notwendigen Graphenalgorithmen mit eingebaut, wahrscheinlich besser, als wenn ich es selber mache.

Referenzzählung ist in jedem Fall ein bisschen ugly. Du bist auf nen bestimmten Pointertyp, z.B. shared_ptr festgelegt, wenn du etwas anderes verwendest, um etwas mit der Einheit zu machen brauchst du zumindest wohldefinierte Situationen, wo die Einheit keinesfalls gelöscht wird. Das wird in Multithreaded-Umgebungen dann noch schwieriger. Ich stelle es mir auch langsamer vor. Ich kann u.U. viele lokale Zeiger zu einer Einheit machen, die alle nicht lange leben, weil ich z.B. nur kurz die Fortbewegung berechne. Jede Zuweisung ist teurer als wenn es ein normaler Pointer wäre.

In jedem Fall sehe ich aber keinen Gewinn durch den Verzicht auf GC. Ich sehe nur mehr Aufwand, mehr Nachdenken. Möglicherweise schlechteres Laufzeitverhalten out-of-the-box, vielleicht mit viel zusätzlichem Aufwand (eigene Allokatoren) geringfügig besseres Laufzeitverhalten. Dass es ohne GC nicht geht, behauptet ja keiner.

Helium

Jester schrieb:

Helium schrieb:

Ich muss nochmehr nachdenken? Da wäre ja der GC doch cooler. Was ist so toll daran, dass ich mir noch ein paar Stunden lang Gedanken machen muss, wie wer wann was warum aufräumt?
Das Argument hat mich jetzt echt nicht überzeugt.

Du mußt es ja auch lesen.

Du brauchst eine Liste mit allen Einheiten, sozusagen die Einheitenverwaltung. Sonst kannste nicht abspeichern. Diese Datenstruktur mußt Du so oder so aufbauen. Auch der GC nimmt Dir das nicht ab.

Volkard sagt, daß diese Datenstruktur dann auch gleich die Freigabe mitverwalten kann. Damit haste nen eindeutigen Besitzer für die Einheiten und weißt wo das delete hin muß. Damit fällt dieses Argument für den GC deutlich schwächer aus.

Mein Zitat endet mit "wobei dann doch zu überlegen ist, ob refcounting der tolle trick ist, oder <snip>". Alles, was davor steht muss ich mir Überlegen, egal ob GC oder nicht (sprich die Geschichte mit der Collection). Alles danach muss ich mir nur überlegen, wenn ich keinen GC habe.

Ansonsten: Siehe Optimizer's post.

daHa

das einheitenbsp ist unbrauchbar.
spielstand speichern is ja schon ein bsp.

ein weiteres:
spaetestens wenn man alles seine einheiten in formation aufstellen will muss ein verwalter her.

und wenn diese formation gehalten werden muss sind konsturkte ala, wenn mein nachbar gekillt ist, schliess die formation mit den nachbarn meines schon gekillten nachbarn eher etwas muehsam zu implementieren.

es fehlt also noch immer ein bsp wo die ueberlegenheit des gc, ausser in verschleiern von programmierfehlern, demonstriert wird.

daHa schrieb:

das einheitenbsp ist unbrauchbar.
spielstand speichern is ja schon ein bsp.

Das hat nur gezeigt, dass die Einheiten trotzdem noch in irgendeiner Datenstruktur gesammelt werden müssen. Dem hat keiner widersprochen, ich sehe auch kein krasses Problem darin und was jetzt genauer noch damit gezeigt werden soll, ist mir momentan ein Rätsel. Und inwiefern das Beispiel "unbrauchbar" ist, wurde bis jetzt weder genauer ausgeführt noch gar bewiesen.

es fehlt also noch immer ein bsp wo die ueberlegenheit des gc, ausser in verschleiern von programmierfehlern, demonstriert wird.

Wurde bereits genannt. Ich muss mir Gedanken machen. Ich muss beispielsweise nen shared_ptr verwenden. Ein shared_ptr ist einem GC in Punkto Zuverlässigkeit, Performance und Komfort in den meisten Fällen unterlegen. q.e.d.
Oder ich kann Graphenalgorithmen verwenden. Das kann der GC mit seinen Generationen und dirty-writes besser als jeder von uns (außer volkard, aber ihm wäre es vielleicht zu viel Aufwand), q.e.d.

Im übrigen glaube ich nicht, dass du beurteilen kannst, wann ich Programmierfehler mache. Es wurde noch nicht mal bewiesen (nur behauptet), dass ein GC zum Verschleiern von Programmierfehlern benutzt werden kann (es wurde sogar behauptet, dass dies oft der Fall sei). Der Beweis, dass es immer einen "Besitzer" geben muss, damit das Design sauber ist (was bei dem Einheiten-Beispiel übrigens der Spieler wäre, also nicht mal ein Argument), steht auch noch aus. Ihr überzeugt mich nicht.

Und nochmal, es ging darum, was an optionaler gc schlecht ist. Man kann argumentieren, dass man es in D nur einfach an- oder ausschalten kann sei schlecht. Dem stimme ich zu, das ist jedoch wenn dann ein Problem von D.
So wie in C++/CLI ist es godlike (ohne Beweis, persönliche Meinung, muss nicht übernommen werden).

daHa

optimizer, bitte

ich hab weder dir noch sonst irgendjemand hier direkt unterstellt das er schlecht programmiert bzw einen schlechten stil pflegt.

es tut mir leid das ich so schlampig forumliert hab das du dich betroffen fuehlst, duerfte mein fehler sein.

ich hab nur darum ersucht ein beispiel aus der praxis zu bringen wo ein gc nachweislich vorteile bringt, und mir erlaubt darauf hinzuweisen das das gebrachte bsp etwas suboptimal ist.

ich hab die frage ernst gemeint.

wenn du meine postings gelesen hast, dann hast du vielleicht auch bermerkt das ich mir schwer tu festzustellen wo der vorteil eines gc liegt.
die grunde dafuer hab ich in einem post oben erwaehnt.

ich hab naemlich bis jetz kein bsp bekommen wo es um etwas anderes geht als dem programmierer das aufraeumen des speichers abzunehem, was ich nicht als vorteil empfinde.

wo die vorteile bei der programmausfuehrung liegen ist mir bis jetzt einfach nicht klar, ich kanns mir auch nicht vorstellen, desshalb hab ich um ein bsp ersucht.

volkard

Optimizer schrieb:

Finde ich nicht. Volkard muss immer noch wissen, wann er die Einheit deleted und das kann er nur über Referenzzählung oder Graphenalgorithmen erreichen.

einheiten werden gelöscht, wenn sie tot sind? zum beispiel sei gesichert, daß pro runde (der hauptschleife) jede einheit einmal mit überlegen drankommt und daß ein dauerbefehl wie "transporter eskortieren" jedesmal prüft, ob der transporter noch lebt, und wenn nicht, sich selbst (also den befehl) löscht. dann könnte man leicht nach jeder runde alle leichen löschen. ohne refcounting und graphenalgos. und mir kommt gar kein gedanke, wozu ich nen gc nehmen sollte. was war noch mal der genaue grund? daß ich irgendwas weniger überlegen muß?

ich überlege folgendes: must, daß mit dem löschen der leichen ist mit zu seltsam, zu spät. die existenz von leichen ist schlimm, ein objekt, das nicht mehr existiert, soll auch im programm nicht mehr herumgeistern.

das andere, die bidirektionalen verknüpfungen, wo der keuzer automatisch bescheid bekommt, wenn der transporter untergegangen ist, braucht natürlich sofort zuschlagende destruktoren. ich muss mir so ne klasse für bidirektionale zeiger basteln, ganz egal ob mit oder ohne gc. dadurch brauche ich nicht mehr mir gedanken zu machen, wer alles bescheid bekommen muß, wenn ich strebe. und ich brauche nicht vor jeder zeigerbenutzung gucken, ob das objekt dahinter noch lebt. so, jetzt gibt es keine wilden zeiger mehr (ohne gc typischerweise zeiger auf gelöschten speicher, mit gc typischerweise zeiger auf als tot markierte einheiten) und keinen bedarf für einen gc.

In jedem Fall sehe ich aber keinen Gewinn durch den Verzicht auf GC.

ich sehe keinen gwinn duch den gc.
das argument, daß man unbedingt etwas nehmen sollte, das kostenlos und optional ist, kann ich nicht nachvollziehen. warum sollte ich zu meinem auto ne kostenlose optionale (also ich habe die wahl, ob ich sie dann benutze) atombombe einbauen lassen, falls mir das einer anbietet?

Ich sehe nur mehr Aufwand, mehr Nachdenken.

mehr nachdenken in welchem rahmen denn? wenn man eh mehrere tage über das design nachdenken muß, um einen ersten entwurf zu haben, und nochmal wochenlang experimentieren muss (und ich glaube kaum, daß du für so ein spiel dir deutlich weniger zeit nehmen solltest), dann darf da auch ein wenig nachdenken über die speicherfreigabe drin sein. und dieses nachdenken jetzt in minuten zu messen und anzuklagen, zeigt nur die halbe wahrheit. mit gc dahinter komme ich zu anderen problemen, nämlich verzögerten destrukor-aufrufen, die mir mehr nachdenken bereiten oder die besonders eleganze lösungen erst gar nicht zulassen, so daß ich mit gc länger nachdenken muss.

Helium

volkard schrieb:

mit gc dahinter komme ich zu anderen problemen, nämlich verzögerten destrukor-aufrufen, die mir mehr nachdenken bereiten oder die besonders eleganze lösungen erst gar nicht zulassen, so daß ich mit gc länger nachdenken muss.

Der Thread hat doch immernoch ein wening D-Hintergrund, oder? Dort gibt es trotz GC sofort zuschlagende Destruktoren ("auto"-Klassen).

volkard schrieb:

zum beispiel sei gesichert, daß pro runde (der hauptschleife) jede einheit einmal mit überlegen drankommt und daß ein dauerbefehl wie "transporter eskortieren" jedesmal prüft, ob der transporter noch lebt, und wenn nicht, sich selbst (also den befehl) löscht.

Und alle eingereihten Befehle ebenfalls ständig überprüft. Und ich kann die Einheit nie schlafen legen, wenn sie z.B. in einem Gebäude ist. Sondern muss auch in solchen Situationen alle eingereihten Befehle auf Gültigkeit prüfen. Ich finde sowas nervig. Du findest das gutes Design, ich empfinde das aber eher als eine Einschränkung in meinen Design-Möglichkeiten, denn jetzt bin ich schonmal darauf festgelegt, in jeder Runde alle Befehle zu validieren.

Zunehmend wird es auch wichtiger, die 64 Kerne zukünftiger Prozessoren auszunutzen. Wenn alle Threads ununterbrochen allokieren und Zeiger verbiegen können wie sie wollen, halte ich das für einen Vorteil. Der GC macht natürlich irgendwann einen harten Break, der dann 64fach wehtut, den macht er aber nicht oft. Demgegenüber musst du bei anderen Systemen vielleicht viel mehr synchronisieren.

das argument, daß man unbedingt etwas nehmen sollte, das kostenlos und optional ist, kann ich nicht nachvollziehen. warum sollte ich zu meinem auto ne kostenlose optionale (also ich habe die wahl, ob ich sie dann benutze) atombombe einbauen lassen, falls mir das einer anbietet?

Als echter C++ler musst du sie (sowohl GC als auch die A-Bombe) einbauen. Du hast ja auch Überladen von '&&' und ',', warum keine Atombombe? Bei keinem Feature wird gegeizt, egal wie zeifelhaft der Sinn ist. Warum ausgerechnet bei diesem?

mehr nachdenken in welchem rahmen denn? wenn man eh mehrere tage über das design nachdenken muß, um einen ersten entwurf zu haben, und nochmal wochenlang experimentieren muss (und ich glaube kaum, daß du für so ein spiel dir deutlich weniger zeit nehmen solltest), dann darf da auch ein wenig nachdenken über die speicherfreigabe drin sein.

Gut, Argument. Das Nachdenken wäre eigentlich nicht so schlimm, das habe ich auch mit GC. Ich kann auch nen OutOfMemory kriegen, weil ich einfach aus meiner Liste die gestorbenen Einheiten vergessen habe, auszutragen. Da muss ich nen Tool anwerfen, was mir den Heap-Status anzeigt, dann seh ich den Fehler hoffentlich bald.

Aber wenn ohne GC halt doch mal ein anderer Fehler in der Speicherverwaltung ist (z.B. ein fehlgeleiteter Zeiger), hast du wirklich Freude beim debuggen, was ich nicht habe. Und beim debuggen geht bestimmt mehr Zeit drauf als beim Design.

mit gc dahinter komme ich zu anderen problemen, nämlich verzögerten destrukor-aufrufen, die mir mehr nachdenken bereiten oder die besonders eleganze lösungen erst gar nicht zulassen, so daß ich mit gc länger nachdenken muss.

Am meisten managed man doch immer die Resource "Speicher". Wenn jede Einheit eine Socket-Verbindung hält, brauche ich selbstverständlich ein anständiges System mit deterministischer Destruktion. Wenn das nicht der Fall ist, ist die verzögerte Destruktion aber eher ein Vorteil. Außerdem verstehe ich nicht, welche elegante Lösung ein GC nicht zulassen würde... ein GC tut ja schließlich meinen Objekten nichts, wenn ich sie referenziere, verhindert also auch keine deterministische Destruktion.

kartoffelsack

Was alle am for_each so toll finden, versteh ich net. Habs mal ein mittelgroßes Ein-Mann-Projekt lang versucht überall einzusetzen, wo ichs brauche (zugegeben die C++-Variante) --> an zwei Stellen. Ich hab echt extrem selten die Anforderung irgendwas mit ALLEN Objekten eines Containers zu tun. Sehr oft hingegen muss ich entscheiden ob ein Objekt noch in dem Container zu bleiben hat oder nicht. Und da komm ich um ne klassische Schleife net rum.

Seit ich mal tagelang nach Fehlern wegen zyklischer Referenzierung gesucht hab, bin ich von der Gleichwertigkeit von smartpointern zu ner GC auch nicht mehr überzeugt. Allerdings ist das Ref-Counting in C++ halt nur ein Nebenprodukt der automatischen Dtor-Aufrufe. Und mit denen kann ich auch andere Sachen wie Speicher verwalten und dafür gibts in den GC-Sprachen imho nix gleichwertiges.