D vs. C++



  • @Apfelbirne

    Building and Running Singularity schrieb:

    Getting Started
    ...
    This document describes the steps to build the Singularity source code and boot your Singularity image into Virtual PC or real hardware.
    ...

    Wenn man Gegenargumentiert sollte man, wenigstens sich mal die Sachen ansehen.



  • Zeus schrieb:

    @Apfelbirne

    Building and Running Singularity schrieb:

    Getting Started
    ...
    This document describes the steps to build the Singularity source code and boot your Singularity image into Virtual PC or real hardware.
    ...

    Wenn man Gegenargumentiert sollte man, wenigstens sich mal die Sachen ansehen.

    Ach komm, da wird einfach nativ mit nem speziellen Compiler compiliert und viel drumrum mitgeliefert.

    Aber laß uns einfach mal schauen, was Heise Developer zur Systemprogammierung sagt:

    Nach Meinung des Autors sind die Sprachen der (direkten) C-Familie (C/C++ und D) immer noch die einzigen, die sich für die Systemprogrammierung eignen

    http://www.heise.de/developer/artikel/C-11-auch-ein-Stimmungsbild-1345406.html



  • Apfelbirne schrieb:

    Zeus schrieb:

    @Apfelbirne

    Building and Running Singularity schrieb:

    Getting Started
    ...
    This document describes the steps to build the Singularity source code and boot your Singularity image into Virtual PC or real hardware.
    ...

    Wenn man Gegenargumentiert sollte man, wenigstens sich mal die Sachen ansehen.

    Ach komm, da wird einfach nativ mit nem speziellen Compiler compiliert und viel drumrum mitgeliefert.

    Aber laß uns einfach mal schauen, was Heise Developer zur Systemprogammierung sagt:

    Nach Meinung des Autors sind die Sprachen der (direkten) C-Familie (C/C++ und D) immer noch die einzigen, die sich für die Systemprogrammierung eignen

    http://www.heise.de/developer/artikel/C-11-auch-ein-Stimmungsbild-1345406.html

    Ups, etas zu kurz zitiert, da steht noch mehr wichtiges:

    Nur sie bringen die Voraussetzungen (zum Beispiel Hardwarenähe) mit, Rechner bis an ihre Leistungsgrenze auszureizen. Ulrich Drepper sprach das in einem Vortrag auf einem früheren LinuxTag am Beispiel von NUMA-Architekturen (Non-Uniform Memory Access) an: Im Gegensatz zu Fortran, C und C++, so der GLIBC-Maintainer, seien die zur Ausreizung der Möglichkeiten moderner NUMA-Systeme nötigen Programmierschnittstellen zur Speicher- und Prozessaffinität in anderen Sprachen noch nicht einmal vorhanden.

    Herb Sutter schlug in dieselbe Kerbe, als er auf der diesjährigen "C++ And Beyond"-Konferenz in seiner Keynote "Why C++" das Ende des verlorenen Jahrzehnts für C++ und die Rückbesinnung auf Performance, und damit auf C++, auch und vor allem bei seinem Arbeitgeber Microsoft, herausstellte.

    Auch wenn die Aussagen und die damit einhergehenden Implikationen mit einer Portion Skepsis zu behandeln sind, zeigen sie beispielhaft eine weitverbreitete Ansicht: C und C++ sind Sprachen für die Systemprogrammierung, Java, C# und Konsorten sind nur für die Anwendungsentwicklung geeignet. Vertreter beider Lager stellen zwar gerne heraus, dass ihre Sprache sehr wohl in der Domäne der anderen zu überzeugen vermag, doch ist ein Anwendungsentwicklerteam gut beraten, C++ nur zu wählen, wenn das notwendig ist, um die Hardware auszureizen. Und umgekehrt.

    Gerade deshalb haben jedoch C++ und die "sauberere C++-Alternative" D gute Chancen, verloren gegangenes Terrain (zurück) zu erobern. Die aktuelle Diskrepanz zwischen dem Fortschritt in der Parallelität der Hardware auf der einen Seite und der vergleichsweisen Rückständigkeit der Programmiermodelle auf Softwareseite zwingen (System- und Anwendungs-)Entwickler im Moment dazu, sich mit der Hardware auf einer Ebene zu beschäftigen, wie das seit den 1980er-Jahren nicht mehr der Fall war.



  • Apfelbirne, ich denke nicht, dass deine Definition haltbar ist. Javascript kann man zu nativem Code kompilieren und C kann man interpretieren. Wo ziehst du die Grenze? Mit nur wenigen zusätzlichen Funktionen (z.B. readMemoryAt , writeMemoryAt ) hat JS vollen Hardwarezugriff.

    Man kann sicherlich für eine gegebenen Sprache entscheiden, ob sie zum jetzigen Zeitpunkt für Systemprogrammierung geeignet ist, aber eine Schwarz-Weiß-Unterteilung in Systemprogrammiersprache oder nicht halte ich für naiv.



  • Zeus schrieb:

    @Apfelbirne

    Building and Running Singularity schrieb:

    Getting Started
    ...
    This document describes the steps to build the Singularity source code and boot your Singularity image into Virtual PC or real hardware.
    ...

    Wenn man Gegenargumentiert sollte man, wenigstens sich mal die Sachen ansehen.

    Und dazu noch etwas.

    Schau mal, ob deine Spielerei, also dieses C# OS auch de nerweitereten AVX Befehlssatz nutzen tut!

    Mit C, D, C++ kann ich das IMMER machen, wenn es der Compiler nicht kann, dann erlauben mir C, D und C++ Inline Assembler mit dem das geht.

    Und jetzt probier das mal mit Java, C# oder Javascript, ohne auf extra APIs zuzugreifen die mithilfe von C & Co dafür programmiert wurden, um genau das zu können.



  • thread-leser schrieb:

    Apfelbirne, ich denke nicht, dass deine Definition haltbar ist. Javascript kann man zu nativem Code kompilieren und C kann man interpretieren. Wo ziehst du die Grenze? Mit nur wenigen zusätzlichen Funktionen (z.B. readMemoryAt , writeMemoryAt ) hat JS vollen Hardwarezugriff.

    Nutze AVX in Javascript ohne den Compiler dafür vorzubereiten.



  • Apfelbirne schrieb:

    Mit C, D, C++ kann ich das IMMER machen, wenn es der Compiler nicht kann, dann erlauben mir C, D und C++ Inline Assembler mit dem das geht.

    Zeig mir bitte die Stelle im C++ Standard wo das steht.



  • Und noch etwas.

    In der Systemprogrammierung muß es bei Bedarf auch möglich sein, Code zu schreiben, der eine vollständig bewiesene Fehlerfreiheit und harte echte Echtzeitfähigkeit liefern kann.

    Mit C, D und C++ geht das (auch wenn ich bei Sicherheitskritischen Dingen eher Ada nehmen würde, aber es geht), bei Javascript mußt du dich auf die Javascript Laufzeitumgebung verlassen.





  • dot schrieb:

    Apfelbirne schrieb:

    Mit C, D, C++ kann ich das IMMER machen, wenn es der Compiler nicht kann, dann erlauben mir C, D und C++ Inline Assembler mit dem das geht.

    Zeig mir bitte die Stelle im C++ Standard wo das steht.

    Du kannst in C++ Inline Assembler nutzen. Jeder gute C++ Compiler kann das.

    In D ist das Schlüsselwort asm{} sogar Teil des Standards.



  • dot schrieb:

    Btw: http://en.wikipedia.org/wiki/PicoJava

    Hatte ich als Ausnahme schon genannt, siehe oben "Java µC".
    Da inzwischen Tot, nicht der Rede wert.

    Und wenn eine Sprache eine ganz spezielle HW braucht, damit man von Systemprogrammierung sprechen kann, dann ist das kein besonders gutes Zeichen, daß die Sprache zur Systemprogrammierung auszeichnen soll.



  • Apfelbirne schrieb:

    Du kannst in C++ Inline Assembler nutzen. Jeder gute C++ Compiler kann das.

    Nö, MSVC z.B. kanns nur unter bestimmten Umständen. Aber inline Asm ist sowieso unwichtig.



  • Apfelbirne schrieb:

    In D ist das Schlüsselwort asm{} sogar Teil des Standards.

    Siehe auch:
    http://www.d-programming-language.org/iasm.html



  • Ja aber von AVX steht nix im Standard. Der Standard definiert nichtmal die Syntax von inline Asm, was inline Asm zu ner praktisch zu 100% unportablen Geschichte macht. Aber wie gesagt spielt inline Asm sowieso keine Rolle, also wen interessierts 😉



  • dot schrieb:

    Apfelbirne schrieb:

    Du kannst in C++ Inline Assembler nutzen. Jeder gute C++ Compiler kann das.

    Nö, MSVC z.B. kanns nur unter bestimmten Umständen. Aber inline Asm ist sowieso unwichtig.

    MSVS Express Edition != MSVC Prof.

    Kauf dir also mal ein richtiges und nicht abgespecktes und künstlich limitierstes MSVC.
    Ich kann Inline Assembler in meinem MSVC jedenfalls nutzen.

    _asm{}

    http://msdn.microsoft.com/en-us/library/4ks26t93(v=vs.80).aspx



  • Apfelbirne schrieb:

    Ich kann Inline Assembler in meinem MSVC jedenfalls nutzen.

    Nö kannst du nicht, lies die von dir verlinkte Seite mal aufmerksam durch...
    Mit Express oder nicht hat das nix zu tun, alle Editionen von Visual Studio verwenden den selben Compiler.



  • dot schrieb:

    Ja aber von AVX steht nix im Standard...

    Warum sollte AVX im Sprachstandard stehen?

    Es ist ein CPU spezifischer Befehlssatz und D erlaubt mir mit Hilfe von inline Assembler diesen Befehlssatz zu nutzen, wenn es die D Compilerimplementierung noch nicht kann.

    Bei JAVA geht das z.B. nicht.
    Hier rennt die JVM immer hinterher und inline Assembler ist in Java erst gar nicht möglich. (zumindest nicht ohne C Ausweichkonstrukte als API Hilfe)

    Genau wegen solchen Sachen, ist C in der Systemprogrammierung ja immer noch führend und wurde nie von Java, C# und Co abgelöst.



  • dot schrieb:

    Apfelbirne schrieb:

    Ich kann Inline Assembler in meinem MSVC jedenfalls nutzen.

    Nö kannst du nicht, lies die von dir verlinkte Seite mal aufmerksam durch...
    Mit Express oder nicht hat das nix zu tun, alle Editionen von Visual Studio verwenden den selben Compiler.

    Schön, wenn du das meinst:
    "Inline assembly is not supported on the Itanium and x64 processors"

    Und ich kann trotzdem immer noch einen separaten Assembler wie MASM oder NASM nehmen und dann von meinem C, C++ oder D Code den jeweiligen mit MASM oder NASM erstellten Objektcode verwenden.
    Mach das mal mit Java.



  • dot schrieb:

    Apfelbirne schrieb:

    Du kannst in C++ Inline Assembler nutzen. Jeder gute C++ Compiler kann das.

    Nö, MSVC z.B. kanns nur unter bestimmten Umständen. Aber inline Asm ist sowieso unwichtig.

    In der Anwendungsentwicklung vielleicht, in der Systemprogrammierung ist Asm nach wie vor wichtig und manchmal sinnvoll.



  • Apfelbirne schrieb:

    dot schrieb:

    Ja aber von AVX steht nix im Standard...

    Warum sollte AVX im Sprachstandard stehen?

    Darum gehts ja. Du läufst hier rum und behauptest du könntest mit C++ AVX nutzen, das ist aber natürlich Schwachsinn, weil AVX absolut nichts mit C++ zu tun hat. Auf die Tatsache dass nicht jeder Compiler inline Asm überhaupt erst unterstützen muss und dass es dafür schon gar keine einheitliche Syntax gibt, hab ich ja auch schon Hingewiesen. Wenn man z.B. bedenkt, dass Windows mit MSVC gebaut wird und MSVC inline Asm nur für eine einzige, mittlerweile unwichtige, Plattform unterstützt, dann fragt man sich schon wie wichtig inline Asm jetzt für diese "Systemprogrammierung" sein soll. Immerhin sitz ich vor einem 64bit Betriebssystem, das mit einem x64 MSVC gebaut wurde, der kein inline Asm unterstützt. Das bisschen ASM was man für ein OS tatsächlich braucht kann man auch gleich einfach durch nen richtigen Assembler jagen. Hat noch dazu den Vorteil dass der C++ Code portable bleibt und die richtig plattformspezifischen Dinge vom Buildsystem dazugelinked werden können...


Anmelden zum Antworten