Wofür wird C++ heute noch eingesetzt?
-
Ich bin auch der Meinung, man sollte die Sprache nehmen, die für den Einsatzzweck am besten geeignet ist. Ich glaube aber nicht, dass deswegen C++ aussterben wird.
Ich halte des meist sehr einfach, bei Oberflächen Programmierung wird zu C# mit WPF gegriffen, sobald es aber um Dienste geht die auch mal länger als ein paar Stunden laufen dann wird C++ genommen.
Das letzte Projekt mit C++ Dienst wurde vor einem Jahr angefangen, also auch nichts historisch gewachsenes.
Und ja ich weis C# geht auch für Dienste, hatte dabei aber schon genug Schwierigkeiten.
Mfg Marco
PS: gehöre nicht zu den ewigen gestrigen.
-
Dass sich Microsoft eine "Rückkehr" zu C++ wünscht, denke ich nicht. Das ist ein Gerücht, was damals im Zuge der Windows 8/Metro Präsentation entstanden ist und selbst wenn die Windows 8/Metro Leute bei MS diese Schiene vertreten sollten, hat ihr enormer Miserfolg ihnen sicherlich den Wind aus den Segeln genommen. Die Wichtigkeit des .NET Frameworks und C# nehmen in Windows doch von Version zu Version eher zu.
Natürlich hat man in C++ feinere Kontrolle über Speicher und Ressourcen, aber das spielt ja bei den meisten der Anwendungen keine Rolle, insbesondere bei all den Nachteilen die man mit C++ dafür auch in Kauf nehmen muss. Ausführungsgeschwindigkeit ist schon lange kein Argument mehr, weil .NET und Java genauso schnell sind. Und so eine richtig tragende Rolle im OS und Embedded Bereich, wie manch einer einem gerne glauben machen will, spielt C++ auch nicht. Dort ist C einfach meistens die bessere Wahl. Windows Treiber kann man z.B. gar nicht in C++ schreiben und im Linux Kernel ist C++ doch auch unerwünscht, soweit ich weiss.
@Marc-O Dein Problem mit Diensten erschließt sich mir jetzt nicht. Wenn du da Schwierigkeiten hattest, liegt das doch wahrscheinlich eher an deiner Unvertrautheit (?) mit dem .NET Framework?
-
Phil_ schrieb:
Und so eine richtig tragende Rolle im OS und Embedded Bereich, wie manch einer einem gerne glauben machen will, spielt C++ auch nicht. Dort ist C einfach meistens die bessere Wahl.
Embedded Systeme sind unglaublich vielfälltig. Schwer zu sagen, was da am meisten eingesetzt wird. Je kleiner desto wohl mehr C als C++, aber auch das teilweise historisch bedingt. Aber auch bei den kleinen gibt es diverse C++ Anwendungen:
- Arduino ist ja recht weit verbreitet. Die "Sketch" Sprache da ist leicht getarntes C++, verwendet wird der g++. Die IDE dagegen ist Java.
- Etwas größer ist die mbed Plattform vom Prozessorhaus ARM. Die wird ja gerade zu Betriebssystem für "Dinge" im Internet der Dinge ausgebaut. Im Moment ist C++ da die einzige Programmiersprache für die Mikrocontroller. In den Tools wird viel Python verwendet.
Gehen wir mal zu etwas größeren Embedded Systemen, Robotersteuerung. Da findet man sehr viel C++.
- Da gibt es Open Source Projekte wie Orocos.org, da fällt mir nicht mal eine irgendwie geartete C Alternative ein. Kannst Du eine nennen ?
- Die Point Clound Library (unter pointclouds.org) ist weit verbreitet in der Robotik. Auch da kenne ich keine C Alternative.
- Bei beiden liegt das auch an der Mathematik. Für C++ gibt es Eigen, Armadillo, usw. Da gibt es in C nicht so viel entsprechendes.
Gehen wir mal weg von Embedded. Der nächste Bereich wäre CAD. Die marktführenden Systeme (CATIA, Pro Engineer, usw.) sind alle in C++ geschrieben. Für Plugins wird meist eine spezielle Visual Studio Version gefordert. Viele kleinere Anbieter von CAD Systemen bauen auf dem ACIS-Kernel der Spatial Corporation auf. Der ist in C++ geschrieben.
Ein Spezialgebiet beim CAD ist der Vergleich von Konstruktionsdaten mit Laserscans. Da gibt es eigentlich nur zwei Anbieter in der Industrie Polyworks und Geomagic (früher Rapidform). Beide in Visual C++ geschrieben.
Kommen wir von den Robotern zu den SPSsen. Beckhoff ist ein deutscher Anbieter, der Visual Studio verwendet. Man kann da auch mit VC++ Code für die SPS schreiben, statt den SPS-Dialekten. Die Siemens Soft-SPSsen (die auf PC-Hardware laufen), haben ein Visual C++ SDK, sind wahrscheinlich selber damit geschrieben. Mitsubishi SPS (weltweit nach Siemens die Nummer 2) haben ein optinales C++ SDK.
Alles in allem gibt es in der Industrie so viel C++ Software, dass die Sprache noch Jahrzente im Einsatz bleiben wird. Trotzdem sind neue Sprachen wichtig und nützlich. Aber bis die in diesen Anwendungsgebieten auftauchen, wird es etwas dauern.
-
[quote="nn"]
Phil_ schrieb:
Kommen wir von den Robotern zu den SPSsen. Beckhoff ist ein deutscher Anbieter, der Visual Studio verwendet. Man kann da auch mit VC++ Code für die SPS schreiben, statt den SPS-Dialekten. Die Siemens Soft-SPSsen (die auf PC-Hardware laufen), haben ein Visual C++ SDK, sind wahrscheinlich selber damit geschrieben. Mitsubishi SPS (weltweit nach Siemens die Nummer 2) haben ein optinales C++ SDK.
Alles in allem gibt es in der Industrie so viel C++ Software, dass die Sprache noch Jahrzente im Einsatz bleiben wird. Trotzdem sind neue Sprachen wichtig und nützlich. Aber bis die in diesen Anwendungsgebieten auftauchen, wird es etwas dauern.
Beckhoff benutzt TwinCAT, welches auf Codesys basiert. Beckhoff hat das nur in VS integriert.
Ich für meinen Teil bin froh das man C++ benutzen kann und das auch wieder im kommen ist, da die SPS Programmiersprachen, außer ST, generell furchtbar sind.
Roboter, egal ob Industrieroboter oder andere, werden auch zunehmend mit C++ programmiert. (ros.org)Für Anwendungsentwicklung war doch sowieso schon eher Java in Benutzung bzw. C#.
-
Ja, bei Industrie-Robotern wird sehr viel C++ eingesetzt.
Nicht nur bei ros, auch bei den kommerziellen gibt es teilweise die Möglichkeit komplizierte Dinge in C++ zu machen. Dabei entdeckt man dann auch Indizien wie Dateinamen, dass zumindest Teile der Steuerung in C++ implementiert sind.
-
Automotive: Die Steuergeräte im Auto sind meist in C, das HMI meist in C++. Dann Mikro-Controller aller Art, für die Senorik im Auto, sind oft die Klasse RL78K von Renesas. Da gibt es eine C/C++ IDE aber da würde keiner was mit JAVA oder C# machen.
-
Für all diese industriellen Sachen wäre Rust super geeignet, denn da kann man sich noch weniger Fehler leisten. Ich drücke fest die Daumen, dass auch dort C++ immer weniger eine Rolle spielen wird in Zukunft. Nach den VM-Sprachen kommen jetzt endlich neue Systemsprachen auf den Markt...es wird auch Zeit.
-
Wenn solche Einsatzfelder einmal besetzt sind, ändert sich da nur langsam was. Da kann man in Jahrzehnten rechnen (eher mehr als eins).
Wo Rust & Co früher auftauchen könnten sind kombinierte Ansätze, wie z.B. hier
http://halcon.com/
Im Innern C/C++/Assembler und GPU-Programmierung. Nach außen C/C++/.net . Wenn bei solchen Produkten mal Rust auftaucht, dann kann man darüber nachdenken es zu benutzen.Es hat einige Jahre nach dem Erscheinen von .net gedauert, bis C# in solchen Produkten auftauchte (und Delphi verschwandt). C++ war die ganze Zeit über da ...
-
Rustiger schrieb:
Für all diese industriellen Sachen wäre Rust super geeignet, denn da kann man sich noch weniger Fehler leisten. Ich drücke fest die Daumen, dass auch dort C++ immer weniger eine Rolle spielen wird in Zukunft. Nach den VM-Sprachen kommen jetzt endlich neue Systemsprachen auf den Markt...es wird auch Zeit.
Welche Vorteile hätte den Rust gegenüber C++?
-
Cybertec schrieb:
Rustiger schrieb:
Für all diese industriellen Sachen wäre Rust super geeignet, denn da kann man sich noch weniger Fehler leisten. Ich drücke fest die Daumen, dass auch dort C++ immer weniger eine Rolle spielen wird in Zukunft. Nach den VM-Sprachen kommen jetzt endlich neue Systemsprachen auf den Markt...es wird auch Zeit.
Welche Vorteile hätte den Rust gegenüber C++?
Für eine ausführliche Diskussion siehe diesen Thread.
-
Ja klar wird es Jahrzehnte dauern bis sich eine neue Systemsprache wirklich etabliert hat. Ich persönlich finde es auch schwer in Rust rein zu kommen, da man einfach anderes Denken lernen muss und mir fehlt auch noch GUI, IDE etc, obwohl Binding zu C-Libs wirklich da extrem schnell realisiert werden. SDL, GTK, OpenGL, GLGW und viele andere sind ja alle schon da.
Interessant ist auch dass man mit Rust auch gut fürs Web programmieren kann. Da gibt es schon ein fertiges Projekt, mir fällt der Name nicht ein.
Dazu ist der neue Paketmanager und Buildtool cargo echt toll. Keine Probleme mehr Libs zu nutzen, da werden Abhängigkeiten aufgelöst, fehlende Libs gleich runter geladen, ein Projekt mit Ordner-Struktur und XML-Build-Datei angelegt, usw.. Mit cargo run z.B. wird gebaut und gleich gestartet und so weiter und so fort...echt nett.
Auf https://crates.io/ kann man sich so das werkeln an Libs anschauen. Da wird wirklich alles mögliche für Rust verfügbar gemacht.
Und bald ist Rust auch endlich wirklich Final und dann werden auch die IDE-Unterstützung, Bücher etc. nicht lange auf sich warten lassen. Bevor eine Sprache nicht final ist macht ja so etwas keinen Sinn.
-
Diese Rust-Trollerei ist mittlerweile echt lästig.
-
Wenn dir Sicherheit lästig ist, dann tust du mir Leid. Mir gefällt nun einmal das Konzept hinter Rust und wenn eine Sprache allein schon für mehr Sicherheit in der IT-Welt sorgen kann, dann tue ich alles um diese auch zu verkaufen. Das ist mein Beitrag gegen NSA und Konsorten. Du kannst dies gern Trollerei nennen. Ich nenne es, eine neue Sprache bekannt machen und aufzeigen was sie besser als C++ macht.
-
-
@Offtopic Ethon:
Kann es sein, dass du noch so ein Bubi von 25 bist?
-
Also ich muss doch jetzt mal klar sagen, Rustiger kennt sich nicht aus. D ist viel besser als Rust.
-
Ethon schrieb:
Diese Rust-Trollerei ist mittlerweile echt lästig.
-
Ich habe nie gesagt, dass ich ich auskenne und D habe ich auch nocht nicht probiert. Sprachen in denen ich schon was geschrieben habe sind: C, C++, PHP, Java, Javascript, Python und jetzt halt Rust. Es ist ja auch nicht so dass ich jetzt nie wieder in den genannten Sprachen was machen werde. Aktiv arbeite ich am meisten mit Java, davor C++. Nebenbei schaue ich mir Rust Stück für Stück an bin halt total begeistert und schreibe darüber.
Nein, ein Experte oder Profi bin ich nicht. Nur ein Programmierer mit einer Meinung zu den Sprachen die er schon ausprobiert hat.
-
Ethon schrieb:
Diese Rust-Trollerei ist mittlerweile echt lästig.
Knuth, Turing, Gödel, das Programmieren selber ist (ganz unabhängig von einer eingesetzten Sprache!) viel viel viel viel viel komplexer als es von der Ferne den Anschein hat. Das muß man kapieren, dann erst sollte man über Sprachen reden.
Also von der Ferne sieht der klassische Personaler da jemanden im Keller rumgammeln, der den ganzen Tag Tasten drückt, und der Personaler denkt sich, daß seine 5-jährige Tochter auf dem PlayBa-Spielzeug-Telefon das auch macht. Also wozu versiffte Progger bezahlen? Nur weil Kinderarbeit verboten ist und Terschutzgesetze verbieten, es Schimpasen machen zu lassen?
Ich kann es dem klassischen Personaler nicht erklären, was wir tun und was wir sind. Kann ihm nur sagen, daß wir alle Personaldinge im Prinzip können (meine 5-jährige Tochter kann das sogar), aber wir können nicht alles lösen und wir (oder die Mathenachbarn halt) beweisen gleich selber, daß wir beschränkt sind.
Ähm, der Personaler läßt seine Pilstulpe fallen vor Unfassung ob der Begeisterung, die das Kellerkind zeigte, als sei der Beweis eigener Beschränktheit das Größte einer Fachrichtung. Das geht dem Personaler nicht in den Kopf. Und für uns ist es mit das Größte.
Es wird noch schlimmer. Eine Andeutung sei http://de.wikipedia.org/wiki/Liste_von_Komplexitätsklassen
Proggern ist verdammt kompliziert. Wie kommt eine Weihnachtsnase auf den absurden Gedanken, durch Beschneidung der Programmiersprache hilfreich zu sein?
Zu C++ gibt es zur Zeit weit und breit keine Alternative. Nur da kann man einigermaßen ausdrücken, was man als Mensch tun täte, hätte man diese Aufgabe. Nur C++ ergibt sich (inzwischen endlich konsequent) den Alltagssorgen der Progger, die Alltagsprobleme unmittelbar proggen wollen. Alle anderen üblichen als allgemein verwendungsfähig propagierten Sprachen~(außer Perl)~ erzählen einem mehr oder viel mehr und zum Kotzen mehr, wie man die Probleme erst ändern muss, um sie lösen zu können.
-
Na aus meiner Sicht gibt es keine wirkliche Alternative zu C und C++.
Ich muss aber sagen ich bin ein Effizienzfanatiker.
Wenn ich sehe das mein Laptop mit einem i5 und 4GiB RAM bein 3 Programmen in die Knie geht ist das für mich nur ein Beweis dafür was für ein Irrweg z.B. Java geht.
(Die 3 Programme waren Firefox mit etwa 20 Tabs, Eclipse und ein Spring (Java) Projekt).Aus meiner Sicht ist Java in Serverfarmen ok, da kommt es nicht auf einen RAM Riegel an, da ist es sogar billiger 100GiB mehr RAM zu kaufen als das Programm zu optimieren.
Aber im Consumer Bereich geht das einfach nicht (selbst am Desktop schaffen einige Programme die 8GiB und nochmal 100€ für neuen RAM will ich nicht ausgeben) und da ist Java (leider) auch immer verbreiteter (an die Spieler unter euch, vergleicht mal den Speicherbedarf des Minecraft Servers mit dem in C geschriebenen Nachbau das sind so etwa 50% weniger).Aber das sollte gar nicht gegen Java jetzt so sehr gehen, vielmehr wollte ich ausdrücken das man immer eine Gewisse Effizienz erhalten sollte. Dann haben auch Bytecode Sprachen wie Java und Skriptsprachen wie Python einen Verwendungszweck (mal nebenbei Python ist erstaunlich leistungsfähig).
==> Wenn ich selber die Auswahl zwischen zwei Programmen habe wähle ich das effizientere und das ist nunmal oft C/++. Und das haben bisjetzt auch alle mit denen ich zusammen gearbeitet habe genau so gesehen.