ich versuche mich grade an einem "simplen" Schiffeversenken-Spiel. Bis jetzt bin ich soweit, dass mir das Programm in ein bestimmtes Feld ein 'X' zeichnet (Abhängig der ausgewählten Positionen). Jetzt wollte ich es ein wenig erweitern und sage: "Die Klasse 'Schiff1' hat 3 Lebenspunkte, also trage doch bitte 3 Felder für das Schiff ein! Wenn 'Schiff1' 2 Lebenspunkte hat, dann trage doch bitte 2 Felder ein."

Ich dachte das wär einfach, indem ich eine for-Schleife benutze, jedoch scheint es komplizierter zu sein, als ich dachte.

CShip

struct SPositionShip
{
	int x;
	int y;
};

class CShip
{
private:
	unsigned int iLP;
	int iPosX;
	int iPosY;
public:
	CShip(int iPosX, int iPosY)
	{
		this->iPosX = iPosX;
		this->iPosY = iPosY;
		this->iLP	= 3;
	}
	~CShip() { }

	SPositionShip SetShip()
	{
		SPositionShip PosShip;
		PosShip.x = iPosX;
		PosShip.y = iPosY;
		return PosShip;
	}

	int GetLP()
	{
		return this->iLP;
	}
};

Main

int main()
{
	char acField[9][9];
	CShip Ship1(3, 5);
	std::vector<SPositionShip> PosShip;
	for(int i = 0; i < Ship1.GetLP(); i++)
	{
		SPositionShip PosBuffer;
		PosShip.push_back(PosBuffer);

		PosShip[i]	= Ship1.SetShip();
		PosShip[i].x += i;
		PosShip[i].y += i;
	}

	// Spielfeld zeichen
	for(int i = 0; i < 9; i++)
	{
		std::cout << "\n\n			";
		for(int j = 0; j < 9; j++)
		{
			for(unsigned int l = 0; l < PosShip.size(); l++)
			{
				if(i == PosShip[l].x - 1 && j == PosShip[l].y - 1) acField[i][j] = '#';
				else acField[i][j] = 'O';
			}
			std::cout << "  " << acField[i][j];
		}
	}

	_getch();
	return 0;
}

Naja aufjedenfall zeichnet er mir immernoch nur ein Feld ein. Warum weiß ich auch nicht Ich hoffe ihr könnt mir helfen

MFG

Tu 'mir und uns allen nen Gefallen und nenne deine Klasse ganz normal Ship und verwende nicht die ungarische Notation.

Darf ich dann auch fragen wieso?

for(int i = 0; i < 9; i++)
	{
		std::cout << "\n\n			";
		for(int j = 0; j < 9; j++)
		{
			for(int l = 0; l < PosShip.size(); l++)
			{
				if(i == PosShip[l].x - 1 && j == PosShip[l].y - 1)
				{
					acField[i][j] = '#';
					break;
				}
				else acField[i][j] = 'O';
			}
			std::cout << "  " << acField[i][j];
		}
	}

Hm okay, scheinst ja sehr selbstbewusst zu sein, wenn du sowas schreibst...

Er hat da nicht ganz unrecht. Es gibt viele gute Gründe die dagegen sprechen und wenige dafür. Siehe hier für eine ausführliche Begründung:
http://www.c-plusplus.net/forum/p1773551#1773551

Okay, ich habs selber gelöst. Hier nochmal die "fertige" for-Schleife.

Ach, ich wollte es mir gerade angucken. Was mir schonmal beim Querlesen aufgefallen ist:
1. Initialisierungsliste mal googlen und benutzen.
2. Wozu einen leeren Destruktor definieren? Deutet da drauf hin, dass du mal Destruktoren gesehen hast, aber nicht verstanden. Häufig wird so etwas auch von schlechten Lehrern weitergegeben. Was von beidem hier der Fall ist, musst du wissen.
3. Deine Methode SetShip macht ganz merkwürdige Sachen, die nicht zum Namen passen. Eher so eine Art GetPos von dem was es macht. Den Rückgabewert kannst du übrigens bei POD-structs auch direkt initialisieren mit SPositionShip PosShip ={iPosX, iPosY}; . Oder spendier der Position einen passenden Konstruktor.
4. Bei Klassenmethoden ist ein this-> implizit und nur nötig, um Namenskonflikte aufzulösen.

