Was kommt nach den Grundlagen?
-
Hallo!
Ich bin neu hier im Forum und auch noch neu in der C++ Programmierung.
Vor etwa 2 Monaten habe ich mir das Buch C++ lernen und professionell anwenden
gekauft und die Grundlagen gelernt. Ich habe bereits einige kleinere
Programme erstellt und mir jetzt zusätzlich die C++ Programmiersprache
als weiterführendes Grundlagenbuch gekauft. Nun bin ich mir nicht im Klaren,
was ich als nächstes angehen soll. Sollte ich mich in ein Fachgebiet vertiefen,
wie die Netzwerk Programmierung oder sollte ich die Grundlagen noch weiter
vertiefen?
Ich würde mich über eure Antworten freuen.
-
WinSock / WinAPI fand ich eigentlich ganz interessant, aber grundsätzlich kann man wohl festhalten dass du einfach irgendwas schreiben solltest. Übung gehört halt dazu, besonders am Anfang.
-
Was kommt nach den Grundlagen?
Erfahrung sammeln. Wenn du ein Gebiet hast das dich interessiert dann beschäftige dich damit. Im Prinzip ist es ganz egal was du programmierst, Hauptsache du Programmierst. Der einzige Weg eine Sprache zu lernen ist sie zu verwenden
-
WinApi würde mich auch sehr interessieren.
Ist diese Schnittstelle noch aktuell? Ich habe gehört, dass sie abgelöst worden
sei.
-
cooky451 schrieb:
WinSock / WinAPI fand ich eigentlich ganz interessant, aber grundsätzlich kann man wohl festhalten dass du einfach irgendwas schreiben solltest. Übung gehört halt dazu, besonders am Anfang.
Das Erlernen eines Frameworks ist kein weiterer Schritt nach den Grundlagen. Das ist etwas, was bei Bedarf nebenbei geschieht.
Meine Meinung:
1. Das erste ist mal, dass man die Sprache wirklich gut beherrscht. Das heißt, Du musst mit allen Sprachmitteln, die C++ zu bieten hat, halbwegs umgehen können. Inklusive Templates und und und. Du musst C++ Code komplett lesen können.
2. Dann solltest Du Bücher durcharbeiten, in denen etwas dazu steht, wie ein guter C++ Stil aussehen sollte. Am Anfang wären das wohl die "Effective C++"-Bücher. Aber es gibt weitergehende. Gleichzeitig dazu solltest Du natürlich jede Menge programmieren.
3. Dann kommt der Stil im Großen, bzw. das Design. Ich meine dabei Entwurfsmuster. Besorg Dir ein Buch über Entwurfsmuster, arbeite es durch und wende sie an.
4. (Auswechselbar mit 3) Du solltest Dir Wissen über Algorithmen und Datenstrukturen aneignen. Das ist größtenteils sprachunabhängig. Wenn Du interessante Dinge programmieren möchtest, dann musst Du Dich mit Algorithmen auskennen. Dann musst Du Datenstrukturen wie Bäume, Hashtabellen, Graphen, Listen und so weiter im Schlaf nutzen können und Du musst wissen, wann Du was nutzt. Du musst Problemstellungen einschätzen können, um zu wissen, wie Du sie angehen kannst. Bzw. um überhaupt zu wissen, welche Probleme Du angehen solltest. Das ist der Punkt, wo wir von "Informatik" reden. Du betreibst Informatik, wenn Du Dir bewusst bist, warum Du welche Probleme in welcher Programmiersprache wie löst und wenn Du Dir diese Probleme selbst designst.
-
Welche Programme habt ihr denn am Anfang geschrieben um die Grundlage zu festigen?
-
Was richtig Sinn macht, ist es eigene generische Containerklassen zu bauen. Nicht unbedingt um der STL zu konkurieren, aber um das Verstädniss dafür zu bekommen.
Nicht nur eine zweifache Liste die ein Integer ausgibt, sondern mit Exeptions , Iterartoren und und und.
-
Gregor schrieb:
cooky451 schrieb:
WinSock / WinAPI fand ich eigentlich ganz interessant, aber grundsätzlich kann man wohl festhalten dass du einfach irgendwas schreiben solltest. Übung gehört halt dazu, besonders am Anfang.
Das Erlernen eines Frameworks ist kein weiterer Schritt nach den Grundlagen. Das ist etwas, was bei Bedarf nebenbei geschieht.
Meine Meinung:
1. Das erste ist mal, dass man die Sprache wirklich gut beherrscht. Das heißt, Du musst mit allen Sprachmitteln, die C++ zu bieten hat, halbwegs umgehen können. Inklusive Templates und und und. Du musst C++ Code komplett lesen können.
2. Dann solltest Du Bücher durcharbeiten, in denen etwas dazu steht, wie ein guter C++ Stil aussehen sollte. Am Anfang wären das wohl die "Effective C++"-Bücher. Aber es gibt weitergehende. Gleichzeitig dazu solltest Du natürlich jede Menge programmieren.
3. Dann kommt der Stil im Großen, bzw. das Design. Ich meine dabei Entwurfsmuster. Besorg Dir ein Buch über Entwurfsmuster, arbeite es durch und wende sie an.
4. (Auswechselbar mit 3) Du solltest Dir Wissen über Algorithmen und Datenstrukturen aneignen. Das ist größtenteils sprachunabhängig. Wenn Du interessante Dinge programmieren möchtest, dann musst Du Dich mit Algorithmen auskennen. Dann musst Du Datenstrukturen wie Bäume, Hashtabellen, Graphen, Listen und so weiter im Schlaf nutzen können und Du musst wissen, wann Du was nutzt. Du musst Problemstellungen einschätzen können, um zu wissen, wie Du sie angehen kannst. Bzw. um überhaupt zu wissen, welche Probleme Du angehen solltest. Das ist der Punkt, wo wir von "Informatik" reden. Du betreibst Informatik, wenn Du Dir bewusst bist, warum Du welche Probleme in welcher Programmiersprache wie löst und wenn Du Dir diese Probleme selbst designst.
Theoretisch ja, aber dieses Vorgehen ist wohl total langweilig und mühselig und wahrscheinlich unrealistisch. Und ein Framework lernt man nicht mal so nebenbei, vorallem wenn man das Thema (GUI-Programmierung) vorher noch nicht kennt. Außerdem lernt man auch was über Designpattern, wenn man Frameworks lernt. Wenn man immer nur C++ Konsolenprogrammierung bereit, werden einem die meisten Designpatters auch relativ sinnlos vorkommen. Und 4. würde ich während 1. und 2. machen.
-
Wäre es sinnvoll sich jetzt schon mit GUI Programmierung zu befassen?
-
double-b schrieb:
Wäre es sinnvoll sich jetzt schon mit GUI Programmierung zu befassen?
Sinnvoll ist das, worauf du Lust hast. Wenn dich GUI Programmierung interessiert, könnte die WinAPI die richtige Wahl als Einstieg sein.
Das Tutorial finde ich ganz angenehm:
http://pronix.linuxdelta.de/C/win32/index.shtml
-
Danke für eure Anworten. Ich werde mich dann mal mit der Windowsprogrammierung
beschäftigen.
-
Ich weiss nicht, ob WinAPI ein guter Einstieg in die GUI-Programmierung ist. Das Framework ist C und relativ Low-Level (halt die Betriebssystem-Schnittstelle). Eventuell wäre ein GUI-Framework wie Qt, Ultimate++, VCF, gtkmm, etc. oder Artchis algierlib am Anfang geeigneter, weil du dich auf C++ und objektorientierte Dinge wie Design-Patterns konzentrieren könntest.
-
Man kann doch trotzdem die Vorteile der Objektorientierung nutzen, obwohl man
eine in C geschriebene Schnittstelle benutzt, oder?
-
Ja, sicher. OOP funktioniert auch in C selbst. Aber gewisse Techniken und Design Patterns wirst du nur in C++ antreffen. Und auch wenn du in eigenen Projekten viele von ihnen verwendest, ohne es zu wissen, lernst du einige davon nicht automatisch.
Aber OOP-Design ist ja nur ein Teil. Die Herangehensweise ist halt je nach Framework und je nach Sprache ziemlich unterschiedlich. Es ist sicher gut viele Varianten zu sehen, sofern man etwas kritisch ist. Teilweise werden Dinge wegen Limitierungen der Sprache (in C, oder in C++ vor 15 Jahren) unnötig umständlich gelöst. Nicht dass du dir solche Dinge aneignest
Das könntest du aber auch schön verhindern, indem du Bücher wie "Effective C++" oder "Exceptional C++" liest. Das sind oft empfohlene Werke für Fortgeschrittene, die einige Tricks und Fallgruben in C++ ansprechen.
-
Du bist also der Meinung es spricht nichts dagegen sich mit Windows
Programmierung zu beschäftigen, aber ich sollte mir zusätzlich
einen guten Stil angewöhnen und mich mit Algorithmen und anderen
Techniken beschäftigen?
-
Wenn du für Windows entwickeln willst ist es sicherlich nicht schlecht die Grundlagen der WinAPI zu kennen...
-
Nexus schrieb:
Ja, sicher. OOP funktioniert auch in C selbst. Aber gewisse Techniken und Design Patterns wirst du nur in C++ antreffen. Und auch wenn du in eigenen Projekten viele von ihnen verwendest, ohne es zu wissen, lernst du einige davon nicht automatisch.
Also um das mal klarzustellen, wenn Leute, wie hier Nexus, sagen, dass man auch in C OOP betreiben kann, dann meinen sie damit, dass man, wenn man es darauf anlegt, gegen jede Sprache kämpfen kann und mit ihr in einer Art und Weise programmieren kann, für die sie nicht gedacht ist.
Das heißt aber nicht, dass C die Programmiertechniken, die man bei objektorientierter Programmierung einsetzt, in irgendeiner Weise unterstützt. Um es mal ganz klar auszudrücken: C ist nicht für objektorientierte Programmierung gedacht. Und es handelt sich dabei auch in keinster Weise um eine Sprache, mit der man OOP lernen kann.
-
Aber man kann doch beispielsweise die winapi funktionen nutzen, um komfortablere
C++ Funktionen zu programmieren.
-
dot schrieb:
Wenn du für Windows entwickeln willst ist es sicherlich nicht schlecht die Grundlagen der WinAPI zu kennen...
Ich habe mich zwar nie mit WinAPI beschäftigt, aber ich halte das trotzdem einfach mal für Quatsch.
Warum sollte man sich bei GUI-Programmierung mit Low-Level Kram auseinandersetzen? Was sind die _wichtigen_ Einsichten, die man dadurch gewinnt? Für mich hört sich das so an, als ob man Sachen in Assembler schreiben sollte, weil man sonst nicht versteht, was der Rechner macht. Aber das ist genauso Quatsch.
Die Einsichten, die man dadurch gewinnen könnte, sollte man sich lieber mit einem guten Buch über die entsprechende Thematik aneignen. Statt Assembler zu lernen, sollte man lieber ein Buch über Computer-Architektur und Design lesen. Und statt WinAPI zu nutzen sollte man vermutlich gar nichts lesen. Ich sehe dazu überhaupt gar keinen Grund.
-
twotime schrieb:
Theoretisch ja, aber dieses Vorgehen ist wohl total langweilig und mühselig und wahrscheinlich unrealistisch. Und ein Framework lernt man nicht mal so nebenbei, vorallem wenn man das Thema (GUI-Programmierung) vorher noch nicht kennt. Außerdem lernt man auch was über Designpattern, wenn man Frameworks lernt. Wenn man immer nur C++ Konsolenprogrammierung bereit, werden einem die meisten Designpatters auch relativ sinnlos vorkommen. Und 4. würde ich während 1. und 2. machen.
Ich habe nichts dagegen, dass der Threadersteller sich mit GUI-Programmierung beschäftigt. Aber ich sehe das nur als Anwendungsgebiet, in dem man die Dinge, die man wirklich lernt, ausprobieren kann.
Klar, ich habe damals auch recht früh mal einen grafischen Taschenrechner und so programmiert. Aber das relevante dabei war nicht, herauszufinden, wie man irgendwelche Buttons realisiert. Das interessante dabei war das, was sich hinter der GUI abgespielt hat. Praktisch das Zusammenspiel der einzelnen Programmkomponenten. Dort liegt die Herausforderung. Die Herausforderung sollte nie in der GUI liegen.
