dynamische Speicherallokation
-
Mitleid schrieb:
Rein zur Gegendarstellung: Ich würde auf fertige Container verzichten und erst lernen Speicherverwaltung und ihre Tücken zu begreifen, zu verstehen wie Container implementiert werden können, bevor ich dann die Fertigpackung der STL verwenden würde. Einfach um letztlich mehr begriffen zu haben.
Deine Ansicht. Ich würde erst einmal ein grundsätzliches Verständnis von Programmabläufen und -logik als sinnvoll betrachten (da weitgehend Sprachunabhängig), und dann auf die Details wie die Umsetzung eingehen. Das ein paar Interna zum Verständnis sinnvoll sind stimmt, nur die Reihenfolge sehe ich zumindest aus Lehrtechnischen Gründen anders herum.
-
asc schrieb:
Deine Ansicht.
Ja. Aber die Diskussion hatten wir hier schon häufig. Wollte es nur nicht unkommentiert stehen lassen. Es führen viele Wege nach Rom, wie es so schön heißt.
-
Mitleid schrieb:
Rein zur Gegendarstellung: Ich würde auf fertige Container verzichten und erst lernen Speicherverwaltung und ihre Tücken zu begreifen, zu verstehen wie Container implementiert werden können, bevor ich dann die Fertigpackung der STL verwenden würde. Einfach um letztlich mehr begriffen zu haben.
Altes Thema. Verständnis der Interna ist zwar schön, aber nicht nötig. Das tolle an der Objektorientierung ist ja eben dass man die Klassen als Black Box benutzen kann, ohne über die Vorgänge drinnen Bescheid zu wissen. Es reicht, das Interface zu kennen. Ich muss keine Ahnung davon haben wie ein Motor aufgebaut ist, um mit dem Auto einkaufen zu fahren. Genausowenig brauche ich Ahnung von Containerimplementation um einen vector im Hausgebrauch zu benutzen. Man beschäftigt sich erst mit dem Gesamtüberblick, dann mit den Details.
-
Naja bei dem thema gehen die Meinungen auseinander. Ich bin da auch eher Mitleids Meinung.
-
Also, nur um mal aus meiner Sicht, die eben die eines gerade erste Lernenden ist, zu sprechen. Ich mag's eher "von der Pike auf". Das ist vielleicht anstrengender, aber man muss sich nachher nicht mehr mit "kleinkram" rumschlagen.
Klar, Fahrradfahren ist schön, aber wenn ich bei einem Platten nicht weiß, wie ich einen Schlauch wechsel, ist die ganze Tour im Arsch.
Aber das ist auch nur meine Meinung
Nochmal danke für die vielen Tips!
-
ElseKling schrieb:
Klar, Fahrradfahren ist schön, aber wenn ich bei einem Platten nicht weiß, wie ich einen Schlauch wechsel, ist die ganze Tour im *****.
Aber das ist auch nur meine Meinung
Sicher. Nur, wie hast dus gelernt? Hat Vati dir erst beigebracht den Schlauch zu flicken, die Birne vom Rücklicht zu wechseln und die Gangschaltung nachzustellen, oder hast du erst richtig fahren gelernt - ohne stützräder?