klucki9 schrieb:

Hm okay, scheinst ja sehr selbstbewusst zu sein, wenn du sowas schreibst...

Er hat da nicht ganz unrecht. Es gibt viele gute Gründe die dagegen sprechen und wenige dafür. Siehe hier für eine ausführliche Begründung:
http://www.c-plusplus.net/forum/p1773551#1773551

Okay, ich habs selber gelöst. Hier nochmal die "fertige" for-Schleife.

Ach, ich wollte es mir gerade angucken. Was mir schonmal beim Querlesen aufgefallen ist:
1. Initialisierungsliste mal googlen und benutzen.
2. Wozu einen leeren Destruktor definieren? Deutet da drauf hin, dass du mal Destruktoren gesehen hast, aber nicht verstanden. Häufig wird so etwas auch von schlechten Lehrern weitergegeben. Was von beidem hier der Fall ist, musst du wissen.
3. Deine Methode SetShip macht ganz merkwürdige Sachen, die nicht zum Namen passen. Eher so eine Art GetPos von dem was es macht. Den Rückgabewert kannst du übrigens bei POD-structs auch direkt initialisieren mit SPositionShip PosShip ={iPosX, iPosY}; . Oder spendier der Position einen passenden Konstruktor.
4. Bei Klassenmethoden ist ein this-> implizit und nur nötig, um Namenskonflikte aufzulösen.

1.] Okay
2.] Ja wurde mir so beigebracht, was soll denn sonst da rein? Alles auf NULL setzen?
3.] Ja das ist mir auch aufgefallen. Ich hätte auch einfach GetPosX und GetPosY als funktionen definieren sollen und einfach in der main()-Funktion mit der Struktur binden sollen:

SPositionShip PosShip1
PosShip1.x = Ship1.GetPosX();
PosShip1.y = Ship1.GetPosY();

oder wie meinst du das?
4.] Ja ich weiß, ist es schlimm, es trotzdem zu machen (aus übersichtlichen Gründen)?

Danke dir

Hm okay, scheinst ja sehr selbstbewusst zu sein, wenn du sowas schreibst... Naja, aber das ist hier nicht das Thema. Vielleicht kannst du mir ja mal helfen :p

Gewoehn dich dran, 314159265358979 traegt generell nichts zum Thema bei, sondern ist immer auf der Suche nach Fehlern oder anderen Sachen die er dem Threadsteller auf die Nase binden kann.

2.] Ja wurde mir so beigebracht, was soll denn sonst da rein? Alles auf NULL setzen?

Nein bloß nicht. Lass es einfach ganz weg.

Hmm. Ungarische Notation, Destruktoren nicht verstanden. Wechsel lieber den Lehrer. Lieber nichts gelernt, als falsch gelernt.

3.] Ja das ist mir auch aufgefallen. Ich hätte auch einfach GetPosX und GetPosY als funktionen definieren sollen und einfach in der main()-Funktion mit der Struktur binden sollen:

SPositionShip PosShip1
PosShip1.x = Ship1.GetPosX();
PosShip1.y = Ship1.GetPosY();

oder wie meinst du das?

Kommt es dir nicht etwas komisch vor, erst ein neues Objekt anzulegen, dann Wert für Wert dessen Attribute zu setzen und es dann zurück zu geben, anstatt z.B. gleich das richtige zurück zu geben?

4.] Ja ich weiß, ist es schlimm, es trotzdem zu machen (aus übersichtlichen Gründen)?

Nein, das ist in Ordnung, wenn's dadurch besser lesbar ist.