ganz einfache frage

[Shade Of Mine]

Nexus schrieb:

@ Shade Of Mine
Wir versuchen nur, dem Fragesteller so präzise Antworten wie möglich zu geben. Die "Frage" war: "ich brauche eine Funktion, die das und das macht". Da die händischen Möglichkeiten bereits genannt wurden, sollte es doch legitim sein, eine elegante Methode auch noch zu erwähnen? Gerade weil die Aufgabenstellung keine Bedingungen diesbezüglich stellte...

Es spricht nichts dagegen auch die richtige Variante zu nennen - aber drakon hat zB den Sinn einer Aufgabe nicht verstanden.

Und das schockiert mich.

[Simon2]

Shade Of Mine schrieb:

Aeh...

Ihr wisst schon wie man etwas lernt, oder?
Indem man es anwendet.

Ein Funktionsaufruf lehrt garnix. Ausser wie man eine Funktion aufruft....

Eben.
Wer sagt denn, dass das Lernen von std::count() (und insgesamt vom lösungsgerechten Umgang mit dem vollständigen Umfang der Sprachmittel) soviel weniger wert ist als das Lernen vom "Raderfinden" ?
und wo ist die Grenze? Darf man noch std::cout verwenden? Besteht C++ "eigentlich" nur noch aus primitiven Typen und den Operatoren darauf - und der Rest ist "Schummeln" ?

Gruß,

Simon2.

[volkard]

Simon2 schrieb:

Wer sagt denn, dass das Lernen von std::count() (und insgesamt vom lösungsgerechten Umgang mit dem vollständigen Umfang der Sprachmittel) soviel weniger wert ist als das Lernen vom "Raderfinden" ?

ich.

und wo ist die Grenze? Darf man noch std::cout verwenden? Besteht C++ "eigentlich" nur noch aus primitiven Typen und den Operatoren darauf - und der Rest ist "Schummeln" ?

solange man lernen alles will, darf man nur das anwenden, was man auch selber gebaut hat oder sicher bauen könnte.

schau dir das lernen in der mathematik an. gib dem drittklässler einen taschenrechner und sag ihm, daß er das kleine einmaleins nicht lernen soll, und es wird ein stümper werden, der den realschulabschluß nicht packt.

[Simon2]

Klar, wer "...alles.." lernen will, darf das gerne tun.
Der sollte aber erstmal wieder anfangen, Feuer nur mit Naturprodukten herzustellen.
Als nächstes mit selbstgebauten Holzwerkzeugen nach Erz graben (möglichst erstmal Eisen & Kupfer). Lustig wird's dann, seinen ersten Strom herzustellen - da kann er gleich mit Wind-/Wasserkraft anfangen. Mit Windkraft und Strom gräbt sich's dann viel leichter nach Öl (=> Kunststoffe für Isolatoren und irgendwann mal Platinen) und Halbleitermaterialien. ...
Ich klinke mich dann aber erst in 200 Jahren wieder ein, wenn er seinen ersten Transistor gelötet hat.

Mal im Ernst: Hier geht es um die Aneignung von Wissen, das einem berufliche Möglichkeiten eröffnet. Und zumindest in unserer Firma brauchen wir deutlich mehr Leute, die die vorgegebenen Strukturen effizient zu einer Lösung der aktuellen Probleme einsetzen können, als solche, die alles aus dem Nichts erschaffen können - aber erst in 3 Jahren fertig sind.

Natürlich gehören "Schleifen" zum grundlegenden Verständnis und sollten auch meiner Meinung nach gelernt werden. Aber warum müssen die Lehrer immer wieder dieselben Aufgaben stellen, für die es bereits Standardlösungen gibt? Als Schüler kommt man sich da veralbert vor. Sollen sich halt mal was Neues einfallen lassen....

Gruß,

Simon2.

[volkard]

Simon2 schrieb:

brauchen wir deutlich mehr Leute, die die vorgegebenen Strukturen effizient zu einer Lösung der aktuellen Probleme einsetzen können,

