4. C# nachfolger von C++

C# nachfolger von C++

  • N

    Artchi schrieb:

    Das ist sicherlich alles im Embeddedbereich, wo in den Konzernen noch C oder verstärker C++ benötigt wird. Richtig. Aber ich sitze in einem der größen Konzerne und hier ist Java ganz einfach Konzernstandard. C++ interessiert nicht die Bohne im Desktop- und Server-Bereich. Java, Java, Java! 😡

    Leider, habe ich hier in meinem Umfeld keinen C++-Bedarf. 😞

    Jein. Da sind zwar viele auch im Embeddedbereich tätig, aber die Stellen wofür die Leute suchen haben eigentlich relativ wenig mit den eigentlichen Embedded-Systemen zu tun. Die haben meistens C++ Frameworks als Abstraktionsschichten und genau in dem Bereich suchen die dann auch Leute, d.h. du musst von dem ganzen Embedded-Kram eigentlich Null Ahnung haben.
    Ausserdem gibts da auch noch andere Sachen, z.B. im Bildverarbeitungsbereich, wo auch C++ sehr stark gefragt ist.

    Also was ich jetzt so bisher an Erfahrungen gemacht habe ist die, dass sehr viel Java-Leute gesucht werden, aber das auch C/C++ nach wie vor sehr gefragt ist.
    Im C# Bereich siehts da bisschen kläglicher aus. Es werden zwar auch ab und an C# Leute gesucht, aber das sind im Vergleich zu Java/C++ eher wenige. Soll jetzt aber kein Flamewar oder sowas geben...

    0
  • ?

    Hallo,

    erstmals danke für die vielen Infos. Kann mir jetzt schon ein besseres Bild machen. Mich irritiert ständig diese .Net-Diskussion und Werbungen in Fachzeitschriften. Da wird das immer so dargestellt das .Net alleine die Zukunft ist. Also so wie ich das verstehe ist folgendes:

    C/C++: für komplexe Anwendungen, Echtzeit- und Desktopanwendungen
    Java: für Client-Server-Programme
    C# und C++/CLI: für .Net-Anwendungen

    ist das richtig so ?

    0
  • C

    in der Microcontrollerprogrammierung (Atmel, Pic, ...) wird auch im Wesentlichen C/C++ eingesetzt (es gibt zwar auch Leute, die da Basic benutzen ...), bei Mikrocontrollern mit extrem begrenztem Speicher (vgl. z.B. ATtiny 26 - 128 Bytes - hoffe hab das net verwechselt) empfiehlt es sich auch teilweise Assembler zu nehmen

    0
  • N

    Kurt01 schrieb:

    Hallo,

    erstmals danke für die vielen Infos. Kann mir jetzt schon ein besseres Bild machen. Mich irritiert ständig diese .Net-Diskussion und Werbungen in Fachzeitschriften. Da wird das immer so dargestellt das .Net alleine die Zukunft ist. Also so wie ich das verstehe ist folgendes:

    C/C++: für komplexe Anwendungen, Echtzeit- und Desktopanwendungen
    Java: für Client-Server-Programme
    C# und C++/CLI: für .Net-Anwendungen

    ist das richtig so ?

    Hmm also was man im Prinzip glaub auch sagen kann, dass .NET eigentlich so etwas wie das JDK von Java ist, also eine sehr große umfassende Bibliothek. Nur, dass .NET eben "universell" ist, also von den verschiedensten Sprachen genutzt werden kann, eben z.B. auch von C++.
    C# ist eben eine Sprache, die im Prinzip sehr vieles von Java abgeschaut hat, und deshalb auch relativ ähnlich aufgebaut ist. Und wenn du C# programmierst benutzt du natürlich auch das .NET Framework, während das in C++ im Moment eher weniger gemacht wird...

    0
  • C

    nep schrieb:

    Hmm also was man im Prinzip glaub auch sagen kann, dass .NET eigentlich so etwas wie das JDK von Java ist, also eine sehr große umfassende Bibliothek.

    wohl eher von C#

    0
  • ?

    Checker&Murckser schrieb:

    nep schrieb:

    Hmm also was man im Prinzip glaub auch sagen kann, dass .NET eigentlich so etwas wie das JDK von Java ist, also eine sehr große umfassende Bibliothek.

    wohl eher von C#

    Habt ihr auch manchmal das Gefühl, dass Leute sätze nicht verstehen.

    0
  • ?

    Sagt mal schrieb:

    Habt ihr auch manchmal das Gefühl, dass Leute sätze nicht verstehen.

    Willkommen im Forum 😉

    0
  • T

    So, also bei uns in der Firma (world leading Biotech :D) haben die früher alle Daten mit Excel ausgewertet, und dann haben sie mal nen Chemiker eingestellt, der sich als wahrer Crack rausgestellt hat. Der hat dann ein Datenbank System (Oracle) mit VB Frontend aufgebaut, die neue Version ist nun aber in Delphi gemacht. Klar lässt die Performance zu wünschen übrig, aber dafür hat er neue Features in einem halben Tag eingebaut. (Es ist wirklich ein hochspezialisiertes Powertool und echt genial für ne One Man Show) Wenn ich den frag was er von C++ hält schüttelt er nur den Kopf, sei viel zu komplex um Produktiv zu sein. Naja wahrscheinlich kann ers nicht, und Schuster bleib bei deinen Leisten. Seit der Übernahme haben wir noch einen computational Chemist, der schreibt seine eigenen Tools in C/C++ und entwickelt Datenbank Frontends für die Holländer in Java, weil so gefordert.

    Was ich damit sagen will? Es kommt immer auf die Situation, Anforderung an Funktionalität und Support, sowie auf den Einsatzbereich an.

    0
  • N

    Sowieso. Aber genau das verstehen viele nicht beim traditionellen Flamewar C++ vs Java.
    Wobei ich mich eben da ein wenig frage wo man da C# zu sehen hat. IMHO ist es im Moment einfach besser, dass man Java den Vorrang vor C# gibt, es sei denn man will schon im Vorhinein ausschließlich für Windows entwickeln, dabei aber so ein schönes Programmiermodell wie Java haben, und gleichzeitig relativ native Windowsprogramme haben.

    0
  • ?

    Kurt01 schrieb:

    C/C++: für komplexe Anwendungen, Echtzeit- und Desktopanwendungen
    Java: für Client-Server-Programme
    C# und C++/CLI: für .Net-Anwendungen

    Kann man nicht pauschalisieren. Das hängt von vielen Faktoren ab, der größte bei Neuentwicklungen dürfte wohl Firmenpolitik sein. Qualität ist leider für viele Firmen nur noch sekundär. Zu guter Qualität einer Software zähle ich nicht nur Ergonomie und Fehlerfreiheit, sondern vor allem auch Performance(Ausführungsgeschwindigkeit, Speicherverbrauch, etc.). Das sind leider Wünsche die in der heutigen Zeit der "Gewinnmaximierung um jedem Preis" keine Rolle mehr spielen.

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

    Komplexe Anwendungen lassen sich auch in C# oder Java realisieren - sogar mit erheblich weniger Aufwand. IMHO sind die beiden Sprachen die Antwort auf den Mangel an guten Programmierern auf dem weltweiten Arbeitsmarkt.

    @Artchi: Du scheinst Dich gut mit der Firmenpolitik von MS bezüglich C# und C++ auszukennen. Man hört des öfteren, dass MS in Zukunft primär auf C# setzt und nur noch für performance kritische Anwendungen C++ einsetzen will. Ist da etwas dran, kennst Du offizielle MS Links zu den Themen?

    0
  • D

    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?

    0
  • N

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

    0
  • G

    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?

    https://rtsj.dev.java.net/

    0
  • D

    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?

    https://rtsj.dev.java.net/

    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.

    0
  • G

    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.

    0
  • N

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

    0
  • ?

    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.

    0
  • N

    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.

    0
  • G

    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.

    0
  • N

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

    0
Anmelden zum Antworten