C-Strings vergleichen

1. .h an Standardheadern ist ein Fehler.
2. Wenn du weißt, dass in main kein return notwendig ist, warum hast du sein Fehlen dann als Fehler bezeichnet?

Übrigens ist ; nach Funktionskörpern ebenfalls ein Fehler; ein standardkonformer Compiler darf so etwas durchaus ablehnen.

Ansonsten kann es durchaus sein, dass einzelne J.W.-Leser zusätzlich durch andere Quellen verwirrt werden (ich schaue in deine Richtung, Markt+Technik!), aber Wolfs Bücher enthalten viele Fehlinformationen, und die Gefahr ist hoch, dass jemand wie du (zaunpfahl-wink) diese Bücher liest und den Kram darin glaubt, weil sie in einem Buch stehen. Wir kriegen hier viele Leute, die seine Bücher lesen und hier mit Fragen kommen, die gar nicht erst aufgekommen wären, hätten sie vernünftige Bücher gelesen. Darum ist er hier so berüchtigt.

Obwohl es zugegeben vergleichsweise selten vorkommt, dass jemand sie trotzdem so vehement verteidigt wie du.

Michael E.

Felixxx schrieb:

Ja, das ist mir klar^^ Für Windows ist das wayne. Für DOS war es das nicht.

Was hat denn die Standardrückgabe mit dem verwendeten Betriebssystem zu tun?

Felixxx

seldon schrieb:

1. .h an Standardheadern ist ein Fehler.
2. Wenn du weißt, dass in main kein return notwendig ist, warum hast du sein Fehlen dann als Fehler bezeichnet?

Übrigens ist ; nach Funktionskörpern ebenfalls ein Fehler; ein standardkonformer Compiler darf so etwas durchaus ablehnen.

1. Die meisten Compiler geben nur eine Warnung aus. Das Programm wird auch korrekt ausgeführt.
2. Stützt sich auf 1. ! Ebenfalls wird hier eine Warnung ausgegeben. Deswegen habe ich es auch erwähnt.

Den Semikolon-Fehler hatte ich ebenfalls erwähnt.

Wie dem auch sei, ich gehe jetzt pennen, haut rein Jungs.
Hat Spaß gemacht hier ein bisschen zu diskutieren.
So vehment habe ich reagiert, weil Eure Abneigung dem Buch gegenüber nicht weniger heftig ist und ich die richtigen Gründe dafür noch nicht wirklich erfahren habe.

unskilled

Übrigens ist ; nach Funktionskörpern ebenfalls ein Fehler; ein standardkonformer Compiler darf so etwas durchaus ablehnen

woher entnimmst du das?
ich glaube nicht, dass im standard steht, dass leere anweisungen verboten sind...

int main()
{
;;;
}

verboten?

int x;;
int main() {}

verboten?

int main() {}
;;

verboten?

ich glaube, keins davon ist nicht 100%ig standard-konform.
soll nicht heißen, dass es gut ist, semikoli zu spammen - aber fehler ists meines erachtens keiner...

bb

Michael E.

Felixxx schrieb:

1. Die meisten Compiler geben nur eine Warnung aus. Das Programm wird auch korrekt ausgeführt.
2. Stützt sich auf 1. ! Ebenfalls wird hier eine Warnung ausgegeben. Deswegen habe ich es auch erwähnt.

Also ist standardkonform, was dein Compiler schluckt?

volkard

unskilled schrieb:

ich glaube nicht, dass im standard steht, dass leere anweisungen verboten sind...

Es steht explizit drin, daß es die leere Anweisung gibt, die nur aus einem Semikolon besteht. Die leere Anweisung darf er also nicht ablehnen. Anweisungen stehen innerhalb von Funktionen. Dort kannste Semikola hinknallen in jeder Menge.
Außerhalb wäre es eine leere Deklaration. Und die ist nirgends erlaubt worden. Also kann ein standardkonformer Compiler sie ablehnen.

Felixxx

Michael E. schrieb:

Felixxx schrieb:

1. Die meisten Compiler geben nur eine Warnung aus. Das Programm wird auch korrekt ausgeführt.
2. Stützt sich auf 1. ! Ebenfalls wird hier eine Warnung ausgegeben. Deswegen habe ich es auch erwähnt.

Also ist standardkonform, was dein Compiler schluckt?

Ich habe keinen Ahnung von was Du redest oder auf was Du hinaus willst, aber ich habe den Eindruck dass du nicht verstehst, auf was _ich_ hinaus will. Ich erzähls dir morgen bzw. in ein paar Stunden

$ g++ test.cc
test.cc:1:22: schwerwiegender Fehler: iostream.h: Datei oder Verzeichnis nicht gefunden
Kompilierung beendet.

