-
Gesamte Inhalte
9912 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
3
Inhaltstyp
Profile
Forum
Downloads
Kalender
Blogs
Shop
Alle Inhalte von Klotzkopp
-
Kannst du mal diese ganzen unsinnigen Sleeps rausmachen und die Ausgaben zusammenfassen? Das sieht ja furchtbar aus.
-
Hast du bemerkt, dass in Schnittstelle.h wiederum die Tserial_event.h eingebunden wird? Wenn du das machst, binden sich die Dateien gegenseitig ein, das funktioniert nicht. Über die Includedirektiven kann man Headerdateien vor anderem Code einbinden. Es können aber nicht zwei Dateien gleichzeitig jeweils vor der anderen sein. Die Include-Guards (#ifndef/#define/#endif) sorgen dafür, dass hier keine Endlos-Include-Rekursion passiert, aber trotzdem steht hinterher eine der beiden Dateien hinter der anderen. In den meisten Fällen lässt sich das mit Forward Declarations auflösen. Ich weiß nicht, ob Schnittstelle.h in Tserial_event.h gebraucht wird, aber die Includedirektive für Tserial_event.h in Schnittstelle.h ist nicht unbedingt notwendig. Hier wird nur ein Zeiger des Typs Tserial_event benutzt, ohne auf irgendwelche Member zuzugreifen. Dafür reicht auch eine Forward Declaration. Ersetz also die Includedirektive für Tserial_event.h in Schnittstelle.h durch class Tserial_event; // oder struct Tserial_event, was auch immer Tserial_event ist.[/code]
-
Erstens könnte man eher deinem Code ansehen, wie gut du dich auskennst, als dem fertigen Programm, und zweitens wird hier niemand einfach so ausführbare Dateien aus dem Internet runterladen und ausführen.
-
Hast du denn Haltepunkte gesetzt? Wie hast du den Debugger gestartet? Das funktioniert nicht. Wenn du mehrere Bedingungen verknüpfen willst, musst du sie alle komplett ausschreiben: if((Brett[i][j][3] == ("2") || Brett[i][j][3] == ("3") usw. Übrigens: Dir wurde schon vorher geraten, auf goto zu verzichten. Gewöhn dir das bitte schnellstens ab. Goto ist kein Ersatz für Schleifenkonstrukte! Und das hier if(tempCheck == choiceGes) { return true; } else { return false; }[/code] ist eine unnötig ausschweifende Schreibweise für [code]return tempCheck == choiceGes;
-
Wenn man nach "Code Blocks Debugging Tutorial" sucht, findet man so einiges. Beispielsweise das hier:
-
Problem mit der Initialisierung von Direct3D!
Klotzkopp antwortete auf banji's Thema in C++: Compiler, IDEs, APIs
Welchen Compiler verwendest du? -
Lass das [maxSize] hier weg, es bewirkt nicht das, was du glaubst. Machen wir ein kleines Spiel: Was ist pZeiger[0]? Antwort: Das erste Element des Arrays pZeiger. Was ist pZeiger[1]? Antwort: Das zweite Element des Arrays pZeiger. Was ist pZeiger[maxSize]? Antwort: Das maxSize+1.te Element des Arrays pZeiger. Erstens hat dein Array gar nicht so viele Elemente, und zweitens willst du sicher nicht nur ein einzelnes Element übergeben, oder? Mir ist klar, dass du hier versuchst, eine Größenangabe mitzuliefern, aber das funktioniert so nicht. Überhaupt geht bei Arrays die Größeninformation verloren, wenn man sie als Funktionsparameter benutzt. In der Funktion kommt nur ein Zeiger auf das erste Element an. Die folgenden Funktionsdeklarationen sind also absolut gleichwertig: void einlesen(int& i, Adressen* pZeiger[40]); void einlesen(int& i, Adressen* pZeiger[]); void einlesen(int& i, Adressen** pZeiger);[/code] Wenn du diesen Funktionen eine Größenangabe mitgeben willst, musst du dafür einen zusätzlichen Parameter einführen. Mittelfristig solltest du versuchen, von eigener Speicherverwaltung wegzukommen und statt dessen die Container der Standardbibliothek zu benutzen. Das macht vieles einfacher und verringert die Gefahr von Speicherlecks und Pufferüberläufen.
-
Um den Thread mal wieder zum eigentlichen Thema zurückzuführen, werfe ich einfach mal was in den Raum: #include <vector> #include <iostream> #include <string> #include <algorithm> enum FieldType { Leer, Kreis, Kreuz }; template <class FieldType> class TTTField { public: TTTField( int size, FieldType const& init ) : field( size, std::vector<FieldType>( size, init ) ), empty(init) { generate_win_pos(); } bool set_field( int x, int y, FieldType const& type ) { if( field[x][y] != empty ) return false; field[x][y] = type; return true; } void generate_win_pos() { const int size = field.size(); const int max_check = size - 2; for( int i=0; i<max_check; ++i ) { for( int j=0; j<max_check; ++j ) { std::vector<std::pair<int,int> > w[4]; for( int k=0; k<3; ++k ) { w[0].push_back( std::make_pair( i + k, j ) ); w[1].push_back( std::make_pair( i, j + k ) ); w[2].push_back( std::make_pair( i + k, j + k ) ); w[3].push_back( std::make_pair( i + k, j + (2 - k ) ) ); } win_pos.insert( win_pos.begin(), w, w+4 ); } } } bool check_win_pos( FieldType const& type ) const { for( size_t i = 0; i<win_pos.size(); ++i ) { bool win_found = true; for( size_t j = 0; j<win_pos[i].size(); ++j ) { if( field[win_pos[i][j].first][win_pos[i][j].second] != type ) { win_found = false; break; } } if( win_found ) return true; } return false; } bool is_full() const { for( size_t i = 0; i<field.size(); ++i ) if( std::find(field[i].begin(), field[i].end(), empty ) != field[i].end() ) return false; return true; } void print( std::ostream& stream ) const { for( size_t i = 0; i<field.size(); ++i ) { for( size_t j = 0; j<field[i].size(); ++j ) stream << field[j][i]; stream << '\n'; } } private: std::vector<std::vector<FieldType> > field; std::vector<std::vector<std::pair<int,int> > > win_pos; FieldType empty; }; template <class FieldType> class Player { public: Player( FieldType const& type, std::string name ) : name(name), type(type) {} FieldType const& get_type() const { return type; } std::string const& get_name() const { return name; } private: std::string name; FieldType type; }; std::ostream& operator<<( std::ostream& stream, FieldType type ) { switch( type ) { case Leer: return stream << '#'; case Kreis: return stream << 'O'; case Kreuz: return stream << 'X'; } } int main() { TTTField<FieldType> field(3, Leer); std::vector<Player<FieldType> > players; players.push_back( Player<FieldType>(Kreis, "1") ); players.push_back( Player<FieldType>(Kreuz, "2") ); std::vector<Player<FieldType> >::const_iterator current = players.begin(); while( true ) { std::cout << "Spieler " << current->get_name() << std::endl; int x, y; do { std::cin >> x >> y; } while( !field.set_field( x, y, current->get_type()) ); field.print( std::cout ); if( field.check_win_pos( current->get_type() ) ) { std::cout << "Spieler " << current->get_name() << " hat gewonnen!\n"; break; } if( field.is_full() ) { std::cout << "Unentschieden\n"; break; } if( ++current == players.end() ) current = players.begin(); } } [/code] Da fehlt noch, dass die Feldgröße vom Benutzer eingegeben wird, und ein paar Kleinigkeiten wie das Abfangen falscher Eingaben, ungültiger Parameterwerte usw. Außerdem habe ich versucht, bei der Codeformatierung Platz zu sparen.
-
Ich habe das Gefühl, dass du mindestens die Hälfte von dem, was ich schreibe, ignorierst. Ich hatte vorher schon gesagt, dass ein 32-Bit-long für eine zehnstellige Kontonummer nicht ausreicht. Ich habe dir auch erklärt und danach als Code gezeigt, wie du die verkleinerte BLZ und die Kontonummer zusammenrechnen kannst, jetzt kommst du wieder mit CString::Format. Gut, kann man so machen, dann hätte ich mir die letzten beiden Beiträge auch sparen können. Aber es sollte doch inzwischen bei dir angekommen sein, dass du für solche Zahlen 64-Bit-Datentypen benutzen sollst. Und du kommst wieder mit int(!).
-
Passt irgendwie nicht zusammen. Aber du musst es wissen.
-
Was willst du mit cout? Wenn du mit BLZNr % 97 weiterrechnen willst, musst du das Ergebnis einer Variablen zuweisen. Mit cout kannst du es nur ausgeben, das bringt dir nichts BLZNr %= 97; unsigned __int64 BLZundKtNr = BLZNr * 10000000000ull + KtNr;[/code]
-
Auch hier hilft die Mathematik: 341234567890 = 340000000000 + 1234567890[/code] Du willst die 34 um 10 Stellen nach links verschieben (denn so lang ist die Kontonummer), also musst du sie mit 10 hoch 10 multiplizieren: 34 * (10 hoch 10) = 340000000000
-
Ich erlaube mir mal, darauf hinzuweisen, dass das ein C++-Programm ist. Laut Aufgabenstellung sollst du ein C-Programm schreiben.
-
Der Windows-Taschenrechner sagt 34. Nachgerechnet: 70090100 / 97 = 722578,35... 722578 * 97 = 70090066 70090100 - 70090066 = 34 Wie kommst du auf 35?
-
Bist du wirklich ganz sicher, dass du ein neues Projekt erstellt hast? Die Versionsnummer aus der Fehlermeldung lässt eher darauf schließen, dass du ein Projekt zu öffnen versuchst, das aus VB.NET 2005 stammt.
-
Doch, es hat ausschließlich mit dem Editor zu tun. Der Compiler ist gegenüber Zeichencodierungen komplett blind, dem ist egal, ob du deine Stringliterale sonstwie codierst. Die werden einfach nur eins zu eins ins Programm übertragen. Einfacher wäre es natürlich, einen UTF-8-fähigen Editor zu verwenden. Oder die Strings gar nicht erst in den Quelltext zu schreiben, sondern in eine externe Datei. Man könnte XML benutzen, da hat man die Möglichkeit, die Codierung mit abzuspeichern, um Missverständnisse zu vermeiden. Ganz ehrlich, ich glaube nicht, dass du als "Noob" das beurteilen kannst. Bedenke auch, dass ich versuche, dir Lösungen vorzuschlagen, die du auch umsetzen kannst. Nö, du sagtest, du hättest keine Erfahrung damit. Die Probleme packst du immer erst nach und nach aus. Da ist doch ein Codebeispiel dabei. Wenn da etwas unklar ist, dann sag bitte, was. Zum Umwandeln von UTF-8 in UCS-2 würde ich unter Windows MultiByteToWideChar benutzen, aber du wolltest ja eine portable Lösung. Da kenne ich zur Zeit nichts anderes außer boost. Es hilft, gelegentliche Ausrutscher unter der Wahrnehmungsschwelle zu halten. Gegen Kindergartenkinder hilft es natürlich nicht, aber die sind selten. Die Warnung des arroganten Obermackers hat wohl nicht gereicht. Na dann...
-
Nein, nicht zusammenzählen. Genauso unter Beachtung der Stellenanzahl hintereinanderpacken wie vorher. Um mal bei deinem Beispiel zu bleiben: 700901001234567890131400 mod 97 = ? 70090100 mod 97 = 34 => 700901001234567890131400 mod 97 = 341234567890131400 mod 97 341234567890131400 ist jetzt schon eine Zahl, die in einen 64-Bit-Integer passt. Du kannst das aber auch noch weiter reduzieren: 341234567890 mod 97 = 19 => 341234567890131400 mod 97 = 19131400 mod 97 19131400 passt locker in einen 32-Bit-Integer.
-
Ich versuche nur, dir zu erklären, was das eigentliche Problem ist. Übrigens ist unser Wortfilter nicht dazu da, dass man ihn durch alternative Schreibweisen umgeht. Und bleib bitte sachlich. Betrachte dich als verwarnt. Ich kann nur annehmen, dass du mich nicht verstanden hast. Das klingt nach Strings suchen und vergleichen. Das ist von der Codierung unabhängig, solange beide Strings gleich codiert sind. Wenn es dann soweit ist, wäre es notwendig, sich Gedanken zu machen, ob du eine UTF-8-fähige Regex-Bibliothek findest oder alles nach UCS2/4 umwandelst. Was meinst du mit "normale Eingabe"? "mögen" ist ganz klar ein String, der als UTF-8 codiert und dann als ISO 8859-1 decodiert wurde. Nein, du hast mich wieder nicht verstanden. Deine Bemühungen (soweit ich sie verstanden habe) zielten darauf ab, dass du versucht hast, die vom Server empfangenen, UTF-8-codierten Daten in UCS2/4 umzuwandeln. Ich habe dich nur darauf hingewiesen, dass IRC nicht auf UTF-8 festgelegt ist, du also damit rechnen must, anders codierte Strings zu empfangen. Was konkret, steht in dem Wikipedia-Link. Nö, hast du nicht. Du hast erwähnt, dass du das verwendet hast, aber nicht, dass dabei die selben Probleme auftraten. Ich bin weder ein "Linux User" noch habe ich Linux irgendwie gelobt. Keine Ahnung, wo du das rausliest. Ich habe nur erwähnt, dass dir das Problem unter Linux nicht aufgefallen wäre. Wenn bei dir auch unter Linux Probleme auftraten, muss das an etwas anderem gelegen haben. Da ich deinen Code nicht kenne, kann ich dazu nicht mehr sagen. Vielleicht hat der Server just in diesem Moment mal nicht UTF-8 mit dir gesprochen. Entschuldige, die meisten, die hier mit "funktioniert nicht" auftauchen, möchten es zum Funktionieren bringen. Hellsehen kann ich leider nicht. Du wirst es mir überlassen müssen, was ich als Müll betrachte und entferne. Ja, Anfänger unterschätzen oft den Aufwand, den man betreiben muss, um mit allen Besonderheiten bestehender nicht standardisierter Software klarzukommen. Ich habe dir bereits eine Empfehlung gegeben, wie du weiter vorgehen sollst. Ob du das annimmst, ist deine Sache. Aber ich kann es auch nochmal etwas einfacher formulieren: Plan A: Speichere deine Vergleichs- und Suchstrings als UTF-8. Plan B: Benutze utf8_codecvt_facet aus der boost-Bibliothek.
-
Beachte, dass eine Kontonummer mit 10 Stellen zu groß für einen long sein kann, da muss ein 64-Bit-Datentyp her, z.B. unsigned __int64. Das Formatfeld sollte dann %I64u sein. Du musst außerdem darauf achten, dass die Teile deiner Prüfzahl die richtige Länge haben. Gegebenenfalls musst du (z.B. bei der Kontonummer) mit Nullen auffüllen! Du kannst das erreichen, indem direkt hinter dem % für das jeweilige Formatfeld eine Null, gefolgt von der Anzahl der Stellen angibst. Für die Kontonummer also beispielsweise %010I64u. Richtig, die Zahl ist zu groß, selbst für einen 64-Bit-Integer. Die Fließkommatypen helfen dir auch nicht weiter. Sie können zwar so große Zahlen speichern, sind dann aber in den hinteren Stellen ungenau. Hier können die Rechenregeln für Kongruenzen helfen. Es ändert nichts am Ergebnis, wenn du die Einzelteile deiner Prüfzahl schon vorher modulo 97 nimmst. Damit schrumpft die BLZ auf maximal 2 Stellen. Du kannst dasselbe Verfahren dann nochmal auf die gekürzte BLZ + angehängte Kontonummer anwenden, damit sollte die Gesamtzahl klein genug sein, dass sie in einen 32-Bit-Integer passt.
-
2005 oder 2008?
-
Der Unterschied mag nicht so groß sein, wie ich ihn dargestellt habe. Es geht mir darum, dass jon1991 das machen muss, wie er selbst schreibt. Er hat also von jemandem diese Aufgabe bekommen. Und dieser Jemand hat vermutlich ziemlich klare Vorstellungen davon, ob C++ oder C++/CLI verwendet werden soll. Insofern halte ich hier eine klare Abgrenzung für wichtig. Ja, das geht. Allerdings verlässt man mit GUI-Programmierung in WinAPI (also ohne .NET) sehr schnell den Bereich von "einfach".
-
Das ist schon mal eine falsche Schlussfolgerung. Der Grund des Problems ist ja, dass der Server gerade kein ASCII sendet. Sockets liefern dir ihre Daten immer als Strom von Bytes, daraus kannst du gar nichts über die Codierung der Daten ablesen. Was ist denn "normal"? In der ASCII-Codierung gibt es kein ö, es muss also eine andere Codierung verwendet werden. Falls der Vergleichsstring in deinem Quellcode steht, kommt es auf deinen Editor an, wie das Zeichen codiert wird. Du hättest übrigens dein Problem überhaupt nicht als solches wahrgenommen, wenn du unter Linux entwickelt hättest, weil da UTF-8 ein Quasi-Standard ist, damit dein Quellcode auch UTF-8-codiert wäre und die Strings damit gleich wären. Wenn du unter Linux in deinem Quellcode "mögen" schreibst, siehst du in Windows vermutlich auch "mögen". Das liegt nicht daran, dass UTF-8 irgendwie falsch oder nicht "normal" ist. Es liegt auch nicht daran, dass das ö als zwei Bytes codiert ist. Die seltsamen Zeichen rühren nur daher, dass die Daten falsch interpretiert werden. Schau dir mal deinen "normalen" Quellcode unter Linux an. Andersrum geht das nämlich auch schief: Wenn man deinen ISO 8859-1/Windows-1252-codierten Quelltext als UTF-8 interpretiert, steht da auch nicht mehr "mögen". Aber doch nur, weil dein Vergleichsstring eine andere Codierung hat. Bevor du dich jetzt komplett auf UTF-8 einschießt: Es gibt für IRC (noch) keine vorgeschriebene Zeichencodierung: Internet Relay Chat - Wikipedia, the free encyclopedia Es ist richtig, dass UTF-8 weit verbreitet ist, aber es könnte dir immer noch passieren, dass du anders codierte Daten empfängst. Ok, unter der Annahme, dass jeder andere Code, den du so findest, ohnehin falsch ist, und es eine einzig richtig Lösung gibt, die noch niemand sonst gefunden hat, kann man so argumentieren. Aber es lohnt sich manchmal auch, zu lernen, wie man fremden Code zum Laufen bringt. Die Frage ist doch: Willst du dich auf UTF-8 festlegen, und musst du noch etwas anderes tun als Strings vergleichen? Du schreibst zwar von "Bearbeiten", hast aber immer noch nicht genauer erklärt, was du mit den Strings tun willst. Solange es nur Vergleiche sind, und du dich mit UTF-8 zufrieden gibst, würde ich dir empfehlen, einfach deine Vergleichsstrings gleich in der passenden Codierung abzulegen, dann kannst du dir sämliche Umcodierungen zur Laufzeit sparen. Du kannst sie im Quellcode (also als Stringliterale) ablegen, wenn du einen UTF-8-fähigen Editor benutzt.
-
Das ist eine unzureichende Problembeschreibung. Wie willst du sie verarbeiten, und warum genau geht das nicht? Da du uns die Grundlagen, die zu dieser Erkenntnis geführt haben, nicht verrätst, kann man dazu erst mal nicht viel sagen. So sieht es aus, wenn man einen String, der eigentlich UTF-8-codiert ist, in einer falschen Codierung betrachtet. Der String an sich ist wohl in Ordnung. Nur die Funktion, die diesen Text daraus erzeugt hat, geht von einer anderen Codierung aus. Auch mit dieser Fehlerbeschreibung kann man nichts anfangen. Bevor du solche Unterscheidungen machst, solltest du selbst von "C/C++" wegkommen. Willst du C oder C++? "STL" (du meinst vermutlich die C++ Standard Library) und boost klingen nach C++, nicht nach C. Und was boost angeht: Gerade wegen ihrer Portierbarkeit sehe ich keinen Grund, diese Bibliothek zu ignorieren, zumal sie utf8_codecvt_facet anbietet. Wie gesagt, zuerst musst du genau beschreiben, was eigentlich das Problem ist, und warum du glaubst, dass eine Umkodierung nach UCS2/UCS4 eine Lösung für dieses Problem ist.
-
Dass du deinen Code nicht einfach irgendwohin schreiben sollst, sondern in Methoden von Klassen.
-
RichTextBox r = new RichTextBox(); r.LoadFile("test.rtf");[/code]