Also ich beschäftige mich in einem Weiterbildungskurs aktuell mit "C". Soweit auch kein Problem und den bisweiligen Code bis "_getch", "strcpy", "casts" usw. check ich auch.
Ich hab nur 1 Problem, und das ist, lt. dem Trainer, der Algorithmus.
Heisst also ich kapier den Code der geschrieben wird, nur selbst Code zu schreiben der das gewünschte Ergebnis bringt funktioniert net so wirklich.
Daher meine Frage an die ge-, und beübten: Wie kann ich mich näher mit dem Algorithmus eines Programms befassen um künftig auch selber einfacher Code schreiben zu können?
Also leider ein nicht ausreichend vorhandenes Grundelement der Programmierung.
Mit den Tutorials der Seite beschäftige ich mich übrigens gerade.
Thx@all

Eingabe:
    Zahl1, Zahl2
Verarbeitung:
    Zahl3 = Zahl1 + Zahl2
Ausgabe:
    Zeige Zahl3

Dann überlegst du dir, welche Elemente du für jeden Schritt brauchst und fängst an. Als erstes muss natürlich ein Grundgerüst stehen. Bei einer Konsolen-Anwendung schreibst du dir also erstmal die Main Funktion oder überlässt diese Aufgabe meinetwegen auch dem Klassen-Assi (Falls du MS Visual Studio benutzt).

Mach dir zum Anfang vielleicht ein Paar Notizen. Sowas in der Richtung (EVA Schema hilft )

Ja, wirklich? Zeig mal ein "EVA-Schema" für ein Programm, das 10 Zahlen einliest und sortiert wieder ausgibt. Wenn man sowas erstellen kann, dann kann man den Code IMHO auch sofort schreiben. Ich glaube nicht, dass einen so ein "EVA-Schema" weiterbringt.

@Ki: Ok, vielleicht bringt es dich weiter. Es ist ja jeder Mensch anders. Ich glaube aber, dass du dein Problem so nicht wirklich lösen können wirst. ...ich glaube sogar, dass du dein Problem gar nicht lösen können wirst. Was dir fehlt ist IMHO Talent. Sorry, wenn ich dir das so direkt sage. Es mag sein, dass du bezüglich deines Problems kleine Fortschritte machen wirst und das ist auch sehr wahrscheinlich. Ich denke aber nicht, dass aus dir jemals ein guter Programmierer werden wird. Ganz ehrlich: Ich würde dir empfehlen, dir ein anderes Betätigungsfeld zu suchen.

...so, jetzt könnt ihr mich alle fertig machen, weil ich so ne demotivierende Antwort gegeben habe, die alles andere als nett ist. :p

Sorry, es sind leider nicht mehr Smileys erlaubt. Ich hätte gerne alles zugekleistert.

Ja, wirklich? Zeig mal ein "EVA-Schema" für ein Programm, das 10 Zahlen einliest und sortiert wieder ausgibt. Wenn man sowas erstellen kann, dann kann man den Code IMHO auch sofort schreiben. Ich glaube nicht, dass einen so ein "EVA-Schema" weiterbringt.
...

Ok, das war jetzt bezogen auf sein kleines Zahlen-Additions Problem. Bei grösseren Sachen ist das natürlich Humbug. Ich würde entweder PAP's schreiben und wenns ins Detail geht dann Pseudo-Code. Letztendlich ist das sowieso alles Gewöhnungssache. Meistens mach ich mir bei komplizierten Sachen ein paar krakelige Notizen, einen PAP, meditiere dann ein bisschen über das Konzept und dann fang ich an zu hacken. Bis jetzt komm ich damit ganz gut klar. Kleinere Sachen kann ich i.d.R sofort ohne Probleme umsetzen.

Ich weiß noch, als ich C++ gelernt habe (habe vorher Assembler ohne Ende programmiert), und ich absolut nicht kapiert habe, was OO sein soll. Aber an einem bestimmten Tag, gab es bei mir den Aha!-Effekt. Das ist einer der Momente in meinem Leben, an die ich mich wie gestern erinnern kann. Und verdammt nochmal, ich habe OO-Talent! Heute löse ich alle Aufgaben im Beruf mit Links!

