Besser werden in c++
-
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 KoenigAlexandrescu finde ich nicht erwähnenswert in der Reihe.
Und aus Nicolai Josuttis und Daveed Vandervorde hast Du eine Person gemacht.
-
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.
-
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.
-
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)
-
aup schrieb:
Woher weiß Hacker eigentlich wie in Firmen gearbeitet wird? Er ist doch noch nie im Leben gearbeitet (aufgrund seines Alters)
Es gibt auch andere Informationsquellen als die eigene Erfahrung, Dödel.
-
Zurück zum Thema, klärt das privat.
-
Ich denke bei neuen Projekten hilft es, das Design "von oben nach unten", statt umgekehrt aufzubauen. Das bedeutet man ignoriert erst mal die "arbeitende", untere Ebene, und konzentriert sich vollends auf die Interfaces.
Man stellt sich also z.B. irgendeine Interaktion mit dem Nutzer vor und überlegt welchen Weg die gehen soll, welche Klasse das handhabt etc.
Das verhindert auch, dass man das Interface der Implementierung statt der Aufgabe anpasst.
-
Hallo,
Ich habe früher auch immer einfach los programmiert irgendwann hatte
ich auch keine Lust mehr obwohl ich wusste was ich programmieren wollte.
Jetzt nehme ich mir vorher ein Blatt und mache ein Skizze + Stich Punkte
und Plan alles, doch wenn du mit mehreren arbeitest empfehl ich ein UML-
Programm. Sonst mach ich es dann halt immer so dass ich eine main.cpp habe
und sonst immer dann Header Dateien schreibe die dann nichts mit den anderen
Funktionen zu tun haben.