Wie lange hat es gedauert bis ihr alle Aspekte von C++ verinnerlicht hattet?
-
dot schrieb:
Ich sagte nicht, dass Shared Ownership niemals Sinn macht
Hab ich auch nicht so verstanden, keine Sorge. Ich bin selbst der Meinung, dass
shared_ptroft zu leichtsinnig eingesetzt wird und sich Leute der Kosten nicht bewusst sind. Aber hättest du für so ein Ressourcen-System auchshared_ptrverwendet, oder wie hättest du das gelöst?dot schrieb:
Ich hab mir ja schon beim Verfassen des entsprechenden Postings gedacht, dass irgendwer was gegen meinen Wortlaut haben wird
Mit der extremen Formulierung hast du es geradezu provoziert :p
Nein, ich wollte nur darauf hinweisen, dass Move-Semantik nicht etwas ist, das mit C++11 vom Himmel gefallen ist. Aber zum ersten Mal kann man es jetzt sauber umsetzen.
Butterbrot schrieb:
*hust Ähm, Moderator? Wäre es möglich die MoveTheRValue-Diskussion, die zweifellos sehr interessant ist, abzusplitten?
Ja, wäre eine gute Idee.
-
Um auf's Thema zurückzukommen:
Ich hatte ca. 42 Wochen gebraucht, bis ich Guru in allen Belangen war und endlich an die Öffentlichkeit treten wollte. Dann kam dieser eine versoffene Abend und seither laufe ich meiner Form hinterher!
-
Nexus schrieb:
Aber hättest du für so ein Ressourcen-System auch
shared_ptrverwendet, oder wie hättest du das gelöst?Jap, wenn shared_ptr direkt eine einfache Lösung für das konkrete Problem bieten würde, hätte ich es wohl einfach verwendet. In meinem Fall mit dem Glyph Cache dachte ich darüber nach, erstmal selbst einfach eine Art Reference Counting zu implementieren (shared_ptr wäre dort nicht wirklich anwendbar). Mit dem letzten Refactoring ist es nun allerdings nichtmehr notwendig, die Glyphen im Cache zu behalten, solange sie noch irgendwo verwendet werden und damit eröffnet sich die Möglichkeit, das Ding in einen richtigen Cache zu verwandeln und einfach einen LRU o.ä. Algorithmus zu verwenden. Imo wäre das in dem Fall eine bessere Lösung, da all die gegenseitigen Referenzierungen zwischen Dingen, die Glyphen verwenden und den Glyphen selbst verschwinden. Und bei einer potentiell großen Anzahl an Buchstaben, ist das wohl erstrebenswert. In deinem Beispiel mit den Bildern ist shared_ptr allerdings natürlich eine attraktive Lösung. Die Frage ist allerdings wieder, wie viele dieser Bilder nun tatsächlich von mehr als einem Objekt verwendet werden und ob ein geteiltes Bild nicht vielleicht einfach dort gehalten werden kann, wo auch die Objekte, die es verwenden, gehalten werden oder ob nicht vielleicht zumindest auf anderem Wege einfach die gleiche Lebensdauer garantiert werden kann, ohne jetzt direkt jedem Objekt Besitz über das Bild zu geben. Ich denke da jetzt z.B. wieder an Texturen. Meistens wird eben ein bestimmes Modell eine bestimmte Textur verwenden. Der Fall, dass verschiedene Modelle die gleiche Textur verwenden, ist natürlich durchaus vorstellbar, aber sicherlich nicht unbedingt der Regelfall. Und in dem Fall wird es wohl nicht unwahrscheinlich sein, dass zwischen diesen Modellen auch ein logischer Zusammenhang besteht und diese daher auch irgendwo an gemeinsamer Stelle verwaltet werden, womit es dann aber vielleicht möglich wäre, die Textur zusammen mit den Modellen zu halten und einfach eine Referenz an die Modelle zu übergeben. Und schon ist die Shared Ownership wieder aufgelöst...
Nexus schrieb:
dot schrieb:
Ich hab mir ja schon beim Verfassen des entsprechenden Postings gedacht, dass irgendwer was gegen meinen Wortlaut haben wird
Mit der extremen Formulierung hast du es geradezu provoziert :p
Nein, ich wollte nur darauf hinweisen, dass Move-Semantik nicht etwas ist, das mit C++11 vom Himmel gefallen ist. Aber zum ersten Mal kann man es jetzt sauber umsetzen.
Nun, da stimmen wir natürlich in unserer Meinung völlig überein, aber zugegeben, ich hab es etwas provokant Formuliert...
-
Habe ich was verpasst? Macht shared_ptr kein ref counting? Und warum wird unique_ptr ins Spiel gebracht, wenn es um shared ownership geht. Und was hat das mit move-Semantik zu tun? Ging vorher auch schon, musst man halt selbst machen. Warum sollten auf einmal Referenzen out werden? Welche alten Prinzipien werden jetzt ungueltig?
-
Um zum Thema zurückzukommen:
allein die wichtigsten Fakten über C++ zu lernen, dürfte irgendwas zwiaschen 3 und 12 Monaten dauern, bis man alle Einzelheiten und Feinheiten kennt, deutlich länger (Der Standard ist groß...).
Die ganzen Implikationen zu lernen, d.h. wie man mit der Sprache umgeht, was Sinn macht und was nicht, dauert noch sehr viel länger, auch je nachdem wie viele der Sprachelemente man benutzt. Ich würde mich z.B. durchaus schon als Fortgeschrittener bis Profi sehen, habe aber auch schon 2004 mit C++ angefangen. 5 Jahre hats aber sicherlich gedauert, bis ich mich so weit gesehen habe. Das heißt aber nicht, dass es nicht mehr zu lernen gibt, ich habe z.B. noch einige Defizite im neuen Standard, auch in vielen feinen Details des alten Standards, ich kann mit dingen wie Mehrfachvererbung und virtueller Vererbung einfach nicht umgehen. Das Konzept und die Probleme verstehe ich (denke ich), habe aber keine Erfahrung damit. Bis ich den neuen Standard weitgehend intus habe steht der nächste schon wieder vor der Tür - ich denke man kann guten Gewissens behaupten, dass man wie in so vielen Bereichen des Lebens einfach nie auslernt.
-
Danke, sehr gut beschrieben und endlich wieder Topic^^
-
pumuckl schrieb:
...bis man alle Einzelheiten und Feinheiten kennt, deutlich länger...
Wenn dies den überhaupt je geschieht. Es gibt Bereiche die einfach für viele Anwendungen unnötig, oder nur sehr selten relevant sind.
Ich habe jetzt mal genauer nachgeschaut... Angefangen mit C++ habe ich etwa Ende 1996. Ich kenne das was für meine tägliche Arbeit nötig und möglich ist. So habe ich mich aus mehreren Gründen noch nicht wirklich mit vielen Themen zu C++11 und speziellen Teilen (z.B. Template Metaprogrammierung) beschäftigt - da ich es auch gar nicht einsetzen könnte, selbst wenn ich wollte. Es war schon schwierig genug einiges vom Standard in das Projekt einzubauen (hier wurde vorher vieles händisch gemacht).
Daher: Hängt euch nicht mit "allen Aspekten" auf. Solide Kenntnisse kann man innerhalb eines Jahres erwerben, wobei mindestens noch ein paar Jahre allgemeine Projekterfahrungen nötig sind um wirklich sinnvoll programmieren zu können (Vieles lernt man erst durch Anwendung, oder durch Rückmeldung von anderen) - Erfahrung sollte man nie unterschätzen. Ebenso wird man erst im laufe einiger Zeit abschätzen können was wirklich für die Projekte sinnvoll ist.
C++ vollständig zu beherrschen bringt meist in der Praxis nicht wirklich so viel - so lange man solide Kenntnisse der wesentlichen Bereiche beherrscht reicht dies.
-
Obwohl ich nicht den kompletten Thread gelesen hab, und deshalb auch nicht weiß, ob sowas in der Art nicht schon geschrieben wurde, möchte ich trotzdem gerne mitspielen.
Analog zur Frage "Wie lange hat es gedauert bis ihr alle Aspekte von C++ verinnerlicht hattet?" gibt es im einem Akrobatik-Forum, in dem ich viel unterwegs bin, öfters mal fragen wie "Wie lange habt ihr gebraucht bis ihr einen guten Rückwärtssalto konntet?". Die Standard-Antwort auf sowas ist dann:'Naja, kommt drauf an, was du unter "gut" verstehst. Da hat jeder andere Ansprüche. Außerdem kommt jeder mit anderen athletischen Voraussetzungen daher. Manche haben auch koordinative Vorteile, weil sie vorher schon mal etwas ähnliches gemacht haben, und nicht jeder Steckt gleich viel Energie ins Training. Weil Leute also aus mehreren Gründen verschieden schnell lernen, kannst du also aus den Posts, die eventuell als Antwort auf deine Frage kommen werden, kaum ableiten, wie lange "es" bei dir dauern wird.'
Ich hab das Gefühl, dass sich das fast komplett auf C++ übertragen lässt.
-
Dobi schrieb:
Ich hab das Gefühl, dass sich das fast komplett auf C++ übertragen lässt.
Definitiv, klasse Beitrag!
-
Habe gerade in Herb Sutters Blog auch etwas passendes zum Thema gelesen:
I just got back from teaching a class, and I’m always amazed at the breadth and diversity of C++ developers. As Bjarne Stroustrup famously says: “No one knows ‘what most C++ developers do.’”
In particular, I’m surprised at how strongly some people feel about certain features, such as refactoring or safety or raw performance or exhaustive conformance, that don’t matter much at all to other people, ...
-
nn schrieb:
Habe gerade in Herb Sutters Blog auch etwas passendes zum Thema gelesen:
Hat eigentlich mit dem Thema wenig zu tun. Hier gehts um die Sprache C++ und wie man damit entwickelt (bzw. das Entwickeln lernt). In dem Blogpost (und dem Zitat) gehts um was ganz anderes, nämlich um Features der IDEs/Compiler, die Leute nutzen, sich wünschen und erwarten. Das ist etwas was mit der Sprache erstmal wenig zu tun hat.
Was eher in die Richtugn geht: http://www.meetingcpp.com/index.php/newsreader/items/islands-of-c.html - hier gehts um die verschiedenen "Geschmacksrichtungen" und Subsets von C++, die verschiedene C++-Entwickler benutzen. Nennt sich alles C++, aber die Lernkurven und damit die Zeit, die man benötigt, um "es" zu beherrschen, sind unterschiedlich.
In dem Sinne eine weitere Antwort an den Fragesteller: nicht nur "verinnerlicht" ist wie schon in vorigen Beiträgen gesagt ein schwammiger und ungenauer Begriff, sondern auch "alle Aspekte von C++". Je nach Entwicklungsumgebungen sind verschiedene Bibliotheken und Bibliotheksteile mit dem verbunden, was der jeweilige Entwickler als "alle Aspekte" verstehen mag.
-
Butterbrot schrieb:
(...)frage mich wie lange ihr hier gebraucht habt, bis ihr alles was C++ so bietet wirklich verstanden habt und aus dem FF anwenden könnt?
Ich habe 1996 mit StormC++ angefangen, und bin nicht davon überzeugt C++ komplett verstanden zu haben. Außerdem ist die Sprache so umfangreich, dass ich Mühe habe jemandem zu glauben, der behauptet, C++ komplett "aus dem FF" anwenden zu können.
Butterbrot schrieb:
(...) wie lange habt ihr gebraucht um die ganzen verschiedenen Konstruktoren, Operatorüberladungen, Templatesystem etc drauf hattet(...)
"Drauf haben" in Form von "Kennen-und-schonmal-angewendet-haben" geht recht fix. Mit den richtigen Büchern und Projekten ist das in ein paar wenigen Jahren geschafft.
Spaß beiseite, es ist natürlich wichtig sich die Bestandteile der Sprache anzuschauen. Aber auf "Krampf" zu versuchen alles zu verstehen, auch wenn du es nicht brauchst, ist vielleicht ein wenig viel.
Wie gesagt, ich bin seit ein paar "Jährchen" dabei, und lerne immer noch jeden Tag dazu.
Achja, @Dobi:
++ !
-
C++ ist ein Werkzeug. Es mag durchaus möglich sein, dass man sein Werkzeug in und auswendig kennt (was im Falle von C++ allerdings sicherlich viele viele Jahre in Anspruch nimmt; ich lern jetzt seit 10+ Jahren C++ und würd sagen, dass ich einen ganz guten Überblick hab, aber es gibt immer noch viele Winkel, in die ich noch nie geschaut hab). Aber selbst wenn jemand sein Werkzeug in und auswendig kennt, kann man daraus nicht schließen, dass er auch tatsächlich schonmal alles mit diesem Werkzeug gemacht hat, was man damit machen kann. Ich würde sogar soweit gehen und behaupten, dass man selbst mit einem simplen Schraubenzieher immer noch Dinge machen kann, auf die noch nie ein Mensch gekommen ist...
-
Irgendjemand hat mal gesagt, dass ein guter Programmierer rund 10000 Stunden an Programmierarbeit braucht um sich wirklich Pro zu nennen. Ich beispielsweise habe studienbedingt mit C, C++, Matlab, Assembler, Pascal und LabView in den Jahren 2006/07 ungefähr parallel angefangen. Matlab als erstes. Bei den ersten drei halte ich mich mittlerweile für recht gut. Ich kann es nicht auswendig, könnte aber auch ohne Probleme alles sehr schnell wieder rauskramen, da ich weiß wo es steht. Es kommt halt darauf an, was man halt so an Projekten gestartet hat. An sich kommt es beim Programmieren auch nicht unbedingt nur auf das Können der Progsprachen an, sondern an der Fähigkeit, die Zusammenhänge aufzubauen die man Programmieren will. Das kann man nur trainieren und das dauert meines Erachtens die Hauptzeit. Richtig lernen kann man meines Erachtens nur, wenn man sich selbst an größere Projekte wagt. Matlab hab ich gelernt weil ich Bildgebungsalgorithmen und die dafür zugehörige Signalverarbeitungsmathematik brauchte. C, weil ich Mexfiles applizieren musste und diverse Algorithmen auf C in kleine Bibliotheken umschrieb und C++, weil ich einmal ein Qt4 Projekt anfing, um ein Kassenabrechnungssystem zu basteln bzw im Moment eine kleine IDE für Bildverarbeitungsalgorithmen schreibe. Da nutze ich C-Libs und C++ nebenher. Dabei treten ständig neue Probleme auf, die es zu lösen gilt. Da kann man nachblättern, hartnäckig in Foren fragen, aber es ist irgendwann gelöst und idR sogar so, dass man es auch richtig verstanden hat.
Im Kern kann man einfach nur sagen. Machen! Je mehr, desto schneller hat man es drauf.
Grüße, Inge
-
Irgendjemand hat mal gesagt, dass ein guter Programmierer rund 10000 Stunden an Programmierarbeit braucht um sich wirklich Pro zu nennen
Jaja, irgendwer, hoerensagen, ... btw. Peter Norvig hier das Essay http://norvig.com/21-days.html
-
knivil schrieb:
Jaja, irgendwer, hoerensagen, ... btw. Peter Norvig hier das Essay http://norvig.com/21-days.html
Dieses Essay ist absoluter Rotz. Falsche Analyse, falsche Annahmen und von diesen überwiegend trivialen Tipps sollte man ihm ein paar um die Ohren hauen.
-
pumuckl schrieb:
nn schrieb:
Habe gerade in Herb Sutters Blog auch etwas passendes zum Thema gelesen:
Hat eigentlich mit dem Thema wenig zu tun.
Ich sehe das durchaus so, dass Anhänger verschiedener "Geschmacksrichtungen" sehr unterschiedlich starke Neigungen zeigen, sich mit Neuerungen oder "entfernten Winkeln" der Sprache auseinanderzusetzen.
Aber auch wenn man sich damit auseinandersetzt, fällt mir sofort das Zitat von Scott Meyers ein:
My best advice? Don't get fancy. Treat a new C++ feature like you would treat a loaded automatic weapon in a crowded room: never use it just because it looks nifty. Wait until you understand the consequences, don't get cute, write what you know, and know what you write.
-
Mitleid schrieb:
knivil schrieb:
Jaja, irgendwer, hoerensagen, ... btw. Peter Norvig hier das Essay http://norvig.com/21-days.html
Dieses Essay ist absoluter Rotz. Falsche Analyse, falsche Annahmen und von diesen überwiegend trivialen Tipps sollte man ihm ein paar um die Ohren hauen.
Jaja, die moechtegern Pros. Natuerlich hast du die Refernezen verfolgt und die verlinkten Papers gelesen, hast ein Doktor auf diesen Gebieten und kennst dich voll aus.