Ich will ja keinem sagen dass er nicht Reifen flicken lernen darf, bevor er ordentlich fahren kann. Ich sag nur dass mans nicht muss - entgegen der Aussagen mancher Leute in derartigen Diskussionen, die verlangen dass man erst Pointerfrickeleien verstehen muss bevor man die Werkzeuge benutzt die einem genau das abnehmen.
-
ElseKling schrieb:
Klar, Fahrradfahren ist schön, aber wenn ich bei einem Platten nicht weiß, wie ich einen Schlauch wechsel, ist die ganze Tour im *****.
Ich finde hinderlich wenn ich mich erst 90% der Zeit mit Dingen beschäftigen muss, die vielleicht in 10% der Fälle relevant sein könnten. Ich kenne hier recht viele die der Ansicht sind das man vor std::string erst die C-Strings durchnehmen, und Funktionen wie printf & Co lernen muss.
Ich bin der Meinung das Grundlagenwissen sinnvoll ist, aber weder in dem Maß und auch nur zielgerichtet (z.B. verwende ich nur äußerst selten Funktionen aus dem C-Bereich, mit Ausnahme von cmath).
Ebenso geht es bei mir auch beim Radfahren: Ich möchte erstmal Radfahren können, bevor ich lerne einen Schlauch auszutauschen. Ich lese bei Geräten auch erstmal die Kurzanleitung und verwende diese - was im Fehlerfall bestimmte Lampen am Drucker bedeuten schlag ich bei Bedarf nach.
cu André
-
asc schrieb:
Ich kenne hier recht viele die der Ansicht sind das man vor std::string erst die C-Strings durchnehmen, und Funktionen wie printf & Co lernen muss.
verwechsle da was nicht. nullterminierte strings ja. printf nein. arrays ja, FILE nein.
asc schrieb:
Ebenso geht es bei mir auch beim Radfahren: Ich möchte erstmal Radfahren können, bevor ich
laufen lerne.
ja, aber dann haste immer das problem, daß du keinen radweg von der küche ins badezimmer hast, daß die treppen so doof zu befahren sind und so. ganz kritisch wird's, wenn du mal vom rad gefallen bis und kein notrad dabei hast, um zum hauptfahrrad ziu radeln.
-
volkard schrieb:
asc schrieb:
Ebenso geht es bei mir auch beim Radfahren: Ich möchte erstmal Radfahren können, bevor ich
laufen lerne.
Tut mir leid, aber ungeachtet der unterschiedlichen Ansichten von Uns zum Thema C++, halte ich es von einem Moderator wirklich für unter der Würde, Beispiele mitten im Satz zu trennen und deren Bedeutung komplett zu verdrehen.
Ob man nun mit dem Lernen von der Programmierung mit der Verwendung als Mittel zum Zweck herangeht, und von dort aus nach dem Anwenden vereinzelt auf Sprachinterna eingeht, oder umgekehrt: Beides führt zum Ziel, nur die Ansichten darüber welche Richtung zielführender ist, gehen massiv auseinander.
Nur die Erfahrung die ich auch ständig durch dieses Forum bestätigt sehe: Man löst sich sehr schwer von dem zuerst gelernten. Daher bin ich der Meinung das man immer erst sehen sollte wie üblicherweise unter C++ programmiert wird, und von dort aus auf Interna eingegangen wird, nicht umgekehrt. Zudem bin ich auch der Meinung das man Details nicht immer bis ins letzte Detail benötigt, sondern bei Bedarf dann sein Wissen ergänzt. Heutzutage wird man ohnehin schon mit Informationen überschüttet, warum nicht die Informationsmengen auf den Bedarf hin auslegen.
cu André
-
volkard schrieb:
ja, aber dann haste immer das problem, daß du keinen radweg von der küche ins badezimmer hast, daß die treppen so doof zu befahren sind und so.
Als Anfänger möchte ich die Freiheit genießen und die große weite Welt erkunden. Weiter Strecken zurücklegen statt mich in engen Häusern rumzutreiben. Im Drive-In vorbeiradeln statt mich selber an den Herd zu stellen. Die Feinmotorik lern ich noch früh genug, nämlich dann wenn ich sie brauche.
ganz kritisch wird's, wenn du mal vom rad gefallen bis und kein notrad dabei hast, um zum hauptfahrrad ziu radeln.
Wenn ich vom Fahrrad falle ists an der Zeit, laufen zu lernen bzw. mir mein Notrad zu bauen. Aber nicht früher.
In einer Zeit wo immer mehr Bibliotheken die nötigen Abstraktionen von low-level Funktionalität anbieten und die eigentliche Programmierung auf der Ebene von Design Patterns und hohem Abstraktionsniveau stattfindet, wo es kaum noch pure Programmierer und dafür umso mehr Entwickler und Software-Architekten gibt, ist der Ansatz, bei Level 0 anzufangen, einfach nicht mehr zeitgemäß. Um den Kleinscheiß sollte man sich nurnoch kümmern müssen, wenn die gewünschte Funktionalität nicht bereits im gewünschten Umfang (oder mit der nötigen Performance) in einer Bilbiothek geboten wird, oder wenn man sich selber mit der Bibliotheksentwicklung beschäftigt.
Man sieht hier im Forum immer wieder, wie sich Leute mit Problemen auf niedrigem Level wie handgestrickten Schleifen, segfaults, Speicherlecks usw. abquälen, weil sie mit dem low-level Kram angefangen haben, ohne zu wissen dass ihnen das ganze Gefrickel von Algorithmen, Containern und Smartpointern abgenommen werden kann.
-
pumuckl schrieb:
In einer Zeit wo immer mehr Bibliotheken die nötigen Abstraktionen von low-level Funktionalität anbieten und die eigentliche Programmierung auf der Ebene von Design Patterns und hohem Abstraktionsniveau stattfindet, wo es kaum noch pure Programmierer und dafür umso mehr Entwickler und Software-Architekten gibt, ist der Ansatz, bei Level 0 anzufangen, einfach nicht mehr zeitgemäß. Um den Kleinscheiß sollte man sich nurnoch kümmern müssen, wenn die gewünschte Funktionalität nicht bereits im gewünschten Umfang (oder mit der nötigen Performance) in einer Bilbiothek geboten wird, oder wenn man sich selber mit der Bibliotheksentwicklung beschäftigt.
Man sieht hier im Forum immer wieder, wie sich Leute mit Problemen auf niedrigem Level wie handgestrickten Schleifen, segfaults, Speicherlecks usw. abquälen, weil sie mit dem low-level Kram angefangen haben, ohne zu wissen dass ihnen das ganze Gefrickel von Algorithmen, Containern und Smartpointern abgenommen werden kann.Das ist zwar soweit richtig, allerdings muß man sich dann die Frage stellen wer macht denn die Bibliotheken? Wenn sich jeder nurnoch auf die Smartpointer und Container verlässt weil sie einfach Funktionieren und nicht schlecht sind dann haben die leute evtl nichtmal den Drang dahinter zu schaun, und sind damit nurnoch ind er Lage die Bibliotheken zu benutzen und dans sehe ichs chon als problem. Nimm zB Smartpointer, du setzt jemandem einen Smartpointer vor, aber ohne das Problem das er bekämpfen soll zu verstehen werden ihn die leute einfach benutzen und evtl garnicht auf den Gedanken kommen mal selbst herum zu experimentieren. Zumal man ja auch sagen muß viele Anfänger hier machen das als Hobby und da komtm es aufs Ergebniss an und nicht wie schnell und effektiv es zustande kam.
-
asc schrieb:
Tut mir leid, aber ungeachtet der unterschiedlichen Ansichten von Uns zum Thema C++, halte ich es von einem Moderator wirklich für unter der Würde, Beispiele mitten im Satz zu trennen und deren Bedeutung
zu verdeutlichen.
nimm mich einfach als normalen menschen, der viel öfters recht hat, als du. nicht als moderator.
-
volkard schrieb:
nimm mich einfach als normalen menschen, der viel öfters recht hat, als du. nicht als moderator.
kennst du "fremdschämen"? das tue ich gerade.
-
volkard schrieb:
der viel öfters recht hat
also zumindest in punkto grammatik wohl eher nich...
