mit extern: undefined reference to _Dice1' ohne extern: error:Dice1' was not declared in this scope
mit forward declaration: error: `Dice1' was not declared in this scope

#include <iostream>
#include <stdlib.h>
#include "gamehandler.h"
#include "dice.h"
#include "board.h"
#include "piece.h"
#include "player.h"

using namespace std;

extern dice Dice1;
extern dice Dice2;
extern board Board;
extern player Red;

gamehandler GameHandler;
piece* piece_ptr[4];
player Purble;

gamehandler::gamehandler()
{
}

gamehandler::~gamehandler()
{
}

void gamehandler::run()
{
  player Red;
  board Board;
  dice Dice1;
  dice Dice2;

  cout << "Welcome" << endl;
  Board.setPieceToStart(piece_ptr[0]);
  GameHandler.nextCommand();
}

beim Erzeugen der Objekte wirft mir der Compiler natürlch keinen Error. Erst wenn ich auf diese dann zugreifen will.

wie zb hier:

void gamehandler::commandRoll()
{
  int roll = Dice1.roll() + Dice2.roll();
  cout << "You rolled [" << roll << "]" << endl;
  Board.movePiece(roll);
  GameHandler.nextCommand();
}

danke = )

hab erstmal eine Lösung gefundn.
Habe im header von gamehandler Zeiger für die jeweiligen Objekte deklariert. mit new dann die Objekte erzeugt und den Zeigern zugewiesen.

Was meinst du mit "den Zeiger zugewiesen"?

Hoffentlich nicht sowas:

// im Header
Dice *dice;

// im CC
void func(){
  Dice d;
  dice = &d;
}

void func2(){
  dice->roll();
}

sust schrieb:

Ich habs mit #include, extern und forward declaration versucht "hinzubiegen". Aber da ich scheinbar den genauen Unterschied dieser 3 Befehle noch immer nicht verstanden habe hat mir auch das nicht geholfen

Dann würde ich dir dringend raten, die Grundlagen noch einmal genau anzuschauen. Die von dir genannten Möglichkeiten (keine Befehle!) stellen drei komplett unterschiedliche Sprachmittel dar.

// .header
class gamehandler
{
  private:
    board* board_;
    dice* first_dice_;
    dice* second_dice_;
};

// .cpp
void gamehandler::run()
{
  board_ = new board;
  first_dice_ = new dice;
  second_dice_ = new dice;
}

@ nexus: Danke, nachdem ich mir die Frage heute nochmal durchgelesen habe wars mir irgendwie peinlich. Natürlich sind auch Objekte die ich in Methoden deklariere nur lokal bekannt, sollte ich eigentlich wissen. Bei Variablen die ich lokal anlege denk ich nichtmal darüber nach weil ichs einfach weiß, aber kaum erzeuge ich ein Objekt vergess ich die Grundlagen *confused*
Mit #include, extern und forward declaration hast du natürlich recht, sobald ich mein c++ Buch wiederhabe werd ich mich nochmal intensiv damit beschäftigen.

-------
Ein sehr ähnliches Problem habe ich nun wieder mit vektoren. (beschäftige mich zum ersten mal damit)

// .header
#include <string>
#include <vector>

#ifndef field_H
#define field_H

class piece;

class field
{
  protected:
    std::string print_name_;
    std::vector<piece* > pieces_;

  private:
    field(field &);

  public:
    field();
    field(std::string const print_name);
    virtual ~field();
    std::string& getPrintName();
    void setPieces(piece* piece);
    piece* getPieces();

    friend std::ostream &operator<<(std::ostream &ostr, field &field);

};

#endif

// .cpp
#include "field.h"
#include <iostream>

using namespace std;

field::field()
{
}

field::field(string const print_name) : print_name_(print_name)
{
}

field::~field()
{
}

std::string& field::getPrintName()
{
  return print_name_;
}

void field::setPieces(piece* piece)
{
  pieces_.push_back(piece);
}

piece* getPieces()
{
  cout << pieces_[0]->getPieceColor() << endl;
}

error: `pieces_' was not declared in this scope

Der Vektor "pieces_" ist im headerfile deklariert. In setPieces kann ich noch ohne Probleme ein Element hinzufügen und initialisieren.
Die für Testzwecke eingebaute Ausgabe in getPieces funktioniert allerdings nicht. Dort kennt er pieces_ scheinbar nicht.

danke schonmal : )

Grüssli

class field
{
    field(std::string const print_name);   // Das const hier ist unnötig, siehe Link unten
    virtual ~field();
    std::string& getPrintName();  // Man kann hier den String verändern, ist das beabsichtigt?
    void setPieces(piece* piece);
    piece* getPieces();

    friend std::ostream &operator<<(std::ostream &ostr, field &field);  // 2. Parameter sollte const-Referenz sein
};

Wegen dem const : Hier wurde die Sache sehr gut erläutert.

Ausserdem würde ich die Variablen nicht mit _ beenden, aber das ist natürlich Geschmackssache.

Tut mit leid das ich eure Zeit mit teils so "dummen" Fragen beanspruche.

Nexus schrieb:

Was den oberen Code betrifft: Wieso forderst du den Speicher nicht im Konstruktor an? Dann könntest du ihn mit delete im Destruktor wieder ordentlich freigeben. Du musst einfach aufpassen, wenn du die Klasse kopierst oder zuweist, müsstest du Copy-Ctor bzw. Zuweisungsoperator auch noch selbst implementieren.

Hm, ich könnts auch im Konstruktor machen. Aber wieso macht das einen Unterschied? Ich geb den Speicher auch so im Destruktor mit delete wieder frei, oder darf ich das dann nicht?
Die Klasse sollte und darf nicht kopiert werden. (Darum auch der Private Copy-Ctor, der dies hoffentlich vermeiden sollte)

private:
  field(field &);

Bedanke mich auch ganz Herzlich dass du mich auf meine Fehler beim verwenden(oder auch nicht verwenden) von const hingewiesen hast. Aus diesem grund hab ich gleich meine ganze Klasse gepostet und nicht nur stückweise Codeausschnitte, war mir sichher ich werd auf Fehler aufmerksam gemacht : )

Nexus schrieb:

Ausserdem würde ich die Variablen nicht mit _ beenden, aber das ist natürlich Geschmackssache.

Habs so als Codingstandard gelernt. Gibt halt keinen internationalen Standard denk ich mal, und ich komm zur Zeit mit diesem ganz gut zurecht *g*

Hm, ich könnts auch im Konstruktor machen. Aber wieso macht das einen Unterschied? Ich geb den Speicher auch so im Destruktor mit delete wieder frei, oder darf ich das dann nicht?

Es kommt eben drauf an, wann du die Variablen benötigst. Wenn du sowieso jedes Mal nach dem Konstruieren eines Objekts die run() -Methode aufrufst, könntest du es gerade so gut im Konstruktor machen. Aber falls das Objekt zuerst noch mit Nullpointern verweilen soll, ist es schon gut, wie du es machst