Besser werden in c++

SeppJ

Ein guter Tipp ist, hier im Forum Fragen zu beantworten. Bald sind Semesterferien zuende, dann kommen wieder mehr Fragen. Und versuch die Fragen möglichst gut zu beantworten, nicht wischiwaschi. Ist egal, ob du dann eben eine Stunde nach der ersten Antwort nochmal mit einer inhaltsgleichen, aber gut recherchierten Antwort kommst. Und versuch Beispielprogramme so gut zu designen wie du kannst. Guck dir zum Beispiel mal an, wie Werner Salomon auf einfache I/O-Fragen antwortet, die man zwar mit 10 Zeilen Gehacke auch beantworten könnte, aber die man auch eleganter lösen kann, wenn man die Eingeweide der Streams umschreibt. Das kann man dann später selber in großen Projekten benutzen (ich habe mich beispielsweise dankbar an den automatisch einrückenden Streambuf erinnert), aber man muss so etwas ein paar mal an einfachen Beispielen üben, bevor man das eigenständig anwenden kann.

Außerdem solltest du natürlich so Standardquellen wie Effective C++ (leicht Fortgeschritten), Guru of the Week(teilweise ziemlich Fortgeschritten) oder die Artikel im Magazin (leicht Fortgeschritten) gelesen und verstanden haben, falls du das nicht schon längst getan hast^*.

^*: Es ist bei C++ schwer abzuschätzen, was gemeint ist, wenn sich jemand selber als "fortgeschritten" einschätzt, da es in C++ so viel zu wissen gibt, dass viele totale Anfänger gar nicht mal wissen, was es alles zu wissen gibt und nach ihrem ersten "C++ von A bis Z" denken, sie wären gut. Vielleicht sind das für dich alles Kinkerlitzchen was ich aufgezählt habe, vielleicht bist du einer von denen die C mit cout gelernt haben und denken, das wäre alles.

Hi, danke erstmal für die Antworten.

Was ist mein Background?
Ich bin Physik-Student, programmieren ist ein Hobby für mich, wobei ich es gut genug beherrschen möchte um es auch im Beruf als "zusätzlichen Skill" nutzen zu können.

Was heißt bei mir "Fortgeschritten"?
Mal eine Liste was mir so einfällt.
Folgendes kenne ich hab ihren Sinn Verstanden und kann ich Anwenden:
for, if, while, #define, const(eigentlich alle keywords), Zeiger, Referenzen, STL, Funktionen, Funktionspointer, Klassen(Construtor, Copy-Const., Zuweisungsoperator, Destruktor), Templates, Standard-Bib von c++...

Damit habe ich mich versucht, ist aber wegen umschreiben, neuschreiben, etc. nicht viel geworden:
Direct3D, SFML.

Folgende Schlagwörter habe ich gelesen sagen mir aber nicht viel, bzw. nur ganz wage etwas:
Lambda-Kalkül, Meta-Programmierung, Factory, Design Pattern

Die neuen Features von c++11 sind mir Fremd.

Ich werde mir die Links mal ansehen, danke!

EinUnreg schrieb:

Damit habe ich mich versucht, ist aber wegen umschreiben, neuschreiben, etc. nicht viel geworden:
Direct3D, SFML.

Kann es sein, dass du einfach zu wenig Ahnung von Grafik hattest?

Ethon

SeppJ schrieb:

Und versuch Beispielprogramme so gut zu designen wie du kannst. Guck dir zum Beispiel mal an, wie Werner Salomon auf einfache I/O-Fragen antwortet, die man zwar mit 10 Zeilen Gehacke auch beantworten könnte, aber die man auch eleganter lösen kann, wenn man die Eingeweide der Streams umschreibt.

Was imho zu sehr ausartet. So manche Antworten helfen dem Fragesteller überhaupt nicht, da es oft overdesigned ist.

daddy_felix

EinUnreg schrieb:

Sobald das Projekt größer wird muss ich ständig Dinge umschreiben, verschieben, neumachen, da vergeht wieder schnell die Lust.

Das ist ganz normal. Kein Programm ist von Anfang an perfekt. Ich würde die das Buch "Refactoring: Improving the Design of Existing Code" von Martin Fowler empfehlen (ist zwar Java, aber die Konzepte sind übertragbar). Er beschreibt diverse Kriterien für lesbaren und wartbaren Code und wie man "schlechten" Code schrittweise überarbeitet und in die "gute" Version überführt. Wenn man diese Punkte im Hinterkopf hat, programmiert man das nächste Mal gleich etwas besser.

