Ich versuche gerade einen Vector mit Pointern zu meinem eigenen Objekt zu erstellen, diesen Vector packe ich in ein Array:

std::vector<Piece*> m_allPieces[2];

Das Problem ist, wenn ich mein Programm so kompiliere erhalte ich einen Memory Error und das ganze stürzt ab ^^

Wie soll ich das jetzt lösen? Vector in Vector???

Hab grade herausgefunden, dass das ganze gar nicht an dem Array liegt, wenn ich einen Vector deklariere im Header, stürzt das Program sofort ab... aber zum Beispiel ein Iterator funktioniert (Kann ihn schlecht benutzen oder einen vector xD)

Aber ich erhalte nun eine Fehlermeldung: (Windows Meldung)

Ausnahme: std::bad_alloc

hmm

Ich versuche gerade einen Vector mit Pointern zu meinem eigenen Objekt zu erstellen, diesen Vector packe ich in ein Array:

Tönt kompliziert. Was willst du genau erreichen (was, nicht wie)?

Dein Fehler liegt nicht in der Verwendung von vector-Arrays an sich. Das ist kein Problem. Folglich machst du bei deren Verwendung irgendwas falsch.

Nunja ich verwende mein Vector noch gar nirgends, ich deklariere ihn bloss im Header...

Ich werde versuchen eine genauere Fehlermeldung rauszubekommen ^^

Nunja ich verwende mein Vector noch gar nirgends, ich deklariere ihn bloss im Header...

Dann liegt es sicher nicht daran. Zeige doch mal etwas Code.

Und es wäre gut, wenn du noch auf meine obere Frage eingehen könntest.

Samyboy schrieb:

Ich versuche gerade einen Vector mit Pointern zu meinem eigenen Objekt zu erstellen, diesen Vector packe ich in ein Array:

Tönt kompliziert. Was willst du genau erreichen (was, nicht wie)?

Nunja ich versuche alle meine Schachfiguren in ein Array von 2 Vectoren zu speichern (alle Weisse in m_allPieces[0] und alle Schwarzen in m_allPieces[1], weil WHITE und BLACK konstante 0 und 1 sind...)

Danach möchte ich sie einzeln ansprechen können, um die Position herauszufinden und so weiter...

Ich könnte natürlich mein "main-board" Array durchlaufen, aber da hab ich halt die Schwarzen und Weissen Figuren nicht getrennt...

2 vector<Piece*>
2 vector<Piece*>::iterator
1 vector<Piece*> und 1 vector<Piece*>::iterator

Hier mal meine Board Klasse, die betroffen ist:

class Board {
    public:
        Board();
        ~Board();

        void Draw(sf::RenderWindow* window);
        bool MoveIsLegal(int move[2][2], unsigned int& player);
        void DoMove(int move[2][2]);
        void Reset();
        void AddPiece(Piece* piece, int position[2]);
        Piece* GetPosition(int position[2]);

        // std::vector<Piece*> GetThreateningPieces(int position[2]);

    private:
        Piece* m_board[8][8];
        std::vector<Piece*> m_allPiecesWhite;
        // std::vector<Piece*> m_allPiecesBlack; // Wenn das kein Kommentar ist stürzts ab!
        // std::vector<Piece*>::iterator iter;
        char m_boardWithLetters[8][8];
        void DeletePiece(int position[2], int color);
};

Wenn ich sonst noch Code zeigen soll, bitte sagen! Bin echt dankbar für jede Hilfe, bin jetzt schon etwa ne Stunde dran :p

Meine Glaskugel sagt aber, dass du bestimmt was falsch machst bei der Pointerfrickelei.

Empfohlener Ansatz zur Problembehebung: Schmeiß alles weg. Überdenke dein Schachproblem. Mach ein neues, sauberes Design. -> Proft!

Das ist zwar grauenhaftes Design, aber an sich noch kein Fehler.

Meine Glaskugel sagt aber, dass du bestimmt was falsch machst bei der Pointerfrickelei.

Empfohlener Ansatz zur Problembehebung: Schmeiß alles weg. Überdenke dein Schachproblem. Mach ein neues, sauberes Design. -> Proft!

Könnteste bitte konkret werden mit Design?