warum muss ich jetzt an prof84 denken?

Natürlich gehören "Schleifen" zum grundlegenden Verständnis und sollten auch meiner Meinung nach gelernt werden. Aber warum müssen die Lehrer immer wieder dieselben Aufgaben stellen,

weils auch sinnbringende lösungen sein sollen, wo man das gefphl hat, das auch mal später brauchen zu können.

für die es bereits Standardlösungen gibt?

weils auch sinnbringende lösungen sein sollen, wo man das gefphl hat, das auch mal später brauchen zu können.

Als Schüler kommt man sich da veralbert vor. Sollen sich halt mal was Neues einfallen lassen....

aber bei aufgaben, die völlig praxisfremd sind, wärs schlimmer.
da soll man dann eine klasse Algorithmus bauen und davon erben oder noch dümmeren schwachsinn.

[Simon2]

volkard schrieb:

Simon2 schrieb:

brauchen wir deutlich mehr Leute, die die vorgegebenen Strukturen effizient zu einer Lösung der aktuellen Probleme einsetzen können,

warum muss ich jetzt an prof84 denken?...

Keine Ahnung, kenne ich nicht.

volkard schrieb:

...weils auch sinnbringende lösungen sein sollen, wo man das gefphl hat, das auch mal später brauchen zu können. ...
aber bei aufgaben, die völlig praxisfremd sind, wärs schlimmer.
...

Was kann es Sinnloseres und Praxisferneres geben, als das Rad neu zu erfinden?

Gruß,

Simon2.

[Nexus]

Simon2 schrieb:

Was kann es Sinnloseres und Praxisferneres geben, als das Rad neu zu erfinden?

Bei der Übung hier geht es wahrscheinlich weniger darum, dass man die benötigte Funktionalität hat, als dass man bei der Implementierung etwas lernt. Wieso sollte man sich eine verkettete Liste bauen, wenn es std::list gibt? Entweder man braucht irgendetwas, das std::list nicht bietet, oder aber - was wahrscheinlicher ist - man will sich im Bereich Zeiger, Klassen und Templates fortbilden.

Nichtsdestotrotz finde ich es angebracht, hier std::count() zu erwähnen. Allerdings sollte dies nicht über die selbstgeschriebene Version gestellt werden, wenn man die Aufgabenstellung nicht genau kennt.

[Shade Of Mine]

Simon2 schrieb:

Natürlich gehören "Schleifen" zum grundlegenden Verständnis und sollten auch meiner Meinung nach gelernt werden. Aber warum müssen die Lehrer immer wieder dieselben Aufgaben stellen, für die es bereits Standardlösungen gibt? Als Schüler kommt man sich da veralbert vor. Sollen sich halt mal was Neues einfallen lassen....

Nein. So einfache Sachen sind wichtig - denn du musst es ja selber nachvollziehen können ob dein Ergebnis korrekt ist.

Super ist zB multiplikation/division über addition/subtraktion zu implementieren, in einem array etwas suchen oder zählen, einfaches sortieren, schauen ob etwas sortiert ist, etc.

all das wofür es standard lösungen gibt - denn idR gibt es genau deshalb eine standard lösung dafür weil man es immer wieder braucht...

du fängst beim lernen immer klein an. das macht ja auch sinn. du musst count() implementieren können bevor du es verwenden darfst. denn wenn nicht, dann führt das zu furchtbarem.

würdest du mathematik lehren indem du eine formel sammlung hergibst und einen taschenrechner. und dann eben die fläche eine quadrats als a^2 ausrechnen lässt? Oder würdest du erklären was ^ macht und was die fläche bedeutet, etc.

diese grundlagen sind essentiell! count() anwenden ist trivial, das kann ein schimpanse. count() implementieren nicht. da es aber nicht für alles vorgefertigte lösungen gibt muss man lernen probleme selber lösen zu können - am besten fängt man mit problemen an die man im kopf überprüfen kann - das man also weiß ob die lösung korrekt ist oder nicht.

