Review meines C++ Tutorials
-
phippse schrieb:
dass enum laut unserem informatik lehrer auch "böse" ist
Wüsste nicht warum. Man muss nur auf den Scope aufpassen. Denn enum öffnet ja selber keinen Scope - dh die enum-Werte sind dann im darüberliegenden Namespace. Dies kann zu Namensproblemen führen. Deswegen packe ich enums manchmal in einen eigenen Namensraum.
Aber sonst wüsste ich nicht was an enum böse ist.
-
das logo oben links nervt irgendwie. der text sollte erst unter dem logo beginnen
-
shade : von deinen leistungen / aussagen halt ich selten was aber diesesmal hab ich nix zu meckern.
-
nichts zum inhalt schrieb:
das logo oben links nervt irgendwie. der text sollte erst unter dem logo beginnen
so besser?
bzw. will jemand das logo doch dort haben? oder soll es ganz weg? bzw. woanders hin?
-
Hallo,
ich habe mir gerade mal "die größten C++ Lügen" durchgelesen.
Anmerkungen:
* Das "die" würde ich durch "Die" ersetzen. Oder anders gesagt: Ich würde zu einem einheitlichen Stil bei den Überschriften raten. "Der this-Zeiger" aber "die Lügen" wirkt so willkürlich
* iostream.h
Durch den Bezug auf die alten Header könnte man den Eindruck bekommen, iostream.h wäre irgendwann mal Standard gewesen. Dem ist aber nicht so. <iostream.h> vs. <iostream> ist weniger ein "alte Benennung" vs. "neue Bennung", denn ein "Prä-Standard-Stream" vs. "Standard-Stream".* Die letzten beiden Punkte passen imo nicht wirklich zu Thema.
* "Bücher/Tutorials veraltet und verbreiten wissen" -> Wissen wird hier imo groß geschrieben.
"CObject und seine Probleme":
* "Diese Argumente werden häufig von Befürworten von Klasse-Prefixen"
Freudscher Verschreiber? Klasse-Prefixen -> Klassen-Präfixen* "die implementations Details" -> Die Implementationsdetails
* "Vielleicht ist Int64 noch eine Klasse zum verwalten von großen Zahlen, aber wird später auf geändert werden, indem Int64 später zu einem typedef auf long long wird." -> Zum Verwalten. Das "auf" ist zuviel bzw. der Satz kaputt.
* "als Namespace ersatz" -> als Namespace Ersatz
* "da das Interface ja nahezu Identisch ist" -> identisch klein.
* "Und jedesmal wenn wir ein Policy ändern müssen wir den Namen ändern" -> Und jedesmal wenn wir ein Policy ändern, müssen wir auch den Namen der Variablen ändern.
* "Dabei interessiert es uns eigentlich nicht sonderlich ob der SmartPointer ein Reference-Counting macht, oder ob er als Ring implementiert" -> ist
* "Weiters soll der Anwendercode" -> Desweiteren, Zusätzlich, Weiterhin...
"Weiters" habe ich noch nie gehört.* "Es gibt soviele Klasse" -> Klassen
* "Denn in der OOP interessiert uns nicht der Typ (Klasse), sondern die Variable (Objekt). Es heißt ja auch Objekt Orientierte Programmierung und nicht Klassen Orientierte Programmierung."
Dieser Schluss ist leuchtet mir nicht ein.
In der OOP steht nicht der konkrete Typ eines Objekts, sondern sein Verhalten, also das Protokol, dass das Objekt versteht im Vordergrund. Das hat aber eigentlich keinen direkten Einfluss auf Präfixe. Wenn man erstmal auf die schwachsinnge Idee gekommen ist, allen udts ein eindeutiges Typ-Präfix (im Gegensatz zu einem manchmal sinnvollen Package-Präfix) zu spendieren, könnte man ja so argumentieren:
"Durch den Typ-Präfix erkenne ich schneller, welchen statischen Typ ein Objekt hat was es mir erleichtert, die entsprechende Klassendokumentation und damit die Beschreibung des Verhaltens eines Objekts zu finden".Ansonsten gibt es hier viele "Prefixe" die man durch "Präfixe" ersetzen könnte
-
HumeSikkins schrieb:
Hallo,
ich habe mir gerade mal "die größten C++ Lügen" durchgelesen.thx - aber wie ich bereits geschrieben habe: befindet sich erst im Aufbau.
Die Idee stammt von kingruedi - ebenso wie die erste Version. Da wird es nicht nur ein paar Änderungen, sondern auch Erweiterungen geben.
Deine Kritikpunkte sind aber schon notiert
thx!* Die letzten beiden Punkte passen imo nicht wirklich zu Thema.
stimmt zwar, aber wo würdest du sie unterbringen?
vielen Dank für die Mühe!
-
zB kann man ein C++ Programm sowohl für Windows als auch für einen Toaster schreiben! Man muss lediglich das Programm für den Toaster neu kompilieren.
Ich glaube, dass diese Aussage einen kompletten Anfänger etwas verwirren kann.
Nimm statt Toaster lieber UNIX.
-
Ich glaube, die Verwirrung ist an der Stelle beabsichtigt, anders kann man jemandem wahrscheinlich keine neuen Horizone eröffnen
-
Ist nicht direkt inhaltlich: Eine Downloadmöglichkeit (als .zip oder so) wäre nicht übel, denn offline lesen ist billiger...
-
Mauro schrieb:
Eine Downloadmöglichkeit (als .zip oder so) wäre nicht übel
Wenn es einmal fertig wird, werde ich mir das überlegen. Vorläufig ist es aber erst im entstehen - es kann sich momentan dauernd etwas ändern. deshalb will ich keine halbfertigen Versionen im Netz kursieren sehen...
-
du verwendest denglisch (hört sich blöd an). es gibt kein "static Variablen" sondern nur statische Variablen bzw. static variables wenn dus auf englisch haben willst. analog "static Member und Methoden"
grüße
-
also ich finde dein tutorial echt spitze.. ich hab noch nie ein tut gesehen, in dem die ganzen themen behandelt wurden, die du dort aufgenommen hast.. wirklich sehr umfangreich und trotzdem noch übersichtlich und verständlich..
da kann ich echt noch einiges lernen :)..
-
Meine Überlegung dahinter war:
static ist das Schlüsselwort, also schreibe ich static Variablen - da der Leser dann weiss was gemeint ist. Bei statisch müsste er es (zugegebener maßen recht einfach) herleiten.Was sagen die Anderen dazu?
Soll ich konsequent Deutsch verwenden oder passt es so?
Soll ich Deutsch und in Klammer den englischen Ausdruck verwenden?
eure Meinung ist gefragt.
-
Du hast irgend wie ein </a> vergessen, deswegen sieht der Mozilla alles als einen Link an! (bei allen Kapiteln!)
-
Ich würde sagen: deutsche Begriffe bevorzugen (statische Variable ist OK), aber nicht sklavisch (Schablone statt Template fände ich übertrieben), wenn es mal unklar ist auf jeden Fall den englischen Fachbegriff angeben.
-
@kingruedi:
stimmt. ist heute wohl bei einem Replace-durchlauf verloren gegangen. ist aber schon wieder gefixt.@Bashar:
klingt vernünftig. Werde ich umsetzen (es sei denn jemand ist anderer Meinung...?)
-
am besten wäre natürlich deutsch und in klammer der englische name. damit hat der leser wenigstens beide begriffe mal gehört und kann auch in englischen hilfen nachschlagen.
grüße
-
- ich bin für static Variablen, weil static Variablen nicht wirklich statisch sind (man kann statisch z.b. als const verstehen)
- wenn man static Variablen sagt, hatt das ein Eigennamen-Karakter,
- wenn man nach static sucht findet man mehr passendes als wenn man nach statisch sucht
- du hast dich schon mal für static Varibalen entschieden, auch wenn du nicht drüber nachgedacht hast sagt das doch was aus
- ich habe nix gegen denglisch, ich schreibe leiber gutes denglisch, als schlechtes englisch. mit reinen deutsch kann man sowieso nicht programmieren
- ich sehe nur nachteil mit statisch
-
Gerard schrieb:
(man kann statisch z.b. als const verstehen)
Wie das?
wenn man static Variablen sagt hatt das ein Eigennamen-Karakter,
sagst du virtual-Funktion oder virtuelle Funktion?
-
Compiler schrieb:
Erst wird der C++ zu Assembler umgeformt
fehlt da irgendwo ein "Code"?
Auf der Hello-World-Seite kommt meiner Ansicht nach der Kasten mit der Erklärung, was zu tun ist, wenn sich das Fenster trotz cin.get() schließt etwas zu früh. An der Stelle war weder die Rede von schnellem beenden, noch überhaupt von einem Fenster. Ich finde da solltest Du zuerst beschreiben, wozu das cin.get() gut ist, und anschließend die Erläuterung.
Merkkasten bei if und else schrieb:
Detto bei ...
AFAIK heißt das "dito"
Variablentypen schrieb:
genauereste Gleitkommazahl
Das ist Absicht, oder?
Wenn ich Zeit hab les ich morgen nochmal rein. Ich bin auch für die deutschen Begriffe (natürlich ohne Schablone) und dem englischen Begriff in Klammern.
MfG Jester
P.S.: Fast vergessen: Das macht schonmal einen sehr guten Eindruck. In welchem Umfang bzw. mit welchem Inhalt hast Du Dir den Text über die Compiler denn vorgestellt?