Wie heißt der Nachfolger ...

Gregor

Original erstellt von HumeSikkins:
**
Fand die Sprache aber nicht so prickelnd.**

Was war schlecht?

HumeSikkins

Was war schlecht?

Damals gab's z.B. noch keine Templates. Gegenargument war deren Komplexität. Damit war ich gar nicht einverstanden. Jetzt habe ich aber gerade gesehen, dass es jetzt doch einen Vorschlag dafür gibt.

Außerdem erschien mir die Sprache zu sehr OOP. Ich bin ein Fan von Multi-Paradigm Sprachen.

Aber wie gesagt, ich habe bisher nur ein wenig über die Sprache gelesen. Bin also nicht wirklich in der Position um ein gutes Urteil abgeben zu können.

davie

Zu sehr OOP?
Dann dürfte dir C++ aber auch nicht zusagen
Ich find' die Sprache ganz interessant

BTW: Der D-Smiley:

Gibts da mittlerweile auch einen Linux Compiler?

HumeSikkins

Dann dürfte dir C++ aber auch nicht zusagen

Hä? Wieso? C++ ist doch nicht nur OOP. Da gibt's keine Zwangsroot-Klasse. Klassen sind standardmäßig nicht für die Vererbung geeignet. Es gibt Funktionen und alles was man sonst noch so zur funktionalen Programmierung braucht. Built-Ins sind keine Objekte. Objekte haben standardmäßig eine value-Semantik und keine Referenzsemantik. Es gibt eine ausgeprägte Unterstützung für die generische Programmierung. Also kurz. Ich kann ich C++ sehr schöne OO-Programme schreiben. Es ist aber ebenso einfach Programme zu schreiben die nicht OOP und dennoch schön sind.

davie

leider noch nicht, aber soll bald soweit sein.

syncronize { Noesis->pc_neu_start(); }

@Loggy: brauchen neue Keywords.

Helium

D hat einige interessante Ansätze. Mit einigen Dingen komme ich überhauptnicht klar. Ähnlich, wie HumeSikkins bin ich gegen eine Zwangsbasisklasse, und für Valuesemantik.

Für die, die es noch nicht kennen:

http://www.digitalmars.com/d/

Shade Of Mine

Original erstellt von Helium:
D hat einige interessante Ansätze. Mit einigen Dingen komme ich überhauptnicht klar. Ähnlich, wie HumeSikkins bin ich gegen eine Zwangsbasisklasse, und für Valuesemantik.

Vollkommene zustimmung.

Ausserdem scheint mir das template-system auch nicht ganz ideal zu sein.
Da sollte man viel vorausschauender denken - die templates muessen erweitert werden!

Gregor

Original erstellt von Helium:
[QB]für Valuesemantik.

Warum?

Shade Of Mine

Original erstellt von Gregor:
Warum?

Warum sollte mir die Sprache aufzwingen wie ich meine Objekte anzulegen habe?

Vielleicht ist es nur eine kleine Klasse, die sollte doch auf den Stack rauf -> kann ja sein, dass ich sie zeitkritisch verwenden will.

Das Problem ist, dass die Sprache mir aufzwingt WIE ich meine Objekte anlegen soll... Dabei weiss ich doch wohl selber besser ob das jetzt auf den Heap (FreeStore) oder auf den Stack kommen soll. (schliesslich weiss nur ich, was ich mit diesem Objekt alles machen will)

Gregor

Hmmm... also ich habe den Text jetzt auch mal etwas überflogen und bisher gefällt mir die Sprache größtenteils.

Es kommt mir so vor, als ob die Sprache ein Zwischending zwischen C++ und Java ist und noch ein paar Erweiterungen hat, die keine der anderen Sprachen hat. IMHO wurden auch jeweils die richtigen Features von C++ und Java übernommen.

Von C++ gibt es :

Operator Overloading
Templates
...

Von Java gibt es :

Threads als Bestandteil der Standardbibliothek
Eine genau festgesetzte Größe der (meisten) primitiven Datentypen
Garbage Collection (Übrigens : Durch den GC ist das Arbeiten mit Objekten auf dem Heap in Java schneller als in C++, allerdings ist man in C++ auf dem Stack noch schneller ;))
Keine "Forward Declaractions"
...

EDIT : IMHO ist aber der größte Vorteil gegenüber C++, dass eine Menge Komplexität beseitigt wurde. Bei C++ sind durch diese Komplexität ja nichtmal die Compiler standardkonform.

[ Dieser Beitrag wurde am 24.11.2002 um 14:55 Uhr von Gregor editiert. ]

Shade Of Mine

