D vs. C++



  • Olaf Alaf schrieb:

    In der Praxis frickelt man eben in C. Und alles andere ist heutzutage höchstens ein Experiment, aber NOCH nichts ernstzunehmendes.

    Hm, stimmt. Ich nehme mein Betriebssystem, meine IDE+Compiler, meinen Browser und das ganze Gedöns auch nicht wirklich ernst.



  • pumuckl schrieb:

    Olaf Alaf schrieb:

    In der Praxis frickelt man eben in C. Und alles andere ist heutzutage höchstens ein Experiment, aber NOCH nichts ernstzunehmendes.

    Hm, stimmt. Ich nehme mein Betriebssystem, meine IDE+Compiler, meinen Browser und das ganze Gedöns auch nicht wirklich ernst.

    Hättest du den Thread gelesen, wüsstest du, dass sich Olaf damit ausdrücklich auf Systemprogrammierung bezieht.

    @Apfelbirne: Du verstehst nicht, es geht nicht darum, was "man" kann, sondern was "man" tut. Mit geeigneten Bibliotheken, Frameworks und Wrappern kann man seinen Mikrocontroller auch in Javascript programmieren, kein Problem. Nur wird in der Praxis de facto zu >99% C benutzt, da kannst du auf der Tauglichkeit von D oder Heldenmut herumreiten wie du willst.



  • C++ lässt sich mit einem geeignetem Subset genauso gut für Low-Level Programmierung nutzen. RTTI und Exceptions einfach nicht benutzen und am Anfang manuell Konstruktoren aufrufen. Mehr muss man nicht machen und man profitiert eigentlich nur noch von C++'s Extras.

    Zu 😨 Hab mir mal die Gegenüberstellung von C++ und D angeschaut und die "Verbesserungen" von D klingen größtenteils vollkommen blödsinnig. Größtenteils Sachen die C++ aus guten Gründen einfach nicht als Sprachfeatures sondern als Teil von Bibliotheken implementiert.



  • Ethon schrieb:

    und am Anfang manuell Konstruktoren aufrufen.

    Also bei meinem Mini-OS muss ich keine Konstruktoren manuell aufrufen. Wovon sprichst du?



  • 314159265358979 schrieb:

    Ethon schrieb:

    und am Anfang manuell Konstruktoren aufrufen.

    Also bei meinem Mini-OS muss ich keine Konstruktoren manuell aufrufen. Wovon sprichst du?

    Das hängt vom Compiler und verwendeten Binary-Format ab. ELF-Binaries haben z.B. eine eigene .init und .fini Section. Wenn der Compiler diese verwendet und der OS-Loader sich nicht drum kümmert bei Prozessstart bzw. -ende dort mal reinzucallen, werden die Konstruktoren und Destruktoren von Objekten mit static storage duration z.B. nicht aufgerufen...



  • Genau. Läuft zb beim GCC auf ungefähr soetwas heraus:

    // Lizenz: public domain
    
    typedef void (*constructor)();
    
    // Im Linkerskript definiert
    extern "C" constructor start_ctors;
    extern "C" constructor end_ctors;
    
    extern "C" void initialiseConstructors();
    
    // Ruft die Konstruktoren für globale/statische Objekte auf
    void initialiseConstructors()
    {
      for (constructor* i = &start_ctors;i != &end_ctors;++i)
        (*i)();
    }
    


  • Ach, das meinst du. Naja, das ist ja nicht wirklich ein Problem.



  • thread-leser schrieb:

    @Apfelbirne: Du verstehst nicht, es geht nicht darum, was "man" kann, sondern was "man" tut. Mit geeigneten Bibliotheken, Frameworks und Wrappern kann man seinen Mikrocontroller auch in Javascript programmieren, kein Problem.

    Und noch einer, der nicht verstanden hat, was eine Programmiersprache für die Systemprogrammierung ist.

    Mit einer Programmiersprache für die Systemprogrammierung kannst du ein Betriebssystem programmieren, daß direkt nativ auf der Hardware läuft.
    Das geht mit Javascript niemals, denn Javascript braucht mindestens einen Scriptinterpreter der dazu selbst noch ein OS braucht.
    Javascript ist also keine Programmiersprache für die Systemprogrammierung, D und C++ dagegen schon.

    Und es geht auf keinen fall darum, was man tut, sondern darum welche Eigenschaften die Programmiersprache besitzt um etwas zu tun.

    Nur wird in der Praxis de facto zu >99% C benutzt, da kannst du auf der Tauglichkeit von D oder Heldenmut herumreiten wie du willst.

    Das ist irrelevant, denn die Frage war, welche Sprachen zu den Sprachen der Systemprogrammierung dazugehören und C++ und D gehören neben C nunmal genau dazu.
    Javascript und Java aber (mit Ausnahme dieser eingestellten Java µC) niemals, denn die brauchen wie bereits gesagt, mindestens schonmal einen Interpreter oder eine VM.

    Leute, ihr müßt also erstmal lernen was Systemprogrammierung bedeutet.



  • Bei Microsoft gibst nen Betriebssystem im Managed Code 🙂 Source Code: http://singularity.codeplex.com/SourceControl/changeset/view/45126



  • Noch etwas, da der Begriff wirklich nicht klar zu sein scheint.

    Der Begriff Systemprogrammierung kommt nicht von der Aufgabenstellung "Systeme zu programmieren".

    Nach dieser Definition könnte man nämlich selbst mit Java, Scriptsprachen und Basic Systeme programmieren, solange man die notwendigen Laufzeitumgebungen installiert, so wie du "thread-leser" und "Olaf Alaf" es verstanden haben.
    Aber das ist nicht die korrekte Definition von Systemprogrammierung.

    Systemprogrammierung ist anders defniet.
    Systemprogammierung zeichnet sich dadurch aus, ohne nennenswerte Hilfen wie VM, RundumschlagAPIs, Interpreter & Co hardwarenah zu programmieren, so daß die Hardware erst für andere übergeordnete Anwendungsprogramme, Interpreter und damit später auch Abstrakte High Level Sprachen wie z.b. diverse Scriptsprachen erst überhaupt lauffähig wird.

    D.h. mit Systemprogrammierung programmiert man das OS, die Firmware, die Treiber und meinetwegen auch noch eine grundlegende Systemlib, teilweise auch unter Verwendung von Inline Assembler & Co.

    Und um um das zu tun muß die dafür verwendete Programmiersprache diverse Eigenschaften besitzen.
    C, D und C++ besitzen diese Eigenschaften, deswegen sind diese Sprachen für die Systemprogrammierung geeignet.

    So, ich hoffe jetzt ist endlich klar, was Systemprogrammierung bedeutet.



  • Zeus schrieb:

    Bei Microsoft gibst nen Betriebssystem im Managed Code 🙂 Source Code: http://singularity.codeplex.com/SourceControl/changeset/view/45126

    Und das läuft nicht ohne .Net Umgebung.
    Also Schwachsinnsvergleich.

    Das es Versuche gibt, Betriebssysteme in Java zu schreiben kenne ich auch, aber wenn die dann im Browser laufen müssen und ein großes Geraffel an VM, Webserver usw. benötigen, um überhaupt ausführbar zu sein, dann ist das keine Systemprogrammierung.

    Es ist halt ein netter Versuch ein Bestriebsystem auf Anwendungsebene zu entwickeln, mehr aber auch nicht.

    Ich persönlich halte nicht viel von Betriebssystemen auf Anwendungsebene, denn die reichen gerademal als Lerntest, für die Praxis ist das aber ziemlich weltfremd.
    Denn in der Praxis hat man echte Hardware ohne irgendwelche Hilfsumgebungen.



  • @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.




Anmelden zum Antworten