D Programmierung

Ben04

Anon schrieb:

Da würd ich einfach nen smart pointer mit referenzzählung nehmen.

Informier dich mal über zyklistiche Abhängigkeiten und wie beide Ansätze diese handeln. Dannach über die Allokations, Deallocations und Unterhaltskosten von GCs und einem Freestore.

Anon schrieb:

Da würd ich einfach nen smart pointer mit referenzzählung nehmen.

Zwei Einheiten greifen sich gegenseitig an. Da brauchst du schon ausgefeiltere Algorithmen, z.B. Entdeckung von zyklischen Abhängigkeiten in einem gerichteten Graphen.

Das ist übrigens auch ein gutes Beispiel, wo Referenzzählung ineffizient ist. So oft stirbt eine Einheit nicht, im Vergleich dazu kann sich ihr Ziel durchaus häufig ändern. Bei jeder Änderung zahlst du.

Ben04 schrieb:

Anon schrieb:

Da würd ich einfach nen smart pointer mit referenzzählung nehmen.

Informier dich mal über zyklistiche Abhängigkeiten und wie beide Ansätze diese handeln. Dannach über die Allokations, Deallocations und Unterhaltskosten von GCs und einem Freestore.

Klingt interressant, kennst du zu dem Thema (oder Themen?) nen paar Empfehlenswerte Artikel?

Ben04

Any schrieb:

Ben04 schrieb:

Anon schrieb:

Da würd ich einfach nen smart pointer mit referenzzählung nehmen.

Informier dich mal über zyklistiche Abhängigkeiten und wie beide Ansätze diese handeln. Dannach über die Allokations, Deallocations und Unterhaltskosten von GCs und einem Freestore.

Klingt interressant, kennst du zu dem Thema (oder Themen?) nen paar Empfehlenswerte Artikel?

http://de.wikipedia.org/wiki/Automatische_Speicherbereinigung#Algorithmen
Die ersten beiden sind reine GC Algos. Der dritte wird eigentlich selten für GCs benutzt, eigentlich handelt es sich hier um den shared_ptr Ansatz.

Man sollte auch wissen, dass ein GC ohne Destruktoren arbeitet. Sollte sich ein Destruktor einmal nicht auf Speicherfreigabe beschränken muss man auf die in C++ gängige Mechanismen zurückgreifen.

Der Artikel in der Wikipedia muss dringend überarbeitet werden.
Hier ist noch was anderes:
http://msdn.microsoft.com/msdnmag/issues/1100/GCI/default.aspx
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx
http://www.virtualmachine.de/2000-ernst-schneider/node13.html
http://www.virtualmachine.de/2000-ernst-schneider/node48.html
http://www.memorymanagement.org/articles/recycle.html

sind alle nicht so hochwertig, aber IMHO etwas besser.

Der taugt n bissl was:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

daHa

das einheitenbsp ist ein bissl ungluecklich als bsp fuer einen gc, da die einheiten sowieso ueber die armee verwaltet werden muessen

verfolgung angriff sieht dann so aus, fein.arme amleben? aktion
oder aehnlich, bitte phantasie anstrengen

diese akademischen bsp bringen nix.
ausser man braucht einen gc weil man seine design deffizite abwaelzen will.

im uebrigen, wie funktionert bei D das optionale gc aktivieren? hab in der doku keien compileroption gefunden, hab ich was ueberlesen oder gibt es aehnliche konstrukte wie fixed (glaub in c# nennt sich das so)

Artchi

D finde ich auch interessant, habe es aber bisher noch nie ausprobiert. Deshalb hier meine (wertfreie) Frage: wäre C++/CLI nicht eine Alternative, wenn man z.B. jetzt einen GC haben will? Das C++/CLI bisher nur auf MS-Platform verfügbar ist, mal außen vorgelassen.

c.rackwitz

Artchi schrieb:

D finde ich auch interessant, habe es aber bisher noch nie ausprobiert. Deshalb hier meine (wertfreie) Frage: wäre C++/CLI nicht eine Alternative, wenn man z.B. jetzt einen GC haben will? Das C++/CLI bisher nur auf MS-Platform verfügbar ist, mal außen vorgelassen.

meine meinung:
keine alternative, weil es ein D frontend fuer gcc gibt, welches nur noch ein paar versionen hinter der referenz DMD liegt.

D __IST__ ES.

volkard

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.

Gregor

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?

daHa

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)

Konrad

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.