D vs. C++
-
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...
-
dot schrieb:
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...
Schön, dann nutze mal den Objekt- bzw Maschinencode der mit dem richtigen Assembler erstellt wurde, von Java aus.
-
-
Apfelbirne, du bist lustig und unseriös zugleich.
Du scheinst die Sprache D nicht über die Definition einer Systemsprache zu zu einer solchen zu machen, sondern du definierst "Systemsprache" als das was D verkörpert, was totaler Blödsinn ist.
Dir ist schon bewusst, dass man mit ein paar entsprechenden Handgriffen theoretisch in jeder Sprache Betriebssysteme bauen kann wenn man will? Und wo ziehst du die Grenze wie viele Handgriffe erlaubt sind? Du ziehst die Grenze genau da, wo D noch zu Systemsprachen gehört und Java nicht mehr. Völliger Unsinn.
Da man theoretisch alles mit jeder Sprache machen kann, ist es unsinnig über "theoretisch wäre <XYZ> möglich..." zu argumentieren.
Sinnvoller wäre es eine Systemsprache als solche dann zu bezeichnen, wenn darin (in der entsprechenden Sprache) wirklich im erwähnenswerten Ausmaß (also nicht nur Einzelfälle/einzelne Experimente) Betriebssysteme entwickelt werden.
Das wäre eine realitätsnahe Definition und frei von Grauzonen.Und wenn man danach geht, was wirklich ist, dann endet die Suche bei C.
-
dot schrieb:
Tja, war wohl nix:
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.
Bedingung paar Seiten vorher nicht erfüllt. (nein, ich erachte das nicht als notwendig, dies ständig zu wiederholen)
-
Olaf Alaf schrieb:
:
Dir ist schon bewusst, dass man mit ein paar entsprechenden Handgriffen theoretisch in jeder Sprache Betriebssysteme bauen kann wenn man will? Und wo ziehst du die Grenze wie viele Handgriffe erlaubt sind? Du ziehst die Grenze genau da, wo D noch zu Systemsprachen gehört und Java nicht mehr. Völliger Unsinn.Nö, siehe auch die zuvor erwähnten Punkte echte Echtzeitfähigkeit & vollständig bewiesene Fehlerfreiheit.
Sinnvoller wäre es eine Systemsprache als solche dann zu bezeichnen, wenn darin (in der entsprechenden Sprache) wirklich im erwähnenswerten Ausmaß (also nicht nur Einzelfälle/einzelne Experimente) Betriebssysteme entwickelt werden.
Das wäre eine realitätsnahe Definition und frei von Grauzonen.Und wenn man danach geht, was wirklich ist, dann endet die Suche bei C.
AFAIK ist Haiku & BeOS in C++ programmiert.
-
Apfelbirne schrieb:
Nö, siehe auch die zuvor erwähnten Punkte echte Echtzeitfähigkeit & vollständig bewiesene Fehlerfreiheit.
In dem Fall würdest du wohl lieber Ada verwenden als C, C++ oder D
-
Olaf Alaf schrieb:
Und wenn man danach geht, was wirklich ist, dann endet die Suche bei C.
Noch was.
Und dann schau mal, was andere Firmen in der Praxis zur Systemprogrammierung nutzen:
We use the following programming languages:
C
C++
Assembly
FORTRANhttp://www.softage.ru/system_programming/
C++ wird also benutzt, schließe also nicht von dir auf andere nur weil du es nicht tust.
-
dot schrieb:
Apfelbirne schrieb:
Nö, siehe auch die zuvor erwähnten Punkte echte Echtzeitfähigkeit & vollständig bewiesene Fehlerfreiheit.
In dem Fall würdest du wohl lieber Ada verwenden als C, C++ oder D
Ja und, jeder Entwickler darf das nehmen, wofür er es am besten geeignet erachtet.
Auch wenn ich also der Meinung bin, daß C möglich ist, so würde ich für den Code für ein Atomkraftwerk trotzdem aus guten Gründen Ada nehmen.
Aber Java werde ich dafür niemals verwenden, bei Java ist es sogar nichtmal erlaubt, dies für ein AKW zu nutzen.
-
Apfelbirne schrieb:
C++ wird also benutzt, schließe also nicht von dir auf andere nur weil du es nicht tust.
Wenn im Endeffekt bei der Programmierung des Systems in C++ nur noch ein Subset-von C++ verwendet, welches man fast schon als C mit Klassen bezeichnen kann, dann kann doch wohl kaum die Rede von C++ sein.
-
Und nein, C code, der erfolgreich mit einem C++ Compiler kompiliert wurde, ist kein C++.
-
Apfelbirne schrieb:
Aber Java werde ich dafür niemals verwenden, bei Java ist es sogar nichtmal erlaubt, dies für ein AKW zu nutzen.
Weshalb nicht? Selbst die NASA setzt das für einen Marsroboter ein!
-
Apfelbirne schrieb:
AFAIK ist Haiku & BeOS in C++ programmiert.
Nein intern mit C, nur dass diese OSen eine C++API anbietet.
-
Steffo schrieb:
Apfelbirne schrieb:
Aber Java werde ich dafür niemals verwenden, bei Java ist es sogar nichtmal erlaubt, dies für ein AKW zu nutzen.
Weshalb nicht? Selbst die NASA setzt das für einen Marsroboter ein!
Für welchen Marsroboter?
Quelle?Mir ist kein Marsroboter bekannt, für den Java benutzt wird.
Macht auch wenig sinn, da Weltraumgeräte gegen Strahlung robust sein müssen und man daher auch bevorzugt neben hardend CPUs auch lahme CPUs in großer Fertigungstechnik verwendet, womit kein Platz für viel Leistung oder viel Speicherplatz da ist, was ein Java Programm aber mitsam VM benötigen würde.Ich würde sagen, deine Behauptung ist eine Urban Legend.
Und eventuell verwechselst du das mit normalen Desktopanwendungen die die NASA durchaus für diverse Weltraumprojekte verwendet, aber diese Anwendungen laufen auf normalen Computern und nicht auf Weltraumgerät.