zB pi auf 200mio stellen berechnen wäre doof, weil das nicht sinnvoll überprüfbar ist. zählen wieviele a in "hallo welt" vorkommen, ist dagegen schon deutlich einfacher überprüfbar.

Praxis ist dabei erstmal irrelevant. aber stell dir mal einen auto designer vor der keine ahnung hat was die idee und das konzept eines Rads ist. er baut immer die gleichen 4 räder in ein auto ein, weil er das halt so gelernt hat. sehr super. wenn er aber gelernt hat wie ein rad aufgebaut ist und welche probleme es löst, welche es nicht löst, wo es probleme hat, etc. dann wird er in einem gelädewagen größere räder einbauen.

und deshalb muss man die grundlagen lernen - oder wie es so schön heisst: gehen lernen bevor man läuft.

[freaky]

Shade Of Mine schrieb:

...

/sign
Das ist was ich meinte. Außerdem nochmal zum Threadersteller, eig. steht in seinem Comment das er eine Funktion schreiben soll und nicht nur eine Funktion benutzen soll. Ihr seid doch alle eig. nur besser in C++ geworden, weil ihr Sachen nach programmiert habt, erweitert habt, selbst geschrieben habt. Ich musste letztens eine Verketteteliste schreiben, die grad mal ein paar Sachen konnte wie der Vector-Container. Gedacht hab ich zwar "wofür das Rad nochmal erfinden", im nach hinein dachte ich aber, "wow ich hab was dazu gelernt", hab verstanden wie es funktioniert und was man brauch etc. Wie soll der Threadersteller nun wissen wie std::count() Funktioniert? Er weiß das die Funktion existiert, doch warum und wie sie funktioniert, weiß er nicht.

[Simon2]

Hi,

also ich glaube, Ihr schreibt das eher aus einem "musste ich früher auch machen"-Impuls. Dazu sind mir die Grenzen viel zu willkürlich:
Aha, eine Liste sollte man mal programmiert haben, bevor man std::list anwendet, aber ein Speichermanagementsystem, bevor man new macht nicht?
Eine Zählschleife MUSS vor dem ersten Gebrauch von std::count() sein, aber die Implementation von Ausgabe auf die Konsole macht man nicht selbst?
Wer hat denn schonmal arithmetische Operationen oder Zuweisungen "direkt" programmiert, evor er "*" und "=" verwendet hat?

Ich will nichtmal behaupten, dass man nicht auch mal "Basics" nachprogrammieren dürfte oder dabei gar niemals etwas lernen könnte ... aber es als Voraussetzung für die Verwendung bereits implementierter "Räder" zu nehmen, halte ich für zu selbstbezogen argumentiert.

Gruß,

Simon2.

P.S.: Ich habe wohl noch nie eine verkettete Liste selbst programmiert; habe nur mal implementationen gesehen und gedacht: "Was für ein nerviges Gefrickel! Gut, dass ich das nicht selbst machen/debuggen muss."

[Shade Of Mine]

Simon2 schrieb:

also ich glaube, Ihr schreibt das eher aus einem "musste ich früher auch machen"-Impuls.

Nein. Ich mache es heute immer noch so.

Dazu sind mir die Grenzen viel zu willkürlich:
Aha, eine Liste sollte man mal programmiert haben, bevor man std::list anwendet, aber ein Speichermanagementsystem, bevor man new macht nicht?

Nein, diese Grenze hast du erfunden, nicht ich.

Es ist durchaus OK new, std::list und auch count() zu verwenden ohne die implementierung zu kennen. Es geht nicht um die Tools sondern die Aufgabe.

Wenn die Aufgabe ist: schreibe eine verkettete liste, dann schreibt man eine liste und tut nicht von std::list erben. weil da sonst der lernfaktor 0 ist.

wenn ich matrix multiplation in der schule lerne, dann lerne ich ja auch matrix multiplaktion und nicht "wie bediene ich einen taschenrechner".

