new, arrays statt vector, char* statt string - warum?
-
asc schrieb:
...Das Problem ist auch das Lehrer scheinbar auch weitgehend resistent gegen Empfehlungen oder Angebote sind...
Stimmt.
Ich denke, dass da 2 Faktoren zusammenkommen:
1.) Allgemeine "Weiterbildungsfaulheit". Da will ich mich gar nicht ausschließen: Ich brenne nicht mehr in JEDEM Aspekt meiner Berufstätigkeit darauf, das Neueste vom Neusten zu lernen - das war zu Beginn meines Berufslebens noch anders.
Und ich denke mal, dass es recht vielen Leuten so geht - auch mein Friseur fährt nicht auf 20 Weiterbildungskongresse im Jahr ....2.) Lehrer haben oftmals ein Selbstverständnis als "Wissenquelle in einem Umfeld von lauter Senken" und nicht selten halten ein solches Image sogar für lebensnotwendig. Das verbietet ihnen nahezu, Ratschläge von Außenstehenden (erst Recht vermittelt und erkennbar für Schüler) anzunehmen.
Gruß,
Simon2 (dessen Vater selbst Lehrer mit 0% von 1.) und 100% von 2.) ist)
-
Simon2 schrieb:
1.) Allgemeine "Weiterbildungsfaulheit"...
Das scheint inzwischen fast überall eher die Regel als Ausnahme zu sein. Und teilweise verstehe ich es auch (O-Zitat eines Chefs: "...mich interessiert es nicht was du in deiner Freizeit machst..."). Und wenn man sich selbst weiterbildet wird das von Seiten der Chefs teilweise sehr negativ aufgefasst (Im Sinne: er könnte dann ja vielleicht überqualifiziert für den Posten sein).
Wenn ich bedenke was ich in den letzten 4 Jahren an privaten Mitteln in meine Fortbildung gesteckt habe, muss ich sagen ich kenne nicht wenige Leute die das in ihrem Leben nicht selbst investieren. Und dann bekommt man ggf. auch noch Kritik von oben. Nee Danke, für eine solche Firma nie wieder (Wobei es bei mir nicht ein Einstellen der Weiterbildung, sondern ein Einstellung des Arbeitsverhältnis bei meiner aktuellen Firma ist)...
Simon2 schrieb:
2.) Lehrer haben oftmals ein Selbstverständnis als "Wissenquelle in einem Umfeld von lauter Senken" und nicht selten halten ein solches Image sogar für lebensnotwendig. Das verbietet ihnen nahezu, Ratschläge von Außenstehenden (erst Recht vermittelt und erkennbar für Schüler) anzunehmen.
Wenn man das (eher schlechte) Image nimmt das Lehrer haben, frage ich mich ob dies noch gerechtfertigt ist.
cu André
-
Naja ich bin immer noch der Meinung, das C++ lernen nicht einfach daraus besteht STL container zu verwenden etc. Und ddas wissen ab dieser ebene auszubauen... ich selber verwende die STL Container echt gern, aber ich will auch wissen was dahinter passiert bzw. was auf einer tieferen ebene passiert.
Mal ab gesehen von den schlechte Büchern, sollte jeder wissen wie man in C speicher allokiert bearbeitet etc.
Oft ist es gewohnheit , routine von frühr das man oft viel selber machen will. Ich verwende gern fertige bibliotheken , container etc. aber ich will auch wissen was dahinter geschieht:)
-
BorisDieKlinge schrieb:
Mal ab gesehen von den schlechte Büchern, sollte jeder wissen wie man in C speicher allokiert bearbeitet etc.
Weiss jeder JAVA-Programmierer, wie die JAVA-Collections im Hintergrund in C Speicher allokieren?
Und selbst wenn man das wissen müssen sollte: Bestimmt nicht zu Anfang.
Es aus Interesse wissen zu wollen ist eine andere Sache. Aber vorher muss ich wissen, wie ich es benutze. Ein Automechaniker wird schließlich auch nicht lernen, wie man einen Ottomotor baut, bevor er selbst einen Führerschein hat. (Wobei ich nicht weiss, ob Automechaniker tatsächlich zwangsweise einen Führerschein haben müssen)
-
BorisDieKlinge schrieb:
Naja ich bin immer noch der Meinung, das C++ lernen nicht einfach daraus besteht STL container zu verwenden etc. Und ddas wissen ab dieser ebene auszubauen... ich selber verwende die STL Container echt gern, aber ich will auch wissen was dahinter passiert bzw. was auf einer tieferen ebene passiert.
Mal ab gesehen von den schlechte Büchern, sollte jeder wissen wie man in C speicher allokiert bearbeitet etc.
Oft ist es gewohnheit , routine von frühr das man oft viel selber machen will. Ich verwende gern fertige bibliotheken , container etc. aber ich will auch wissen was dahinter geschieht:)
Ja?
Also mich interessiert nicht die Bohne, wie die STL tut, was sie tut. Mal davon abgesehen, kann sie auf viele verschiedene Arten und Weisen tun, was sie tut.
Ich benutze Bibliotheken, weil sie mir das Leben erleichtern. Wenn ich jedes Mal noch die kompletten Interna einer Bibliothek verstehen muss, geht das für mich irgendwie am Zweck vorbei. Und nicht selten habe ich erlebt, das Leute ihr Wissen über die Interna ausnutzen, um irgendwelchen Scheiss damit zusammen zuschreiben.
Dich interessiert doch bestimmt auch nicht, wie printf Pixel auf den Bildschirm zaubert, oder wie malloc genau den Speicher allokiert, oder?Klar, sollte man Wissen, was ein Pointer ist, und wie man ihn benutzt. Sonst könnte man auch die STL vergessen, weil man Iteratoren nicht versteht. Man sollte auch die Basics verstanden haben. Aber es ist eine Sache, die Dinge verstanden zu haben. Eine andere Sache ist es, sie ständig zu benutzen. Entweder wider besseren Wissens (besonders schlimm) oder weil man es nicht besser weiß.
Das Problem (das der Op auch angesprochen hatte) ist doch viel mehr, dass viele Leute die STL komplett liegen lassen, und dann irgendwas super umständliches für eigentlich banale Dinge zusammen schreiben. Oder noch schlimmer, dass die erweiterten Möglichkeiten die C++ gegenüber C bietet nur dazu benutzt werden, alten C Code in schicke Kleider zu packen.
-
BorisDieKlinge schrieb:
ich selber verwende die STL Container echt gern, aber ich will auch wissen was dahinter passiert bzw. was auf einer tieferen ebene passiert.
Man merkt nahezu allen deinen Beispielen auch deine C-Vorliebe an. Dennoch benötigt man keinerlei C-Kenntnisse. Die STL kann gänzlich mit C++ Mitteln umgesetzt werden, und man braucht dazu auch nicht zu wissen wie...
BorisDieKlinge schrieb:
Mal ab gesehen von den schlechte Büchern, sollte jeder wissen wie man in C speicher allokiert bearbeitet etc.
... unter C Speicher alloziert wird.
Ein C++ Buch sollte auch C++ beibringen und nicht C. Wenn ich eine Anleitung für das Austauschen einer Grafikkarte schreibe, muss ich auch nicht erst schreiben wie ich eine Soundkarte zusammenbaue um dann über Umwege a) zur Grafikkarte und b) zu dem eigentlichen Umtausch zu kommen.
cu André
-
Ja, wenn du aus eigenem Antrieb mehr wissen willst, als nötig ist, dann ist das ja deine persönliche Einstellung. Aber viele Bücher zwingen den C++-Anfänger dazu, sich mit Hintergrundwissen zu beschäftigen, obwohl ihn das nur daran hindert, C++ zu benutzen. Denn darum geht es ja ein einem Anfängerbuch: wie benutze ich C++?! Und nicht wie arbeitet ein Allokator auf Hardware-Ebene. DAS kann sich jeder später aneignen, wenn er will.
Die wenigsten Java oder C# Programmierer wissen, was im Hintergrundpassiert. Sie wissen es auch nur abstrakt, weil sie mal ein paar Skizzen gesehen haben. Warum muß aber ein C++ler wissen, wie der Allokator arbeitet? Wenn er doch eh schon funktioniert?
-
Ein automechaniker muss wissen wie ein otto motor funktioniert, muss aber keinen otto motor bauen.. das ist ein unterschied;) Ich will ja auch keine kompeltten container selber bauen, trozdem will ich wissen wie es funktiert
Deswgen hasse ich Java... ^^ Wenn ich mal schnell ein kleine tool bauen muss nehm ich VB^^ java ist nichts halber und nichts ganzes... Ich fühl mich nicht als richtiger programmierer, wenn ich nicht weis was so i nen tiefen abgeht.
Un 99% von euch Freaks hier, wissen ja wohl auch was weiter unten passiert.. ihr seht es aus ner anderen perspektive wie frischlinge;) Jetzt wo ihr wisst was so background funktioniert, ist es euch auch egal STL container zuverwenden, weil ihr softwaretechnisch so erfahren seit das ihr wisst was im hintergrund passiert..
Ihr müsst das mal aus der sicht eines kompletten anfänger sehen, der nich mal weis was ein byte ist..
-
BorisDieKlinge schrieb:
Ich will ja auch keine kompeltten container selber bauen, trozdem will ich wissen wie es funktiert
Mag sein, dass Du es willst.
Man muss es aber nicht wissen. Das einzige, das interessant ist, sind die Eigenschaften, die einem ein Container zusichert (wahlfreier Zugriff etc.). Das gleiche gilt für die Algorithmen. Es ist nur interessant, was sie tun, und ggf. noch wie hoch die Komplexität ist.
Mehr muss man nicht wissen.
Und ich bezweifle, dass Du verstehst, wie VB intern läuft.
-
BorisDieKlinge schrieb:
Ein automechaniker muss wissen wie ein otto motor funktioniert, muss aber keinen otto motor bauen.. das ist ein unterschied;)
Ich sprach von zu Anfang. Und Du wirst mir sicher zustimmen, dass der Mechaniker nicht wissen muss, wie der Ottomotor genau funktioniert, um den Ölwechsel zu lernen.
Un 99% freaks hier, wissen ja wohl auch was weiter unten passiert.. ihr seht es aus ner anderen perspektive wie frischlinge;)
Und genau um die geht es hier.
-
BorisDieKlinge schrieb:
Deswgen hasse ich Java... ^^ Wenn ich mal schnell ein kleine tool bauen muss nehm ich VB^^ java ist nichts halber und nichts ganzes... Ich fühl mich nicht als richtiger programmierer, wenn ich nicht weis was so i nen tiefen abgeht.
gerade java ist sehr transparent finde ich. bei vb sieht es da schon komplett anders aus - zumindest im nicht .net VB...
-
BorisDieKlinge schrieb:
Ich fühl mich nicht als richtiger programmierer, wenn ich nicht weis was so i nen tiefen abgeht.
Wenn du dazu wirklich konsequent stehen würdest, würdest du mit einem Magneten die Bits auf deiner Festplatte von Hand manipulieren statt in einer IDE C++-Code einzutippen, damit du dich als "richtiger Programmierer" fühlst.
Un 99% von euch Freaks hier, wissen ja wohl auch was weiter unten passiert.. ihr seht es aus ner anderen perspektive wie frischlinge;) Jetzt wo ihr wisst was so background funktioniert, ist es euch auch egal STL container zuverwenden, weil ihr softwaretechnisch so erfahren seit das ihr wisst was im hintergrund passiert..
Du schlägst also im Prinzip vor, dass man am besten mit Brainf*ck anfängt, damit man die Grundlagen beherrscht und sich dann langsam über Assembler und C zu BASIC vorarbeitet?
Spaß beiseite - für einen Anfänger ist
v = new int[xyz]doch genauso eine Blackbox wievector<int> v(xyz). Bei beiden weiß er nicht, was hinter den Kulissen passiert. Ich bezweifle deshalb, dass das wirklich eine nennenswert verbreitete Motivation dafür ist, den kompliziertesten und fehleranfälligsten Weg zu wählen.
-
phänomenal schrieb:
Spaß beiseite - für einen Anfänger ist
v = new int[xyz]doch genauso eine Blackbox wievector<int> v(xyz). Bei beiden weiß er nicht, was hinter den Kulissen passiert. Ich bezweifle deshalb, dass das wirklich eine nennenswert verbreitete Motivation dafür ist, den kompliziertesten und fehleranfälligsten Weg zu wählen.Jo, und für die Variante
vector<int> v(xyz)spricht ausserdem noch, dass der Anfänger auch nicht wissen muss, was passiert.
Beiv = new int[xyz]hingegen muss er es wissen, sonst handelt er sich früher oder später ein fehlerhaftes Programm ein.
-
Tachyon schrieb:
phänomenal schrieb:
Spaß beiseite - für einen Anfänger ist
v = new int[xyz]doch genauso eine Blackbox wievector<int> v(xyz). Bei beiden weiß er nicht, was hinter den Kulissen passiert. Ich bezweifle deshalb, dass das wirklich eine nennenswert verbreitete Motivation dafür ist, den kompliziertesten und fehleranfälligsten Weg zu wählen.Jo, und für die Variante
vector<int> v(xyz)spricht ausserdem noch, dass der Anfänger auch nicht wissen muss, was passiert.
Beiv = new int[xyz]hingegen muss er es wissen, sonst handelt er sich früher oder später ein fehlerhaftes Programm ein.Ich verstehe nicht ganz was du damit meinst. Widerspricht deine Aussage nicht meiner? Was muss er bei
newdenn unbedingt mehr wissen als beivector<>, außer dass noch eindeletedazu gehört?
-
BorisDieKlinge schrieb:
...ich will auch wissen was dahinter passiert bzw. was auf einer tieferen ebene passiert....
Das ist doch auch gut !
Ist halt die Frage, inwieweit Du dieses Wissen mal gewinnbringend einbringen kannst, aber das ist nicht immer ein Gegenargument gegen Neugier !In meiner Erfahrung ist es aber
- weder der pädagogisch sinnvolle erste Schritt (so wie man nicht erst einen Rechner zusammenlötet bevor man sein erstes Programm schreibt)
- noch der beste Schritt zu hoher Produktivität.
Was da an Zeit und Arbeitskraft verbraten wird, indem tausende von C-Programmierern das Rad permanent wieder neu erfinden ... oder sich in das jeweilige Rad ihres Vorgängers einarbeiten müssen (*), treibt einem die Tränen in die Augen. Was hätte man in der Zeit alles Großartiges machen können !?!?
(*): Denn auch C-Programmierer werden ihr einmal mühsam entworfenen "Containermodul" und Algorithmensammlung nicht jedesmal neu schreiben, sondern wiederzuverwenden streben ... leider mit proprietären Schnittstellen/Eigenschaften.
Aber dagegen, z.B. aus den STL-Implementierungen zu lernen, ist IMHO nichts einzuwenden. Allerdings habe ich deutlich mehr (weil Konzeptionelles) aus der Struktur der STL gelernt als aus der Bitfuddelei der konkreten Implementierung ...
Gruß,
Simon2.
-
phänomenal schrieb:
Was muss er bei
newdenn unbedingt mehr wissen als beivector<>, außer dass noch eindeletedazu gehört?Genau darum geht es doch unter anderem, um das delete[] (und auch um die Sachen das es Unterschiede zwischen delete und delete[] gibt etc).
-
phänomenal schrieb:
...Spaß beiseite - für einen Anfänger ist
v = new int[xyz]doch genauso eine Blackbox wievector<int> v(xyz). Bei beiden weiß er nicht, was hinter den Kulissen passiert. Ich bezweifle deshalb, dass das wirklich eine nennenswert verbreitete Motivation dafür ist, den kompliziertesten und fehleranfälligsten Weg zu wählen.
Gutes Argument 
Ich glaube übrigens, dass Tachyon Dein Argument noch um einen weiteren Vorteil verstärken wollte...
Gruß,
Simon2.
-
asc schrieb:
Genau darum geht es doch unter anderem, um das delete[] (und auch um die Sachen das es Unterschiede zwischen delete und delete[] gibt etc).
Ja, ok, jetzt. Da stand ich kurz auf dem Schlauch.
-
Simon2 schrieb:
phänomenal schrieb:
...Spaß beiseite - für einen Anfänger ist
v = new int[xyz]doch genauso eine Blackbox wievector<int> v(xyz). Bei beiden weiß er nicht, was hinter den Kulissen passiert. Ich bezweifle deshalb, dass das wirklich eine nennenswert verbreitete Motivation dafür ist, den kompliziertesten und fehleranfälligsten Weg zu wählen. Gutes Argument Ich glaube übrigens, dass Tachyon Dein Argument noch um einen weiteren Vorteil verstärken wollte...
Gruß,
Simon2.
Jup. Bei new muss man eben wissen, dass man a) einen Pointer braucht, um den Speicherbereich zu referenzieren, b) der Pointer auch ins Nirvana zeigen kann, c) der Pointer explizit wieder freigegeben werden muss, d) Unterschiede zwischen delete und delete[] bestehen, usw.
Obwohl ich eigentlich Deine Aussage stärken wollte widerspreche ich Dir, bei genaurer Betrachtung, zum Teil.
Für die reine Benutzung von v-Vektor und v-Heapobjekt ergibt sich für den Benutzer tatsächlich erstmal kein Unterschied. Aber wenn man mit der Benutzung fertig ist, oder wenn v "leer" sein soll, ergibt sich sehr wohl ein Unterschied.
Bei v-Vektor muss man sich um all diese Dinge wenig gedanken machen. Bei v-Heap muss man sehr konkret wissen, wie das ganze Geschäft mit dem dynamischen Speicher abläuft.
Für die meisten Anwendungsfälle (vor allem, die, die für Anfänger relevent sind) muss man aber von dem ganzen Pointergeschäft nichts wissen, weil man sehr gut ohne auskommt.
-
Shade Of Mine schrieb:
BorisDieKlinge schrieb:
Deswgen hasse ich Java... ^^ Wenn ich mal schnell ein kleine tool bauen muss nehm ich VB^^ java ist nichts halber und nichts ganzes... Ich fühl mich nicht als richtiger programmierer, wenn ich nicht weis was so i nen tiefen abgeht.
gerade java ist sehr transparent finde ich. bei vb sieht es da schon komplett anders aus - zumindest im nicht .net VB...
Eigentlich hat er recht, wenn er sagt, dass er Java hasst, weil er keine Ahnung davon hat. Das kann man doch bestätigen.