Die Programmiersprache D

rüdiger

Optimizer schrieb:

Wieder ein toller Seiteneffekt versteckt. Sehr elitär, ich bin begeistert. (Das ist der Grund, warum der []-op einen getter und setter haben sollte)

Das Beispiel drückt doch aus, was passieren soll. Die Anzahl von x wird um eine neue Anzahl "anzahl" erhöht. Falls es eben keine (0) x gibt, dann ist der Wert danach "anzahl".

Das hat nichts mit "Elitär" zu tun, sondern einfach mit Ausdrucksstärke.

Falls es eben keine (0) x gibt, dann ist der Wert danach "anzahl"

Das wird meiner Meinung nach in dieser Zeile überhaupt nicht ausgedrückt. Dass ein Ausdruck map[key] = value unter Umständen einen neuen Key hinzufügt finde ich akzeptabel. Man baut eine Assoziation explizit auf, egal ob es vorher schon so eine gab oder nicht. Aber in deinem Beispiel wird zuerst der Wert gelesen und dieses Lesen fügt einen neuen Wert hinzu. Das drückt dein Code aus meiner Sicht nicht aus.

Es ist auch eher Zufall, dass in diesem Beispiel so ein Verhalten wünschenswert ist. Was soll denn bei einem String ein sinvoller default-Wert für den Key sein? char* auf 0? Die map verhält sich so, weil sie nicht zwischen lesen und schreiben unterscheidet, nicht weil es irgendwie sinnvoll wäre.

Und "ausdrucksstark" macht das eine Programmiersprache natürlich auch nicht. Ich könnte auch die Java-Map beim getten einen neuen Key hinzufügen lassen. Zum Glück haben sie es nicht so gemacht.

rüdiger

Optimizer schrieb:

Falls es eben keine (0) x gibt, dann ist der Wert danach "anzahl"

Das wird meiner Meinung nach in dieser Zeile überhaupt nicht ausgedrückt.

Nur weil du viele explizite Angaben erwartest. Aber es ist imho schon sehr logisch, dass man nach Erhöhung der Anzahl um anzahl Elemente eine um anzahl höhere Anzahl von Elementen hat und dass dies auch für den Fall von keinen Elementen vorher gilt.

Aus dem Grund versucht man ja Programme abstrakt und gekapselt zu modellieren. Die Details sind unwichtig, wichtig ist, dass das erreicht wird, was man möglichst verständlich ausdrückt.

Optimizer schrieb:

Was soll denn bei einem String ein sinvoller default-Wert für den Key sein? char* auf 0?

ein leerer String und bei einem Zeiger ein Nullpointer.

Helium

Ich wette es sind schon etlich Bugs entstanden weil jemand

foo = map[key];

geschrieben hat und unerwarteter weise einfach mal ein frisch konstruiertes Objekt zurückgegeben wurde statt dass derjenige einen Fehler erhalten hätte.

kartoffelsack schrieb:

RAII gibts nicht, oder?

In Wikipedia steht das es RAII in D gibt:
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

GPC schrieb:

Das komplette PDF kann man hier downloaden.

...
So, weiter geht's hier

Das PDF Dokument ist nicht mehr verfügbar.

GPC

PDF schrieb:

GPC schrieb:

Das komplette PDF kann man hier downloaden.

...
So, weiter geht's hier

Das PDF Dokument ist nicht mehr verfügbar.

Liegt am Hoster, der da gerade Probleme macht.

theliquidwave

Cool, echt geil geschrieben :>
Gibt es eigentlich schon ordentliche IDEs für D?

Edit: Gibt es eigentlich auch this->-Zeiger und würdest du diese empfehlen, oder nicht? In deiner PDF verwendest du diese ja nicht.

Gruß

GPC

theliquidwave schrieb:

Gibt es eigentlich schon ordentliche IDEs für D?

Jein http://stackoverflow.com/questions/50179/an-ide-for-d
Aber der echte Programmierer nimmt emacs oder vim, ist doch klar

Edit: Gibt es eigentlich auch this->-Zeiger

Klar gibt es den.

und würdest du diese empfehlen, oder nicht?

Das ist eine Frage des persönlichen Stils und der jeweiligen "Kultur" der Sprache. In C# ist es recht verbreitet, immer this zu benutzen, in C++ weniger.
Inzwischen verwende ich immer den this-Zeiger, wenn ich auf Instanzvariablen zugreife. Und zwar um sie deutlich von den lokalen/statischen/whatever-Variablen abzuheben. Andere finden das total hässlich und meinen, es müllt den Code zu. Ist Ansichtssache
Schwachsinn ist allerdings, dass es von der Performance schlechter wäre, wenn man this->member anstatt nur member schreibt.
Also, such's dir aus