die idee dahinter ist lernen. siehst du echt nicht ein dass man bei der verwendung von count() nichts lernt? bedenke bitte: der OP ist in einem stadium wo er nicht sicher im umgang mit schleifen ist. count() hat hier den effekt dass er eine lektion einfach ueberspringt. das ist natuerlich bequem, aber schleifen muss er anwenden lernen, er muss schleifen einfach verstehen und beherrschen. und wenn er jetzt count() verwendet waehrend seine kollegen sich mit eine zaehlschleife rumschlagen, dann hat er am ende einen nachteil ihnen gegenueber.

Ich will nichtmal behaupten, dass man nicht auch mal "Basics" nachprogrammieren dürfte oder dabei gar niemals etwas lernen könnte ... aber es als Voraussetzung für die Verwendung bereits implementierter "Räder" zu nehmen, halte ich für zu selbstbezogen argumentiert.

Kleine Frage:
als du Autofahren gelernt hast, war das in einem auto mit automatikschaltung, tempomat und automatischem einparker? oder war es in einem auto mit handschaltung und ohne schnick schnack?

wenn du die grundlagen nicht beherrschst (es geht hier nicht darum die ganze STL nachzuprogrammierern sondern einfach schleifen anwenden zu koennen (und der OP kann eben schleifen _nicht_ korrekt anwenden) wie willst du dann komplexe probleme loesen?

P.S.: Ich habe wohl noch nie eine verkettete Liste selbst programmiert; habe nur mal implementationen gesehen und gedacht: "Was für ein nerviges Gefrickel! Gut, dass ich das nicht selbst machen/debuggen muss."

das verstehe ich nicht.
du hast echt nie eine liste implementiert? eine einfach verkettete liste ist in 0 komma nix fertig und als ring ist eine doppelt verkettete auch trivial. da muss man nix debuggen oder frickeln...

wie dem auch sei: eine einfache Frage:

sagen wir einmal die naechste aufgabe die der OP bekommt lautet: zaehle alle buchstaben die in der zeichenkette. natuerlich kannst du jetzt ganz lustig sum() empfehlen, aber dann kommt die aufgabe die 3 am haeufigst vorkommenden buchstaben auszugeben. was jetzt?
alle anderen mitschueler koennen diese aufgabe problemlos loesen, denn sie haben die beiden vorhergehenden verstanden. sie koennen solche probleme loesen und die loesungen auf andere probleme umlegen. waehrend unser armer OP wieder zu dir rennen muss und fragen welche fertige funktion es hierfuer gibt.

man koennte natuerlich verlangen dass alle aufgaben die gestellt werden nicht mit fertigen funktionen der STL implementierbar sein duerfen - aber das waere doch wahnsinns aufwand. deshalb nimmt man triviale beispiele die jeder versteht.

wenn man keine trivialen probleme loesen kann, wie will man dann komplexe loesen?

[taja]

Simon2 schrieb:

P.S.: Ich habe wohl noch nie eine verkettete Liste selbst programmiert

Das ist wohl dein Problem, hättest du es gemacht, dann würdest du jetzt wissen, dass es nicht um "Rad neuerfinden" geht, sondern darum die Grundlagen von Pointern, Resourcenverwaltung usw zu lernen. Außerdem, wer eine Liste selber programmiert, kann damit auch schon fast automatisch eine fertige verwenden, andersrum geht das nciht.

[Kritiker]

Simon2 schrieb:

P.S.: Ich habe wohl noch nie eine verkettete Liste selbst programmiert; habe nur mal implementationen gesehen und gedacht: "Was für ein nerviges Gefrickel! Gut, dass ich das nicht selbst machen/debuggen muss."

Die einfachste aller Datenstrukturen ist für dich schon gefrickel
Was machst du eigentlich wenn du mal vor einem Problem stehst das sich nicht mit einer Funktion aus der Standardbibliothek lösen lässt?
Z.B. verlangt dein Chef von dir einen Oktalen Baum zu schreiben. Sagst du ihm dann das ginge nicht, weil du nie gelernt hast wie man eine Baumstruktur schreibt. Die STL hatte dir bisher die Möglichkeit gegeben mit binären Bäumen zu arbeiten, deswegen hast du dich nie mit ihnen beschäftigt...

[freaky]

Was würdest du als Anfänger machen wenn du in einen Programmierkurs bist und es heisst "Schreibe in C++ UND in Delphi...". Dumm an der Sache ist, dass es wahrscheinlich dann kein std::count in Delphi gibt

Simon2 schrieb:

Wer hat denn schonmal arithmetische Operationen oder Zuweisungen "direkt" programmiert, evor er "*" und "=" verwendet hat?

... Nicht grad das beste Beispiel, aber dann könnte man ja noch ein wenig Tiefer gehen und sagen "bau deine eigene <iostream>, dein eigene std und wenn wir dabei sind, deinen eigenen compiler"...

Ich will jetzt nicht sagen das du komplett auf dem falschen Weg bist, aber bevor ich etwas benutze, will ich es wissen wie es geht und es zu benutzen wissen und warum es dies und jenes braucht.

[drakon]

das verstehe ich nicht.
du hast echt nie eine liste implementiert? eine einfach verkettete liste ist in 0 komma nix fertig und als ring ist eine doppelt verkettete auch trivial. da muss man nix debuggen oder frickeln...

Wenn es so trivial ist. Warum sollte man es dann machen? - Ich schliesse mich da Simon an. Ich habe eine normale Liste auch nie programmiert und wüsste nicht, warum ich es tun sollte. Ich nehme mir da lieber etwas anderes vor, dass nicht schon so zugänglich vorhanden ist, wie z.B ein R-Tree, oder ähnliches. Da lernt man auch etwas davon..

wie dem auch sei: eine einfache Frage:

sagen wir einmal die naechste aufgabe die der OP bekommt lautet: zaehle alle buchstaben die in der zeichenkette. natuerlich kannst du jetzt ganz lustig sum() empfehlen, aber dann kommt die aufgabe die 3 am haeufigst vorkommenden buchstaben auszugeben. was jetzt?

Fände ich besser, wenn so eine Frage kommt. Also Zuerst wird dann vom Lehrer im Unterricht eine Aufgabe gemacht, wo das triviale zählen steht, dann sagt er nach einer Stunde, dass die ganze Arbeite "umsonst" gewesen ist und man einfach die Funktion nutzen kann. Und dann kommt die Aufgabe für die Leute wie man nun das macht, was nicht direkt mit einer Funktion geht.. Wer das einfache durchzählen dann nicht verstanden hat, kann sich das ja mal anschauen und selber nachprogrammieren und dann an die Aufgabe, die etwas mehr Kreativität benötigt.

Allerdings hängt das ganze ja von der Stufe ab, in der der OP sich befindet..

Und an das, dass ich nicht verstehe soll, was eine Aufgabe soll:
Mir ging es eigentlich darum, dass man die Aufgabe elegant löst. Und wenn man andere Wege kennt, dann sollte man es nicht umständlicher machen, damit man die Aufgabe "richtig" gelöst hat.. Dann sollte die Aufgabe anders gestellt sein und auch die miteinbeziehen, die vlt. schon etwas anderes kennen und sagen, dass man die std-lib nicht benutzen darf.

[freaky]

drakon schrieb:

Mir ging es eigentlich darum, dass man die Aufgabe elegant löst.

Okay, wenn jemand zu mir demnächst meint "programmier in C/C++ ein Ego-Shooter", lade ich dann auch einfach den Quake-Sourcecode runter und Compile den? Wäre anscheinend die eleganteste Lösung ...

drakon schrieb:

Ich habe eine normale Liste auch nie programmiert und wüsste nicht, warum ich es tun sollte.

Was würdest du machen wenn es hieße, du sollst einen erweiterten Vector-Container schreiben? Ich denke kaum das du in <vector> Datei rumfrickeln würdest, seh ich das richtig? Schön das du was von deinen R-Tree's lernst, doch bevor ein Anfänger einen B-Tree, R-Tree oder sonst eine Liste baut und an die fortgeschrittenen Sachen geht, erstmal wissen wie überhaupt die einfach Verketteteliste geht. Bevor ich ein 3D Spiel programmieren würde, würde ich mich wahrscheinlich erstmal an einem 2D Spiel versuchen

[Simon2]

Shade Of Mine schrieb:

Simon2 schrieb:

also ich glaube, Ihr schreibt das eher aus einem "musste ich früher auch machen"-Impuls.

Nein. Ich mache es heute immer noch so....

Das hat doch mit der Herkunft dieser Einstellung zu tun.

Shade Of Mine schrieb:

...siehst du echt nicht ein dass man bei der verwendung von count() nichts lernt? ...

Kann ich genauso umdrehen: Siehst Du nicht, dass man mit der Vernwenduing von std::count() etwas lernt?
Es hilft (wie eigentlich immer) in einer Diskussion gar nichts, wenn man versucht, den Anderen auf eine Extremposition festuzunageln versucht.

Shade Of Mine schrieb:

..als du Autofahren gelernt hast, war das in einem auto mit automatikschaltung, tempomat und automatischem einparker? oder war es in einem auto mit handschaltung und ohne schnick schnack?...

Sehr gutes Beispiel: Als ich Autofahren gelernt habe, habe ich gerlernt, die bereits vorhandene Technik einzusetzen! Ich musste weder eine Motorkurbel bedienen, noch erst einemal ein Getriebe zusammensetzen.
Natürlich habe ich AUCH ein Automatikauto gefahren, aber eben auch einen Wagen mit Schaltgetriebe.

Shade Of Mine schrieb:

...du hast echt nie eine liste implementiert? eine einfach verkettete liste ist in 0 komma nix fertig und als ring ist eine doppelt verkettete auch trivial. da muss man nix debuggen oder frickeln...

Was gibt es denn dann für micht zu lernen, wenn es so trivial ist?

Shade Of Mine schrieb:

sagen wir einmal die naechste aufgabe die der OP bekommt lautet: zaehle alle buchstaben die in der zeichenkette. natuerlich kannst du jetzt ganz lustig sum() empfehlen, aber dann kommt die aufgabe die 3 am haeufigst vorkommenden buchstaben auszugeben. was jetzt?...

Programmieren eben - mit den Mitteln, die es gibt.
Deswegen finde ich die 2. Aufgabe eben gut, wenn man Schleifen lernen soll und die erste nicht.
Es gehört IMHO für einen guten Programmierer dazu, die optimale Lösung zu finden - und das ist in 90% der Fälle Reuse.

Shade Of Mine schrieb:

...
man koennte natuerlich verlangen dass alle aufgaben die gestellt werden nicht mit fertigen funktionen der STL implementierbar sein duerfen - aber das waere doch wahnsinns aufwand. ...

Wieso? Ist doch wirklich Quatsch. Wir sehen doch schon hier im Forum, wie oft die leichte Abwandlung einer "Standardaufgabe" bereits die STL-Verwendung unnötig kompliziert macht und man mit einer "handgestrickten" Lösung viel besser fährt.
Nenene, als Informatiklehrer sollte man sowas schon drauf haben.
Aber es wird hier so sein wie immer: Der Info-Lehrer kennt bestimmt die STL gar nicht, denkt im Wesentlichen in Pointern, primitiven Datentypen und Operationen darauf und kommt gar nicht auf die Idee, dass er 80% Sprache noch nicht einmal ansatzweise gesehen hat.

Gruß,

Simon2.

[Simon2]

taja schrieb:

Simon2 schrieb:

P.S.: Ich habe wohl noch nie eine verkettete Liste selbst programmiert

Das ist wohl dein Problem, hättest du es gemacht, dann würdest du jetzt wissen, dass es nicht um "Rad neuerfinden" geht, ...

Kritiker schrieb:

Simon2 schrieb:

P.S.: Ich habe wohl noch nie eine verkettete Liste selbst programmiert; habe nur mal implementationen gesehen und gedacht: "Was für ein nerviges Gefrickel! Gut, dass ich das nicht selbst machen/debuggen muss."

Die einfachste aller Datenstrukturen ist für dich schon gefrickel
..

Ah! Ich wusste, dass ich damit in ein Wespennest steche. Ich habe den heiligen Gral der C-Programmierung befleckt! :p

Eigentlich ist mir ziemlich egal, ob Ihr mich für eine Flasche haltet oder nicht. Ich werde ganz gut bezahlt für das, was ich kann und seltsamerweise hat sich meine Abneigung gegen Selbstgestrickte Pointerfrickelei noch nie negativ auf meine Arbeit ausgewirkt (auch nicht bei der Analyse und Weiterentwicklung von fremdem Code).

Kritiker schrieb:

...
Was machst du eigentlich wenn du mal vor einem Problem stehst das sich nicht mit einer Funktion aus der Standardbibliothek lösen lässt?...

Dann löse ich es ohne StdLib - aber ich überlege mir seeeehr genau, ob es sich wirklich um ein derart exotisches Problem handelt, denn nach meiner Erfahrung ist das viiiiel seltener der Fall als oftmals (z.B. von jüngeren Kollegen) angenommen wird.

Kritiker schrieb:

...Z.B. verlangt dein Chef von dir einen Oktalen Baum zu schreiben. ...

Dann würde ich ihm sagen, dass er seine Arbeit machen soll, denn das ist keine fachliche Anforderung. Und wenn sich aus einer sauberen fachlichen Anforderung ergibt, dass sie am besten durch einen oktalen Baum umgesetzt werden kann, dann sehe ich nach, ob es davon bereits eine gute Implementierung gibt.
Und erst, wenn ich davon keine finde, setze ich mich hin und schreibe das selbst.
Über das Thema "Lernen" lass ich ja noch mit mir reden, aber sobald es darum geht, effizient Arbeit zu erledigen, ist der "ach das schreib ich mal eben selbst"-Ansatz die falsche Herangehensweise, für die einen jeder Projektmanager (zurecht) den Kopf abreißt.

Gruß,

Simon2.

P.S. Ich muss zugeben, dass ich damals in der 9. Klasse (also vor äh ... 25 Jahren) im Imfounterricht mal eine verkettete Liste programmiert habe (auch eine doppelte und diverse Baumstrukturen). Spaß gemacht hat's nicht ...

[volkard]

Simon2 schrieb:

bla

könntest du denn eine verkettete liste bauen? wenn ja, nimm meistens std::list.
aber wenn nein, dann tu es, um zu lernen, zu beispiel, daß zeiger nicht weh tun und kein gefrickele sind, sondern nur dann gefrickel werden, wenn der zeigerbenutzer von seinen listen nix gelernt hat.

außerdem wirste hier keinen gral der c-programmierung finden. falsches forum.

[taja]

Simon2 schrieb:

taja schrieb:

Simon2 schrieb:

P.S.: Ich habe wohl noch nie eine verkettete Liste selbst programmiert

Das ist wohl dein Problem, hättest du es gemacht, dann würdest du jetzt wissen, dass es nicht um "Rad neuerfinden" geht, ...

Ah! Ich wusste, dass ich damit in ein Wespennest steche. Ich habe den heiligen Gral der C-Programmierung befleckt! :p

Du hast es eindeutig kappiert...

Simon2 schrieb:

Eigentlich ist mir ziemlich egal, ob Ihr mich für eine Flasche haltet oder nicht. Ich werde ganz gut bezahlt für das, was ich kann und seltsamerweise hat sich meine Abneigung gegen Selbstgestrickte Pointerfrickelei noch nie negativ auf meine Arbeit ausgewirkt (auch nicht bei der Analyse und Weiterentwicklung von fremdem Code).

Du bist doch der in dessen Firma plötzlich Objekte in Listen auftauchen die da garnicht rein gehören und daran ist natürlich Java schuld und die Leute die damit arbeiten...