Archiv verlassen und diese Seite im Standarddesign anzeigen : C# oder Java?
Jesus
2006-02-09, 19:34:08
Hallo,
wir planen zur Zeit ein neues Projekt und wissen noch nicht welche Programmiersprache/Umgebung dafür besser geeignet ist.
Es handelt sich um eine reine Windows Applikation, auch mit graphischen Elementen, portierbarkeit spielt keine Rolle dabei. Es wird sehr viel Wert auf genaue Timings und (PC) Hardwarezugriffe (Serielle Schnittstellen, PCMCIA KArten...) gelegt werden, sodass durchaus auch C DLLs usw. eingebunden werden müssen um die entsprechenden Timings die man mit "higher" Level sprachen nicht so ganz erreicht zu erreichen.
Zur Auswahl stehen Java und C# (.NET 2.0) wobei ich persönlich eher zu C# tendiere, aber ich kenne Java zu wenig um mir da ein Urteil zu erlauben.
mfg,
Jesus
5tyle
2006-02-09, 19:42:06
Wenns um Hardwarezugriffe und Geschwindigkeit/Timing geht ist .NET nicht unbedingt eine gute Wahl. Ist nämlich relativ langsam. Da könnten Probleme entstehen. Kann ich nicht empfehlen.
Java.. hm weiss nicht ob das passend ist.
Warum nicht C++ / WinAPI.
Jesus
2006-02-09, 19:44:18
Wenns um Hardwarezugriffe und Geschwindigkeit geht ist .NET nicht unbedingt eine gute Wahl. Java.. hm weiss nicht ob das passend ist.
Warum nicht C++ / WinAPI.
Naja es wird auch sehr viel Windows Forms usw verlangt werden, daher will ich nicht unbedingt Zeit mit C++ vergeuden. Hardware zurgriffe sollen ja hauptsächlich über DLLs laufen.
5tyle
2006-02-09, 19:45:54
Mit der WinAPI kannst du auf einfache Art und Weise Fenster erzeugen. Die bietet dir eigentlich alle Funktionen, die Windows so enthält. Das ist relativ einfach verglichen mit z.B. Java
Aufgrund seiner Langsamkeit empfehle ich das .NET Framework nicht. Müsste man aber testen inwiefern da Schwierigkeiten entstehen könnten.
Was heißt "timings" für dich? Zeitmessung oder Einhalten von Zeitlimits?
Langsam sind weder .Net noch die JVM. Das macht meist weniger als Faktor 2 (im Vergleich zu C++) aus. Das kann man in den meisten Anwendungen locker durch Verbesserungen am Code erreichen.
Benutz doch Managed C++.
Damit kannst du deine Oberfläche mit Managed Code bauen, alle Vorteile von .Net nutzen und deine performancekritischen Dinge mit normalem unmanaged C++ schreiben.
Wenn dann C++/CLI. Managed C++ ist übler Scheiß.
Demirug
2006-02-09, 20:10:37
Also wenn C# die Timeing Forderungen nicht schafft dann geht es auch mit C++ erst mal nicht. In einem solchen Fall muss nämlich dann ein Kerneltreiber mit Interrupt handling her.
Zudem würde ich allgemein keine Applikation die scheinbar Echtzeit Forderungen hat im Windows Userspace ohne zusätzliche Hardware laufen lassen.
Ich weiß ja nicht genau was ihr vor habt aber ohne ausreichenden FIFOs zwischen der externen Welt und dem PC fasse ich sowas nicht an. Solche Projekte können nur schief gehen.
Ach so zum Thema: C# oder Java dürften sich für die UI nicht viel geben, C# sieht halt "nativ" aus.
grakaman
2006-02-09, 21:52:36
Benutz doch Managed C++.
Damit kannst du deine Oberfläche mit Managed Code bauen, alle Vorteile von .Net nutzen und deine performancekritischen Dinge mit normalem unmanaged C++ schreiben.
Na wenn er eh schon C# kann, empfiehlt sich C#. Entweder macht er dort über P/Invoke seine Zugriffe auf unmanaged Code oder er schreibt eben für seine performancekritischen Sachen Wrapperklassen in C++.NET oder C++/CLI und bindet die in sein C# Programm ein.
Demirug
2006-02-09, 21:59:40
Na wenn er eh schon C# kann, empfiehlt sich C#. Entweder macht er dort über P/Invoke seine Zugriffe auf unmanaged Code oder er schreibt eben für seine performancekritischen Sachen Wrapperklassen in C++.NET oder C++/CLI und bindet die in sein C# Programm ein.
Die Serielle Schnittstellen wird ja inzwischen native unterstützt und für die andere Hardware müsste man erst mal die entsprechedende API kennen.
Solange es normales C ist funktioniert P/Invoke eigentlich immer. Bisher brauchte ich nur einmal einen C++/CLI Wrapper. Das war für ein Custom COM Interface.
Wie geschrieben sagt meine Erfahrung das wenn es aus Timeing gründen nicht mit C# geht fällt man auch mit C++ auf die Nase.
Monger
2006-02-09, 22:21:24
So wie das Problem beschrieben wird, ist Java auf jeden Fall aus dem Rennen. (Und das sage ich, obwohl ich eigentlich Java-Enthusiast bin)
Grafische Oberflächen: nach wie vor in Java hässlich. Zumindest habe ich noch keine Entwicklungsumgebung bzw. Plugin gesehen, was einen wirklich schnell und bequem eine Oberfläche machen lässt. Visual Studio dagegen bietet natürlich da alles an was man braucht.
Auch die Hardware Zugriffe dürften mit Visual Studio dank umfangreichen Bibliotheken kein Problem sein. Auch die Koppelung an andere DLLs, COM Objekte o.ä. kann .NET qohl insgesamt naturgemäß leichter als Java.
Java finde ich als Sprache unheimlich schick, und ist für reine Logik-Anwendungen imho sehr produktiv. Aber dein Fall trifft imho ausgerechnet ein ganzes Bündel von Java Schwächen.
Was du mit Timings meinst, ist mir nicht ganz klar. Ich vermute, du meinst NICHT Echtzeitfähigkeit. Und da fehlt mir irgendwie das Vorstellungsvermögen, was denn eine aktuelle CPU so an die Grenzen treiben könnte, dass Latenzen und Jitter der CPU schlimmer als die natürlichen Abweichungen der Hardware sein könnten.
Sprich: imho hat ein schlechtes Mainboard eine stärkere Auswirkung auf deine Peripherie als Unterschiede in den Programmiersprachen haben könnten.
Jesus
2006-02-09, 22:29:40
Was du mit Timings meinst, ist mir nicht ganz klar. Ich vermute, du meinst NICHT Echtzeitfähigkeit. Und da fehlt mir irgendwie das Vorstellungsvermögen, was denn eine aktuelle CPU so an die Grenzen treiben könnte, dass Latenzen und Jitter der CPU schlimmer als die natürlichen Abweichungen der Hardware sein könnten.
Sprich: imho hat ein schlechtes Mainboard eine stärkere Auswirkung auf deine Peripherie als Unterschiede in den Programmiersprachen haben könnten.
Mit Timings meine ich vorallem die implememtierung von verschiedenen seriellen Protokollen (senden und empfangen und auswerten), die nicht vom PC unterstützt werden (verscheiden "inter-byte-gaps" usw.). Alles zwischen 10kbit und 1mbit soll dann in der Application ausgwertet werden. Bisher wurde das in VB6 mit etwas C gemacht, was zwar funktioiniert aber doch einige üble Schwachstellen hat. Daher ist jetzt die neuimplementierung in C# o.ä. geplant.
Darkstar
2006-02-09, 22:35:45
Grafische Oberflächen: nach wie vor in Java hässlich. Zumindest habe ich noch keine Entwicklungsumgebung bzw. Plugin gesehen, was einen wirklich schnell und bequem eine Oberfläche machen lässt. Visual Studio dagegen bietet natürlich da alles an was man braucht.Da empfehle ich Dir, mal einen Blick auf Matisse (http://www.netbeans.org/community/releases/50/index.html#matisse) zu werfen, den GUI-Builder im neuen NetBeans 5.0 (http://www.netbeans.org/community/releases/50/index.html).
Beim Rest würde ich 100%ig zustimmen.
Demirug
2006-02-09, 22:52:28
Mit Timings meine ich vorallem die implememtierung von verschiedenen seriellen Protokollen (senden und empfangen und auswerten), die nicht vom PC unterstützt werden (verscheiden "inter-byte-gaps" usw.). Alles zwischen 10kbit und 1mbit soll dann in der Application ausgwertet werden. Bisher wurde das in VB6 mit etwas C gemacht, was zwar funktioiniert aber doch einige üble Schwachstellen hat. Daher ist jetzt die neuimplementierung in C# o.ä. geplant.
Ich würde nicht davon ausgehen das es besser wird. Es gibt schon einen gute Grund warum man das Protokolhandling im Chipsatz macht und dort einen FIFO hat.
Sehe ich auch so. Bei 1 MBit hat man nur wenige Tausend CPU-Zyklen pro Datum. Du hast keine Chance dafür zu sorgen dass dein Programm in der Zeit überhaupt läuft.
Wäre ein Realtime-OS dafür eigentliche eine mögliche Lösung?
ScottManDeath
2006-02-10, 01:45:24
Ich habe mit C# auch schon "relativ" hardwarenahe Dinge gemacht. Habe (siehe Attachment) ein USB Modul angesteuert. An diesem USB Modul hängt ein Microcontroller dran, der eine LED Matrix mit Daten versorgt.
Die C-DLL des USB Treibers habe ich mit COM gewrappt, von Managed C++ (mit schon vorhandenem C++ Code) angesprochen und über Remoting mit Videodaten bestückt. Diese habe ich in einem in C++ geschriebenem DirectShowPlugin abgegriffen, per COM an ein C# Objekt übergegen, welches die daten dann remooted hat. Flaschenhals waren neben der HW das .NET Remoting. Sockets hätten es ca 20% schneller gemacht.
Jesus
2006-02-10, 08:49:14
Also kann man definitiv sagen das Java für solche Dinge ungeeignet ist?
Monger
2006-02-10, 09:43:05
Also kann man definitiv sagen das Java für solche Dinge ungeeignet ist?
Ich glaube, darüber sind sich hier alle einig, ja.
Shink
2006-02-10, 11:45:30
Ich glaube, darüber sind sich hier alle einig, ja.
Also ich finde, zumindest serielle Kommunikation ist mit Java sehr praktisch (javax.comm). Prinzipiell kann man ja mit JNI alles nativ ansprechen, aber da würde ich .NET-Sprachen definitiv vorziehen.
Was Oberflächen betrifft, finde ich Visual Studio unbrauchbar. Der Designer kann ja nicht einmal Elemente variabler Größe erstellen, oder hab ich da etwas übersehen? Das bekommt z.B. die Apple-Entwicklungsumgebung ganz gut hin (wie hieß die noch mal?)
grakaman
2006-02-10, 11:56:57
Was Oberflächen betrifft, finde ich Visual Studio unbrauchbar. Der Designer kann ja nicht einmal Elemente variabler Größe erstellen, oder hab ich da etwas übersehen? Das bekommt z.B. die Apple-Entwicklungsumgebung ganz gut hin (wie hieß die noch mal?)
Du könntest mal die Anchor-Eigenschaft eines Ctrl. ausprobieren, falls du das meinst.
Crushinator
2006-02-10, 12:42:07
[... Anfangsposting ...] Zur Auswahl stehen Java und C# (.NET 2.0) wobei ich persönlich eher zu C# tendiere, aber ich kenne Java zu wenig um mir da ein Urteil zu erlauben.
Ich möchte zusammenfassend festhalten, daß das Vorhaben mit beiden Sprachen auf qualitativ ähnlichem Niveau (was Endresultat angeht) realisierbar ist, weil man mit beiden auf nativen Code zugreifen kann. Ich würde in solchen Fällen (wo es auf Portierbarkeit auch nicht ankommt) immer das nehmen wo man die meiste Erfahrung mit hat. :)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.