D Programmierung

volkard schrieb:

c.rackwitz schrieb:

dafuer hab ich garbage collection,

ein nachteil

Ein Vorteil, diese Möglichkeit zu haben. Ich würde natürlich stark davon Gebrauch machen, aber wenn man es nicht muss, wo ist der Nachteil?

ordentliche arrays

falsch, du hast ein ordentliches foreach aber unordentliche arrays.

Was ist nicht ordentlich? In D ist die Syntax nicht mehr so bescheuert mit char* argv[] // hääääh?, man hat bounds-checking, kann die Länge getten. Was fehlt?

und strings

haste die in c++ nicht?

Ich glaube, ordentliche Strings fehlen in beiden Sprachen.

nested/anonymous funktionen

vortiel?

Super genial in Verbindung mit function delegates.

Was will ich mit GC? Ich muss mich in C++ nie um das Löschen des Speichers kümmern, passiert automatisch und zu genau dem richtigen Zeitpunkt.

Anon schrieb:

Was will ich mit GC? Ich muss mich in C++ nie um das Löschen des Speichers kümmern, passiert automatisch und zu genau dem richtigen Zeitpunkt.

Es wird oft übersehen, dass Fehler im Speichermanagement sich nicht darauf beschränken, etwas nicht zu destruieren. Man kann zum Beispiel Pointer zu gelöschten Objekten dereferenzieren. Auch kann die GC schlicht und einfach ein Performance-Vorteil sein, den man vielleicht nur noch mit eigenen, für diesen speziellen Zweck erstellten Allokatoren einholen kann. Auch das Buchführen wie bei Referenzzählung kommt nicht umsonst.

Ich will hier aber nicht über die Vor- und Nachteile von GC diskutieren. Bedenke einfach, dass es ausreichend viele Programmierer gibt, die das schätzen und das es deshalb nicht verkehrt ist, diese optionale Möglichkeit zu haben. Das mit der optionalen Möglichkeit muss doch gerade C++ Programmierern einleuchten. Naja und es kommt sogar anscheinend mit dem nächsten Standard.

Walli

Optimizer schrieb:

Naja und es kommt sogar anscheinend mit dem nächsten Standard.

Wäre mir neu. Wo hast du das her?

Walli schrieb:

Optimizer schrieb:

Naja und es kommt sogar anscheinend mit dem nächsten Standard.

Wäre mir neu. Wo hast du das her?

Da hatte Artchi mal nen Link gepostet, in dem es heißt:

Der gute alte Stroustrup schrieb:

Naturally, applying these ideals and rules is an art rather than a science and people can (and do) disagree on what is a natural development of C++ and what would be a new paradigm. C++0x will most likely support optional garbage collection

(Quelle: http://www.artima.com/cppsource/cpp0x.html)

Walli

Ich schau mal rein. Danke!

Anon schrieb:

passiert automatisch und zu genau dem richtigen Zeitpunkt.

Woher willst Du zur Compilezeit wissen wann der richtige Zeitpunkt gekommen ist? In großen Enterprisesystemen kannst Du zur Laufzeit kaum erahnen, zu welchen Zeitpunkt hohe Last herrscht. Ein GC räumt i.d.R. genau dann auf, wenn dafür Zeit frei ist.

Nicht umsonst ist Java im Enterprise Bereich(Sprichwort J2EE) der Standard geworden.

Weil ich das Programm geschrieben habe?
Für sowas gibts custom De-/Allokatoren

Anon schrieb:

Weil ich das Programm geschrieben habe?
Für sowas gibts custom De-/Allokatoren

So trivial ist das nicht immer. Du kannst beispielsweise bei einem Echtzeitstrategiespiel nicht auf triviale Weise erahnen, wann eine Einheit genau nicht mehr referenziert wird. Dazu müsstest du alle Einheiten checken, ob sie gerade die gestorbene Einheit als Ziel haben.

Das ist natürlich kaum praktisch durchführbar, deshalb löscht man die Einheit aus dem Speicher erst bei Spielende (WarCraft III), oder baut eine zusätzliche Indirektion ein, so dass die verfolgende Einheit die Zieleinheit nicht mehr direkt referenziert. Das macht die Sache natürlich etwas langsamer und anfälliger für cache-misses.

Du siehst, es gibt keinen Königsweg. Auch Garbage Collection kann mal zum Nachteil ausarten, aber für viele praktische Probleme ist es eine bequeme Lösung. Es gilt auch hier die 90:10-Regel. Nur 10 Prozent der Allokationen kosten dem GC nachher beim Aufräumen echt nennenswert was und für dort kann man sich dann immer noch eine Lösung mit manuellem Management einfallen lassen. Bei dem Beispiel mit den Einheiten würde ich beispielsweise nicht vermuten, dass der GC überfordert ist, weil man nicht im Spiel pro Sekunde ein paar Millionen Einheiten baut und zerstört.

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

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.