vector<long>-Iterations-Problem
-
Hallo Forum!
Aufgabe: Einen gegebenen Ziffern-String in eine Long-Zahl umwandeln.
Meine Idee: Ziffern-Zeichen in ihren Wert umwandeln, in einem vector<long> speichern, jedes Element mit seiner Stellenwertigkeit multiplizieren und dann aufaddieren.
Mein Problem: Beim Anlegen eines Hilfsvektors, in dem die Stellenwertigkeit festgehalten wird, stürzt das Programm ab.
Der relevante Codeausschnitt (mit cout-Testausgaben als Fehlerquelle eingegrenzt):
// Lege einen Hilfsvektor an, in dem die Stellenwertigkeit festgehalten // wird und fülle ihn: vector<long> wertigkeit(zahlString.length()); wertigkeit[zahlString.length() - 1] = 10L; for (size_t i = zahlString.length() - 2; i >= 0; --i) { wertigkeit[i] = wertigkeit[i + 1] * 10; }Wo liegt der Denkfehler?
-
Leider begreife ich Dein Vorgehen nicht.
Aber ich habe ein alternatives Vorgehen: Sammle doch einfach den Wert als Zahl.
"2543"
0 habich.
2 kommt. 010+2=2, 2 habich.
5 kommt. 210+5=25, 25 habich.
4 kommt. 2510+4=254, 254 habich.
3 kommt. 25410+3=2543, 2543 habich.
Stringende kommt.
2543 habich.
-
@volkard - Das ist im Prinzip genau mein Vorgehen, nur ohne den Umweg über besagten Hilfsvektor mit der Stellenwertigkeit. Und eine gute Idee, danke.

Warum obiges Codefragment das Programm zum Absturz bringt, interessiert mich aber trotzdem...
-
Erstens: Abgesehen davon, daß du seine Größe verwendest, greifst du überhaußt nicht auf den Eingabestring zu.
Zweitens: Warum so umständlich, wenn das auch mit Bordmitteln zu bewerkstelligen ist? (schau mal in die FAQ unter "Einmal String nach Zahl und zurück")
Drittens: Kontest du auch einschränken, in welchem Durchlauf es kracht?
Viertens: size_t ist ein vorzeichenloser Zahlentyp - der ist immer größer oder gleich 0
-
dennis.cpp schrieb:
Warum obiges Codefragment das Programm zum Absturz bringt, interessiert mich aber trotzdem...
Das läßt sich konkret finden, indem man selber Computer spielt und sich Schritt für Schritt alles durchspielt und sich die Variableninhalte immer aufschreibt und aktualisiert.
Der Debugger hilft auch ungemein dabei. Aber hier nicht. Die Zeilen machen so sauviel auf einmal, daß man schon Profi sein muß, um lesen zu können, was der Debugger einem da sagen will.
Ich schlage vor, daß Du das Problem vertagst. In 10 Wochen wirst Du gar nicht mehr nachvollziehen können, wie Du zu dem Code hier kamst, und Deine Anfängerprobleme werden auch nicht Kern Deiner weiteren Forschungen sein. Tu es weg, das hier war kein glücklicher Code-Entwurf, fürchte ich. In 10 Wochen kannste Dein Vorgehen mit dem Sammeln und aufaddieren der gewichteten Stellenwertigkeiten zum Spaß noch mal hineinklimpern. Dann wird's auch gleich finktionieren.
-
Meine Lösung sieht jetzt so aus und funktioniert so weit:
#include<iostream> #include<vector> #include<string> #include<cstddef> using namespace std; int main() { // Der Zahlstring, der umgewandelt werden soll: string zahlString = "17462309"; // Ein Vektor, in dem die einzelnen Zeichen als Ziffern gespeichert werden: vector<long> ziffern(zahlString.length()); // Iteriere über den String und wandele die einzelnen Zeichen in ihren // Ziffernwert um. Speichere die Ziffern im Vektor: for (size_t i = 0; i < zahlString.length(); ++i) { int temp; temp = zahlString[i] - '0'; ziffern[i] = static_cast<long>(temp); } // Die Variablen für die Ergebnisse: long zahl, quersumme; zahl = ziffern[0]; quersumme = ziffern[0]; // Zahl zusammenbauen und Quersumme errechnen: for (size_t i = 1; i < ziffern.size(); ++i) { zahl *= 10; zahl += ziffern[i]; quersumme += ziffern[i]; } // Ausgabe: cout << "Die Zahl: " << zahl << endl; cout << "Die Quersumme: " << quersumme << endl; }@CStoll:
1. In diesem kleinen Fragment nicht, nein. Ist für diese Teilaufgabe doch auch gar nicht sinnvoll? Das sollte ja nur ein Hilfsvektor sein. Der geplante Weg war: vector<long> für die Ziffern, Zeichen für Zeichen des String umwandeln und in diesem ersten Vektor speichern (bis hierhin hat alles funktioniert), zweiten vector<long> mit Stellenwertigkeit erstellen (1, 10, 100, 1000 usw.) (das ist der Codeausschnitt von oben), Elemente des ersten Vektors mit Elementen des zweiten multiplizieren und aufsummieren.2. Weil die Bordmittel an dieser Stelle des Buches noch nicht besprochen sind.

