C++ nach C#?
-
Meine Einschätzung ist, dass man mit Java/C# bei kleinen Projekten fast immer schneller ist als mit C++, und bei größeren Projekten sich das dann ausgleicht und Richtung C++ verschiebt. Kommt natürlich auch auf die Projekte drauf an. Ich hab früher Enterprise Software in C# geschrieben, da gibts einfach sehr viele Probleme, für die die Sprache und das Framework schon was haben. Da kann man z.B. sehr viel mit Refection erschlagen, z.B. ORM und Data Binding. Kommt in Enterprise Anwendungen ständig vor, deswegen ist man da produktiv. Dann braucht man natürlich ständig XML, hat man sogar auch in die Sprache integriert, mit Linq to XML. Webservices usw. wird alles problemlos unterstützt.
Jetzt arbeite ich an einem großen C++ Projekt und brauche einfach nicht so viel davon. Datenbanken spielen bei uns zwar auch eine Rolle, aber anders, da hat man mit ORM kaum was gewonnen, Stammdaten und irgendwelche Eingabemasken mit Data Binding usw. kommt praktisch nicht vor. Ich bin in dem Projekt subjektiv auf das Projekt bezogen genauso produktiv wie früher mit C#, ich vermisse die Sprache und das Framework also auch nicht. Und wenn wir mal GUI machen, dann ist die meist sehr komplex, einfache Eingabemasken sind extrem selten und irrelevant, und da komm ich mit Qt auch wunderbar zurecht. Da kommen die Features von C++, z.B. RAII und gute Unterstützung für Value Typen stärker zur Geltung. Ich finds sehr angenehm, mit richtigen Value Typen zu arbeiten. Und man kann die Klassen leichter so aufbauen, dass der Compiler falsche Benutzung verhindert. Und das ist bei einem Projekt mit zig Millionen Zeilen Code und dutzenden Entwicklern schon wichtig. Und unsere Architektur ist teilweise sehr komplex und unüberschaubar. An einem "Prozess" oder Workflow können mehrere Prozesse, meist teilweise auf unterschiedlichen Rechnern, beteiligt sein, dann gibts an zig Stellen Customizations, wo irgendwelche Scripte ausgeführt werden, die wir nicht unbedingt im Griff haben, Plugins die innerhalb anderer System (z.B. CAD) laufen, Fremdsoftware usw... RAII heißt dann z.B. wir haben ein Handle auf ein Objekt, dass in einem anderen Prozess auf einem anderen Rechner lebt. Und dieses Objekt könnte wiederum eine Referenz auf ein Objekt (z.B. ein Callback) in unserem Prozess haben. Da ist es sehr wichtig, dass es alles stabil, in der richtigen Reihenfolge und zeitnah freigegeben wird, und nicht dass der GC irgendwann mal irgendwas in zufälliger Reihenfolge freigibt.
-
RAIIGCFrage schrieb:
Was theoretisch alles passieren kann ist mir in der täglichen Praxis so ziemlich egal, außer es geht um Sicherheit.
In der Praxis hast du dummerweise viele Programmierer die es einfach nicht schert aufzupassen. Bzw. die einfach doof sind. Oder beides.
Deswegen gibt es in der Praxis auch so viele Java und C# Projekte die Probleme mit der Resourcenverwaltung haben. Die man alle paar Tage oder gar Stunden neu starten muss weil sie sonst anfangen Zahnräder zu spucken. Oder die einen megafetten DB-Server brauchen, weil sie meinen DB-Connections einfach nicht freigeben zu müssen ("macht eh der GC für mich").Dummerweise machen diese Programmierer in der Praxis mit C++ genau so viele Fehler. Bloss eben andere. Nämliche oft welche wo dann gleich das ganze Programm abschmiert.
Daher sind Sprachen wie Java oder C# im enterprisigen Bereich beliebt. Weil's halt besser ist wenn man "nur" Performance-Probleme hat die man mit nem periodischen Restart oder nem dickeren DB-Server beheben kann - als wenn das Programm einfach abkackt.
(OK, natürlich nicht nur daher, aber es ist sicher einer der Gründe.)
-
Ist das Chauffeur-Wissen? Wenn nein, dann nenne mir ein paar C# und/oder Java-Anwendungen bei denen dies so ist. Eigentlich müsste es ja viel mehr als ein paar Anwendungen sein um solch eine Behauptung aufstellen zu können.
Einen dickeren Rechner hinzustellen, kann weit aus sparsamer sein, als längere Entwicklungszeiten, oder noch schlimmer Fachkräftemangel weil die Sprache zu komplex ist.
-
QuellenBitte schrieb:
Chauffeur-Wissen
Supi Argument.
QuellenBitte schrieb:
Fachkräftemangel
Geh weiter extrem wichtige PowerPoint-Präsentationen malen.
-
hustbaer schrieb:
RAIIGCFrage schrieb:
Was theoretisch alles passieren kann ist mir in der täglichen Praxis so ziemlich egal, außer es geht um Sicherheit.
In der Praxis hast du dummerweise viele Programmierer die es einfach nicht schert aufzupassen. Bzw. die einfach doof sind. Oder beides.
Das kann ich zwar unterschreiben (Gerade das von dir weiter unten angesprochene nicht-schließen von DB-Connections wird zum Teil selbst in Fachliteratur gerne gemacht), aber ich kenne aus der Praxis bislang keinen einzigen Fall bei dem...
hustbaer schrieb:
Deswegen gibt es in der Praxis auch so viele Java und C# Projekte die Probleme mit der Resourcenverwaltung haben. Die man alle paar Tage oder gar Stunden neu starten muss weil sie sonst anfangen Zahnräder zu spucken. Oder die einen megafetten DB-Server brauchen, weil sie meinen DB-Connections einfach nicht freigeben zu müssen ("macht eh der GC für mich").
...dies nötig wäre. Zumindest sind mir solche Fälle eigentlich das letzte mal vor etwa 10 Jahren vor die Flinte gekommen.
hustbaer schrieb:
Daher sind Sprachen wie Java oder C# im enterprisigen Bereich beliebt. Weil's halt besser ist wenn man "nur" Performance-Probleme hat die man mit nem periodischen Restart oder nem dickeren DB-Server beheben kann - als wenn das Programm einfach abkackt...
Nach meiner Erfahrung sind es ganz andere Argumente für C# im Enterprise-Bereich. Zwar braucht eine C#/Java-Anwendung (auch bei guter Programmierung) mehr Ressourcen als eine C++-Anwendung gleicher Art und Qualität, entscheidend ist aber die Entwicklungszeit (und diese ist nach meiner Erfahrung, im Gegensatz zu Mechanics Erfahrung - in jeder Projektgröße stark bemerkbar).
Es ist billiger einen etwas höher gerüsteten PC hinzustellen (vorwiegend geht es um etwas mehr RAM, und vielleicht ein klein wenig schnelleren Prozessor), als eine längere Entwicklungszeit zu bezahlen.
hustbaer schrieb:
(OK, natürlich nicht nur daher, aber es ist sicher einer der Gründe.)
Keiner der Gründe die ich als wirklich relevant in der Praxis bemerkt hätte.
P.S: Davon abgesehen kann es für die Performance sogar manchmal besser sein eine Connection nicht gleich frei zu geben (und Connectionpooling zu betreiben). Das ist aber abhängig davon wie häufig man Connections erzeugen muss.
-
Es ist ganz einfach. Wenn man C++ vermeiden kann, dann tut man dies. Eine Entwicklung mit C++ ist nun einmal teurer, als die Entwicklung mit Wald- und Wiesen-Sprachen, die jeder Fachinformatiker mal schnell, in angemessener Zeit, gelernt hat. Und Entwicklungskosten sind nun einmal das Teure bei der Softwareentwicklung. Als Projektleiter muss ich auch schauen ob ich Ausfälle in meinem Team schnell ersetzt bekommen und ob die Weiterpflege keine all zu große Einarbeitung erfordert.
Natürlich gibt es Projekte, wie Numerik-Libs, Grafikgeschichten, Multimedia etc. da muss man C++ einsetzen. Aber wie gesagt, wenn man die Wahl hat und die letzte Performance nicht die große Rolle spielt, dann meidet man C++ natürlich wo es nur geht.
-
CppMeider schrieb:
Es ist ganz einfach. Wenn man C++ vermeiden kann, dann tut man dies.
Sicher nicht. Es kommt aber darauf an für die richtige Aufgabe...
a) ...das richtige Werkzeug zu wählen.
b) ...vorhandene Fähigkeiten zu nutzen.Wenn man bislang ausschließlich in C++ entwickelt hat, kann C++ das richtige Werkzeug sein, wenn die Einarbeit in die Alternativen länger braucht, als an Entwicklungszeit eingespart wird.
Und zudem gibt es Anwendungsfälle in denen die "Wald- und Wiesen-Sprachen" ungeeignet sind, und Sprachen wie C und C++ tatsächlich das Mittel der Wahl sind.
CppMeider schrieb:
Als Projektleiter muss ich auch schauen ob ich Ausfälle in meinem Team schnell ersetzt bekommen...
Zu solchen Ausfällen sollte es in Firmen die ihre Angestellten gut behandeln nicht zu häufig kommen. Sonst ist etwas am Arbeitsklima oder gezahlten Gehalt falsch. Es gibt Firmen die z.B. nur auf Gehaltskosten schauen, aber vergessen das Einarbeitung viel Geld kostet, ebenso wie Erfahrung Zeit sparen kann - und wo die Fluktuationen sehr hoch sind. Es gibt andere Firmen in denen ein Ausfall nur sehr selten unerwartet (z.B. Krankheit) kommt.
CppMeider schrieb:
Aber wie gesagt, wenn man die Wahl hat und die letzte Performance nicht die große Rolle spielt, dann meidet man C++ natürlich wo es nur geht.
Wenn man die Wahl hat muss man dennoch schauen wie die Fähigkeiten der Mitarbeiter sind. Und manchmal führt dies tatsächlich auch dazu das man doch zu solchen Sprachen greift.
-
Wenn man C++ meiden kann, dann tut man dies. Das bedeutet, die Mitarbeiter haben kein Problem mit einer anderen Sprache und das Projekt erfährt auch kein Nachteil.
Mitarbeiter können aus verschiedenen Gründen kommen und gehen, da hat man als Chef, bei vielen Gründen, gar keinen Einfluss drauf. Umzug, Bereichs- und/oder Sprachenwechsel, Krankheit, Berufswechseln und so weiter und so fort, sind Variablen die man gar nicht beeinflussen kann.
Als Unternehmer muss ich dann, bei einem langjährigen Projekt, auch auf solche Mitarbeiter- Fluktuationen vorbereitet sein. Wenn mein Projekt also nicht durch Lecacy-Code, Libs oder Performance auf C++ unbedingt angewiesen ist, dann lasse ich doch die Finger davon.
Nicht falsch verstehen. Ich mag C++, so als Hobby. Auf Arbeit würde ich es aber nicht freiwillig einsetzten, wenn ich nicht muss.
-
CppMeider schrieb:
Wenn man C++ meiden kann, dann tut man dies. Das bedeutet, die Mitarbeiter haben kein Problem mit einer anderen Sprache und das Projekt erfährt auch kein Nachteil.
Wenn die Mitarbeiter erst die andere Sprache lernen müssen, dann muss man dennoch nachdenken. Wenn erst lernen auf dem Programm steht erfährt das Projekt eben doch einen Nachteil (und wenn es gar Alle sind, erst recht, ungeachtet davon ob die Mitarbeiter lernwillig oder nicht sind).
CppMeider schrieb:
Mitarbeiter können aus verschiedenen Gründen kommen und gehen, da hat man als Chef, bei vielen Gründen, gar keinen Einfluss drauf. Umzug, Bereichs- und/oder Sprachenwechsel, Krankheit, Berufswechseln und so weiter und so fort, sind Variablen die man gar nicht beeinflussen kann.
Nach meiner Erfahrung ist die Fluktuation nur da hoch, wo auch irgend was im argen liegt. Und da hat man als Chef durchaus Einfluss. Es gibt immer etwas Fluktuation, aber diese sollte in der Regel stark überschaubar sein.
CppMeider schrieb:
Nicht falsch verstehen. Ich mag C++, so als Hobby. Auf Arbeit würde ich es aber nicht freiwillig einsetzten, wenn ich nicht muss.
Ich will C++ nicht in den Himmel heben, ich selbst ziehe C# vor. Dennoch ist die Aussage "Wenn man C++ meiden kann, dann tut man dies" sicherlich auch viel zu pauschalisiert.
-
Und ich meide eben C# und mache freiwillig und gern C++. Nicht weil ich C# nicht mag, sondern weil ich die Projekte nicht mag. Will ich als C# Entwickler arbeiten, lande ich mit großer Wahrscheinlichkeit irgendwo als 0815 Enterprise Entwickler. Mag ich nicht mehr machen.
QuellenBitte schrieb:
Ist das Chauffeur-Wissen? Wenn nein, dann nenne mir ein paar C# und/oder Java-Anwendungen bei denen dies so ist.
Ich weiß auch nicht genau, was hustbaer meint, aber so viele bekannte C# Programme für Endanwender gibts ja nicht. Und wenn er dir paar Individualprogramme nennt, mit denen er schlechte Erfahrungen gemacht hat, wird dir das auch nicht weiterhelfen.
Ein Beispiel aus der Java Welt wäre denke ich Eclipse. Wird bei mir auch ständig langsamer und irgendwann muss ich das neustarten.