theliquidwave

Okay. Dankeschön :>
Ein kleiner Hinweis: auf Seite 16 ist im ersten Satz ein kleiner Tippfehler

Edit: Deine Arbeit ist echt geil, kann man super zum umsteigen empfehlen. Auf deutsch fand ich nichts besseres und es ist gut zu lesen </schleimscheiß>

Edit2: Ich kann diese IDE nur empfehlen! http://d-ide.sourceforge.net/

Gruß

Ethon

So, ich grabe den Thread mal aus.

Habe ne Weile D programmiert und es scheint eine eierlegende Wollmilchsau zu sein. Für jedes Problem gibt es eine verdammt elegante Lösung.
D lässt in meinen Augen C++ komplett im Regen stehen.

Warum interessiert sich kein Schwein für D?

Marthog

Vorweg: Ich habe in D noch nie programmiert.

D sieht mir in vieler Hinsicht sehr schön aus. Im Grunde finde ich, dass D so ist, wie C++ sein sollte, mit nur einem großen Nachteil: Der Garbage-Collector.

Ethon

Marthog schrieb:

Vorweg: Ich habe in D noch nie programmiert.

D sieht mir in vieler Hinsicht sehr schön aus. Im Grunde finde ich, dass D so ist, wie C++ sein sollte, mit nur einem großen Nachteil: Der Garbage-Collector.

Für viele Einsatzfälle halte ich den GC für einen großen Vorteil.

In b4 Kernel/Embedded.

GPC

Ich hab mich schon lange nicht mehr mit D beschäftigt.. aber zumindest zum Zeitpunkt, als ich dieses Arbeit geschrieben hab, war es halt so:
- Es macht vieles besser als C++, aber nur etwas und nicht bahnbrechend
- Die Unterstützung durch bedeutende Hersteller (z.B. Microsoft) hat gefehlt und es gab kaum wirklich gute Tools, Libraries etc. Die komplette Infrastruktur hat gefehlt.

Marthog

Ethon schrieb:

Für viele Einsatzfälle halte ich den GC für einen großen Vorteil.

Ich finde die Argumente ja ganz vernünftig, aber will den gc nur als Alternative, also z.B. so dass der gc nur mit einer Extension genutzt wird oder man ihn nur mit bestimmten pointern nutzen kann, also quasi Unterschied zwischen new und gcnew.

Ethon

Marthog schrieb:

Ethon schrieb:

Für viele Einsatzfälle halte ich den GC für einen großen Vorteil.

Ich finde die Argumente ja ganz vernünftig, aber will den gc nur als Alternative, also z.B. so dass der gc nur mit einer Extension genutzt wird oder man ihn nur mit bestimmten pointern nutzen kann, also quasi Unterschied zwischen new und gcnew.

Konkretes Beispiel aus dem echten Leben in dem du keinen GC möchtest?

volkard

Ethon schrieb:

Marthog schrieb:

Ethon schrieb:

Für viele Einsatzfälle halte ich den GC für einen großen Vorteil.

Ich finde die Argumente ja ganz vernünftig, aber will den gc nur als Alternative, also z.B. so dass der gc nur mit einer Extension genutzt wird oder man ihn nur mit bestimmten pointern nutzen kann, also quasi Unterschied zwischen new und gcnew.

Konkretes Beispiel aus dem echten Leben in dem du keinen GC möchtest?

Immer, wenn ich keinen brauche. Ich mag jetzt nicht 99.999% aller Programmieraufgaben auflisten.

DarkShadow44

Immer, wenn ich keinen brauche. Ich mag jetzt nicht 99.999% aller Programmieraufgaben auflisten.

Und der Grund dafür ? Wenn du was wirklich performancekritisches machst kannst du ihn ja immernoch abschalten...
Aber wozu freiwillig mehr Arbeit machen als nötig ?

volkard

DarkShadow44 schrieb:

Immer, wenn ich keinen brauche. Ich mag jetzt nicht 99.999% aller Programmieraufgaben auflisten.

Und der Grund dafür ? Wenn du was wirklich performancekritisches machst kannst du ihn ja immernoch abschalten...
Aber wozu freiwillig mehr Arbeit machen als nötig ?

Mehr Arbeit?
Ich habe mit javaeskem GC und verspäteten Destruktoren *deutlich* mehr Arbeit als mit sofort zuschlagenden Destruktoren wie in C++/Perl.
Wenn der GC hingegen nur für den Speicher zuständig ist und hinter sofort zuschlagenden Destruktoren herräumt, ist es kein Unterschied.
Ich sehe nirgends mehr Arbeit beim Verzicht auf GC (außer vielleicht diesem Fall mit den lock-free queues).