Ich habe das Gefühl das ÜBERHAUPT NICHTS lesbar ist bei meinem Schachprogramm, und ans neu machen hab ich auch schon gedacht ^^

Könnteste bitte konkret werden mit Design?

Ja, wenn du mit deinen Anforderungen konkret wirst. Was soll das Programm denn können?

Samyboy schrieb:

Könnteste bitte konkret werden mit Design?

Ja, wenn du mit deinen Anforderungen konkret wirst. Was soll das Programm denn können?

Naja, ich meinte was vom Design her schlecht ist bei dieser Klasse

Und noch etwas, komischerweise kann ich einen Vector deklarieren, auch ohne #include <vector>? (trotzdem können nicht mehrere vectoren deklariert werden (auch nicht in einem Array z.B), sonst stürzt das ganze ab) Ich glaube die SFML Library nervt da irgendwie die Vectoren oder so oO

Sehr, sehr komisch -.-

(Falls es jemanden was bringt, ich werde nicht schlau draus, leider keine Zeilen angegeben xD)

Eine Ausnahme (erste Chance) bei 0x778d3913 in SMFL.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0x20202020.
Eine Ausnahme (erste Chance) bei 0x778d3913 in SMFL.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0x20202020.
Eine Ausnahme (erste Chance) bei 0x778d3913 in SMFL.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0x20202020.
Eine Ausnahme (erste Chance) bei 0x76f3b727 in SMFL.exe: Microsoft C++-Ausnahme: std::bad_alloc an Speicherposition 0x0044f514..
Eine Ausnahme (erste Chance) bei 0x6780fd85 in SMFL.exe: 0xC0000005: Zugriffsverletzung beim Schreiben an Position 0x00000000.
Unbehandelte Ausnahme bei 0x6780fd85 in SMFL.exe: 0xC0000005: Zugriffsverletzung beim Schreiben an Position 0x00000000

SeppJ schrieb:

Samyboy schrieb:

Könnteste bitte konkret werden mit Design?

Ja, wenn du mit deinen Anforderungen konkret wirst. Was soll das Programm denn können?

Naja, ich meinte was vom Design her schlecht ist bei dieser Klasse

Wie du schon selbst schreibst, ist dein Programm praktisch unlesbar. Außerdem fuchtelst du ohne erkennbaren Grund mit rohen Pointern rum, was gerade bei unerfahrenen Programmierern fast immer schief geht, so auch bei dir. Ich werde mir mal kurz Gedanken machen wie ich ein Schachbrett mit deinen Methoden modellieren würde. Melde mich in ein paar Minuten wieder.

Samyboy schrieb:

SeppJ schrieb:

Samyboy schrieb:

Könnteste bitte konkret werden mit Design?

Ja, wenn du mit deinen Anforderungen konkret wirst. Was soll das Programm denn können?

Naja, ich meinte was vom Design her schlecht ist bei dieser Klasse

Wie du schon selbst schreibst, ist dein Programm praktisch unlesbar. Außerdem fuchtelst du ohne erkennbaren Grund mit rohen Pointern rum, was gerade bei unerfahrenen Programmierern fast immer schief geht, so auch bei dir. Ich werde mir mal kurz Gedanken machen wie ich ein Schachbrett mit deinen Methoden modellieren würde. Melde mich in ein paar Minuten wieder.

Nunja, sollte man nicht möglichs jedes Objekt auf dem Heap speichern und dann die Pointer herumschicken?

Nunja, sollte man nicht möglichs jedes Objekt auf dem Heap speichern und dann die Pointer herumschicken?

Nein, auf keinen Fall! Denk dran, Value-Semantik ist gut. Benutze möglichst automatische Objekte. Wenn du besitzende Zeiger brauchst, kapsle sie (Smart-Pointer, Pointer-Container oder ähnliches). Aber im Anwendungscode sollte new und delete so wenig wie nur möglich auftauchen.

#include <vector>
#include <cassert>

enum Color{white, black};
enum Value{empty, pawn, knight, bishop, rook, queen, king};

// A set of coordinates on a chess board
class Coordinates
{
private:
  unsigned rank, file;
public:
  Coordinates(unsigned x, unsigned y): file(x), rank(y)
  {
    assert(x<8);
    assert(y<8);
  };

