Eigentlich schade, dass man mit dir scheinbar nicht ernsthaft diskutieren kann. Letzter Versuch.
Also C++ hat besonders in der Pointerei "Schwächen" welche sich böse ausnutzen lassen. Hier übernimmt D die Speicherverwaltung selbst (kann man auch ausschalten).
D hat einen GC. Ob das ein Vorteil oder ein Nachteil ist, darüber kann man sich streiten. Solange er abschaltbar ist kann ja jeder selber entscheiden. Nur, wer C++ programmieren KANN (ich verweise auf RAII und so Scherze), der ist nur ganz selten auf wilde Pointerei angewiesen und das kann man oft auch noch wunderbar kapseln. Für alltägliches gibt es diverse Container, Smart-Pointer usw. Wer C++ nur als ein C mit Klassen sieht und wild auf blanken Arrays rumpointert oder Sachen wie printf und Co verwendet, der baut natürlich anfälligen Code. Solche Sachen sind in der C++ Community mehr als verpönt. Ich sehe einen GC jedenfalls nicht als Allheilmittel um unerfahrene Anwender davor zu bewahren Memory Leaks zu bauen.
BTW: Auch für C++ gibt es GCs, die allerdings kaum ein Schwein einsetzt. Mag daran liegen, dass es kein direktes Sprachfeature ist und man sich für so etwas, was nicht unbedingt nötig ist, ungerne eine weitere Library ins Boot holt.
Ich bin nicht "nur" an den objektorientierten Programmierstil gebunden, sondern könnte auch prozedural programmieren. Ich kann es sogar mischen oder direkt in den Code Assembler Code einfügen.
Wo ist jetzt der Vorteil ggü. C++? Eben diese Sachen kann ich dort alle auch machen. Ich kann sogar in Java prozedural programmieren oder in C objektorientiert. Bloß weil eine Sprache gewisse Paradigmen von Haus aus unterstützt ist man ja nicht daran gebunden.
Wenn ich Spass dran hab, kann ich C Bibliotheken einbinden (dank der C-ABI) und ansprechen, dass zeigst Du mir mal in C++.
Da laust mich doch der Affe! Nee, DAS ist GANZ sicher nicht möglich mit C++ </ironie> Und dass C einen Schulabschluss hat war mir auch neu
.
Und für das schreiben von "Ernsthaften Programmen": Intergriertes Unit-Testing, Junge DAS ist für grosse Projekte ein Killerfeature!
Es gibt für die Mainstream-Sprachen Unit-Testing-Frameworks. Ich sehe also nicht warum eine Firma von bereits etablierten Lösungen dringend auf D umsatteln muss. "Junge" (um in deiner Sprache zu bleiben), weißt du eigentlich was es kostet mit einem Großprojekt mal eben mir nichts, dir nichts die Programmiersprache zu wechseln? Die meisten Programme übertreffen nunmal den Codeaufwand einer DVD-Verwaltungssoftware. Natürlich ist es nett, dass D z.B. Design by Contract integriert hat usw., sage ja nichts negatives darüber. Aber es ist sicher kein Killerfeature für den Umstieg, weil man das in anderen Sprachen auch bereits haben kann. Und für neue Projekte bleibt das Risiko, dass D in 10 Jahren von der Bildfläche verschwunden sein könnte. Neee, also wenn sich keine namhaften Firmen finden, die D pushen dann sehe ich schwarz.
Ich persönliche finde alle Neuerungen sehr sehr gut und begrüsse das sehr.
Ich auch!?!
Wenn Du nicht mit D programmieren willst dann lass es eben.
Wie gesagt. Die Frage in diesem Thread war, ob wir uns vorstellen können, dass D es gegen C/C++/Java schafft oder wieder untergehen wird. Es gibt eine Menge interessanter Sprachen (Ada 95, Ruby, Ocaml usw.), die aber für die meisten Leute höchstens zu Studienzwecken interessant sind, eben weil sie kaum ernsthaft verwendet werden. Ich denke, dass es mit D ähnlich sein wird, nicht mehr und nicht weniger. Und so wie ich dein erstes Posting interpretiere sind wir uns doch da einig.
Die Zeiten von Pascal sind noch gar nicht so lange her, und damit konnte man nicht wirklich etwas anfangen (ging zumindest mir so).
