Trident
Off Topic => Off Topic => Thema gestartet von: Zippozipp am 16. Juli 2007, 19:16:16
-
Sodale, es geht an. Da ich keinen Bock habe extra eine Blogseite einzurichten werde ich Euch in Zukunft in diesem Thread hier mit meinen gloreichen Fortschritten mit C++ beglücken.
Hier auch gleich das erste Produkt meiner Lernbemühungen...und jaaaa, ich weiß, ich habe cin zweckentfremdet :biggrin: aber so geht die "Dosbox" erst zu, wenn man Enter drückt.
-
HAX! VIRII! PR0N!
-
Hallo Zippozipp!
Mühsam ernährt sich das Eichhorn
-
Jede lange Reise beginnt mit einem ersten Schritt, nicht wahr?
-
Stimmt, das passt besser :aww:
-
Bah, das ist ja nur ein kompiliertes Binary. Poste doch lieber den Code, dann kann man da auch noch Kommentare dazu abgeben.
-
Ich dachte ausgerechnet bei DIESEM Beispiel wäre der Code noch egal ::)
Aber mir isses wurst, bei den weiteren Ergebnissen kommt der dann eh immer mit dazu.
-
Klar, dass in dem Code keine Offenbarung drin sein wird. Trotzdem kann ich da schon mal anmerken, dass ein "return 0;" am Ende eher unschön ist, da Du einfach davon ausgehst, dass 0 der Wert für erfolgreiche Ausführung ist. Das mag zwar in allen mir bekannten Plattformen richtig sein, sauberer wäre es aber trotzdem, am Anfang die cstdlib zu includen und dann ein "return EXIT_SUCCESS;" zu benutzen (und im Fehlerfall entsprechend ein EXIT_FAILURE).
-
Warum? Nach dem was ich bis dato gelesen habe ist das return 0; nur damit main überhaupt irgend etwas zurückgibt, bei 0 eben nichts. Oder verstehe ich da was falsch!?
-
Nein, der Rückgabewert der main() ist der Wert, den das Programm beim Beenden an das aufrufende Programm (also z.B. der Shell) zurückgibt.
Die Konstante EXIT_SUCCESS (üblicherweise mit 0 belegt), bedeutet dabei "alles ok". Ein EXIT_FAILURE (normalerweise 1) bedeutet dagegen "Fehler aufgetreten". Dieser Code kann beim Zusammenspiel von mehreren Programmen also sehr wichtig sein.
"Nichts zurückgeben" gibt es in C übrigens nicht. Im besten Falle ist der Rückgabewert nicht definiert - wenn Du kein return Statement angibst, gibt die Funktion gerade den Wert zurück, der dort im Speicher auf dem Returnstack liegt.
-
Bei einem Shellprogramm gibt es etwas mehr wie 0 und 1, weil man nämlich in einem Skript die Errorlevels abfragen und entsprechend reagieren kann: Errorlevels (http://www.robvanderwoude.com/errorlevel.html).
Deswegen ist die int Rückgabe auch durchaus gebräuchlich.
-
...Die Konstante EXIT_SUCCESS ... EXIT_FAILURE...
Sind das Compiler Macros? Weil ich finde dazu in allein meinen 3 Büchern nichts. FALLS es welche sind habe ich nur den Vermerk im easy C++ Buch, dass sowas nur bei C Sinn macht und bei C++ eben nicht. Dazu ist in allen C++ Büchern und auch den Onlinekursen, die man so frei einsehen kann (z.B. unter c-plusplus.de) immer main mit return 0; abgeschlossen (insofern main nicht wirklich etwas zurückgeben soll).
Aber im Endeffekt habe ich gar nicht so recht den Plan was ihr meint, ich kann ja erst einmal nur nach meinen Büchern hier gehen. Und bitte seht das nicht als Undankbarkeit, ich freue mich schon über Tips, nur diesem kann ich grade einfach nicht so recht folgen weil er einfach meinen "Lehrmaterialien" widerspricht bzw. in diesen (in keinem der Bücher) vorkommt.
Und glaubt ja nicht ich mache es mir leicht damit hier zu widersprechen, ich bin mir wohl bewusst, dass ich früher oder später bei tiefergehenden Konzepten auf Eure Hilfe angewiesen sein werde.
-
Ja, das sind Makros und wer auch immer schreibt, dass Makros in C++ keinen Sinn machen, hat entweder einen an der Klatsche und meint das in irgendwelchen speziellen zusammenhängen.
-
Von "keinen Sinn" hat niemand was gesagt, nur von "weniger...als". Ich habe grade mal fix durchgeblättert aber die Textstelle so auf die Schnelle nicht finden können. Ich schau morgen bei Tageslich noch mal in Ruhe und sage hier nochmal was dazu, so rede ich nur wie ein blinder von der Farbe.
Fakt ist, egal welches Lehrwerk zu C++ ich mir anschaue ich finde überall das return 0; in main insofern main nichts zurückliefern soll. Das muss doch einen Grund haben!?
Des Rätsels Lösung könnte natürlich auch sein, dass das was ihr hier ansprecht ein so fortgeschrittenes oder spezielles Konzept (für C++) ist, dass es überall zu Beginn aus gutem Grund erst einmal weggelassen wird.
-
*grml* das hat mich jetzt nicht mehr losgelassen, ich musste doch gleich wühlen :whistle1:
Ich habe auch etwas gefunden wegen dem return 0; und zwar in easy C++ auf Seite 73.
C++ verlangt nämlich, dass die main()-Funktion mit einer return-Anweisung beendet wird, die einen Ergebniswert zurückliefert.
Das klingt für mich als MUSS immer per return etwas übergeben werden. Im Folgetext geht es dann darum, wenn nichts sinnvolles dann eben 0 zu übergeben.
Wenn ich das falsch lese/verstehe klärt mich bitte auf, ggf. haben wir ja auch aneinander vorbei geredet bzw. ich habe Euch vollkommen falsch verstanden und ihr meintet was ganz anderes!?
Zu den Macros habe ich übrigens auch noch was gefunden, nämlich ein Zitat von Bjarne Stroustrup, dem Erfinder von C++ und zwar in der Einführung in ISO-C++ von Holger Jakobs (freies E-Book) auf Seite 6.
Die wichtigste Regel bei Macros ist: Benutze keine, es sei denn, es ist unabdingbar. Fast jedes Macro demonstriert eine Schwäche in der Programmiersprache, im Programm oder beim Programmierer.
-
Zu den Macros habe ich übrigens auch noch was gefunden, nämlich ein Zitat von Bjarne Stroustrup, dem Erfinder von C++ und zwar in der Einführung in ISO-C++ von Holger Jakobs (freies E-Book) auf Seite 6.[...]
Nicht gleich das Kind mit dem Badewasser auskippen, bitte. Wir reden hier von "#define" Präprozessor-Anweisungen, die eigentlich ja nichts weiter machen als einen Text im Quelltext durch anderen Text - entweder längeren und eklig zu tippenderen oder Konstanten, die man überall braucht - zu ersetzen. Man kann natürlich auch viel durchgeknalltes und schweinisches damit machen (besonders weil die #define's auch Argumente haben können), aber um einfache Konstanten zu definieren reicht es allemal. Schau Dir z.B. mal dein <stdio.h> an, da findest Du so Dinge wie:
/* The possibilities for the third argument to `fseek'.
These values should not be changed. */
#define SEEK_SET 0 /* Seek from beginning of file. */
#define SEEK_CUR 1 /* Seek from current position. */
#define SEEK_END 2 /* Seek from end of file. */
Man könnte natürlich die Konstanten irgendwo ablegen, vor allem weil man die C-library ja meist eh mitlinkt, und die könnte ja die Konstanten verwalten - nur hat das zwei Haken: Zum einen könnte irgendein amok laufendes Programm die Konstanten in diesem Speicherbereich ändern, und zum anderen sind die Konstanten dann nicht inline im Code zu finden, und der Prozessor muss teilweise lange 32bit bzw. 64bit-Adressen referenzieren, was länger dauert als lokale, relative Referenzen oder direkte Vergleichsparameter im Codestrom aufzulösen.
Man kann zwar in C++ Werte definieren und die mit "const" deklarieren, aber im Regelfall wird das einfach nicht gemacht weil man auch in C++ seinen Heap und Stack trashen kann. Und dann erlaubt C++ natürlich auch so witzige Dinge wie
int y = 42;
const int* pointerToY = &y;
int* imfsckingupY = &y;
*imfsckingupY = 23;
-
Man kann zwar in C++ Werte definieren und die mit "const" deklarieren, aber im Regelfall wird das einfach nicht gemacht weil man auch in C++ seinen Heap und Stack trashen kann. Und dann erlaubt C++ natürlich auch so witzige Dinge wie
Bahnhof!
-
Bahnhof!
Der Stack ist der Teil vom Speicher, auf den ein Programm die Argumente für aufzurufende Funktionen schiebt. Mehr unter http://de.wikipedia.org/wiki/Stapelspeicher
Der Heap wiederum ist der Speicherbereich von dem dynamischer Speicher für beliebiges, zur Laufzeit erst generiertes Zeug angelegt wird. Im klassischen C also das was malloc() macht und in C++ alles was über "new" angelegt wird: http://de.wikipedia.org/wiki/Dynamischer_Speicher
Im klassischen C-Speichermodell liegen Stack und Heap an gegenüberliegenden Enden und wachsen auch gegeneinander. Wächst das eine in den Bereich des anderen macht es Ka-Bumm und dein Programm stürzt ab.
Wir schweifen allerdings leicht vom Thema ab, und vertrau mir deswegen einfach wenn ich sage:
1. Stroustrup mag im akademisch/theoretischen Sinn richtig liegen das Makros nicht "schön" sind und die Sprache sich für solche Konstrukte nicht von einem Präprozessors abhängig machen sollte.
2. Man darf nicht bedingungslos akademisch/theoretische Anforderungen an eine Sprache wie C++ richten, vor allem nicht wenn diese Sprache auf dem Fundement C (und die wiederum auf B und BCPL) ruht, die ja gerade nicht als "schöne Lehrsprache" entwickelt wurde sondern aus der Praxis für die Praxis - mit allen Hacks und Kludges die dazugehören, und:
3. Schon drei mal nicht wenn man seine Spracherweiterung zunächst selbst als eine Art glorifizierten Präprozessor entwickelt.
4. Ausserdem ist Objective C ist das "schönere" objektorientierte C und es gibt haufenweise bessere Sprachen um "richtig" Programmieren zu lernen und die auch das Auge des theoretischen Informatikers erfreuen.
-
Sodale, dann werfe ich mal wieder was zum Fraße vor. Es ist ein einfaches Programm, dass Celsius in Fahrenheit oder Fahrenheit in Celsius umrechnet. Wie man die Nachkommastellen begrenzt weiß ich noch nicht und zu printf komme ich erst in 2 Kapiteln, seht mir also die Formatierungskapriolen nach 8)
Üben wollte ich vor allem mit dem Eingabepuffer und halt auch endlich mal eine Schleife.
Die Variable cels_oder_fahr als Bool ging übrigens nicht, falls mir jemand sagen kann wieso, wäre ich wirklich dankbar. Ich meine der Compiler hatte nix zu meckern aber das Programm funktionierte nicht wie es sollte, es hat immer den ganzen else-Bereich ignoriert. Dabei mache ich den Eingabepuffer eigentlich extra vorher leer...es ist mir echt ein Rätsel.
-
Das return 0 finde ich immer noch hässlich, aber gut, was will man machen...
Bzgl. Deinem bool Problem - ich nehme an, Du hast das genauso wie im Code gemacht, also mit
cin >> cels_oder_fahr;
Wobei cels_oder_fahr als bool deklariert ist.
Nun muss man wissen, dass der bool Datentyp in C++ nichts anderes ist als eine Zahl, wobei der Wert 0 als FALSE interpretiert wird und ein Wert ungleich 0 (also negative oder positive Zahl) als TRUE.
Eine Eingabe von 1 oder 2 ist also immer TRUE.
-
Weiter:
in Zeile 27 sollte das nicht 9,0 sondern 9.0 heißen. (Hint: g++ -Wall)
Die Anzahl der Stellen kannst Du wie folgt beschränken:
#include <iomanip>
cout << eingabewert << " Grad Celsius entsprechen " << setiosflags(ios::fixed) << setprecision(2) << ergebnis_czf <<
" Grad Fahrenheit" << endl;
-
Das return 0 finde ich immer noch hässlich, aber gut, was will man machen...
Bzgl. Deinem bool Problem - ich nehme an, Du hast das genauso wie im Code gemacht, also mit
cin >> cels_oder_fahr;
Wobei cels_oder_fahr als bool deklariert ist.
Nun muss man wissen, dass der bool Datentyp in C++ nichts anderes ist als eine Zahl, wobei der Wert 0 als FALSE interpretiert wird und ein Wert ungleich 0 (also negative oder positive Zahl) als TRUE.
Eine Eingabe von 1 oder 2 ist also immer TRUE.
Ah, stimmt, ich bin irgendwie davon ausgegangen wenn die Variable was anderes als 1 oder 0 bekommt bleibt sie bei ihrem alten Wert, würde also im Endeffekt nur 0 oder 1 aufnehmen. Das ist selbstverständlich quark :shutup: Danke Dir.
Weiter:
in Zeile 27 sollte das nicht 9,0 sondern 9.0 heißen. (Hint: g++ -Wall)
Die Anzahl der Stellen kannst Du wie folgt beschränken:
#include <iomanip>
cout << eingabewert << " Grad Celsius entsprechen " << setiosflags(ios::fixed) << setprecision(2) << ergebnis_czf <<
" Grad Fahrenheit" << endl;
Das mit dem Komma ist natürlich richtig. Der Rest ist mir schon wieder zu viel Bahnhof :biggrin:
Im Anhang ist die gefixte Version (Komma und so).
-
MFC kommt nocht. Erst das easy Buch an dem ich grade bin, dann das Folgebuch, dass der easy-Autor empfiehlt (liegt hier schon rum). Danach dann MFC (Buch liegt hier auch schon) und danach...mal schauen.
Danke für den Link, scheint mir ziemlich umfangreich zu sein.