3. Nein, Code::Blocks gibt mir keine Fehlermeldung. Die Ausführung bleibt einfach hängen. Ich weiß nichtmal, ob es überhaupt einen Durchlauf gibt. (Das sollte ich vielleicht mal ausprobieren.)
4. Stimmt.
Könnte allein dieser Vergleich schon ein Grund für einen Absturz sein?
-
volkard schrieb:
Ich schlage vor, daß Du das Problem vertagst. In 10 Wochen wirst Du gar nicht mehr nachvollziehen können, wie Du zu dem Code hier kamst, und Deine Anfängerprobleme werden auch nicht Kern Deiner weiteren Forschungen sein. Tu es weg, das hier war kein glücklicher Code-Entwurf, fürchte ich. In 10 Wochen kannste Dein Vorgehen mit dem Sammeln und aufaddieren der gewichteten Stellenwertigkeiten zum Spaß noch mal hineinklimpern. Dann wird's auch gleich finktionieren.
Okay, wenn das von *dir* kommt, nehme ich das mal so hin.
Danke jedenfalls für den kleinen Anstoß oben, gelöst habe ich die Aufgabe damit ja. 
-
dennis.cpp schrieb:
Warum obiges Codefragment das Programm zum Absturz bringt, interessiert mich aber trotzdem...
Vermutlich liegt es an dem size_t - wenn du von einer vorzeichenlosen Null eins abziehst, landest du nicht bei -1 (das gibt's nicht), sondern bei einem sehr großen Wert (je nach System meistens etwas über 4 Milliarden).
Edit:
2. Weil die Bordmittel an dieser Stelle des Buches noch nicht besprochen sind.
Das ist ein Grund, aber kein Hindernis

(btw, was ist denn das für ein Buch?)
-
http://ideone.com/lB1Ob
So einfach wärs.
-
dennis.cpp schrieb:
@volkard:
Meine Lösung sieht jetzt so aus und funktioniert so weit:Das freut mich.
Hätte nicht gedacht, daß Du es soo schnell schaffst.Mich würde es freuen, wenn Du die Lösung noch reduzieren könntest. Weil die danach ruft. Sie bettelt. Da bin ich wie Mr Monk. Das ist einfach nicht supi so. Das macht mich total fertig. Wenn Du das nicht löst, werde ich kein besinnliches Osterfest haben. Am Ende brauchst Du außer der Laufvariablen und der sich im Laufe verändernden Ergebnisvariablen gar nichts. Außer vielleicht temporären Variablen, um lange Ausdrücke zu strukturieren.
-
CStoll schrieb:
2. Weil die Bordmittel an dieser Stelle des Buches noch nicht besprochen sind.
Das ist ein Grund, aber kein Hindernis


CStoll schrieb:
(btw, was ist denn das für ein Buch?)
-
volkard schrieb:
Hätte nicht gedacht, daß Du es soo schnell schaffst.
Naja, meine Gedankengänge waren von deinem Tipp ja nicht soooo weit entfernt, ich brauchte nur noch den kleinen Schubs, dass der Umweg total überflüssig ist. Aber danke fürs motivierende Lob.

volkard schrieb:
Mich würde es freuen, wenn Du die Lösung noch reduzieren könntest. Weil die danach ruft. Sie bettelt. Da bin ich wie Mr Monk. Das ist einfach nicht supi so. Das macht mich total fertig. Wenn Du das nicht löst, werde ich kein besinnliches Osterfest haben.
Dein Osterfest muss ich dir allerdings leider vermiesen: So gern ich die Herausforderung annehmen würde, aber ich habe zwischenzeitlich schon die Musterlösung des Buches angeschaut und jede weitere Optimierung wäre damit keine Eigenleistung mehr...
Sorry! *Schulterzuck*
-
dennis.cpp schrieb:
Dein Osterfest muss ich dir allerdings leider vermiesen: So gern ich die Herausforderung annehmen würde,...
Keine Bange, es ist nicht vermiest. Mein Gleichgewicht wäre gestört, wenn Du beständig umständlich programmieren würdest. Das scheint mir nicht der Fall zu sein.
-
dennis.cpp schrieb:
volkard schrieb:
Ich schlage vor, daß Du das Problem vertagst. In 10 Wochen wirst Du gar nicht mehr nachvollziehen können, wie Du zu dem Code hier kamst, und Deine Anfängerprobleme werden auch nicht Kern Deiner weiteren Forschungen sein. Tu es weg, das hier war kein glücklicher Code-Entwurf, fürchte ich. In 10 Wochen kannste Dein Vorgehen mit dem Sammeln und aufaddieren der gewichteten Stellenwertigkeiten zum Spaß noch mal hineinklimpern. Dann wird's auch gleich finktionieren.
Okay, wenn das von *dir* kommt, nehme ich das mal so hin.
Danke jedenfalls für den kleinen Anstoß oben, gelöst habe ich die Aufgabe damit ja. 
Sorry!
Ich dachte, die Aufgabe käme von einem Prof fürs Studium!! Die Profs sind OFT verplant und geben Aufgaben auf, die derzeit nicht sinnvoll lösbar sind. Die sind oft total willkürlich. Die sind oft zum Heulen.
Ich hatte ja keine Ahnung, daß sie aus dem Breymann war. Breymann hat mein vollstes Vertrauen, daß er das Buch nicht nur hingehudelt hat, sondern im Gegenteil, abgesehen davon, daß es schon ein wenig härter ist, eher nix für Hauptschüler, ist es glorios. Kein Wunder, daß Du "soo" schnell warst. Breymann-Aufgaben zu überspringen ist vermutlich nicht schlau. Die meisten Fragesteller hier sind durch einen schlechten Einsteig verdorben und es kostet Monate und Jahre, um sie auf den rechten Weg zu bringen, oder wenigstens davon zu überzeugen, daß die schlimmsten Abwege abwegig sind, wobei 95% leider abspringen.ps: Und auch wenn es noch so danach zieht, vermeide sehr lange das Gamecoding.
-
volkard schrieb:
abgesehen davon, daß es schon ein wenig härter ist, eher nix für Hauptschüler,
Allerdings. Beim ersten Anlauf hatte ich auf den ersten 100 Seiten frustrierend viele Probleme mit dem Buch.
Zwei ganz seichte Anfängerbücher später und ein bisschen hier und da reinschnuppern in den neuen Stroustrup (den ich eigentlich sorgfältig bearbeiten wollte, der mich aber auch ab Kapitel 6 frustriert hat) geht mir der Breymann bisher leichter von der Hand.
Mir fehlt sicherlich das, was man "Naturbegabung", "Talent", wie auch immer nennen möchte. Aber ich *will* C++ lernen, und wenn es schon an der Veranlagung fehlt, dann muss ich das eben durch Zähigkeit ausgleichen. Sprich, Aspekte, die mir Schwierigkeiten machen, so lange und in so vielen Büchern immer und immer wieder lesen und bearbeiten, bis der jeweilige Knoten platzt.

volkard schrieb:
ps: Und auch wenn es noch so danach zieht, vermeide sehr lange das Gamecoding.
Nicht, dass ich in dieser Hinsicht Illusionen *gehabt hätte*, die du hättest bremsen müssen - mich würde dennoch deine Begründung für den Ratschlag interessieren.
-
CStoll schrieb:
Zweitens: Warum so umständlich, wenn das auch mit Bordmitteln zu bewerkstelligen ist? (schau mal in die FAQ unter "Einmal String nach Zahl und zurück")
Um was zu lernen.

-
dennis.cpp schrieb:
3. Nein, Code::Blocks gibt mir keine Fehlermeldung. Die Ausführung bleibt einfach hängen. Ich weiß nichtmal, ob es überhaupt einen Durchlauf gibt. (Das sollte ich vielleicht mal ausprobieren.)
Das ist ja nicht mal ein Compiler sondern eine IDE.
-
dennis.cpp schrieb:
volkard schrieb:
ps: Und auch wenn es noch so danach zieht, vermeide sehr lange das Gamecoding.
Nicht, dass ich in dieser Hinsicht Illusionen *gehabt hätte*, die du hättest bremsen müssen - mich würde dennoch deine Begründung für den Ratschlag interessieren.
Weil ich viele aufstrebende Programmmierer sehe, die vorher rapides Wachstum zeigten, und jetzt als Gamecoder keine sichtbaren Fortschritte machen. Das ist der Grund für mich. Über die Ursachen dafür kann ich nur spekulieren.
Ein Versuch:
Um das Game fertigzubekommen, kann man nicht einfach zur Zeit zu heftige Probleme zurückstellen. Dadurch muß man Probleme "lösen", für die man noch gar keinen Werkzeugkasten hat und gewöhnt sich an, Schrauben mit der Kombizange in die Wand zu hämmern. Seinen Fortschritt hat man dadurch, daß man Models auf dem Bildschrim sieht, nicht dadurch, daß man hübschen wartbaren Code hat. Gamecoder lernen von Gamecoders. Anfänger lernen von Fortgeschrittenen. Aber die Kombizangenkultur ist dort schon bis zu den Profis vorgedrungen. Dadurch ist die Gemeinde abgekippt und für Anfänger als "gefährlich" zu kennzeichnen.
-
EOutOfResources schrieb:
Das ist ja nicht mal ein Compiler sondern eine IDE.
...die aber auch Compilerfehler anzeigt. Ein Kompilierfehler lag ja nicht vor - gebaut wurde das Programm ohne Probleme. Bei der *Ausführung* hat es sich dann aber aufgehangen.
@volkard - Klingt schlüssig. Da würde ich mich aber jetzt fragen, ob dass tatsächlich auf alle Bereiche zutrifft. Entsprechende Fragen in dieser Richtung sind mir hier im Forum zum Beispiel nämlich nur im Zusammenhang mit Träumereien von Egoshootern und Rollenspielen aufgefallen bisher.
Insofern habe ich das Gefühl, dass es gar keine einheitliche "Spiele-Entwicklungs-Szene" gibt, sondern eher unterschiedliche Fraktionen, die sich in der Herangehensweise stark voneinander unterscheiden.
Andererseits kann ich naturgemäß nicht deinen Einblick haben, weil ich erst verhältnismäßig kurz überhaupt hier im Forum angemeldet bin, mich mit Programmierung beschäftige, und schon gleich gar keinen fremden Code größerer Projekte gesehen habe.
Ich kann dich aber, wie gesagt, in dieser Hinsicht beruhigen. Natürlich gibt es auch für mich eine Spiele-Idee, die ich gern irgendwann umsetzen würde. Nur ist es bei mir nicht "mittelfristig ein 3D-Egoshooter", sondern "langfristig (!) ein simples Kneipenwürfelspiel".
-
Die Szene scheint sich zu spalten, John Carmack geht voran, twittert zum Beispiel, daß er "Mehr effektiv C++ programmieren" liest und so Sachen (nachdem er mehr als ein Jahrzehnt lang mit seinem Müllstil große Teilschuld an der Misere verdient hat).
Wir haben hier kein einschlägiges Gamecoders-Forum, sondern bekommen das Geschehen nur am Rande mit.
Die zur Zeit neuesten beiden C++-Threads bei Zerbie:
http://zfx.info/viewtopic.php?f=4&t=1530
http://zfx.info/viewtopic.php?f=4&t=1534
Die treiben einem doch Tränen in die Augen.