Original erstellt von Gregor:
EDIT : IMHO ist aber der größte Vorteil gegenüber C++, dass eine Menge Komplexität beseitigt wurde. Bei C++ sind durch diese Komplexität ja nichtmal die Compiler standardkonform.

Aber dadurch wurden maechtige Features entfernt...
zB fehlt etwas wie 'unsafe' in C#

Ich will die moeglichkeit haben, hardcore optimierungen zu betreiben, wenn ich sie einmal brauche.

Das ist etwas was ich an den 'modernen' Sprachen nicht verstehe:
Warum soll die Sprache klueger sein als ich?
Warum kann ich Objekte nicht auf den Stack legen? Das kann sinnvoll sein. Warum kann ich nicht manchmal Memory selber verwalten? Das kann sinnvoll sein.

Zu deinem Memory Argument: In C++ kannst du, wenn du gute allocatoren verwendest auch so schnell wie Java sein! Schliesslich arbeitet ein GC ja nicht mit Magie sondern nur mit einem memory-pool.

Gerard

Original erstellt von Shade Of Mine:
Zu deinem Memory Argument: In C++ kannst du, wenn du gute allocatoren verwendest auch so schnell wie Java sein! Schliesslich arbeitet ein GC ja nicht mit Magie sondern nur mit einem memory-pool.

ein wenig mehr Magie solltes du ihn schon zu trauen, z.b. kann er warten bis rechenleistung frei ist um den speicher frei zu geben oder er kann ihn defragmentieren, klar kostet das insgesamt mehr rechnenleistung aber er tut es ja mit vorliebe dan wenn welche frei ist (und dan ist es wieder egal)

Gregor

Original erstellt von Dimah:
**
ein wenig mehr Magie solltes du ihn schon zu trauen, z.b. kann er warten bis rechenleistung frei ist um den speicher frei zu geben oder er kann ihn defragmentieren, klar kostet das insgesamt mehr rechnenleistung aber er tut es ja mit vorliebe dan wenn welche frei ist (und dan ist es wieder egal)**

Mir kam es vor allem darauf an, dass der Heap bei Java immer defragmentiert ist. zumindest ein großer Teil des Heaps.

Der Heap hat bei Java 2 Bereiche. Einen Bereich mit alten Objekten und einen mit neuen Objekten. Wenn der Speicher voll ist, dann wird der GC aktiv und macht folgendes (im Bereich der neuen Objekte):

Er geht jedes Objekt durch. Wenn es gelöscht werden kann, dann wird der Speicher freigegeben, wenn nicht, dann wird das Objekt in den Bereich der alten Objekte umkopiert. Der Speicher im Bereich der neuen Objekte wird dann natürlich freigegeben. Der Bereich der neuen Objekte ist somit jederzeit defragmentiert. Der andere Bereich wird auch nicht schnell fragmentiert, da dort nur langlebige Objekte existieren. Die werden nicht so oft gelöscht.

PS : Kann sein, dass es doch etwas anders funktioniert. So genau kenne ich mich da auch nicht aus.

EDIT : Was wird denn in C++ gemacht, wenn zwar überall im Speicher etwas Platz ist, aber jeweils nicht genug Platz, damit das Objekt dort reinpaßt?

[ Dieser Beitrag wurde am 24.11.2002 um 16:33 Uhr von Gregor editiert. ]

Etti

Original erstellt von Gregor:
EDIT : Was wird denn in C++ gemacht, wenn zwar überall im Speicher etwas Platz ist, aber jeweils nicht genug Platz, damit das Objekt dort reinpaßt?

Ich bin mir nicht ganz sicher, aber ich vermute, er würde melden, dass nicht genügend freier Speicher vorhanden ist

Gregor

Original erstellt von Etti:
Ich bin mir nicht ganz sicher, aber ich vermute, er würde melden, dass nicht genügend freier Speicher vorhanden ist

Vermute ich auch fast. Aber eigentlich habe ich absolut das falsche gefragt. Viel interessanter ist wohl folgendes :

Was macht C++, wenn ein Objekt auf dem Heap angelegt wird?

In Java wird es wohl einen Zeiger geben, der hinter das zuletzt erzeugte Objekt zeigt. Nach dem Erzeugen wird der Zeiger dann einfach um die Länge des Objekts nach hinten verschoben. Wenn der GC aktiviert wird, dann wird der Zeiger wieder auf den Anfang des Bereiches der neuen Objekte gesetzt. (So würde ich es zumindest, ohne vorher darüber nachgedacht zu haben, machen)

Wie wird es in C++ gemacht. Wird da jeweils ein Speicherbereich gesucht, in dem das neue Objekt gespeichert werden kann?