Amazon: http://www.amazon.de/Refactoring-Improving-Design-Existing-Technology/dp/0201485672/ref=sr_1_1?ie=UTF8&qid=1333091502&sr=8-1

SeppJ

Ethon schrieb:

Was imho zu sehr ausartet. So manche Antworten helfen dem Fragesteller überhaupt nicht, da es oft overdesigned ist.

Dafür gibt es ja meistens die schnelle Antwort in den ersten 10 Minuten. Die gute Antwort ist dann für alle anderen, damit man sieht, was so alles möglich ist.

krümelkacker

Praxis, Praxis und nochmal Praxis
"Effective C++" von Scott Meyers lesen
sicherstellen, dass Du weißt, was mit "RAII" und "ownership" gemeint ist
Bjarne Stroustrups GoingNative 2012 keynote angucken
Stephan T. Lavavejs STL Serie angucken.
RSS feed von reddit/cpp abbonieren. Da kommen oft mal interessante Links auf Blogs, Vorträge, Neuigkeiten, etc zum Thema C++
...

SeppJ schrieb:

Das kann man dann später selber in großen Projekten benutzen (ich habe mich beispielsweise dankbar an den automatisch einrückenden Streambuf erinnert), aber man muss so etwas ein paar mal an einfachen Beispielen üben, bevor man das eigenständig anwenden kann.

Für einen Moment hat mich Werner Salomon doch tatsächlich glauben lassen, dass es ein Feature bei den C++ Streams gäbe, das ich nicht kenne: stacking von streambufs. Aber dann stellt sich doch heraus, dass er nur gemogelt hat

Wer es noch nicht gelesen hat, sollte unbedingt Standard C++ IOStreams and Locales | ISBN: 0321585585 lesen.

pumuckl

EinUnreg schrieb:

for, if, while, #define, const(eigentlich alle keywords), Zeiger, Referenzen, STL, Funktionen, Funktionspointer, Klassen(Construtor, Copy-Const., Zuweisungsoperator, Destruktor), Templates, Standard-Bib von c++...

Das "Templates" und "Standard-Lib" zwischen dem Rest liest sich in etwa wie folgende Antwort auf die Frage "wo kennst du dich aus in der Welt?": "Hamburg-Bergedorf, Hamburg-Blankenese, Berlin-Tegel, München-Schwabing, Manthattan, Zürich, Afrika, Paraguay, Sidney..."

Sprich: Templates sind so ein riesig weites Feld, dass die Aussage "ich kenne Templates" so ziemlich alles oder eben so ziemlich nichts heißen kann Grade wenn Meta-Programming dir nicht so viel sagt stehst du z.B. bei Templates eher am Anfang.

Ich nenne jetzt einfach mal einige Autoren-Namen, die dir noch viel Wissens-Gold in Form von Druckerschwärze bieten können:
Scott Meyers, Herb Sutter, Andrei Alexandrescu, Nicolai Vandervoorde, Andrew Koenig

Dann ein paar Fundgruben aus dem netz:
http://www.informit.com/articles/index.aspx?st=60233
http://cpp-next.com/

krümelkacker

pumuckl schrieb:

Ich nenne jetzt einfach mal einige Autoren-Namen, die dir noch viel Wissens-Gold in Form von Druckerschwärze bieten können:
Scott Meyers, Herb Sutter, Andrei Alexandrescu, Nicolai Vandervoorde, Andrew Koenig

Alexandrescu finde ich nicht erwähnenswert in der Reihe.
Und aus Nicolai Josuttis und Daveed Vandervorde hast Du eine Person gemacht.

asc

pumuckl schrieb:

...Sprich: Templates sind so ein riesig weites Feld, dass die Aussage "ich kenne Templates" so ziemlich alles oder eben so ziemlich nichts heißen kann Grade wenn Meta-Programming dir nicht so viel sagt stehst du z.B. bei Templates eher am Anfang...

Auch wenn ich dir grundsätzlich recht gebe, bin ich inzwischen der Meinung das der Großteil aller C++ Programmierer auch ohne die TMPL leben kann, ungeachtet davon das es Bereiche gibt in denen sie sinnvoll sein kann (z.B. als Bibliothekendesigner).

P.S: Alexandrescu steht bei mir auch eher im Bereich der selten benötigten Literatur, auch wenn er durchaus unter die Genies zählen mag.

