D Programmierung

c.rackwitz

wenn es nur darum ginge, wuerde ich die sprache nicht benutzen. sie ist ja nicht mal fertig (v0.144 und jedes mal kommen sprachelemente dazu wie z.b. bald arrayliterale).

allerdings fuehlt sich die sprache fuer mich besser als c++ an und das ist mir wichtig.
weil ich so ein dummer mensch bin und mich gerne totquatschen lasse, hier noch ein angriffspunkt: ich mag scheme.

ich lasse mich gerne mit argumenten erschlagen, aber wenn die an mich adressiert sind, dann haben die bitte auch auf mich zuzutreffen. wer etwas gegen (m)eine *meinung* hat, sollte besser nicht in onlineforen unterwegs sein.
*auf volkard schielt*

Jemand, der anderer Meinung ist, darf nicht in einem Onlineforum sein?
Da ich davon ausgehe, dass Du das nicht meinst: Was meinst Du?

daHa schrieb:

dieses beispiel wuerde ich mit einem template displayContainer (name ist natuerlich gemachack) implementieren.
ist dann noch aussagekraeftiger als foreach und gibt noch kuerzerer clientcode.
ausserdem hat man an einer stelle controlle daruerber was gemacht werden soll,is zb dann gut wenn ich zb die ausgabe aendern will, zb von console nach file.

ein typedef so wie du es gemacht hast wuerd ich auch nie machen.
wenn dann myMap_t::iterator
(ausserdem bei map, pos->second, will aber net itupferlreiten)

und waerend es schon sehr inkonsistent ist das es kein reverse_foreach gibt, hab ich in 2 minuten diese funktionalitaet bereitgestellt.

Erzähl nicht, mach es und präsentiere deine Ergebnisse. Du bist nicht der erste, der hierfür eine elegante Lösung sucht.
Mein Ergebnis mit foreach als Sprachfeature habe ich präsentiert, aber ich bin selbstverständlich völlig offen. Gib mir nur was, was ich mir anschaun kann und dann sagen kann "ahja ok, das ist auch ne schöne Lösung".

es ist ok wenn du etwas elleganter findest.
zu verlangen das es alle anderen auch ellegant finden ist diktatorisch.

Selbstverständlich. Deshalb gehe ich ja den Weg über den Versuch, andere ganz ohne Zwang zu überzeugen, dass foreach was feines ist. Über ein reverse_foreach kann man natürlich auch nachdenken, warum nicht?

von auto halt ich wenig, und von iterator typedef auch, wie oben mycontainer_t::iterator/const/reverse ist aus diversen gruenden besser.

Na, diese Meinung teilst du aber nicht mit allzu vielen Leuten.

Optimizer schrieb:

diese foreach fixiertheit ist reines marketinggeplapper fuer/von sprachen die das implementiert haben.
und das halt als grossartiges feature (und ueberlegenheit (der eleganz)) der sprache verkaufen.

Nö, ich mag's. Und ich bin kein Wirtschaftler.

die eine sprache stellt dies bereit, die andere jene, und?

Und manche halt gar nichts äquivalentes.

uebrigens, grad deine sample fehlermeldung ("Map<K, V> does not implement IEnuermable<V>") waer wieder ein bsp warum selbstimplementieren ueberlegen ist/sein kann.

weil wenn ich einen eigene verkettete liste mach, die aus irgendeinem grund ohne iteratoren auskommt, dann spezialisier ich einfach mein displayContainer template und fertig.(wobei dann das Container im Namen natuerlich ungluecklich ist, nur um eventueller kritik vorzubeugen)

Ich denke kurz darüber nach... nein, ich bin nicht überzeugt.

und, ich bin nicht gezwungen irgendwelche interfaces zu vererben was event. wiederum den compileroutput und das laufzeitvehalten eleganter und effizienter macht (machen kann) und mir bei eigenen listen tipparbeit spart wenn ichs nicht will/brauch, eine tatsache die immer verschwiegen wird, event darum um die zuhohrer nicht zu verwirren, was der grund ist warum ich diese foreach fixiertheit als marketinggeplapper bezeichne.
ich koennts so ausdruecken, man lenkt vom produkt (compileroutput laufzeitverhalten, tipparbeit an anderer stelle) auf die verpackung (10 zeichen weniger tipparbeit) ab, und ignoriert die tatsache das auf grund der verpackung ein eventuell schlechteres produkt entsteht, je nach anwendungsfall halt, aber da marketinggeplapper wird froehlich verallgemeinert was das zeug haelt.

Du hast das Anwendungsgebiet noch nicht ganz verstanden. Wenn du den Standard begin-end Kram machst, dann wäre ein foreach stattdessen schön. Ich habe nirgendwo gesagt, dass man krampfhaft überall foreach verwenden soll, auch wenn es Nachteile gegenüber etwas anderem hat.

wegen compilermeldungen
da ich taeglich mit c++ arbeite, nein, im allgemeinen stoeren mich die compilermeldungen nicht, in der regel finde ich sie hilfreich.

Klar, die Meldungen sind hilfreicher als wenn man sie nicht hat. Und verstehe mich bitte nicht falsch: Ich sitze nicht stundenlang da und versuche, den Fehler zu verstehen. Es ist das ganze Übersetzungsmodell, was suckt und keine ordentlichen Meldungen produzieren kann, weil es keine saubere Schnittstellen-Prüfung gibt. Und ich wollte aber auch gar nicht darauf rumhacken sondern nur demonstrieren, warum ein Sprachmittel einfach besser ist als die tausendste ewig komplizierte Template-Funktion, die trotzdem nicht so geil ist.

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)