Existiert schönes C++ in der Praxis?
-
Eisflamme schrieb:
Und bei den ganzen
unique_ptr-Einsätzen spart man sich doch auch dasdeletean Schreibarbeit.Nicht nur das. Man spart sich auch, den Poiner auf Gültigkeit zu überprüfen und kann mit einem einzelnen und übersichtlichen Befehl "moven".
Zum Einen könen wie schon gesagt kaum Leute ordentliches C++. Es gibt ja sogar noch Leute, die Strings mit strcmp, strcpy etc bearbeiten.Dass ganze Iteratorenkonzept ist auch für Neulinge völlig verwirrend. Ich habe erst nach langer Zeit intensiver Beschäftigung mit C++ die Vorteile verstanden und war bis dahin über die übersichtlichen Klassen der Irrlicht-Engine froh.
Viele großen Projekte starteten auch in der Vergangenheit, bevor es Konzepte dazu gab und sind zu komplex, um noch umgestellt zu werden.
Mit Glück haben sie die fast gleichen Klassen aus der boost-library, aber das Einbinden dieser ist auch immer ein erheblicher Aufwand und man schleppt möglicherweise große Mengen Ballast (ungenutzer Code) mit sich rum und bekommt riesige Dateien. Deswegen hat man bei vielen Dingen auch keine RAII Klassen bereit gestellt bekommen oder musste sie selbstständig implementieren.
SmartPointer, die RAII erst konsequent für Pointer implementiert haben, gibt es ja auch erst seit 2011, davor nur die blöden auto_ptr oder halt boost. Das gleiche gilt auch für viele andere Dinge, wie Threads.
Das einzig Blöde ist nur, dass sehr viel auf die schon ewig vorhandenen streams zugunsten von fopen, printf, fputs etc. verzichtet wird, aber das ist die gewohnheit, denn diese Funktionen gibt es oft sogar mit gleichem Namen in fast allen Sprachen.
-
Eisflamme schrieb:
mit
typedefs undautokommt man doch ganz gut klar, finde ich. Und bei den ganzenunique_ptr-Einsätzen spart man sich doch auch dasdeletean Schreibarbeit.Allein das ist schon etwas praxisfern. Wie lange gibts C++11 schon? Noch nicht so lang. Im Gegensatz dazu gibts viele C++ Projekte schon seit Jahrzehnten. Wir benutzen in der Arbeit kein C++11 (und keinen C++11 fähigen Compiler) und es wird sicher noch Jahre dauern, bis wir umsteigen. Und irgendwie hab ich das Gefühl, als ob jetzt alle so tun würden, als ob C++ erst mit C++11 eine schöne Sprache geworden wäre, obwohl sie auch davor immer C++ Fans waren.
Ansonsten hab ich mich natürlich auch schon öfter gefragt, warum man in der Praxis so wenig schönen C++ Code findet. Ich könnte wahrscheinlich tausend Gründe finden, warum unser Code nicht besonders schön ist und warum ich ihn trotzdem ganz brauchbar finde, aber mich würd trotzdem mal interessieren, warum die meisten anderen keinen schönen Code schreiben ^^
-
Mechanics schrieb:
Und irgendwie hab ich das Gefühl, als ob jetzt alle so tun würden, als ob C++ erst mit C++11 eine schöne Sprache geworden wäre, obwohl sie auch davor immer C++ Fans waren.
C++ ist halt deutlich schöner geworden, weil es übersichtlicher und intuitiver geworden ist. Man kann ein Array per initializer_list in der Parameterliste der Funktion erzeugen und muss nicht wie früher den Container vorher anlegen und die Werte einzeln einfügen und man hat endlich ein foreach.
Super Tux Card ist ein Programm, das ordentliches C++ verwendet, aber halt noch c++03.
Die Irrlicht-engine selber ist zwar ordentlich und schön designed, aber RAII fehlt hier auch, an templates mangelt es und auf die stl wird fast vollständig verzichtet (hatte damals aber auch Gründe).
-
Die Leute hier im Forum sind eher Hobby-Progger und programmieren nur ganz kleine Sachen. Jedes größere Projekt ist eklig - egal in welcher Sprache. Versprochen!
-
raii-man schrieb:
Die Leute hier im Forum sind eher Hobby-Progger und programmieren nur ganz kleine Sachen. Jedes größere Projekt ist eklig - egal in welcher Sprache. Versprochen!
Dem würde ich beidem einfach mal so widersprechen.
1.- die meisten hier arbeiten auch beruflich als Software-Entwickler. Es sind sicherlich einige Studenten/Schüler dabei. Einem Schüler kann man unterstellen, dass er von "richtiger" Entwicklung keine/kaum Ahnung hat. Aber schon bei einem Informatik Studenten kann man mit solch einer Behauptung auf die Nase fallen.
2.- Klar, Projekte sind ab einem gewissen Umfang per Definition schon komplex und groß. Aber das bedeutet nicht eklig. Sieh es eher als Herausforderung. Aber es wird sicherlich auch große Projekte geben, die sehr gut sind.
Ich meine, wir Programmierer streben doch alle dem Idealismus nach, gerade hier im Forum. Lauffähigkeit reicht nicht, Fehlerfreiheit und Schönheit des Codes muss genauso erfüllt sein.
Und zumindest mir geht es, dass ich bei total schlechten Code einen Würgereiz kriege und diesen refaktorisiere. Und wenn mir das verwehrt bleibt, dann sinkt meine Motivation ungemein und meine Arbeitskraft geht gegen nullptr. (<-- Höhö^^, Witz g'macht)
-
Skym0sh0 schrieb:
Und zumindest mir geht es, dass ich bei total schlechten Code einen Würgereiz kriege und diesen refaktorisiere. Und wenn mir das verwehrt bleibt, dann sinkt meine Motivation ungemein und meine Arbeitskraft geht gegen nullptr.
Das geht mir auch so. Wenn ich ein kleines Stück Code herunterlade, dann passe ich das an den Standard und meinen Programmierstil an. Bei großen Programmteilen wird natürlich nur die API oder gar nichts angepasst.
-
schöner Code gesucht schrieb:
Wie kann es sein, dass 99% des C++-Codes, den ich finden kann, kein RAII enthält, obwohl es hier im Forum als der einzige Existenzgrund für C++ angepriesen wird?
Ganz davon abgesehen das RAII mit Sicherheit nicht als der einzige Grund für C++ angepriesen wird, wirst du es sicherlich schwer haben, guten C++ Code zu finden (gerade im Internet). Die Gründe sind vielfältig:
1. Gerade im OpenSource-Bereich arbeiten viele Hobbyentwickler mit.
2. Je nach Altersstruktur im Projekt wird man wenig von Konzepten sehen, die erst in den letzten 10 Jahren stark an Bedeutung gewonnen haben.
3. Viele Lehrbücher sind von (Tut mir Leid für die harte Formulierung, trifft aber leider recht häufig zu) Fachidioten, die nach meiner Erfahrung entweder älteren Semesters oder zumindest keine großen Projekte betreut haben.
4. Viele C++ nur als erweitertes C ansehen.
5. Viele Projekte unter Zeitdruck und mit permanenten Stress für die Entwickler gebaut werden.schöner Code gesucht schrieb:
Hier mal eine Funktion aus Code::Blocks, einer Entwicklungsumgebung entwickelt von fähigen C++ern:
Darf ich mal dumm fragen, warum du annimmst, das die Entwickler "fähig" waren?
Für mich sieht dies nach Code aus der definitiv aufgetrennt gehört, von einigen anderen Problemen ganz abgesehen.
schöner Code gesucht schrieb:
Existiert RAII&co. nur in Foren?
Nein, auch wenn in Foren sicherlich mehr davon existiert als Außerhalb davon, alleine schon weil ein Forum wie dieses auch einen gewissen Lehrcharakter haben soll. Gerade wenn es darum geht sollte man den Code möglichst ideal gestalten, damit es überhaupt eine Chance hat sich festzusetzen.
Zudem hat man in einem Forum auch keinen Zeitdruck hinter sich, oder Menschen hinter sich, die nach dem Studium das Lernen eingestellt haben.
schöner Code gesucht schrieb:
Wieso findet man keinen "schönen Code" in Nicht-Spielzeug-C++-Projekten?
Oh, es gibt definitiv auch "schönen Code" in großen Projekten, auch wenn ich dir kein Beispiel zeigen kann (Closed Source). Ich kenne aber auch viel schlechten Code (Die Gründe hast du oben schon bekommen).
-
raii-man schrieb:
Die Leute hier im Forum sind eher Hobby-Progger...
Nach meiner Erfahrung sind hier einige langjährige Entwickler mit Berufserfahrung zu finden (Ich z.B. bin ca. 13,5 Jahre Vollzeit in der Branche tätig). Und kaum ein Projekt davon war unterhalb von etwa 1/4 Millionen Codezeilen (Dies soll nicht über die Qualität, sondern über die Größe eine grobe Aussage treffen), das größte bei etwa dem 20igfachen davon.
raii-man schrieb:
Jedes größere Projekt ist eklig - egal in welcher Sprache. Versprochen!
Falsch. Hier kommt es in erster Linie darauf an, wie das Projekt aufgezogen und strukturiert wurde. Zwar ist die Tendenz für schlechten Code in größeren Projekten nach meiner Erfahrung auch höher, aber auch große Projekte kann man in kleine Einheiten auftrennen und so sinnvoll beherrschbar machen.
Problematisch an großen Projekten ist eher, das diese auch häufig eine lange Laufzeit haben, nicht selten auch ein sehr großes und wechselndes Team. Wenn ein Projekt 20 Jahre alt ist, wird sicherlich auch der ein oder andere Code einem Codestil folgen der vor eben jener Zeit üblich war.
Zudem sind die Entwickler unterschiedliche Codestile gewohnt und ebenso gibt es sehr Viele, die noch immer so programmieren, wie zu ihren Anfangszeiten (Ich verlange ja nicht, das sie extrem viel nebenher lernen, aber einmal alle 2-3 Jahre sich über den aktuellen Stand zu informieren ist wohl nicht zu viel verlangt).
-
Ich habe mit C angefangen und mein Code war voll mit malloc und free. Irgendwann habe ich dann malloc durch new und free durch delete ersetzt und ein paar
KlassenStructs mit Memberfunktionen hinzugefügt, dann char buffer[1024] durch string ersetzt, dann new/delete durch RAII usw. Immer wenn ich was neues gelernt und verstanden habe habe ich es auch eingesetzt, aber nie alles komplett überarbeitet. Entsprechend schlecht sieht der Code aus, von Anfänger-C bis ordentlichem C++ ist alles dabei. Es sind inzwischen ~40k Zeilen geworden.
Jetzt, wo ich deutlich mehr Plan habe könnte ich alles viel besser, aber nun ist der Code wie er ist und einen Monat (Zeit ist geraten) mit "Codeaufhübschung" zu verbringen kann ich nicht rechtfertigen.
Mein Punkt ist, dass Projekte von Leuten angefangen werden, die keine Ahnung haben. Und wenn sie später Ahnung bekommen oder ersetzt werden ist es zu spät.Ich meine mal den Vorschlag gehört zu haben, dass Programmiere in den ersten 5 Jahren keine eigenen Projekte anfangen dürfen. Nachdem sie 5 Jahre unter miserablem Code leiden mussten schreiben sie ordentlichen.
-
nwp3 schrieb:
Nachdem sie 5 Jahre unter miserablem Code leiden mussten schreiben sie ordentlichen.
Oder gewöhnen sich an eben diesen (was nach meiner Erfahrung eher passiert)...
-
nwp3 schrieb:
Ich meine mal den Vorschlag gehört zu haben, dass Programmiere in den ersten 5 Jahren keine eigenen Projekte anfangen dürfen. Nachdem sie 5 Jahre unter miserablem Code leiden mussten schreiben sie ordentlichen.
Ich habe bei mir die Erfahrung gemacht, dass es sich durchaus lohnt, Projekte anzufangen, solange man sich jederzeit der Tatsache bewusst ist, dass man es wahrscheinlich nicht schafft. Solange man ein Ziel vor Augen hat, arbeitet man motiviert weiter. Irgendwann kommt man an den Punkt, dass man es einfach nicht mehr weiterschafft. Dann erkennt man seine Fehler und bemerkt, dass z.B. modularer Aufbau hilft, die Übersicht zu wahren, dass man sich bei exceptions die andauernden Abfragen error-flag-abfragen spart, dass RAII die Aufräumblöcke erspart, vor allem wenn es mehrere returns gibt.
Man darf als Programmierer natürlich nicht zu sehr am Projekt hängen. Ich habe mein erstes 2 weitere Male völlig von vorne angefangen und es letztendlich doch aufgegeben, weil ich eingesehen habe, dass es viel zu viel Arbeit ist, es mich nicht mehr interessiert und im Grunde eine blöde Idee ist, aber ich bereue das überhaupt nicht, denn ich habe dabei die ganze Sprache von Anfang an gelernt.
-
nwp3 schrieb:
Jetzt, wo ich deutlich mehr Plan habe könnte ich alles viel besser, aber nun ist der Code wie er ist und einen Monat (Zeit ist geraten) mit "Codeaufhübschung" zu verbringen kann ich nicht rechtfertigen.
Ich hab mal irgendwo gelesen, dass jeder erste Entwurf inklusive der ersten Umsetzung, die Probe ist. Danach sollte man eigentlich nochmal die ganze Software neu aufbauen, weil man nun weiß, was wie wo verlangt ist und wie das umgesetzt werden kann.
Nachteil: Das ist absolut nicht praktikabel. Z.B. 2 Jahre etwas entwickeln und danach dasselbe innerhalb von 6 Monaten neu zu schreiben ist aus betriebswirtschaftlicher und zeitlicher Sicht nicht machbar.
-
Skym0sh0 schrieb:
Nachteil: Das ist absolut nicht praktikabel. Z.B. 2 Jahre etwas entwickeln und danach dasselbe innerhalb von 6 Monaten neu zu schreiben ist aus betriebswirtschaftlicher und zeitlicher Sicht nicht machbar.
Wenn du das Projkt die nächsten 10 Jahre warten musst, dann schon.
-
Hat das wirklich mal jemand gemacht? Ein 2jähriges Projekt wegwerfen und komplett neumachen? Schafft man das wirklich in 6 Monaten? Und wird es wirklich besser?
-
Mechanics schrieb:
Eisflamme schrieb:
mit
typedefs undautokommt man doch ganz gut klar, finde ich. Und bei den ganzenunique_ptr-Einsätzen spart man sich doch auch dasdeletean Schreibarbeit.Allein das ist schon etwas praxisfern. Wie lange gibts C++11 schon? Noch nicht so lang. Im Gegensatz dazu gibts viele C++ Projekte schon seit Jahrzehnten. Wir benutzen in der Arbeit kein C++11 (und keinen C++11 fähigen Compiler) und es wird sicher noch Jahre dauern, bis wir umsteigen. Und irgendwie hab ich das Gefühl, als ob jetzt alle so tun würden, als ob C++ erst mit C++11 eine schöne Sprache geworden wäre, obwohl sie auch davor immer C++ Fans waren.
Ansonsten hab ich mich natürlich auch schon öfter gefragt, warum man in der Praxis so wenig schönen C++ Code findet. Ich könnte wahrscheinlich tausend Gründe finden, warum unser Code nicht besonders schön ist und warum ich ihn trotzdem ganz brauchbar finde, aber mich würd trotzdem mal interessieren, warum die meisten anderen keinen schönen Code schreiben ^^Da kann ich nur voll zustimmen. Bis Du zufällig ein Kollege von mir
? Auch wir haben kein C++11 und werden es lange nicht haben. Und auch ich denke, dass C++ vor C++11 auch eine großartige Sprache war. Sicher ist C++11 ein Fortschritt. Aber ich bin auch mit C++03 sehr zufrieden und finde es fast schon ein wenig befremdlich, mit welcher Selbstverständlichkeit hier im Foum C++11 angewendet wird. Die meisten Projekte haben lange vor C++11 angefangen.
-
Bashar schrieb:
Hat das wirklich mal jemand gemacht? Ein 2jähriges Projekt wegwerfen und komplett neumachen? Schafft man das wirklich in 6 Monaten? Und wird es wirklich besser?
Zwar nur an einem Projekt, das ich größtenteils alleine betreue, aber ja: Ein 5 Jahre altes Projekt nach Übernahme erst ein halbes Jahr verschlimmbessert, bis ich einsah, dass es unwartbar war. Dann alles weggeworfen und in ein paar Monaten alles sauber neu gemacht, mit mehr Features und einem Code, den ich selbst heute noch (ein paar Jahre später) nur kurz ansehen muss, um ihn zu verstehen.
War eine gute Entscheidung. Hätte ich gleich so machen sollen.
-
Hm, Respekt. Aber ich meinte eigentlich, was selbstentwickeltes wegzuwerfen und selbst neu zu machen.
-
Marthog schrieb:
Es gibt ja sogar noch Leute, die Strings mit strcmp, strcpy etc bearbeiten.
Unglaublich, dass es sowas gibt... Aber das lässt sich wohl nicht vermeiden. Bisher hat man es in der STL nicht mal hinbekommen einen std::string Konstruktor für die fstreams zu basteln.
Von Sockets und anderen lustigen Dingen ( ja, ich weiß, die sind nicht Teil der STL ), mal ganz zu schweigen...
Mich verwundert nicht, dass der eine oder andere streckenweise mit C-Funkionen arbeitet. Ich versuche es, wo immer die Performance es zulässt, mit C++ zu arbeiten. Seit den Shared-Pointern ist es wieder etwas leichter, weil man die auch mal ohne Kopfschmerzen in einen Container kopieren kann ( in den STL-Container ist ja praktisch immer alles mit Kopieroperationen verbunden ), während man es vielleicht mit dem Objekt selbst nicht tun wollen würde.
Es vergeht kein Tag wo ich nicht Gott ( in case he exists ) für die Shared_Pointer ( und die anderen ) danke
-
It0101 schrieb:
Unglaublich, dass es sowas gibt... Aber das lässt sich wohl nicht vermeiden. Bisher hat man es in der STL nicht mal hinbekommen einen std::string Konstruktor für die fstreams zu basteln.
It0101 schrieb:
in den STL-Container ist ja praktisch immer alles mit Kopieroperationen verbunden
Du solltest dir vielleicht mal den aktuell gültigen Standard ansehen
-
Hmm falls sich da inzwischen was getan hat, sollte ich mir den wirklich mal ansehen
Wurde ja wirklich mal Zeit. Die fstream-Konstruktoren waren ja schon fast peinlich
