new, arrays statt vector, char* statt string - warum?

[asc]

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é

[HansiHinterseher]

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?

[BorisDieKlinge]

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..

[Tachyon]

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.

[LordJaxom_lg]

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.

[Shade Of Mine]

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...

[phänomenal]

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 wie vector<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.

[Tachyon]

phänomenal schrieb:

Spaß beiseite - für einen Anfänger ist v = new int[xyz] doch genauso eine Blackbox wie vector<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.
Bei v = new int[xyz] hingegen muss er es wissen, sonst handelt er sich früher oder später ein fehlerhaftes Programm ein.

[phänomenal]

Tachyon schrieb:

phänomenal schrieb:

Spaß beiseite - für einen Anfänger ist v = new int[xyz] doch genauso eine Blackbox wie vector<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.
Bei v = 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 new denn unbedingt mehr wissen als bei vector<> , außer dass noch ein delete dazu gehört?

[Simon2]

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.

[asc]

phänomenal schrieb:

Was muss er bei new denn unbedingt mehr wissen als bei vector<> , außer dass noch ein delete dazu 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).

[Simon2]

phänomenal schrieb:

...Spaß beiseite - für einen Anfänger ist v = new int[xyz] doch genauso eine Blackbox wie vector<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.

[phänomenal]

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.

[Tachyon]

Simon2 schrieb:

phänomenal schrieb:

...Spaß beiseite - für einen Anfänger ist v = new int[xyz] doch genauso eine Blackbox wie vector<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.

[Boris Karloff]

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.

[asc]

Boris Karloff schrieb:

Eigentlich hat er recht, wenn er sagt, dass er Java hasst, weil er keine Ahnung davon hat. Das kann man doch bestätigen.

Das kann man. Vor allem verwundert es mich wie sein Programmcode und Alternativsprachen aussehen wenn er Java hasst

Ich sollte ihn für meine (noch) bisherige Firma empfehlen, da kann er sich dann mit meinen Programmierchef zusammen tun. Der Code in unserem C++ Projekt gleicht den von Boris

cu André

[BorisDieKlinge]

asc schrieb:

ch sollte ihn für meine (noch) bisherige Firma empfehlen, da kann er sich dann mit meinen Programmierchef zusammen tun. Der Code in unserem C++ Projekt gleicht den von Boris

hatte 2 jahre lang java in der schule... und programmiere jetzt seit einem Jahr effektiv C++!

[Hardco(der)re]

Java ist die schwulste sprache der Welt...

[fricky]

Simon2 schrieb:

weder der pädagogisch sinnvolle erste Schritt (so wie man nicht erst einen Rechner zusammenlötet bevor man sein erstes Programm schreibt)

manche machen es umgekehrt, also lernen zuerst programmieren, bevor sie sich für elektronik interessieren. ich gebe boris teilweise recht, daß es sehr unbefriedigend sein kann, nur mit black boxes zu hantieren.

Simon2 schrieb:

(*): 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.

normalerweise nimmt ein C-programmierer für sowas was fertiges. meistens hat er es noch nicht mal selber geschrieben.

[Simon2]

fricky schrieb:

...

Simon2 schrieb:

(*): 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.

normalerweise nimmt ein C-programmierer für sowas was fertiges. meistens hat er es noch nicht mal selber geschrieben.

... aber DAS ist dann nichtmal standardisiert - ergo: Anders Projekt=Neue Einarbeitung (inkl. aller Fehler).

Ich kenne übrigens tatsächlich nur sehr wenig "C-Hasen", die derartige Funktionalitäten von "fremd" einsetzen ... und viele, die immer ihre eigene "Radsammlung" mitbringen. Lustig wird's dann, wenn sie diese in ihre Schnittstellen verwursten.
Allerdings muss ich sagen, dass C in unserer Firma eine Außenseitersprache ist.

Gruß,

Simon2.