vector<long>-Iterations-Problem

[CStoll]

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

[volkard]

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.

[Gast]

@volkard:

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?

[Gast]

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.

[CStoll]

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?)

[314159265358979]

http://ideone.com/lB1Ob
So einfach wärs.

[volkard]

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.

[Gast]

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?)

http://www.amazon.de/Programmierer-lernen-Professionell-anwenden-Lösungen/dp/3446416447/ref=sr_1_3?ie=UTF8&qid=1303426251&sr=8-3

[Gast]

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*

[volkard]

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.

[volkard]

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.

[Gast]

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.

[doppelklick]

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.

[EOutOfResources]

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.

[volkard]

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.

[Gast]

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".

[volkard]

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.

[otze]

dennis.cpp schrieb:

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".

Da kann ich dich beruhigen. Das Kneipenwürfelspiel wirst du sicherlich schon in 1-2 Monaten basteln können. Es wird halt nach nichts aussehen, vielleicht sogar Konsolenbasiert sein, aber du würdest es schon hinkriegen können und schauen ob das Spielprinzip Spaß macht.

Ich muss Volkard zustimmen. Ursprünglich habe ich mit der Programmierung begonnen um - ja- Spiele zu programmieren. Guess what? Ich habe nie eines fertig gestellt und inzwischen möchte ich es auch gar nicht mehr. Ich würde aber gerne Volkards Ratschlag etwas erweitern:

Hüte dich vor größeren Projekten.

Ich habe die Erfahrung gemacht, dass ich am Meisten in der Endphase eines Projektes gelernt habe. Dann ist nämlich der Punkt, an dem sich das Design bewähren muss: hat deine initiale Idee funktioniert? Wo sind die Probleme? Was kann man besser machen? Das alles sieht man erst, wenn der Code an allen Ecken zerbröselt oder das Programm aus irgendeinem anderen Grund einen Schuss in den Ofen wird. Bei großen Projekten kommt dieser Punkt zu spät. Es ist zu viel kaputt um eine ordentliche Begründung zu finden, was falsch lief. Und es ist zu viel kaputt, als dass da noch irgendwas zu retten ist. Aber das bemerkt man als Anfägner nicht. Und wenn da 10000 Zeilen Code bereits im schweiße des angesichts programmiert wurden, dann will man die auch nicht weg werfen. Also schreibt man noch gruseligeren Code um den Müll am Laufen zu halten und die Spirale des Grauens setzt ein...

Die Spieleprogrammierung ist in der Hinsicht noch etwas extremer, weil man immer mit einem Fuß in den Hardware Schnittstellen steht. Und die sind ja immer etwas gruselig. Und wenn man als Anfänger nur von gruseligem Code umgeben ist, tendiert man dazu genau das Selbe zu tun...

@Volkard grausam. Und ich habe selbst mal solch dummen Fragen gestellt...

[Gast]

@otze - *Dass* das Spielprinzip Spaß macht, weiß ich aus 8 Jahren Kneipenjob.

Spaß beiseite: Spannende Beiträge, danke dafür. Ich bin zwar noch nichtmal ansatzweise so weit, mich ernsthaft mit solchen Fragestellungen zu beschäftigen, aber es kann auch nicht schaden, hin und wieder jetzt schon über solche Sachen nachzudenken.

Ich habe übrigens schon ziemlich konkrete Vorstellungen, was aus dem Würfelspiel mal werden soll, und damit dürfte ich 'ne Weile beschäftigt sein. Ich habe mir da verschiedene Zwischenziele gesteckt, die von dir angesprochene einfache Konsolenversion, die vielleicht tatsächlich in ein paar Monaten schon machbar ist (obwohl ich das für mich persönlich bezweifle, ich kenne meine Schwächen sehr genau und weiß, dass das Projekt "Programmierenlernen" bei mir etwas länger dauern wird als bei anderen), ist das erste Zwischenziel.