Ein Semikolon nach Funktionskörpern wird von den meisten Compilern geschluckt, das ist richtig, aber die Grammatik, wie sie im Standard beschrieben wird, gibt es eigentlich nicht her.

Relevante Teile der Grammatik:

function-definition:
  decl-specifier-seq[t]opt[/t] declarator ctor-initializer[t]opt[/t] function-body
  decl-specifier-seq[t]opt[/t] declarator function-try-block

function-body:
  compound-statement

function-try-block:
  try ctor-initializer[t]opt[/t] function-body handler-seq

handler-seq:
  handler handler-seq[t]opt[/t]

handler:
  catch ( exception-declaration ) compound-statement

compound-statement:
  { statement-seqopt }

Bemerke, dass compound-statement durch eine geschweifte Klammer und kein Semikolon beendet wird.

hustbaer

seldon schrieb:

Geldbeträge sind meistens am sinnvollsten in Cent mit großen Integertypen berechnet (etwa std::tr1::int64_t).

Es hat sich eigentlich eingebürgert dass man mit Faktor 10000 arbeitet. Es gibt einfach zu viele Währungen die nicht Faktor 100 für die Unterwährung verwenden, sondern Faktor 1000 oder auch mal 2000.

HKEY

In dem Buch sind n paar Syntaxfehler drin aber es ist nicht überhäuft. Außerdem könnt ihr froh sein, dass es das Buch gibt, denn sonst könnte das Forum ja fast zu machen .
Ich bin jetzt auch bei Strings in dem Buch angekommen und werd es auch weiterlesen, da ich dafür ja gezahlt habe.

SeppJ

HKEY schrieb:

In dem Buch sind n paar Syntaxfehler drin aber es ist nicht überhäuft.

Die Syntaxfehler sind nicht das entscheidende. Sie sind nur selbst für Anfänger offensichtliche Symptome für mangelnde Sorgfalt. Das eigentliche Problem sind falsche Konzepte, fehleranfälliger Programmierstil und schlicht und einfach Fehlinformationen. Diese Dinge kann man natürlich als Anfänger nicht beurteilen, daher halten sie das Buch fälschlicherweise für gut, weil J.W. in einem schönen Deutsch schreibt.
Wenn du die offensichtlichen Fehler ignorierst und auch den fortgeschrittenen Forenteilnehmern nicht glaubst, dass diese nicht die einzigen Fehler sind, dann ist dir nicht zu helfen. Wir sehen uns dann in ein paar Wochen, wenn du das erste Mal ernsthafte Schwierigkeiten bekommst, wegen dem Schrott den du dir jetzt selbst eintrichtern willst. Und dann wird es wieder heißen "Haha, ein neues Opfer.", "Vergiss alles was in dem Buch stand!" und "Kauf dir den C++ Primer!" und die Enttäuschung wird groß sein, dass der Kutschenführerschein den man gemacht hat, nichts für die Autobahn taugt. Betrachte dich als gewarnt.

Felixxx

Naja, dass ich nicht beurteilen kann, ob das Buch gröbere Fehlinformationen vermittelt, das stimmt. Ich bin nun mal Anfänger.

Doch eine Sache : Dieses Buch vermittelt doch so und so nur die Grundlagen von C++ ? Es werden keine komplexeren Vorgänge beschrieben, oder ähnliches ( Na gut, vllt. die GUI-Programmierung am Ende, da bin ich aber 1.) nocht nicht und 2.) werden da auch wohl kaum gröbere Fehler sein).
Ob er bei dem typcasting-Kapitel irgendwas falsch erzählt weiß ich tatsächlich nicht, aber selbst wenn wäre es wohl nicht allzu schlimm. Wenn man merkt, dass irgendwas nicht klaptt,schaut man in einer 2.-Quelle nach oder fragt Bekannte.

Generell kannte ich Galileo-Computing als seriösen Buchverlag, der wirklich gute Bücher rausbrachte.

Michael E.

Damit du in andere Quellen schaust, musst du aber erst mal merken, dass etwas falsch ist. Das ist aber nur bei einfachen Fehlern wie Syntaxfehlern zu schaffen. Wenn ich an sowas denke wie "goto ist verpönt, weil es der Performance schadet: Der Programmablauf wird an der Stelle unterbrochen -> lahm", dann denke ich nur WTF und du glaubst es ihm, wenn du es nicht besser weißt.

Ich verstehe einfach nicht, warum du etwas Falsches lernen willst? Nur weil du da ein paar Euro reingesteckt hast? Verkauf das Buch.

Felixxx

Hmm das stimmt. Ich meinte nicht direkt Syntaxfehler, sondern wenn du ein Programm schreibst und du merkst, dass es nicht so läuft wie du dir das Vorgestellt hast, obwohl du alles beachtet hast. Aber das kostet unnötige Mühe, das stimmt wiederum auch.