  // Checks if other square is a valid move for a <v> from this coordinate:
  bool valid_move(Value v, Coordinates c) const;

};

class Square
{
private:
  // What kind of piece is on the square?
  Value i_value;
  // The color of the piece on the square. Ignored if value is empty.
  Color i_color; 

public:
  Square(Value v, Color c=white): i_value(v), i_color(c){};

  // Draw the piece on output
  void draw(sf::RenderWindow* window) const;

  void set(Value v, Color c=white);

  // Getter:
  Value get_piece();
  Color get_color();
};

// A chessboard
class Board
{
private:
  std::vector<Square> i_squares[64];
  // Returns reference to square at coordinates
  Square& at(Coordinates c);
public:
  // Draws a chessboard and calls draw for all squares
  void draw(sf::RenderWindow* window) const;

  // Set piece at position
  void AddPiece(Coordinates coordinates, Value v, Color c=white);

  // Check if move is legal for player
  bool MoveIsLegal(Coordinates from, Coordinates to, Color player) const;

  // Move a piece
  void DoMove(Coordinates from, Coordinates to);

  // Sets all squares to empty
  void Reset();

  // Resets all squares to the initial value for a standard game
  void InitialPosition();

};

std::vector<Square> i_squares[64];

ein (ganz) gutes Design.

SeppJ, du meinst wohl eher, daß der vector mit 64 Feldern (Square) initialisiert wird, und nicht, daß du 64 vectors erzeugst?

Und Coordinates::valid_move() wird ohne Zugriff auf das Schachbrett auch nicht sehr sinnvoll sein (d.h. z.B. bei Bauern und Königen ist auch die Farbe entscheidend).

Und ich würde auch noch die Trennung von GUI (SFML) und Logic (ChessBoard) vornehmen...

Nunja, sollte man nicht möglichs jedes Objekt auf dem Heap speichern und dann die Pointer herumschicken?

Wenn ein Objekt erst einmal mit new angelegt wurde ist alles was von diesem Objekt ausgeht (Member) automatisch im Heap und nicht im Stack des Programms (des main-Funktionsaufrufes). Geht gar nicht anders. Nur wenn du etwas dann mit new anlegst ist es eben ein beliebiger Speicherbereich und nicht mehr zusammenhängend.

Bis auf

std::vector<Square> i_squares[64];

ein (ganz) gutes Design.

SeppJ, du meinst wohl eher, daß der vector mit 64 Feldern (Square) initialisiert wird, und nicht, daß du 64 vectors erzeugst?

Ups, ähh, ja.

Und Coordinates::valid_move() wird ohne Zugriff auf das Schachbrett auch nicht sehr sinnvoll sein (d.h. z.B. bei Bauern und Königen ist auch die Farbe entscheidend).

Ich hatte mir gedacht, dass die Methode Board::MoveIsLegal() das macht und dabei Coordinates::valid_move() benutzt um überhaupt zu prüfen, wohin gegangen werden kann. Ist sicherlich noch suboptimal, da ich mir nicht wirklich Gedanken gemacht habe, wie man das implementieren würde.

Und ich würde auch noch die Trennung von GUI (SFML) und Logic (ChessBoard) vornehmen...

Ahh, die Urfrage der Spieleprogrammierung. Irgendwie konnte mir nie jemand sagen, welche Vorgehensweise besser ist (ich programmiere aber auch nicht viele Spiele). Ist momentan die Trennung von Logik und Darstellung wieder in?

Ist momentan die Trennung von Logik und Darstellung wieder in?

Ich glaube dies war eigentlich nie out. Wobei man abwägen muss: Ist Wartbarkeit und Portierbarkeit wichtiger als der zusätzliche Aufwand?

Ich arbeite derzeit in einem Projekt, wo es besser gewesen wäre auf ersteres zu setzen. Eine nachträgliche Änderung ist in loser gekoppelten Systemen immer einfacher als in fest "verdrahteten" Systemen. Selbst wenn es nicht um den Austausch der Ausgabeform geht, sondern nur der Anpassung.

Ich guck mir das ganze mal in RUhe an

