C++ nach C#?

hustbaer

@Arcoth
Wichtinge Unterschiede gibt es mMn. einige was das Thema Finalisierung angeht. Bzw. Stolpersteine. Bzw. Dinge die man einfach wissen sollte.
z.B.:
* Der "Destruktor" (C# nenn das dummerweise so) kann aufgerufen werden während noch Memberfunktionen "auf" dem Objekts laufen. Und zwar wenn die Ausführung der Memberfunktionen an einem Punkt angekommen ist, wo "this" danach nicht mehr benötigt wird. Siehe GC.KeepAlive .
* Der "Destruktor" und die Dispose Methode können also auch gleichzeitig laufen.
* Die Dispose Methode kann mehrfach laufen, u.U. auch in verschiedenen Threads.
* Nachdem Dispose aufgerufen wurde können natürlich noch weiterhin andere Memberfunktionen aufgerufen werden.
* Man kann Objekte im "Destruktor" "resurrecten" indem man in irgend einem anderen Objekt wieder eine Referenz auf das bereits "unreachable" gewordene Objekt einträgt. Wenn man das macht muss man es allerdings auch dem GC mitteilen ( GC.ReRegisterForFinalize ). Und "normale" Weak-References glauben danach dass das Objekt immer noch "nicht mehr da" ist - man muss speziell trackResurrection=true übergeben wenn man solche wiederauferstandenen Objekte auch über die Weak-References wieder erreichen können möchte.
* "Destruktoren" von Basisklassen werden automatisch aufgerufen, bei Dispose muss man dies allerdings selbst erledigen.

Und generell sollte man nicht glauben was öfters im Netz zu lesen bekommt, nämlich dass man in C# deterministische Finalisierung (über IDisposable ) kaum jemals wirklich braucht, und es daher damit "nicht übertreiben sollte". Was totaler Humbug ist. Man sollte viel mehr sehr genau darauf achten und es überall dort implementieren wo es eben nötig ist.
Sonst bekommt man ganz schnell ein Programm das schlecht skaliert, oder einfach mal w/o gibt wenn es zu lange läuft ohne neu gestartet zu werden. Kenn man ja auch von einigen Java-Anwendungen.

Ein Pattern das mir beim C# Programmieren sehr geholfen hat, auf das mal als C++ Programmierer schnell kommt, als C++ unkundiger C# Programmierer aber vielleicht nicht, sind "RAII Hilfsklassen". Also Klassen die IDisposable implementieren, die man dann in einem using Block verwenden kann um irgendwas beim Scope-Exit zu machen.

Ist nicht alles ohne RAII und mit GC verpönt? Ich meine aufpassen muss man auch in C++. Aber wenn es reicht in Java und auch C# aufzupassen, warum werden sie dann schlechter gemacht als sie vielleicht sind? Ich mache C++ und Java und mir ist noch NIE da irgendwie die GC oder anderes komischen Sachen in die Quere gekommen und schon gar nicht hat mir RAII gefehlt.

Was theoretisch alles passieren kann ist mir in der täglichen Praxis so ziemlich egal, außer es geht um Sicherheit.

Mechanics

Man vermisst selten wirklich was, wenn man sich an eine Programiersprache gewöhnt hat und damit arbeitet. Hat mich schon immer genervt, dass man in Java keine Strings mit == vergleich kann, und zig andere Sachen. Aber als ich eine Weile Java programmieren musste, war mir das auch völlig egal, ich war im Projekt drin und hab nichts vermisst.

Na, was wird denn immer hier erzählt, dass man in Java irgendwann in Probleme rennt, weil man eben kein RAII hat und sich auf die Willkür eines GC verlassen muss. Dann wird noch propagiert, dass man die ganzen C++-Fehler, die der C++-Compiler anprangert, auch in Java hat, aber diese sind dort keine Fehler, weil nicht so hart geprüft würde. Diese Fehler fliegen einen dann in Java später um die Ohren und in C++ werden die gleich zu Anfang, durch die Fehlermeldungen, gefunden.

Dieser fehlende GC und das RAII hat mich dazu bewogen mein Projekt in C++ neu anzufangen, weil ich den Profis hier vertraute. Ich dachte irgendwann kommt die Keule in Java, weil es eben kein C++ mit so starken Prüfungen ist.

Ich persönlich hatte nie Probleme mit Java und auch C# habe ich ausprobiert. Vom Zeitfaktor bin ich in Java fünf mal so schnell fertig mit dem Code, da komme ich sehr schnell voran und die IDE unterstützt mich da optimal.

Mechanics

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.

hustbaer

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.

volkard

QuellenBitte schrieb:

Chauffeur-Wissen

Supi Argument.

QuellenBitte schrieb:

Fachkräftemangel

Geh weiter extrem wichtige PowerPoint-Präsentationen malen.

asc

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.

asc

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.

asc

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.

Mechanics

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.