D Programmierung

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

[gc]

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.

[Gast]

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.

[Gast]

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.

[Gast]

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

[Gast]

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.

[Ben04]

kartoffelsack schrieb:

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.

Löschen ist natürlich das Beispiel wo ein for_each nicht geht, allerdings ist hierfür auch die normalle Benutzung der for Schleife ungeeignet. Für viele anderen Situation geht es recht gut. Zum Beispiel zum Suchen :

int find_foo(const container&vec)
{
  foreach(i in vec)
    if(is_foo(i))
      return i;
  throw not_found();
}

Zugegeben es wäre nicht schlecht ein etwas flexibleres foreach zu haben das vielleicht auch Löschen möglich machen würde.

[daHa]

std::find/_end/first_of/_if

danke zum suchen braucht man ein for_each auch nicht unbedingt

[Gast]

daHa schrieb:

std::find/_end/first_of/_if

danke zum suchen braucht man ein for_each auch nicht unbedingt

Jo, das wär auch noch zu viel Code. Aber sieh dir das mal an. Irgendwann ist es unlustig, einen Funktor zu schreiben, dem ich dann 5 Parameter (node, candidateList, isObstacle, size, this) übergebe. Es geht sowieso nicht so wahnsinnig elegant, für alle Anwendungsgebiete mit unterschiedlich viel beteiligten Objekten einen Funktor zu definieren. Bei foreach schreib ich den Funktor einfach in den Schleifenrumpf, bei Beibehaltung des gesamten lokalen Kontexts.

private void connectToCandidates(PathfindingNode node, IList<PathfindingNode> candidateList, Predicate<CollisionObject> isObstacle, long size) {
	foreach( PathfindingNode candidate in candidateList ) {
		if( candidate == node   ||   !canConnect(node, candidate, size, ObstacleCategory.FixedPosOnly, isObstacle) )
				continue;

			long distance = node.Pos.DistanceTo(candidate.Pos);
			PathfindingNode.Connect(node, candidate, distance);
		}
}

for-Schleifen habe ich gar nicht so viele. Ich habe eigentlich mehr foreach-Schleifen. Natürlich nicht, um selber FindFirst(Predicate) nach zubauen, aber für Fälle, wo es sich eher anbietet.

[adxin]

volkard schrieb:

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?

Diese Analogie zieht nicht, da unrealistisch. Einen kostenlosen Navi könnte man zu einem Neuwagen doch noch verhandeln.
Außerdem wenn man diese Logik anwendet, dann kann man sich auch folgende Frage stellen: Wozu muss man unbedingt etwas wie Templates nehmen, es ist kostenlos und optional. Ich kann das auch nicht nachvollziehen.
Oder warum soll ich höhere Programmiersprachen wie C o. C++ nehmen, sie sind (manchmal) kostenlos und optional.
Das selbe gilt für for-Schleifen. Warum sollte ich sie anwenden, wenn ich dasselbe mit goto erreichen kann?
(Diese Übertreibungen dienen der Verständlichkeit.)

[volkard]

adxin schrieb:

Diese Analogie zieht nicht, da unrealistisch. Einen kostenlosen Navi könnte man zu einem Neuwagen doch noch verhandeln.

aber es gibt unzweifelhaft kostenlose sachen (wie handys mit vertrag, wie religiöse mitgliedschaften, wie erste extasy-pillen, wie nordic-walking-kurse, wie analsex), die man aufgeschatzt bekommen soll oder enorm tolle sachen zum fairen preis (wie vorwerk-staubsauger), von denen man besser die finger lassen sollte. es ist nicht alles gold, was glänzt. und blei ist sogar giftig.

Außerdem wenn man diese Logik anwendet, dann kann man sich auch folgende Frage stellen: Wozu muss man unbedingt etwas wie Templates nehmen, es ist kostenlos und optional. Ich kann das auch nicht nachvollziehen.
Oder warum soll ich höhere Programmiersprachen wie C o. C++ nehmen, sie sind (manchmal) kostenlos und optional.
Das selbe gilt für for-Schleifen. Warum sollte ich sie anwenden, wenn ich dasselbe mit goto erreichen kann?
(Diese Übertreibungen dienen der Verständlichkeit.)

in den letztgenannten punkten sehe ich noch einen bescheidenen sinn. irgendwie ist keinem ein beispiel eingefallen, wo der gc signifikante vorteile bringt. nur die vermutung, er würde irgendwelches nachdenken vereinfachen, wo ich gegenvermute, daß er um die ecke noch mehr nachdenken erzwingt.

[adxin]

volkard schrieb:

in den letztgenannten punkten sehe ich noch einen bescheidenen sinn. irgendwie ist keinem ein beispiel eingefallen, wo der gc signifikante vorteile bringt. nur die vermutung, er würde irgendwelches nachdenken vereinfachen, wo ich gegenvermute, daß er um die ecke noch mehr nachdenken erzwingt.

Mir fällt auch kein stichhaltes Argument ein, da ich nur Hobby-Programmierer und Schüler bin. Ich habe ich den GC nicht als die Lösung aller Probleme dargestellt.
Ich finde bloß, dass einige Leute hier übertreiben, wenn sie ein foreach als etwas darstellen, was einen Programmierer zum "Bösen" verleitet.

Und um jetzt nochmal auf das ursprüngliche Thema zurück zu kommen:
Mit D kann man alles? machen, was auch mit C++ möglich ist. Darüber hinaus gibt es auch einen optionalen! GC, was soll daran schlecht sein?

PS: Mich würde interessieren, was z.B. die Entwickler von Java sich dabei gedacht haben als sie einen GC den Nutzern aufgezwungen haben. Aus Spaß haben sie das nicht gemacht - behaupte ich jetzt mal. Vielleicht können sie dann diese stichhalten Argumente liefern, wenn es diese überhaupt gibt.