C# nachfolger von C++
-
In letzter Zeit werden auch Echtzeitsysteme in Java geschrieben, was aber wohl an einem Mangel von Ada Programmierern liegen dürfte(Echtzeit bedeutet nur definierte Antwortzeiten, nicht Performance).
Du kannst kein Echtzeitsystem in Java oder C# programmieren, weil man nicht vorhersagen kann wann der GC "zuschlägt". Es seih den die Systeme haben einen eigene JVM.
Hem, nö. Finde ich nicht. Ich kann in jeder Sprache gleich gut GUIs entwickeln. Für C++ gibts sogar mehr GUI-Toolkits als für Java und C# zusammen!
Das hat eher einen anderen Grund. In Java und C# hast du schon einen sehr guten GUI-Toolkit, der von großen Firmen entwickelt wird. Der große Vorteil von Java und C# ist die einheitliche API (z.b. alle nehmen die Sun-String-Klasse, in C++ ist es ein Wirrwar von char*, std::string, CString, WhateverString)
Definitiv ist also C++ immer noch die mächtigste Programmiersprache auf dem Markt ja ? Ich verstehe ganz ehrlich gesagt nicht warum immer mehr Firmen auf C# bzw. .Net basieren und Leute mit solchen Kenntnissen suchen und nicht bei den C++ Programmierern bleiben. Kann mir auch da jemand ein Statement geben ?
Mächtigkeit ist nicht immer ein Vorteil. Je komplexer eine Sprache ist, desto schlechter wartbar und desto fehleranfälliger ist sie.
C# und Java bieten mordernere Lösungen an, zB Paketverwaltung (das include-System in C++ ist extrem altmodisch), Threads...
es wäre nicht sinnvoll ein system in c# zu schreiben
Wieso wäre es nicht sinnvoll?
-
DEvent schrieb:
Du kannst kein Echtzeitsystem in Java oder C# programmieren, weil man nicht vorhersagen kann wann der GC "zuschlägt".
...oder wie lange der braucht.
naja, da könnte man ja eine art interrupt einbauen, der den gc unterbricht...
-
DEvent schrieb:
In letzter Zeit werden auch Echtzeitsysteme in Java geschrieben, was aber wohl an einem Mangel von Ada Programmierern liegen dürfte(Echtzeit bedeutet nur definierte Antwortzeiten, nicht Performance).
Du kannst kein Echtzeitsystem in Java oder C# programmieren, weil man nicht vorhersagen kann wann der GC "zuschlägt". Es seih den die Systeme haben einen eigene JVM.
Oh, interessant. Kannst Du mir dann mal sagen, was genau das da ist?
-
Gregor schrieb:
DEvent schrieb:
In letzter Zeit werden auch Echtzeitsysteme in Java geschrieben, was aber wohl an einem Mangel von Ada Programmierern liegen dürfte(Echtzeit bedeutet nur definierte Antwortzeiten, nicht Performance).
Du kannst kein Echtzeitsystem in Java oder C# programmieren, weil man nicht vorhersagen kann wann der GC "zuschlägt". Es seih den die Systeme haben einen eigene JVM.
Oh, interessant. Kannst Du mir dann mal sagen, was genau das da ist?
http://jcp.org/en/jsr/detail?id=1
This extension is necessary because the guarantees and APIs provided by the standard Java platform do not meet the needs of real-time systems. For example, real-time systems require strong deterministic guarantees and/or control in the areas of thread scheduling, synchronization overhead, lock queuing order, class initialization, maximum interrupt response latency, and GC characteristics. These needs are not met by the standard Java platform, and there is no other extension that addresses them.
Ich bin von der aktuellen Sun-JMV ausgegangen. Ausserdem habe ich dazugeschrieben, man bräuchte eine eigene JVM.
The specification will require updates and/or additions to both the Java Virtual Machine* Specification and the Java Language Specification at least at the semantic level.
-
DEvent schrieb:
Ich bin von der aktuellen Sun-JMV ausgegangen. Ausserdem habe ich dazugeschrieben, man bräuchte eine eigene JVM.
Ah so... gehst Du auch vom aktuellen Windows als darunterliegendes System aus? Da ist nämlich auch generell nichts mit Echtzeit.
Naja, zumindest gibt es in der Javawelt sehr wohl Möglichkeiten, echtzeitfähige Systeme zu erstellen. Darauf wollte ich hinaus.
-
Gregor schrieb:
Naja, zumindest gibt es in der Javawelt sehr wohl Möglichkeiten, echtzeitfähige Systeme zu erstellen.
naja, aber bei 'echtzeit' geht's ja im prinzip nur um die garantierten antwortzeiten (hat ja schon jemand geschrieben hier). wenn man z.b. einmal pro sekunde eine zustandsänderung an einem i/o port erkennen muss, dann geht das auch mit java. passiert das aber 1000 mal pro sekunde, dann sollte man von java besser die finger lassen (und von .NET natürlich auch)...
-
net schrieb:
Gregor schrieb:
Naja, zumindest gibt es in der Javawelt sehr wohl Möglichkeiten, echtzeitfähige Systeme zu erstellen.
naja, aber bei 'echtzeit' geht's ja im prinzip nur um die garantierten antwortzeiten (hat ja schon jemand geschrieben hier). wenn man z.b. einmal pro sekunde eine zustandsänderung an einem i/o port erkennen muss, dann geht das auch mit java. passiert das aber 1000 mal pro sekunde, dann sollte man von java besser die finger lassen (und von .NET natürlich auch)...
blubb blubb.
-
Optimizer schrieb:
blubb blubb.
hey, ich will jetzt keinen flamewar starten oder sowas. ich mag java auch, aber für schnellen low-level kram ist es nicht geeignet. ist doch nicht schlimm, dafür hat es andere vorzüge.
-
net schrieb:
naja, aber bei 'echtzeit' geht's ja im prinzip nur um die garantierten antwortzeiten (hat ja schon jemand geschrieben hier). wenn man z.b. einmal pro sekunde eine zustandsänderung an einem i/o port erkennen muss, dann geht das auch mit java. passiert das aber 1000 mal pro sekunde, dann sollte man von java besser die finger lassen (und von .NET natürlich auch)...
Naja, etwas mehr kannst Du Java schon zutrauen.
http://java.sun.com/javase/technologies/realtime.jsp#faq
Q: How fast is Java RTS? How do you measure Java RTS's performance?
Java RTS performance is measured in two ways: throughput performance for non-real-time logic, and maximum latency and jitter for hard real-time logic. (note: latency is defined as the average time it takes the system to respond to a higher priority interrupt; jitter is a measure of the variability of the latency number) For non-real-time logic this release of Java RTS performs up to 85% as fast as the equivalent non-real-time system on standard Java benchmarks.
For hard real-time logic this release of Java RTS, for our reference platform, has a maximum latency of 20 microseconds and a maximum jitter of 10 microseconds.
...wobei das darunterliegende System auch schon veraltet ist.
Aber ich gebe zu, dass man da mit C vermutlich kürzere Antwortzeiten garantieren kann.
-
Gregor schrieb:
For hard real-time logic this release of Java RTS, for our reference platform, has a maximum latency of 20 microseconds and a maximum jitter of 10 microseconds.
wow, hätt' ich nicht gedacht. ich kenne aus'm 'real life' nur dieses gerät: http://www.auto-und-elektronik.de/product/004001008/af6917acb63.html
in dem flyer von dem ding stand damals tatsächlich sowas von '1 sekunde pro impuls', was mich sehr erschüttert hat
aber das steckt wohl 'ne 'normale JVM' drin, als das gebaut wurde, gab's wohl noch kein java RTS...