Ahh, die Urfrage der Spieleprogrammierung. Irgendwie konnte mir nie jemand sagen, welche Vorgehensweise besser ist (ich programmiere aber auch nicht viele Spiele). Ist momentan die Trennung von Logik und Darstellung wieder in?

Ich bevorzuge die Trennung ganz klar (zumindest sobald ein Projekt etwas grösser ist). Ich denke, der Aufwand ist nur gerade am Anfang höher, wenn man eine Schnittstelle einrichten muss, die eine Verbindung von Logik- und Grafikobjekten herstellt. Aber ich sehe ab und zu Leute, die das nicht so genau nehmen. Oft sind das auch jene, die sich mehr für fertige Spiele als unnötige technische Details wie C++ interessieren.

Aber auch bei fortgeschrittenenen Programmierern sieht man diese Vorgehensweise nicht selten. Natürlich kann es Fälle geben, in denen eine Trennung unangebracht ist. Doch meiner Meinung nach ist der Hauptgrund einfach oft eine kurzsichtige Denkweise (betrifft übrigens generell Designfragen).

Aber auch bei fortgeschrittenenen Programmierern sieht man diese Vorgehensweise nicht selten.

Logisch wenn die Planung nur auf schnelle Ergebnisse ausgelegt ist. Im Endeffekt wird es aber für alle teurer. Sei es nun, weil nicht erwartet wurde das man später nochmal auf das Design aufsetzen muss, sei es weil ein Projekt einen deutlich längeren Lebenszyklus erfährt, oder weil man den Kunden immer alle Wünsche gestern erfüllen will.

Es wird blauäugig an Projekte herangegangen. Die Faulheit einiger Programmierer fördert dies zusätzlich (Warum den Aufwand betreiben "unnötige" Dokumentationen zu verfassen, Schichtentrennungen vorzunehmen oder "unsinnige" Diskussionen am Tisch durchzuführen). Das Ergebnis ist zwar vielleich (wenn alles gut geht) tatsächlich schneller auf dem Weg zum Kunden, aber in der Regel dauert die Fehlerkorrektur, der Einbau neuer Features etc. immer länger.

Am Schluß hat man ein Flickenteppich. Ein Programm das nach außen hin wie ein schillerndes 200-Etagen Hochhaus mit Hightech-Glasaufzug aussieht, aber sich im inneren auf eine morsche Bruchbude aufstützt, bei der Fehler seltener behoben als "umschifft" werden, da die Zeit zum Beheben nicht eingeräumt wird.

Nexus schrieb:

Natürlich kann es Fälle geben, in denen eine Trennung unangebracht ist. Doch meiner Meinung nach ist der Hauptgrund einfach oft eine kurzsichtige Denkweise (betrifft übrigens generell Designfragen).

Vollkommen richtig. Der Haken daran ist nur, das solche "hirnrissigen", "idealistischen" Gedankengänge ja nur von den "Programmierern" stammen können, die über "keinerlei wirtschaftliches Denkvermögen" verfügen.

Ich behaupte das mancherlei Programmierer/Softwareentwickler mehr Ahnung von einer sinnvollen Projektplanung haben, als Manager. Ein Erfolg einer Software setzt sich halt nicht nur aus dem schnellen "Cashflow" zusammen, sondern auch langfristigeren Aspekten wie Kundenzufriedenheit und teilweise daraus resultierender Kundenbindung.

Was aus einem einfachen Satz für eine Diskussion entstehen kann

P.S: asc, ich stimme dir voll zu!

Hier noch ein Auszug aus einem Skript, daß ich mal verfasst hatte (leider hatte der Verlag damals die dafür angedachte Buchreihe eingestellt):

Th69 schrieb:

Als Entwickler sollte man ein Programm nicht zu starr konstruieren, da sich sonst Sonderwünsche und notwendige Erweiterungen nur widerwillig einbringen lassen. Ein Architekt, der nicht weiß, daß sein Haus auf unebenen Grund gebaut wird, kann nach dem Bau auch keine Änderungen mehr vornehmen, außer das Haus abzureißen und wieder von vorn anzufangen. Genau diese Vorgehensweise habe ich in der Praxis jedoch schon oft erlebt - das kostet Zeit und viele, viele Nerven.