D Programmierung
-
daHa schrieb:
ausser man braucht einen gc weil man seine design deffizite abwaelzen will.
zu erwähnen wäre, daß noch unklar ist, ob das für 99% oder 100% der gc-bedürftigkeit gilt.
-
volkard schrieb:
daHa schrieb:
ausser man braucht einen gc weil man seine design deffizite abwaelzen will.
zu erwähnen wäre, daß noch unklar ist, ob das für 99% oder 100% der gc-bedürftigkeit gilt.
Lustig, dass ihr da dann ein "Design Defizit" seht. Ich sehe das eher andersherum. IMHO ist "Design" jeder Art für den Menschen da, also für den, der vor dem Rechner sitzt. Wenn nun eine Technologie bestimmte Designs nicht zulässt, dann ist das ein Problem dieser Technologie. Wenn einem also wegen einem fehlenden GC ein bestimmtes Design aufgezwängt wird, dann ist das in jedem Fall ein Problem der darunterliegenden Technologie. Man muss sich an diese anpassen, obwohl es doch im Idealfall eher andersherum wäre. Eigentlich sollte einen die Technologie bei seinen Designs unterstützen und nicht einschränken.
Bei C++ setzt man doch sonst so darauf, dass möglichst viel erlaubt wird: C++ ist eine Multiparadigmensprache, es wird da also darauf gesetzt, dass man auf ganz unterschiedliche Weisen damit programmieren können soll. Warum also kein optionaler GC wie bei D? Ist da die Verfügbarkeit eines Sprachfeatures plötzlich böse? Warum? Weil C++ es nicht hat?
-
also, nachdem niemand in der bis jetzt lage war wie optional der gc bei D wirklich ist hab ich weiter in der doku herumgesucht.
(so nebenbei, der punkt
How Garbage Collection Works
To be written...)aber ok.
so wie ich das versteh is gar nix optional, sondern der gc is immer hier und laeuft auch(?).
aber man kann ueber malloc pointer erzeugen die nicht von gc verwaltet werden.also sowas als optional zu verstehen, naja.
(womit ich wieder bei marketinggeplapper waer, aber vielleicht hab ich da ja was falsch verstanden, wenns so ist dann bitte D experten, klaehrt mich auf.
hab eher das gefuehl das das ein seiteneffekt ist der sich nicht vermeiden laesst wenn man direct c aufrufe zulaesst
)denke da sind die exestierenden c++ loesungen optionaler, wenn ich gc brauch/will bau ich ihn ein, ansonst is er nicht da.
wobei ich dazusagen muss das ich noch keinen gc mit c++ ausprobiert hab, is mir bis jetzt nicht abgegangen.ich kann verstehen das man eine programiersprache mag.
aber zu behaupten das D das bessere C++ ist, wie ichs in einer sig hier gelesen hab ist doch etwas uebertrieben.irgendwie seh ich nicht das D eine weiterentwicklung von C++ ist, sondern eher eine neue sprache die sich halt an vielem von c/cpp nimmt und das mit java (und nun auch dotnet) features vermischt.
man koennte ja auch sagen das D das bessere Java is weils ordentlich uebersetzt wird, templates kann und direkteren zugriff auf c funtkionalitaet erlaubt
und nicht jeder typ unnoetig von objekt abgeleitet ist.
und foreach, aso, das geht nicht als arument...ja, ich glaub so is es, D ist das bessere Java, die naechste Evolutionstufe von C#, nunja, mir falln leider nicht so viel marketingsprueche ein.
auf jedenfall schoen, kunkurrenz belebt das geschaeft.
-
D ist das bessere C. Ist doch ganz klar.
-
volkard schrieb:
daHa schrieb:
ausser man braucht einen gc weil man seine design deffizite abwaelzen will.
zu erwähnen wäre, daß noch unklar ist, ob das für 99% oder 100% der gc-bedürftigkeit gilt.
Ich würde eher vermuten, dass mit Hilfe eines GC in manchen Situationen gelegentlich ein besseres Design möglich ist. So lange es nur um die Resource "Speicher" geht, scheint mir das jedenfalls nicht abwegig. Wenn ich nen std::auto_ptr aus ner Lib zurückgebe, muss der andere genau das selbe Ding benutzen, um das Objekt korrekt am Leben zu erhalten. Die Alternative wäre zu sagen "danach bitte unbedingt löschen". Demgegenüber, wenn ich ne Referenz wie in Java zurückgebe, siehe da, er kann damit machen, was er will.
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.Umgekehrt würde mich mal genauer interessieren, wie ihr das meint, dass man mit einem GC Designfehler vertuschen kann.
-
Ist ja eh so lustig, sobald der GC im Standard ist, werden hier einige von euch Kritikern ihn selber benutzen und der GC von C++ ist dann natürlich viiiieeeel besser, was dann zur Genüge erklärt, warum ihr jetzt noch dagegen ankämpft.
-
GC ftw. In der Zukunft ist so Mikrospeichermanagement wie explizite Speicherfreigabe für die meisten Standardanwendungen total antiquiert.
-
Naja was heißt er muss den auch benutzen?
//In der Lib typedef std::auto_ptr< MyLibObj > MyLibObjPtr; MyLibObjPtr createMyLibObj(); //Im source #include <mylib.hpp> int main() { MyLibObjPtr libObj = createMyLibObj(); }und er weiß gar nichts davon (gut kann bei auto_ptr böse enden, da muss man dem Benutzer sagen was er darf und was nicht, besser wäre hier ne andere art von smart ptr)
-
Anon schrieb:
Naja was heißt er muss den auch benutzen?
Da kannste typedefs schreiben wie du willst und trotzdem ist's ein auto_ptr und deshalb muss er den auch benutzen.
Man könnte nur per release() den richtigen Zeiger holen und dann raw benutzen oder wahlweise in nen eigenen Smartptr packen. Schön ist's aber imho nicht..
-
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.
-
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.