@Ki! Du brauchst Praxis, Praxis, Praxis...! Und Code lesen hilft einem nicht weiter, man muß es auch praktizieren. Meiner Meinung nach sollte man zu Anfang weniger fremden Code lesen, und später wird man mehr Aha!-Effekte in anderem (besserem) Code haben. Das Posting von Cpp_Junky fand ich sehr gut. Und ich kann bekräftigen, das du dich einfach täglich vor deinen PC setzt (privat meine ich!) versuchst zu coden. Egal ob der Algo schlecht oder gut ist. Wichtig ist, das es funktioniert. "Schön" machen kann man es danach immer noch.

Ich glaube nicht, dass Van Gogh täglich malen

Nicht täglich, aber lernen musste er es wohl auch irgendwann mal.

oder Einstein Mathe geübt hat

Hm, gerade bei Einstein geht man doch mittlerweile davon aus, dass ihm seine erste Frau Milena Maric bei einigen mathematischen Formulierungen seiner Theorien ganz entscheidend geholfen hat...

Werd ich wohl wirklich mit Aufschreiben oder -,zeichnen machen müssen.
Aber wird sich das im Laufe der Praxis ändern? Also ich schätze schon dass sich das EVA-Prinzip irgendwann weitestgehend automatisieren wird oder gibt es tatsächlich erfahrene Programmierer die das permanent auf die Weise machen müssen weil sies anders nicht checken würden?
Für etwaige weitere Tipps bin ich natürlich äusserst dankbar.

Also ich mach mir vorher immer erst Notizen, egal ob jetzt mit Bleistift und Papier oder mit einem Word-Dokument. In seriösen Firmen ist sowas grundsätzlich erforderlich, da du dann selten der einzige bist, der an einem Projekt arbeitet. Und eine gute Dokumentation der verschiedenen Projektphasen ist dann unumgänglich. Machst du sowas nicht, dann endet das im bekannten Trial'n'Error Verfahren und sowas ist im Normalfall der Tod (Projekt oder Firma, was auch immer).

Nein, wie gesagt, das Problem ist dahingehend dass ich nicht weis wie ich zum benötigten Ergebnis komme.
Als einfaches Beispiel: Ich brauche z.b ein Programm wo ich Zahlen eingebe und die anschliessend addiert ausgegeben werden (wie gesagt, nur als Beispiel). Ist eine simple Angelegenheit die ich trotzdem auf die Schnelle nicht hinkriege. Einfach aus dem Grund weil ich nicht weis wie oder mit was ich zu Schreiben beginnen soll bzw. welche Funktionen oder Bedingungen etc. ich benötige.
Wenn der Code vom Trainer gezeigt wird ist er für mich eindeutig klar und verständlich.

So geht es meiner Freundin auch (ich versuche seit geraumer zeit ihr programmieren beizubringen (allerdings VB und nicht C++, sie hält programme ohne GUI nämlich nicht für 'richtige' programme ;))).

Die Idee mit der wir gut fahren ist:
Ein Problem in Teilprobleme zu zerlegen.

Nehmen wir dein Beispiel:
Problem Nr 1:
1 Zahl eingeben.

wir schreiben also ein Programm wo man eine Zahl eingeben kann

#include <iostream.h>
int main() { int zahl; cin>>zahl; }

fertig.

uU auch noch in 2 schritte teilen:

1. programm erstellen das eine zahl hat

#include <iostream.h>
int main() { int zahl; }

2. zahl vom user eingeben lassen

als nächstes das ganze mit 2 zahlen.

nun schreiben wir ein anderes programm:
es soll eine zahl ausgeben:

#include <iostream.h>
int main() { cout<<7; }

nun wollen wir ein anderes programm schreiben, dass eine zahl berechnet:

#include <iostream.h>
int main() { int zahl=3+4; }

nach dem verbinden haben wir:

#include <iostream.h>
int main() { int zahl=3+4; cout<<zahl; }

und unser 1. programm ist:

#include <iostream.h>
int main() { int zahl1; int zahl2; cin>>zahl1; cin>>zahl2; }

wir müssen diese beiden programme nur noch miteinander verbinden:

#include <iostream.h>
int main() {
  int zahl1; int zahl2; cin>>zahl1; cin>>zahl2;
  int zahl=zahl1+zahl2; cout<<zahl;
}

und fertig

mag blöd klingen und aussehen - aber so kann man jedes problem in minimale teilprobleme zerlegen und wird nicht von der komplexität abgeschreckt.
denn
2 zahlen eingeben und addiert wieder ausgeben
ist wesentlich komplexer als:
1 zahl eingeben
und
1 zahl eingeben
wird zu
2 zahlen eingeben

1 zahl ausgeben
und
1 zahl berechnen
wird zu
1 berechnete zahl ausgeben

diese beiden zusammen ergeben dann:
2 zahlen eingeben und daraus eine zahl berechnen und diese ausgeben

schon haben wir es geschafft und nur recht einfache sachen gemacht.

Im prinzip ist das die selbe herangehensweise an 'echte' Probleme - man teil sie in kleinere probleme auf und am ende fügt man sie zusammen.

das schöne daran: wenn etwas nicht klappt sieht man sofort wo der fehler war - weil man nicht das gesamte programm als fehlerhaft einstufen muss, sondern nur den kleinen schritt an dem man gerade arbeitet.

nun kann man sich recht einfach hilfe holen ohne eine komplettlösung zu bekommen

bei meiner freundin hilft es normalerweise wenn ich ihr die richtigen fragen stelle - und so ihr denken in die richtige richtung lenke

das problem mit diagrammen ist IMHO, dass man bereits wissen muss, was man tut/tun will. Sie bringen also nichts wenn man keine ahnung hat wo man anfangen soll. Bei dem 'in Teilprobleme zerlegen' ansatz, kann man auch in der Mitte anfangen - weil es ja egal ist in welcher Reihenfolge man die Teilprobleme löst...

Ich weiß noch, als ich C++ gelernt habe (habe vorher Assembler ohne Ende programmiert), und ich absolut nicht kapiert habe, was OO sein soll. Aber an einem bestimmten Tag, gab es bei mir den Aha!-Effekt. Das ist einer der Momente in meinem Leben, an die ich mich wie gestern erinnern kann. Und verdammt nochmal, ich habe OO-Talent! Heute löse ich alle Aufgaben im Beruf mit Links!

Das kenne ich.

Ähnliches hatte ich mit Zeigern in einem C++ für Dummies Buch oder so...

OOP & Co. lernt man nicht indem man ein Buch liest.

Ich glaube nicht, dass einen so ein "EVA-Schema" weiterbringt.

Das denke ich schon. Wenn Du Dir das einmal aufschreibst, dann hast Du zumindest mal genau fixiert, was Du als kriegst und was Du haben möchtest. Das ist der erste Schritt zu einer guten Problembeschreibung. Und eine solche ist doch in den allermeisten Fällen schon mindestens die halbe Lösung.

Es gibt nunmal einfach Probleme, die man nicht auf einen Schlag in seinen Kopf reinbekommt weil sie zu umfangreich sind. Da ist es wirklich nützlich sich ein paar Notizen zu machen.

Gregor: Kannst Du mal nen Algorithmus implementieren der einen 8x8 Rubik's Cube löst? Nicht auf die Schnelle? Vielleicht fehlt Dir dann das Talent! - Vielleicht aber auch nicht und Du müßtest Dich damit erstmal genauer auseinandersetzen. Und das geht mit Stift und Papier prima.