[ Dieser Beitrag wurde am 24.11.2002 um 17:52 Uhr von Gregor editiert. ]

kartoffelsack

Das sind Details, die jeder Compilerhersteller anders lösen kann. Und wenns einer gut löst, dann gönnts ihm der andere nicht und machts noch besser

Was mir an D nicht gefällt (hab aber schon länger nix mehr drüber gelesen, kann sich also gebessert haben):

Ganz viele der mächtigen Sachen, die auf den ersten Blick vielleicht etwas kompliziert sind, fallen raus, obwohl sie im Endeffekt doch das sind, was die Sprache c++ so gut macht: Templates (habt ja gesagt, die solls jetzt doch geben), Operator-Overloading, namespaces, Mehrfachvererbung.

Außerdem frag ich mich: Wenn ich schon ne neue Sprache mach, die viel einfacher sein soll und bei der ich (anders als bei c++) auch keinen Wert auf Rückwärtskompatibilität lege, warum verwend ich dann nicht ne anständige Syntax? Grad die Syntax isses doch, die C/C++ oft so schwierig macht, weil sie unübersichtlich und wenig intuitiv ist. Da werden laufend neue C-Dialekte geschrieben (Java, C#, D), die Sprache wird aus Gründen der Einfachkeit um ihre besten Features kastriert aber man behält auf jeden Fall immer die seltsame Syntax

Gregor

Original erstellt von kartoffelsack:
**Das sind Details, die jeder Compilerhersteller anders lösen kann. Und wenns einer gut löst, dann gönnts ihm der andere nicht und machts noch besser
**

Es muss hier doch jemand wissen, ob das Anlegen eines Objektes in Abhängigkeit vom belegten Speicher in C++ in konstanter Zeit, in logarithmischer Zeit oder in welcher Zeit auch immer geschieht.

Weiter oben steht noch sowas wie : "Warum sollten die Sprachen klüger als ich sein. Ich bin klüger. Ich weiß, wie ich am Besten optimiere." Wie kann man das wissen, wenn man noch nichtmal sowas weiß? Die Compiler sind IMHO größtenteils klüger als die Programmierer, was das Optimieren betrifft. :p

HumeSikkins

Es muss hier doch jemand wissen, ob das Anlegen eines Objektes in Abhängigkeit vom belegten Speicher in C++ in konstanter Zeit, in logarithmischer Zeit oder in welcher Zeit auch immer geschieht

Nö wie soll er auch. Das dynamische Anlegen eines Objekts geschieht in C++ in zwei Schritten.
1. Aufruf des passenden operator new der den erforderlichen Speicher besorgt
2. Aufruf eines passenden Konstruktor.

Wie im ersten Schritt der Speicher bereitgestellt wird ist nicht definiert und frei varierbar (op new kann schließlich global bzw. pro Klasse überladen werden.) Ein "new Objekt" kann auch ein Objekt auf dem Stack anlegen. Es ist so ziemlich alles möglich.

Viele Implementationen rufen standardmäßig eine C *alloc Funktion auf. Diese Funktionen wiederum verwenden Betriebssystemspezifische Aufrufe und Allokatoren. Unter Linux wird meines Wissens nach hauptsächlich mit einem Slab-Allokator gearbeitet. Wer ganz genau wissen will, was da auf seiner Platform abgeht muss auf jeden Fall ganz schön tief graben oder alles selbst implementieren.

Früher konnte man zumindest relativ gefahrlos behaupten, dass das dynamische Anlegen vieler *kleiner* Objekte ein Performancekiller war, da die Allokatoren für große Speicherblöcke optmiert waren (so wie man sie in der Regel in C braucht). Das gilt so aber nicht mehr unbedingt.

Da es also in C++ nicht *eine* Strategie gibt, kann man auch nicht sagen ob diese in konstanter Zeit, in logarithmischer Zeit oder in welcher Zeit auch immer geschieht.

Gregor

Original erstellt von HumeSikkins:
**
Da es also in C++ nicht *eine* Strategie gibt, kann man auch nicht sagen ob diese in konstanter Zeit, in logarithmischer Zeit oder in welcher Zeit auch immer geschieht.**

Mit anderen Worten :

Es gibt Dinge, bei denen man nicht weiß, ob sie schnell oder langsam sind. Entsprechend kann man da wegen fehlendem Wissen auch keine vernünftige Optimierung betreiben. Wenn man etwas für einen Compiler gut optimiert hat, dann ist es dadurch vielleicht auf einem anderen Compiler langsamer geworden.

Somit spricht also nichts dagegen, an gewissen Punkten etwas Kompetenz an den Compiler abzutreten. Dadurch kriegt dieser auch weitere Möglichkeiten, zu optimieren.