Btw: Wieso ist goto schlecht ? Soweit ich weiß, weil es Spagetthi-Code erzeugt und somit dem Code extrem unübersichtlich macht. Schließlich schreibt man Codes nicht für sich selber ( meistens nicht) sondern für andere, die evtl. später das Ganze verbessern müssen.

Das Buch verkaufe ich nicht. Mir die Mühe nicht wert ^.
Hatte es damals wie gesagt gekauft, wegen 1.) Guter Ruf des Verlages
2.) Guten Kundenrezesionen bei Amazon

Anderseits wird mir immer wieder gesagt, dass Bücher eh nichts taugen, sondern man soll lieber sich irgendein Programm vornehmen und das mit Hilfe von MSDN bzw. Google umsetzen. Wer weiß ...

Michael E.

Felixxx schrieb:

Hmm das stimmt. Ich meinte nicht direkt Syntaxfehler, sondern wenn du ein Programm schreibst und du merkst, dass es nicht so läuft wie du dir das Vorgestellt hast, obwohl du alles beachtet hast. Aber das kostet unnötige Mühe, das stimmt wiederum auch.

Selbst wenn etwas bei dir läuft, kann der Code immer noch undefiniertes Verhalten haben (das haben Quellcodes aus dem Buch übrigens auch) und irgendwann oder vielleicht mit nem anderen Compiler oder vielleicht auch nur bei Vollmond kackt dir alles ab.

Aber ich seh schon, dass du dich von deinem Vorhaben nicht abbringen lässt. Dann viel Spaß.

Felixxx

Das siehst du falsch. Ich hatte so und so wohl nicht vor, das Buch weiter zu lesen. Das liegt daran, dass ich einfach keine Lust mehr habe, weiter an der Konsolo zu proggen um am Ende etwas zu erhalten, womit ich _nichts_ anfangen kann.
Die übermäßige Kritik an dem Buch verrstärkt den Entschluss nurnoch.

Dennoch muss ich wohl mind. darüber disktuieren, dass das Buch wirklich _so_ scheisse sein soll. Denn schlecht fand ich es nicht.

Fändest du es besser wenn hier jeder bedingungslos akzeptieren würde, was ihm gesagt wird ? Ich nicht und ich bin auch nicht der Typ Mensch, der so reagiert ( was Euch sicher schon aufgefallen ist).

volkard

Felixxx schrieb:

Dennoch muss ich wohl mind. darüber disktuieren, dass das Buch wirklich _so_ scheisse sein soll. Denn schlecht fand ich es nicht.
Fändest du es besser wenn hier jeder bedingungslos akzeptieren würde, was ihm gesagt wird?

Paßt gut zusammen. Wenn Du eh bei jeder Seite zweifelst, kann ein Buch auch drei Fehler pro Seite haben, ohne daß es Dir schaden würde.

Felixxx

Joa ^^ Dass deine Meinung Fakt ist bzw. sein muss habe ich auch schon bemerkt

unskilled

Felixxx schrieb:

Dennoch muss ich wohl mind. darüber disktuieren, dass das Buch wirklich _so_ scheisse sein soll. Denn schlecht fand ich es nicht.

als ob du das beurteilen könntest...
du kanntest C++ davor gar nicht und willst es mit diesem buch lernen. das, was du jetzt gelernt hast, ist ein C/C++ Mischmasch - was man aber als Anfänger einfach nicht merken wird.
Allein schon, wenn in einem C++ Buch bevor auf std::string eingegangen wird, char[willkrüliche_zahl] für strings genutzt wird, hat es 2 Zeichen zu viel im Titel. Da hilft auch ein printf-ersetzen durch cout nicht...
Klar wirst du jetzt sagen, "ich sollte doch aber wissen, wie xyz intern funktioniert, wenn ich es verwende" - ist aber kein argument bei programmier(-hoch)-sprachen. dann müsstest du wohl zu allererst asm lernen. oder bei der cpu-architektur anfangen - oder noch weiter unten...

bb

Felixxx

Löl.
Ich kann und will das einfach nicht als Argument gegen ein Buch akzeptieren. Egal welches Buch.
Wenn du ein Haus baust, fängst du dann mit dem Dach an ? Wohl kaum.

C-String gehören genauso zu C wie zu C++, also kann man schlecht von einem Mischmasch aus beiden Sprachen reden. Natürlich stammen C-String aus C, aber man benutzt sie trotzdem sehr häufig in C++. Also macht es Sinn, darauf einzugehen.
Außerdem geht er beim Erwähnen der String-Klasse direkt ganz darauf ein. Sollte er das etwa gleich bei den Basisdatentypen int, char, etc. machen ? Wohl kaum ...

Und nun erklär mir bitte noch, wie das das Vertändnis eines Programmieranfängers durcheinander bringt ? Die Tatsache, dass der Autor vor Strings auf C-String eingeht ?