D vs. C++

[Apfelbirne]

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.

[dot]

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

[Apfelbirne]

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.

[dot]

gern: http://de.wikipedia.org/wiki/Java_Native_Interface

[Olaf Alaf]

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.

[Apfelbirne]

dot schrieb:

gern: http://de.wikipedia.org/wiki/Java_Native_Interface

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)

[Apfelbirne]

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.

[dot]

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

[Apfelbirne]

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
FORTRAN

http://www.softage.ru/system_programming/

C++ wird also benutzt, schließe also nicht von dir auf andere nur weil du es nicht tust.

[Apfelbirne]

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.

[Olaf Alaf]

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.

[Olaf Alaf]

Und nein, C code, der erfolgreich mit einem C++ Compiler kompiliert wurde, ist kein C++.

[Gast]

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!

[Zeus]

Apfelbirne schrieb:

AFAIK ist Haiku & BeOS in C++ programmiert.

Nein intern mit C, nur dass diese OSen eine C++API anbietet.

[Apfelbirne]

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.

[volkard]

Naja, man kann's auch gant pragmatisch angehen.

public class OrbitalShip
{
  public static void main(String[] args)
  {
    while(true)
    {
      try
      {
         work();
      }
      catch(RadiationProblemHardwareException e)
      {
        Housten.out.print("We had a little Problem!");
      }		
    }
  }
}

[Zeus]

Apfelbirne schrieb:

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.

Äh, wo steht das, auf welche Programmiersprachen trifft solche Eigenschaft zu ?

[Apfelbirne]

Zeus schrieb:

Apfelbirne schrieb:

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.

Äh, wo steht das, auf welche Programmiersprachen trifft solche Eigenschaft zu ?

Das sind Eigenschaften des zu entwickelten Programms, allerdings muß die Programmiersprache dies ermöglichen können, was mit Java wegen der JVM, Garbage Collector & Co nicht geht, mit C, D oder C++ aber sehr wohl.

[volkard]

Apfelbirne schrieb:

Das sind Eigenschaften des zu entwickelten Programms, allerdings muß die Programmiersprache dies ermöglichen können, was mit Java wegen der JVM, Garbage Collector & Co nicht geht, mit C, D oder C++ aber sehr wohl.

Reitest Du auf der Echtzeitfähigkeit herum? Erstmal lesen, was das ist…
Ah, einfach nur rechtzeitig antworten können. Da sind VM und GC keine technischen Gegenargumente. Im Gegenteil: GC-Allokationen sind in O(1) und die Deallokationen sind dann normal (und zur Zeit lahm), können aber recht frei vorgeblendet und verzögert werden, verzögern also den Nachrichtenbehandler nicht!! Die Anwendung muß auf Allokationen warten. Auf Deallokationen nicht. Sogesehen ist Java auf schmalbrüstiger Hardware prinzipiell besser geeignet, engere Grenzen der "Quasi-Echtzeit" zu gewährleisten. Und mehr tun wir eh nicht. Echte Echtzeit kannste in Büchern lesen, aber kaumn noch erleben. Außer, wegen anderer Gründe, wie der Strahlungsfestigkeit millimeter breiter Leiter, ist die echte Echtzeit noch zufällig da. Dann wird sie natürlich groß angepriesen.

[Apfelbirne]

volkard schrieb:

Da sind VM und GC keine technischen Gegenargumente. Im Gegenteil: GC-Allokationen sind in O(1) und die Deallokationen sind dann normal (und zur Zeit lahm), können aber recht frei vorgeblendet und verzögert werden, verzögern also den Nachrichtenbehandler nicht!!

Es wäre mir neu, daß man beim GC von Java kontrollieren könnte, wann auf den Ausführungsbefehl genau er unnötige Daten löschen soll.

Bei C++ hat man hier dank Destruktur der voll in der Kontrolle des Programmieres liegt, sicher eine deutlich bessere Kontrolle.

Und die VM ist ein Gegenargument, weil die praktisch wie ne Blackbox ist und man keine Kontrolle über sie hat, was sie gerade tut oder zu tun hat.

Damit schaffst du vielleicht semi bis pseudo Echtzeitfähigkeit, aber eben nicht harte Echtzeitfähigkeit die gut genug ist, um z.B. auf physikalische Prozesse am LHC & Co im Nanosekundenbereich zu reagieren.

Zumal Java auch keine Zeitauflösung bietet die besser als 1 ms ist.

Und mehr tun wir eh nicht.

Tut ihr nicht.
Aber das Anwendungsgebiet der Systemprogrammierung ist groß, so daß es auch vorkommen kann, daß Semi/Pseudo-Echtzeitfähigkeit oder wie du es nennst, Quasi-Echtzeitfähigkeit nicht genügt.

Echte Echtzeit kannste in Büchern lesen, aber kaumn noch erleben.

Wird trotzdem noch benötigt.