Arbeitet ihr mit C++?
-
Komisch das renomierte Firmen für Desktop-Anwendungen, aber immer noch C++-Entwickler suchen:
http://cooljobs.adobe.com/frameset.html?goto=er-viewjob&refnode=400960http://www.magix.com/de/magix-ag/unternehmen/jobs-karriere/jobangebote/standort-dresden/professionals/c-application-developer-mw/
http://www.magix.com/de/magix-ag/unternehmen/jobs-karriere/jobangebote/standort-dresden/professionals/mac-os-x-application-developer-mw/
http://www.magix.com/de/magix-ag/unternehmen/jobs-karriere/jobangebote/standort-dresden/professionals/software-entwickler-cc-mw/Aber ist klar, die haben alle C++ wegen explodierender Kosten satt und suchen wie bekloppt Java- und C#-Entwickler. Und ja, wir reden über Desktop-Anwendungen die wahrscheinlich Millionenfach eingesetzt werden.
Von den ganzen Qt- und KDE-Desktop-Anwendungen, die man überall runter laden kann und die zu Hauf in den ganzen Linux- und BSD-Distros drauf sind, wollen wir nicht reden... weil die ja alle angeblich in Java oder C# programmiert sind.
Also, ich sehe ehrlich gesagt hauptsächlich Desktop-Anwendungen die in C++ und (bei ein paar unverbesserlichen) in C entwickelt sind. Größere Anwendungen in Java-, Python oder C# sind doch eher die Ausnahme. Viele kleine Tools werden heute aber sicherlich z.B. in Python entwickelt, was auch Sinn macht.
-
@Artchi: Und wofür wirst Du nochmal genau bezahlt?
Für C++ Programmierung?
-
Andromeda schrieb:
Ich arbeite so gut wie gar nicht mehr mit C++. Deshalb meine Stimme für "Nein". Manchmal kommt es mir vor, als würde C++ langsam aussterben. Aber bestimmt findet C++ noch sehr oft bei Mikrocontrollern Verwendung.
Für Mikorcontroller nimmt man doch in der Regel eher C, oder nicht? Bei uns ist es jedenfalls so. Ich habe zwar noch nie selbst verglichen, kann mir jedoch vorstellen, dass die Verwendung von char-Array einfach platzsparender ist als z.B. std::string. Unsere ICs haben gerade mal 2KB Flash, da kämpft man um jedes Byte. Während meiner ersten Wochen habe ich versucht, auf einem solchen IC dynamische Arrays mit malloc unterzubringen. Großer Fehler, das Hexfile wächst ungemein, deshalb nur absolute Basics...
Da bei uns ein Mix aus C, C++ und LabView programmiert wird, habe ich natürlich mit Ja gestimmt.
-
Ihr mögt 2 KB haben, aber ihr seid nicht alle anderen.
Es gibt auch Embedded-Systeme die mehr Hauptspeicher zur Verfügung haben. Gibt auch Embedded-Systeme im Megabyte-Bereich.
-
Artchi schrieb:
Ihr mögt 2 KB haben, aber ihr seid nicht alle anderen.
Es gibt auch Embedded-Systeme die mehr Hauptspeicher zur Verfügung haben. Gibt auch Embedded-Systeme im Megabyte-Bereich.Jo, zum Beispiel 512 MB (RAM).
-
Mr. N schrieb:
Artchi schrieb:
Ihr mögt 2 KB haben, aber ihr seid nicht alle anderen.
Es gibt auch Embedded-Systeme die mehr Hauptspeicher zur Verfügung haben. Gibt auch Embedded-Systeme im Megabyte-Bereich.Jo, zum Beispiel 512 MB (RAM).
Ui! Na gut, da sieht die Sache natürlich anders aus...
-
Jo, zum Beispiel 512 MB (RAM).
Cool, arbeitest du nicht zufällig im Conti MMP Projekt: http://www.microsoft.com/auto/partners.mspx
Als embedded system würde ich die Hardware da nicht bezeichnen. "Klein-PC" passt eher...
-
Gregor schrieb:
@Artchi: Und wofür wirst Du nochmal genau bezahlt?
Für C++ Programmierung?Richtig, ich mache Java-CLients. Aber diese benutzen nur wenige Menschen, von weniger als hundert Leute bis hin zu mehreren tausend Leuten (je nach Projekt). Und diese Anwendungen zähle ich unter "Ausnahmen", da sie nur Inhouse eingesetzt werden. Und das es Java ist, ist auch nur aus politischen Gründen. Ob es kostengünstiger ist, glaube ich nicht. Ganz im Gegenteil, bei größeren Client-Anwendungen gibts Beschwerden von Usern über Performance.
Diese Anwendungen sind aber nicht repräsentativ auf dem Markt. Für mich sind solche Desktop-Anwendungen wie Cinema4D, die ganzen Magix-Produkte usw. repräsentativ, da sie nicht nur von einer Firma eingesetzt werden, sondern weltweit einen Markt bedienen müssen. Individual-Software hat auch nicht die Qualität von Standard-Anwendungen. Z.B. müssen unsere Inhouse-User unsere Anwendungen benutzen, egal wie schlecht die Software ist. Bei Standard-Anwendungen auf dem freien Markt entscheidet schon eher die Qualität, ob sie erfolgreich ist. (wir gehen jetzt mal nicht von Quasimonopolisten aus
)Viele führen ja z.B. die heutige C++-Verbreitung an, wegen angeblicher Legacy-Software. Ja, stimmt. Aber nicht der alleinige Grund. Nehmen wir das neue Produkt Adobe Lightroom. Es ist keine Legacy-Anwendung, die zwangsweise in C++ gepflegt werden muß. Diese gibt es erst seit ca. 2 Jahren auf dem Markt. Aber sie wurde in C++ entwickelt, und es wurde die MFC und GDI+ verwendet. Allerdings wurde auch vieles in Lua implementiert. Hier kann man sagen, wo schnell was zusammen gezimmert werden mußte, wurde Lua verwendet. Aber C++ ist immer noch die Basis. Laut Lua-Homepage ist Adobe Lightroom zu 40% in Lua implementiert, also 60% in C++ implementiert.
Das kein Java und kein C# für Lightroom eingesetzt wurde, hat sicherlich auch strategische Gründe: man will es auch auf dem Mac portieren. Die MFC-teile kann man leicht ersetzen. Aber wenn es Java wäre, wäre man von Apples Java-Implementierung abhängig. Soweit mir bekannt, entwickelt Apple seine Java-Implementierung nicht mehr weiter. Zumindest ist ein Java 6 von Apple nicht in Sicht. C++-Compiler wird es aber mit 99,9999999% weiterhin für MacOS geben. Und mit Lua kann man die (angeblichen) zeitaufwändigen C++-Teile schnell implementieren.
Ich sehe eher die Zukunft bei den Desktop-Anwendungen in einem Sprachenmix, wo C++ die Basis ist und eine Scriptsprache angebunden wird. Die besten Beispiele dafür sind Lightroom, Blender 3D u.a. Dort wird die Basis-Anwendung in C++ implementiert und für die schnelle Implementierung, wo keine kritischen Teile sind, wird in einer Scriptsprache erledigt (z.B. Lua oder Python).
-
Komisch, dass die C++-Anhänger bei embedded-Systemen nicht über das "zero cost principle" argumentieren, sondern stattdessen die Argumentation der Pro-Java Fraktion vertreten: "Wir haben ja viel Speicher"
-
Und die Anhänger von C: Es muss unbedingt in die 2 KB reinpassen. Ob jemand das Programm danach noch versteht
-
abc.w schrieb:
Und die Anhänger von C: Es muss unbedingt in die 2 KB reinpassen. Ob jemand das Programm danach noch versteht
Aber sicher doch! Ein kleines Programm mit vergleichsweise wenig Funktion, geringem Funktionsumfang und guten Kommentaren (denn davon passen jede Menge in die 2 KB rein!) ist doch sicher besser und schneller zu verstehen, als ein 20000-Zeilen-Monster, dass sich am kompletten C++-Sprachschatz bedient!
-
Artchi schrieb:
Diese Anwendungen sind aber nicht repräsentativ auf dem Markt.
Für welchen Markt? Für den Massenmarkt? Dafür sind sie sicherlich nicht repräsentativ. Aber ich wage zu behaupten, dass die meiste Software nicht auf den Massenmarkt abzielt, sondern eine weitaus geringere Zielgruppe hat. Und das heißt auch, dass man andere Constraints bei der Entwicklung hat. Wenn man bei einem Massenmarkt die Entwicklungskosten auf eine große Menge verkaufter Produkte umlegen kann und die Kosten jedes einzelnen Exemplars durch andere Dinge dominiert werden, dann hat man dort ganz andere Voraussetzungen für die Wahl der Sprache als bei einer kleinen Zielgruppe. Dort dominieren dann plötzlich die Entwicklungskosten und man ist gezwungen, die Produktivität zu erhöhen, um konkurrenzfähig zu bleiben. Und Du magst denken, was Du willst, C++ hat nicht den Ruf, zu einer hohen Produktivität bei den Entwicklern zu führen. Aus gutem Grund. Deshalb sind Sprachen wie Java in so einem Bereich wesentlich häufiger anzutreffen. Das betrifft auch Desktop-Anwendungen, die für kleinere Zielgruppen entwickelt werden.
Artchi schrieb:
Zumindest ist ein Java 6 von Apple nicht in Sicht.
Für mich sieht es so aus, als ob man das einfach runterladen kann: http://developer.apple.com/java/download/
Artchi schrieb:
Ich sehe eher die Zukunft bei den Desktop-Anwendungen in einem Sprachenmix, wo C++ die Basis ist und eine Scriptsprache angebunden wird.
Ich sehe C++ in Zukunft bei den Desktop-Anwendungen auf dem absteigenden Ast. Java und C# sind da die heißen Kandidaten für die Zukunft.
-
Tim schrieb:
Komisch, dass die C++-Anhänger bei embedded-Systemen nicht über das "zero cost principle" argumentieren, sondern stattdessen die Argumentation der Pro-Java Fraktion vertreten: "Wir haben ja viel Speicher"
Das überrascht mich ehrlich gesagt auch.
Btw. ich sehe schon die dritte Umfrage kommen "Wer verdient mit C++ sein Geld?"
Natürlich wird auch dann wieder diskutiert. Zum Beispiel wenn man nur einen Nebenjob mit C++ hat oder Freiberufler ist, der mal dies und das macht, zählt das dann auch? 