Sobald das Projekt größer wird muss ich ständig Dinge umschreiben, verschieben, neumachen, da vergeht wieder schnell die Lust.

Das ist doch gerade das geile am proggen.

Sobald das Projekt größer wird muss ich ständig Dinge umschreiben, verschieben, neumachen, da vergeht wieder schnell die Lust.

Tja, Planung ist aller Größe Anfang.

Hacker schrieb:

Sobald das Projekt größer wird muss ich ständig Dinge umschreiben, verschieben, neumachen, da vergeht wieder schnell die Lust.

Tja, Planung ist aller Größe Anfang.

Willst du damit etwa sagen das Planung hilft? Wenn ja, liegst du falsch.

pumuckl

Hacker schrieb:

Tja, Planung ist aller Größe Anfang.

Der Ansatz "erst alles planen, dann alles nach Plan umsetzen" kommt aus den Ingenieurwissenschaften, ist sehr puristisch - und schon länger als ungeeignet für größere Software-Projekte erkannt. Die ZEit, die man für die Planung braucht, reicht nämlich mit ziemlicher Sicherheit aus, die Voraussetzungen so zu ändern, dass der Plan entweder nicht mehr durchführbar oder aber nicht mehr angemessen ist. Man wechselt stattdessen immer zwischen Anpassung des Plans und Anpassung des Codes (Refactoring).

Hackers Spruch mit der Planung kommt wohl aus seinem Schach-Thread bei dem er zu wenig geplant hat. Da hat er, so wie es aussieht, erst mal relativ planlos ein paar Klassen erstellt und dann gemerkt, dass er nicht so wirklich weiß, wie er das eigentliche Problem löst.

Planung ist hier auch ein zu allgemeiner Begriff. Natürlich braucht man bei größeren Projekten Planung. Eine neue Windows Version wird ganz sicher nicht ohne Planung entstehen. Da gibt es sicher Pläne wer wann was macht, damit jeder die Teile von anderen rechtzeigt bekommt und noch viel mehr Planung.

Aber hier denken die meisten bei Planung wohl nur an UML Digramme zeichnen.

Das wichtigste bei Anfängerprojekten dürfte wohl erst mal sein, dass man eine Idee hat wie man das Problem löst. Also nicht einfach nur Klassendiagramme zeichnen, sondern überlegen, welche Datenstrukturen man verwenden will, was da drin stehen soll und was damit gemacht werden muss, damit man zum Ergebnis kommt. Am besten ist wohl, wenn man den Ablauf sehr detailiert im Kopf (oder auf dem Papier) durchgehen kann. Also nicht nur, meine Spielfigur zieht wo hin und dann schau ich, ob das gut ist, sondern überlegen, wie das "zieht wo hin" in einer Datenstruktur aussieht und ob man damit das "ob das gut" bewerten kann usw.

Sagt mal, unter Planung versteht ihr hoffentlich einfach mal nachzudenken wie das alles aussehen soll? Keine UML-Diagramme oder sonst irgendetwas ...

Das machen nur Firmen bei wirklich größeren Projekten.

Ich meinte eher, nicht einfach (ja, genau wie ich ) einfach drauflos programmieren, das kann vielleicht bei Projekten unter mehreren Tausend Zeilen noch funktionieren.

asc

Hacker schrieb:

Sagt mal, unter Planung versteht ihr hoffentlich einfach mal nachzudenken wie das alles aussehen soll? Keine UML-Diagramme oder sonst irgendetwas ...

Das machen nur Firmen bei wirklich größeren Projekten.

Grundsätzlich ist Planung sinnvoll, auch wenn dies nicht UML erfordert. Ein paar Notizen und Ideensammlungen sind aber auch sinnvoll. Davon abgesehen: Sofern man es nur auf sehr grober Ebene verwendet, ist etwas wie UML (oder jede andere Darstellungsform) durchaus auch bei kleineren Projekten nicht unbedingt schlecht. Man solltesich nur nicht in den Details verlieren.

Hacker schrieb:

Tja, Planung ist aller Größe Anfang.

Hacker schrieb:

Das machen nur Firmen bei wirklich größeren Projekten.

Wenn du weniger Standardfloskeln raushauen würdest von denen du offensichtlich keine Ahnung hast, würden dich die Leute in ein paar Wochen vielleicht schon wieder ernst nehmen.

Woher weiß Hacker eigentlich wie in Firmen gearbeitet wird? Er ist doch noch nie im Leben gearbeitet (aufgrund seines Alters)