Wie heißt der Nachfolger ...
-
Gibts da mittlerweile auch einen Linux Compiler?
-
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.
-
leider noch nicht, aber soll bald soweit sein.
syncronize { Noesis->pc_neu_start(); }@Loggy: brauchen neue Keywords.
-
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:
-
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!
-
Original erstellt von Helium:
[QB]für Valuesemantik.Warum?
-
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)
-
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. ]
-
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.
-
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)
-
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. ]
-
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
-
Original erstellt von Etti:
Ich bin mir nicht ganz sicher, aber ich vermute, er würde melden, dass nicht genügend freier Speicher vorhanden istVermute 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. ]
-
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
-
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
-
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.
-
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.
-
Es gibt Dinge, bei denen man nicht weiß, ob sie schnell oder langsam sind
Genau. Deshalb heißt es ja auch: nicht raten sondern messen!
. Entsprechend kann man da wegen fehlendem Wissen auch keine vernünftige Optimierung betreiben.
Dem Schluss kann ich nicht folgen. Man kann natürlich niemals eine genrell global gültige Optimierung erzielen. Jedes Verfahren hat seine Vor- und Nachteile. Das heißt aber doch nicht, dass ich nicht optimieren kann. Jede Optimierung ist aber immer nur in einem bestimmten Kontext gültig.
Wenn man etwas für einen Compiler gut optimiert hat, dann ist es dadurch vielleicht auf einem anderen Compiler langsamer geworden.
Natürlich. Das gilt aber doch immer. Wenn ich meinen Code für ein Pentium X optimiere, ist er auf einem Athlon wahrscheinlich langsamer.
Somit spricht also nichts dagegen, an gewissen Punkten etwas Kompetenz an den Compiler abzutreten.
Nö. Natürlich nicht. Das macht man ja auch in extrem vielen Situationen. Ich kümmere mich z.B. nicht um die optimale Registerbelegung.
-
Und trotzdem möchte ich vielleicht einige Objekte auf dem Stack ablegen können! Basta!
-
Du vergleichst hier auch Äpfel mit Birnen.
Klar, weißt Du bei Java, wie Du am besten optimierst, weil Du weißt, wie Java den Speicher reserviert. Aber eigentlich weißt Du nicht, wie Java das macht sondern nur, wie der Java-Compiler von Sun das macht. In C gibts nun mal Compiler von vielen verschiedenen Herstellern. Und ob die Optimierung, die Du durchführst für ne VM vom MS (gibts die noch?) genausogut ist, wie sie auf der von Sun war, is ne andere Frage. Oder auch, ob eine VM-Implementierung auf System X mit Deiner Optimierung genausoviel anfangen kann wie die VM auf System Y kannst Du auch nicht sagen. Könnte ja sein, dass System Y schon besonders gute Systemfunktionen mitbringt, damit der Speicher nicht fragmentiert und die VM auf System Y diese Eigenschaft nutzt. Hochoptimierten Code wirst Du also auch in Java nur für ein System schreiben können.