Nach C kommt D ...

klingt sehr ansprechend , aber die Seite ist anscheinend hoffnungslos überfordert oder einfach nur so down.

Hm, ich hab jetzt nur einen Blick auf die Comparison Table geworfen und bin mir nicht sicher was ich davon halten soll.
Ich bin froh dass es einen potentiellen Ablöser für das in die Jahre gekommene C++ gibt.
Imho steigt und fällt die mögliche Marktdurchdringung auch mit der Qualität des GUI Designers. Da ist .Net um einiges voraus.
Für D gibts einen Port der SWT. Naja, ich weiss nicht. Ich mag die Java GUIs nicht so wirklich.
Performance ist natürlich ein absolutes plus, nähere Benchmarks wären gut. Daher wirds auch für die Spieleentwicklung vermutlich interessant, wo die Anzeige sowieso primär über OpenGL/DirectX stattfindet.

Zitat von iCA-

irgendwie bezweifle ich, dass sich das durchsetzen wird. heutzutage muss da imho schon eine große firma wie ms bei .net oder sun bei java im hintergrund sein.

hab ich mir auch gedacht, allerdings liegt es nicht nur allein an den firmen, sondern man kann ja auch als informatiker was machen und wenn es wirklich so wie es im artikel bei heise beschrieben ist ziemlich gut sein soll wird es wohl über kurz oder lang eine alternative zu java, c# und c++ darstellen

Was ich auch vermisse ist die Möglichkeit Reflections einzusetzen. Gehört find ich zu einer modernen OOPSprache. Man kanns zwar auch ziemlich hässlich einsetzen, aber wenn man sich bemüht ist der Umgang damit doch ziemlich elegant.

den präprozessor wegfallen lassen und wie in java static variablen definieren? nicht einmal wenn das 100% gleich vom compiler interpretiert werden würde, wäre das wünschenswert.

und was ist nochmal an header files so schlecht? in java sind meine klassen im komplett zugemüllt. einzig und allein die template header dll-grenzensache (wer das kennt weiss was ich mein) nervt, aber dafür kann c/c++ herzlich wenig.

Zitat von gue

Zitat von r4pt0R^-

Inwieweit kann man die dpi bei der Habu umstellen?

In diesem Fall hat der Programmierer versagt. Wie so oft kommt es darauf an wie es eingesetzt wird. typedef std::map < std::string, std:air < A, B > > ::iterator ABPairIterator wird aus gutem Grund oft verwendet, und verständlich ists wohl, oder? Wenn ein Programmierer eine Instanz einer Rendererklasse nicht "renderer" sondern "apfelbaum" nennt, sind jetzt Objekte schlecht?

Zitat

Noch schlimmer wird das mit type inference: Viele Programmierer werden selbst nicht mehr wissen, welchen Typ sie da verwenden. "Ähm was liefert die Funktion noch mal zurück? Wurscht - auto x = func(); writeline(x);"

Hier dasselbe. Type inference kann leicht missbraucht werden, würde aber die umständlichen Iteratorinstanzen ohne dem von dir so verhassten typedef lösen (und einige andere nette Dinge erlauben). Btw. kommt Type Deduction in C++0x rein, das ist ein Äquivalent zu Type Inference.

Zitat

- Kein OO-Ansatz: "Freie Funktionen", Standardrepräsentation von Strings ist ein char[] (C lässt grüßen).

"Freie Funktionen" gibt es in C++ und in D ohnehin nicht wirklich. Die Funktionen, die du meinst, sind halt Teil des globalen Namespace. Und nein, nicht alles macht in Klassen Sinn.

Offenbar hast du auch von C keine Ahnung, denn dort ist die Standardrepräsentation ein char* Pointer zu einem Array, nicht das Array selbst. D kann Arrays direkt managen, C kennt Arrays nicht als eigenen Datentyp (der [] operator ist nur ein Index in einen Speicherbereich), daher sind Buffer overflows so leicht und diese einzudämmen so schwer (D weiss über Arraygrößen Bescheid, C logischerweise nicht). Ich hätte mir zwar auch eine echte Stringklasse als Standardrepräsentation gewünscht, aber char[] ist nicht schlecht.

Zitat

- Zu viele Schlüsselwörter, statt modernerer Techniken wie Annotationen. Beispiel: unittest Schlüsselwort statt z.B. [Test]-Annotation in C#.

Das ist reine Geschmackssache. Was ist an [Test] moderner als an unittest Test ?

Zitat von mat

Zitat von gue

Zitat von r4pt0R^-

Inwieweit kann man die dpi bei der Habu umstellen?

Headerfiles sind ein Hack, mehr nicht. Schon allein die Existenz von Include Guards beweist das (Fälle, die diese Guards nicht benötigen, sind eher selten und großteils nur bei C-Programmen zuhause). Headerfiles werden immer vom Präprozessor inkludiert, der Compiler hat dann eine Riesenwurscht vor sich, darum ist es guter Stil viele Forward declarations zu verwenden, um Compilezeiten zu verbessern. Systemspezifische Header wie windows.h sind AUCH drin, was v.a. bei plattformunabhängigen Code sehr problematisch sein kann. Last but not least fügt der Präprozessor auch private Klassenmembers ein - eine absolut sinnlose Aktion.

Die Templatesache ist teils auch ein C++-Problem. Ein System wie in Pascal mit Units und Interfaces wäre für C++ wohl das praktischste. Komplette Umstellung in das 1-File-System wäre wohl zu schwer (v.a. bei Templates).

Und, wenn deine Javafiles zugemüllt sind, solltest du an deinem Stil arbeiten, denn das ist die Zukunft. Künstliche Trennungen gibt es eher selten, und bei C war das kein Feature, sondern eine Konsequenz aus damaligen Compilern...

Schaut zumindest interessant aus. Obs wirklich besser is wird sich noch herausstellen und selbst dann wirds noch Jahre dauern bis es sich durchsetzt. Ich werd das auf jeden Fall genauer im Auge behalten.