Gerade wenn man mit Programmieren anfängt ist es wirklich schwierig den Blick auf das Wesentliche zu richten. Man kann ja als Mensch so ca. 7 Sachen gleichzeitig im Kopf haben, dann ist fertig. Wenn man von diesen 7 Sachen jetzt aber schon 4-5 für syntaktische Probleme reserviert hat... dann wird's halt eng und man muß irgendwo was auslagern.

MfG Jester

Kannst Du mal nen Algorithmus implementieren der einen 8x8 Rubik's Cube löst?

Oh, hör blos auf und guck dir eher mal an, womit Ki hier schon Probleme hat. Er weiß nicht, wie er an die Aufgabe herangehen sollte 2 Zahlen zu addieren. Aus meiner Sicht ist das hier kein Problem der Komplexität oder des Begreifens des Problems, sondern ein Problem, das in seiner Denkweise liegt. Er hat es einfach nicht drauf, ein Problem bzw. eine diesbezügliche Lösung in einer Programmiersprache zu formulieren. Ich sehe nicht, wie sich sowas so einfach verbessern sollte. Vor allem sehe ich nicht den Sinn darin, die Lösung des Problems in etwas Programmiersprachen-ähnlichem zu formulieren, wie es hier vorgeschlagen wurde. Damit wird er doch genau die gleichen Probleme haben, weil es letztendlich nur eine andere Notation ist.

Ehrlich gesagt habe ich auch noch nie jemanden gesehen, der sich solche "Pläne" vor dem Programmieren erstellt. Wenn man sich schriftliche Notizen macht, dann sind das doch in aller Regel ganz informelle Skizzen, die die Problemlösung oder das Problem vielleicht grafisch oder so darstellen. Es handelt sich nicht um eine Notation der Lösung, die man "mit nem Program gleich in Sourcecode umwandeln könnte". Welche Vorteile sollte soetwas gegenüber "Code direkt schreiben" haben?

Zumeist ist es doch wirklich schon die halbe Lösung genau zu wissen was man haben möchte. Zumindest ist das meine Erfahrung.

Oh, hör blos auf und guck dir eher mal an, womit Ki hier schon Probleme hat. Er weiß nicht, wie er an die Aufgabe herangehen sollte 2 Zahlen zu addieren. Aus meiner Sicht ist das hier kein Problem der Komplexität oder des Begreifens des Problems, sondern ein Problem, das in seiner Denkweise liegt. Er hat es einfach nicht drauf, ein Problem bzw. eine diesbezügliche Lösung in einer Programmiersprache zu formulieren.

Man sollte nicht zu hart mit denen sein, die zum ersten mal eine Programmmiersprache sehen, besonders, weil hier auch Leute mitschreiben und lesen, die deutlich unter 18 Jahre alt sind (mal unabhängig, was der OP ist). Ich glaube nicht, daß Du solchen recht tust, indem Du gleich aus der Ferne deren Leistungen aburteilst und jede Motivation im Keim erstickst.

Könntest du eine Aufgabe wie dein Beispiel in Deutschen Sätzen lösen? Also eine Beschreibung was du nacheinander tust.

Ja, ich denke schon. Stellt sich nur die Frage wie lange ich dafür brauchen würde ;-).

So geht es meiner Freundin auch (ich versuche seit geraumer zeit ihr programmieren beizubringen (allerdings VB und nicht C++, sie hält programme ohne GUI nämlich nicht für 'richtige' programme )).

Nerds unter sich. *schauder

Nerds unter sich. *schauder

Ach, Blödsinn; wenn man viel mit jemandem zu tun hat der programmiert, dann ist es doch ganz normal, zumindest ansatzweise verstehen zu wollen, was da ungefähr vorgeht.
Wenn meiner Freundin irgendein Programm abstürzt, dann kann ich sie auch nie mit einem einfachen "Naja, geht halt nicht." abspeisen sondern muss genau erklären was da jetzt gerade schiefgelaufen ist; selbst wenn sie sich sonst nicht sonderlich für Computer interessiert.
(Obwohl ich ihr vor kurzem KTurtle gezeigt habe. )