D Programmierung
-
Ok. Leute der GC muss mit D nicht benutzt werden. Es gibt die Möglichkeit den GC zu verwenden, wieso sollte man den nicht verwenden wenn es sich nicht um eine Zeitkritische Anwendung handelt?! Desweiteren kann man auch Assemblercode einbetten!
-
adxin schrieb:
Der GC wird in D nicht aufgezwungen wie z.B. in Java. Man kann z.B. auch Speicher vorher freigeben. Außerdem gibt es noch das auto-Attribut, der darauf hinweist, dass Speicher beim Verlassen des Scopes freigegeben werden muss.
Ob sich der GC abschalten lässt, weiß ich nicht, aber vielleicht hilft das Beispiel weiter: http://www.digitalmars.com/d/windows.html (Achte auf gc_init(), gc_term() Vielleicht gibt es aber dann einige Probs...).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.
Du warst schneller
-
adxin schrieb:
Der GC wird in D nicht aufgezwungen wie z.B. in Java. Man kann z.B. auch Speicher vorher freigeben. Außerdem gibt es noch das auto-Attribut, der darauf hinweist, dass Speicher beim Verlassen des Scopes freigegeben werden muss.
Ob sich der GC abschalten lässt, weiß ich nicht, aber vielleicht hilft das Beispiel weiter: http://www.digitalmars.com/d/windows.html (Achte auf gc_init(), gc_term() Vielleicht gibt es aber dann einige Probs...).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.
schoen, das ist mal ein brauchbarer hinweis, danke!
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)
-
Vielleicht steht es wirklich nicht sehr offensichtlich drin, aber es wurde in diesem Thread nicht nur einmal gesagt. Insbesondere von mir wurde es auch mindestens einmal fett markiert.
Ich würde vermuten (ohne es zu wissen), dass man in D wie bei C++/CLI eine Unterscheidung zwischen new und gcnew kennt.
-
Optimizer schrieb:
Vielleicht steht es wirklich nicht sehr offensichtlich drin, aber es wurde in diesem Thread nicht nur einmal gesagt. Insbesondere von mir wurde es auch mindestens einmal fett markiert.
Ich würde vermuten (ohne es zu wissen), dass man in D wie bei C++/CLI eine Unterscheidung zwischen new und gcnew kennt.hatte es gelesen, und haette es auch gelesen wenns nicht fettgedruckt gewesen waer.
hatte allerdings meine frage nach dem "wie" nicht beantwortet.
und du kannst es auch noch immer nicht beantworten.
findest du es eigentlich nicht bedenklich das du features als grosartig anpreist von denen du nicht mal weisst wie sie tatseachlich funktionieren?
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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).