Vector in einer Klasse?

[Raidenkk]

Hey,
ich wollte gerade in meiner Spawner Klasse mein vector<CKugel> Kugeln; implementieren bis da Stand das Vector keine Vorlage ist.
Jemand anderes aber meint zu mir das es gehen würde? mache ich was falsch oder kann man einfach keine Vector als Membervariable dekladieren?

[Aramis]

Klar geht das. <vector> inkludieren und dann std::vector - oder, boese, using namespace std; drueber.

[Raidenkk]

ahh habe std völlig vergessen auh man ich sollte mal schlafen gehen -.-!

[kaiserludi]

"da Stand das Vector keine Vorlage ist"
Das hört sich so an, als ob du eine deutschsprachige Version von Visual Studio oder Visual C++ Express Edition benutzt. Ich würde dir empfehlen, auf die englischsprachige umzusteigen, einfach weil die Suchmaschine deiner Wahl dir dann viel mehr nützliche Ergebnisse für Fehlermeldungen oder auch für Menüpunkte, Settings, usw. ausspuckt.

[dot]

+1

[Raidenkk]

Werde ich bald machen wollte nach dem BloopIt Projekt mein PC eh Formatieren.

[Raidenkk]

Meine klasse CKugel funktioniert in meiner main.cpp ganz gut aber sobald ich die Klasse in einem Vector stecke wird anscheinend keine wichtigen Daten mit gespeichert, liegt das vielleicht daran das ich meine Klasse falsch an dem Vector gebe oder aufrufe?

// CKugek Klasse Konstruktor

Code: Alles auswählen

// Konstruktor
CKugel::CKugel (int Farbe, int X, int Y)
{
	// Startwerte setzen
	m_Farbe = Farbe;
	m_X = X;
	m_Y = Y;
	m_AnimX = 0;
	m_AnimY = 0;

	// Image laden
	switch (Farbe)
	{
		// Weis
		case 0:
		{
			m_Image.LoadFromFile ("gfx/Spiel_Kugel_Weis.png");
		} break;
	}

	// Sprite setzen
	m_Sprite.SetImage (m_Image);
}

// CKugel in einem vKugeln Vector stecken.
CSpieler.cpp

Code: Alles auswählen

if (Spielfeld[m_X/64][m_Y/64] == 0)
		{
			Spielfeld[m_X/64][m_Y/64] = 1;
			vKugeln.push_back (CKugel(0,100,10));
			Kugel_Anzahl ++;
		}

// Kugeln wieder aufrufen.
// CSpielfeld.cpp

Code: Alles auswählen

// Kugeln Zeichnen
	for (int i=0; i<m_Kugel_Anzahl; i++)
	{
		m_vKugeln.at(i).Zeichnen (Game);
	}

MFG:
Kevin/Raidenkk

[Schrompf]

Wie lauten die Fehlermeldungen?

[Raidenkk]

Es gibt keine Fehlermeldung nur anscheinend wird mein Sprite von der Klasse CKugel nicht in den Vector gespeichert und die X,Y Koordinaten alle auch nicht, halt alle Membervariablen von meiner Klasse CKugel die in einem Vector sind. Sobald ich mit

Code: Alles auswählen

// Kugeln Zeichnen
for (int i=0; i<m_Kugel_Anzahl; i++)
{
m_vKugeln.at(i).Zeichnen (Game);
}

Die Kugeln aufrufen möchte wird nur ein Weißes Feld gezeichnet obwohl es eine Kugel sein sollte und die X,Y Koordinaten werden auch nicht gespeichert weil dieses Weiße Feld immer bei 0,0 steht.

[Schrompf]

Visual Studio? Setze mal mit F9 einen Breakpoint auf die Zeichnen-Schleife und schau Dir den Inhalt der Variablen an. So rein vom Schauen her würde ich vermuten, dass m_Kugeln_Anzahl 0 ist, weil Du in dem Code-Schnipsel oben eine andere Variable "Kugeln_Anzahl" erhöhst.

Nebenbei: die Kugel-Anzahl brauchst Du nicht mitzurechnen, weil jeder Vector die Anzahl der gespeicherten Elemente kennt. Nimm also in der Schleife besser ein "i < m_vKugeln.size();" als Abbruchbedingung.

Probiere aber trotzdem erstmal das Debuggen. Debuggen ist extrem wichtig für Deine weitere Programmierer-Tätigkeit. Je eher Du das drauf hast, desto schneller und einfacher findest Du Deine Fehler und kommst vorwärts.

[Raidenkk]

Hey nein m_Kugel_Anzahl und Kugel_Anzahl ist das gleiche nur alles was m_Kugel_Anzahl ist bedeutet soviel wie das es die Membervariable für die Klasse ist und alles was Kugel_Anzahl ist wurde von einem Parameter geholt z.b. xD danke ich habe total vergessen das Vector seine eigene Größe feststellen kann. Die Koodinaten werden jetzt gespeichert ich habe vergessen im Konstruktor die erhaltenen Koodinaten mit m_Spirte.SetPosition (m_X, m_Y); zu setzen. Doch das Sprite wird noch nicht gezeichnet da habe ich noch ein Weißes Feld, mal schauen was ich mit dem Breakpoint rauskitzeln kann.

[Raidenkk]

Jetzt bin ich total verwirrt wenn ich meinem Sprite kurz vor dem Zeichnen meiner Kugel zuweise Zeichnet er die Kugeln.

// Überladener Konstruktor
CKugel::CKugel (int Farbe, int X, int Y)
{
// Startwerte setzen
m_Farbe = 0;
m_X = X;
m_Y = Y;
m_AnimX = 0;
m_AnimY = 0;

// Image laden
switch (m_Farbe)
{
// Weis
case 0:
{
m_Image.LoadFromFile ("gfx/Spiel_Kugel_Weis.png");
} break;
}

// Sprite setzen
m_Sprite.SetImage (m_Image);
m_Sprite.SetPosition (m_X, m_Y);
}


// Zeichnen
void CKugel::Zeichnen (sf::RenderWindow &Game)
{
m_Sprite.SetImage (m_Image); // <--- Wird das hier auskommentiert werden die Kugeln nicht gezeichnet.
Game.Draw (m_Sprite);
}

Dabei wird doch das Sprite im Konstruktor zugewiesen....

[EyDu]

Hallo.

Da du offensichtlich noch ganz am Anfang stehst, gebe ich dir mal ein paar Hinweise zu deinem Code. Da kann noch einiges besser geamacht werden. Ich arbeite mich bei deinem Post einfach mal von oben nach unten durch:

Es ist löblich, dass du deinen Code kommentierst, aber Hinweise wie "//Konstruktor", "//Startwerte setzen" oder "Sprite setzen" sind überflüssig. Jeder erkennt auf den ersten Blick, dass es sich um einen Konstruktor handelt, oder dass eine Reihe von Variablen initialisiert wird. Beschränke dich also auf beschreibende Kommentare, welche einen Mehrwert zum Code liefern.

Membervariablen solltest du im Konstruktor in der Initialisierungsliste setzen und nicht per Zuweisung. Bei deinem Beispiel also konkret:

Code: Alles auswählen

CKugel::CKugel(int farbe, int x, int y)
    : mFarbe(farbe)
    , mX(x)
    , mY(y)
    , mAnimX(0)
    , mAnimY(0)
{
}

Das macht die ganze Sache gleich übersichtlicher.

Weiter ist mir aufgefallen, dass du keine Einrückung verwendest. Durch die Klammerung ist dies zwar nicht notwendig, es schafft aber ungemein viel an Übersicht. Auch solltest du keine deutschen und englischen Namen mischen. Entscheide dich einfach für eine Sprache. Außerdem fällt mir die inkonsistente Namensgebung bei dir auf. Mal benutzt du zum Trennen einen Unterstrich (Kugel_Anzahl), mal tust du es nicht (m_AnimX). Ich weiß nicht, welcher Formatierungsstandard momentan für C++ aktuell ist/sind, aber das wird dir hier sicher jemand sagen können. Die vielen Unterstriche und Namen welche mit Großbuchstaben beginnen sind mir so in C++-Code jedoch noch nicht untergekommen.

Auch dein switch/case-Statement mit der inneren Klammerung und dem äußeren break finde ich etwas seltsam. Zumal du nur eine Farbe hast. Statt magische Nummber zu verwenden, wie hier die 0 für Weiß, solltest du besser enums benutzen. Dann kannst du Namen vergeben und hast diesen zentral an einer Steller. Außerdem weißt dich der Comiler dann darauf hin, falls du bei einem switch-Statement einen Fall übersehen hast.

Die magischen Zahlen ziehen sich bei dir aber noch weiter durch den Code. Du benutzt mehrfach das "/64". Was ist, wenn du aus der 64 mal eine 128 machen willst? Dann müsstest du deinen gesamten Code durchgehen und ersetzen. Das ist nicht nur nervig und zeitaufwendig, du wirst dir mit sicherheit auch schwer zu findende Fehler einbauen. Durch den fehlenden Namen wirst du wahrscheinlich in vier Wochen selber nicht mehr wissen für was so manche Nummer steht. Gewöhne dir also an, solche dinge global zu machen und mit einem ordentlichen Namen zu versehen. Dann hast du genau eine Stelle an der du Änderungen durchführst und die Chancen für Fehler sind minimal.

Wie du ja bereits gemerkt hast, haben Vektoren die Größeninformation bereits enthalten. Entferne daher die überflüssige Variable aus deinem Code. In diesem Fall brauchst du aber nicht einmal die Anzahl der enthaltenden Elemente, da man in C++ mittels Iteratoren über Vektoren iteriert und nicht mittels Indizes:

Code: Alles auswählen

for(std::vector<CKugel>::const_iterator it=mKugeln.begin(); it!=mKugeln.end(); ++it) {
    const CKugel & kugel = *it;  //diese Zeile könnte man sparen
    kugel.zeichnen(spiel)        //wenn  man hier it->zeichnen(spiel) verwendet
}

Natürlich sollte man dem Kugel-Vektor mittels

Code: Alles auswählen

typedef std::vector<CKugel> Kugeln

noch einen vernünftigen Namen geben. Das ist nicht nur aussagekräftiger, sondern spart auch einiges an Schreibarbeit (Kugeln::const_iterator, statt std::vector<CKugel>::const_iterator) und ist natürlich viel flexibler.

Sebastian

[BeRsErKeR]

Außerdem fällt mir die inkonsistente Namensgebung bei dir auf. Mal benutzt du zum Trennen einen Unterstrich (Kugel_Anzahl), mal tust du es nicht (m_AnimX). Ich weiß nicht, welcher Formatierungsstandard momentan für C++ aktuell ist/sind, aber das wird dir hier sicher jemand sagen können. Die vielen Unterstriche und Namen welche mit Großbuchstaben beginnen sind mir so in C++-Code jedoch noch nicht untergekommen.

Da scheiden sich die Geister. Ich wüsste nicht, dass es da sowas wie einen einheitlichen Standard gibt. Wichtig ist eigentlich, wie du sagst, eher dass man es für seinen Code einheitlich macht. Ich orientiere mich z.B. an der STL und an gtkmm. Qt macht es aber z.B. schon wieder anders und auch die WinAPI und und und.

[Artificial Mind]

Auch dein switch/case-Statement mit der inneren Klammerung und dem äußeren break finde ich etwas seltsam.

Deine Tipps sind an sich gut, nur hier möchte ich anmerken, dass es durchaus Sinn gibt, eine "innere" Klammerung zu haben, da break keinen neuen scope einführt (faktisch ja eigentlich auch nur ein label ist) und man deswegen immer sehr schnell Probleme bekommt, wenn man gleichnamige Variablien im "break-scope" einführt. Diese müsste man dann am Anfang vom switch deklarieren und das zerstört wieder die Code-Lokalität. Ich bin deswegen auch mittlerweile auf diese "innere Klammerung" umgestiegen.

[Raidenkk]

Sowas nenne ich mal coole Tipps nur das Swicht / Case verwirrt mich wie sollte es denn aussehen wenn ich keine Klammern nutze 0o?

[EyDu]

Die verwendete Formatierung kommt mir nur sehr seltsam vor, da sie sehr reduntant und unübersichtlich wirkt. Ich würde mich bei so etwas auch immer an größere Projekte wie Qt oder die STL halten. Als typisch würde ich etwa "CamelCase" für Typen sehen, "pascalCase" für Funktionen und Variablen und die ungarische Notation ist meines Wissen, bis auf das m-Prefix, ganz schön aus der Mode geraten.

Die Einführung eines neuen Scopes mittels Klammern in switch/case-Statements ist mir bekannt, bei einer einzelnen Zeile finde ich das aber etwas übertrieben. Meine Faustregel ist eher: wenn ich einen neuen Scope innerhalb eines "case"s erzeugen muss, dann wird es höchste Zeit über die Aufteilung in Funktionen nachzudenken. Ist aber eher persönlicher Geschmack und manchmal will man natürlich wirklich nur eine lokale Variable erzeugen um der Berechnung einen Namen zu geben.

[Raidenkk]

@EyDu ich habe nur 50% verstanden da die begriffe Scope/CamelCase/PascalCase für mich Fremdwörter sind.

EDIT:
Ich benutze übrigens alles so wie ich es in dem Buch "C++ für Spieleprogrammierer" gelernt habe und finde es etwas komisch das mir aufeinmal gesagt wir das es sozusagen für die Katz war...
Außer natürlich das mit meinem Deutsch-Englisch das sollte ich mir wirklich abgewöhnen oder meine 2arten von Variablen int m_SpielerX / int m_Spieler_X.

[EyDu]

Es ist ja nicht alles falsch was du gelernt hast, es gibt nur bessere Wege um ans Ziel zu kommen ;-)


Scope = Namensraum
CamelCase = DerErsteBuchstabeJedesWortsWirdGrossGeschrieben
pascalCase = derErsteBuchstabeKleinDannAlleAnfangsbuchstabenGross

Das hättest du aber auch leicht mit Google rausfinden können ;-)

[Raidenkk]

Stimmt aber du hast das so schön aufgelistet das Google es nicht wirklich besser machen hätte können :D

EDIT:
Ich habe jetzt mein 2 Tages Projekt komplett gelöscht und fange jetzt nochmal an, weil wenn will ich es richtig machen. Auch wenn es jetzt schon das 3 mal ist..

[kaiserludi]

Zu den switch-cases:
Ich handhabe es so, dass da nur innere Klammern drum kommen, wenn sie benötigt werden, was meist der Fall ist, wenn eine lokale Variable nötig ist, z.B. weil eine im Case aufgerufene Methode eine Adresse als Parameter erwartet.
Ich empfehle aber auf jeden Fall, immer einen default-case am Ende des switches zu haben, um unerwartetes verhalten abzufangen.
Das geht bei mir sogar soweit:

Code: Alles auswählen

int foo = rand()%2;
switch(foo)
{
    case 0:
        // do something
        break;
    case 1:
        // do something different
        break;
    default:
        assert(false); // should not be possible to happen, perhaps the programm has been executed in a parallel universe with different mathematic laws?
        break;
}

Die Schreibweise von Bezeichnern handhabe ich so:
ClassName/StructName
primitveTypeName (der Konsistenz halber weil die spracheigenen Typen auch keinen großen Anfangsbuchstaben haben)
objectVariableName / primitiveVariableName
globalFunctionName / memberMethodName
mMemberVariable
pPointer / ppDoublePointer, etc.
mpMemberPointer
gGlobalVariable (sehr selten, da der Verzicht auf Globals fast immer die bessere Alternative ist)
MAKRO_NAME
CONST_NAME (damit Konstanten einer einheitlichen Konvention foglen, egal ob per #define vom Präprozessor oder per const vom Compiler angelegt)

Die ungarische Notation als ganzes zu verwenden halte ich für unpraktisch, vor allem für objektorientierte Sprachen, da dann eigentlich auch Objektinstanzen Prefixe für ihre Klasse brauchen und die recht schnell sehr viel mehr als einen Buchstaben brauchen, wen man keine Prefixnamenskonflikte haben will. Bei m für Member und g für Globals, damit man bei der Bennenung von Parametern und locales keine Kollissionen mit bereits belegten Namen hat und p für Pointer, um nicht nachschauen zu müssen, ob man nun (de-)referenzieren muss oder nicht, finde ich, dass die Vorteile des Prefixes überwiegen.

deutsch vs. englisch:
Da empfehle ich, sich anzugewöhnen, grundsätzlich immer unf für alles, inklusive Comments, englisch zu verwenden, zum einen, weil Sprachmischmasch wie while(wahr) unschön aussieht, vor allem aber, damit jederzeit auch wer ohne Deutschkenntnisse etwas mit dem Code anfangen kann, man also z.B. nicht vor einem Problem steht, wenn plötzlich mal ein Kollege aus dem Ausland an dem Projekt mitarbeitet und sich in bestehendem Code zurechtfinden muss oder wenn man einen Codeschnipsel in ein englischsprachiges Fachforum stellt (du wirst früher oder später auf Themengebiete stoßen, die so speziell sind, dass man nicht immer wen mit der eigenen Muttersprache findet, der sich damit auskennt).

Zum Thema Projekt löschen:
Das geht ganz am Anfang, aber schmeiß mal einfach den ganzen Code weg, wenn er erstmal hunderttausende oder Millionen von Zeilen umfasst und du und ein Dutzend andere Programmierer seit einem Jahrzehnt Vollzeit daran gearbeitet haben.
Von daher empfehle ich dir, dich mit dem Thema Refactoring zu beschäftigen, also bestehenden Code großflächig an neue Bedürfnisse anpassen.
Für Fälle, wo einfache Textersetzung nicht mehr weiterhilft, lohnt es sich, sich in VisualAssistX (kostenpflichtig, aber praktisch überlebenswichtig als C++ Programmierer unter Visual Studio für kontextabhängiges Renaming wie z.B. "benenne im Ganzen Programm diese Klasse um, aber nichts, was genauso heißt, aber gar nicht diese Klasse ist, sehr wohl aber Comments, die sich diese Klasse beziehen", vernünftiges Hihlighting und vieles mehr) und Regular Expressions (dauert etwas, bis man sich in der Syntax zurechtfindet, aber sehr mächtig für komplexere Textersetzungsfälle wie z.B. "ersetze alles, was eine dreistellige Zahl gefolgt von einem Kleinbuchstaben, dann einem Unterstrich und dann eienm Großbuchstaben hat, in einem Rutsch, egal wie die Zahl lautet und egal um welche Buchstaben des Alphabets es sich handelt") einzuarbeiten.

[BeRsErKeR]

Zu den switch-cases:
Ich handhabe es so, dass da nur innere Klammern drum kommen, wenn sie benötigt werden, was meist der Fall ist, wenn eine lokale Variable nötig ist, z.B. weil eine im Case aufgerufene Methode eine Adresse als Parameter erwartet.
Ich empfehle aber auf jeden Fall, immer einen default-case am Ende des switches zu haben, um unerwartetes verhalten abzufangen.
Das geht bei mir sogar soweit:

Code: Alles auswählen

int foo = rand()%2;
switch(foo)
{
    case 0:
        // do something
        break;
    case 1:
        // do something different
        break;
    default:
        assert(false); // should not be possible to happen, perhaps the programm has been executed in a parallel universe with different mathematic laws?
        break;
}

Ich handhabe es genauso. Der default-Zweig ist meines Wissens sogar Pflicht. Mit vollem Warnlevel bekommt man beim gcc glaub ich eins auf den Deckel wenn es fehlt. Beim VC++ weiß ich es nicht. In der Regel sollte er immer vorhanden sein, auch wenn er in deinem Beispiel lächerlich erscheint. Es kann sich ja auch an der Berechnung von foo was ändern.

[Lynxeye]

Ein default im Switch kann weggelassen werden, wenn das switch sich auf ein enum bezieht. Dann ist es sogar sinnvoll, da der Compiler so erkennen kann ob alle möglichen enum Werte behandelt werden und warnt, wenn dies nicht der Fall ist.

[Schrompf]

Ich programmiere übrigens komplett auf Deutsch, soweit möglich und praktisch. Ersetzt natürlich keine Englisch-Kenntnisse, die Du eh immer und überall in der Computerei brauchst, aber ich persönlich denke, dass man besser vorwärts kommt, wenn man in seiner Muttersprache arbeiten kann.

[kaiserludi]

Ich programmiere übrigens komplett auf Deutsch, soweit möglich und praktisch. Ersetzt natürlich keine Englisch-Kenntnisse, die Du eh immer und überall in der Computerei brauchst, aber ich persönlich denke, dass man besser vorwärts kommt, wenn man in seiner Muttersprache arbeiten kann.

Ist eine reine Sache der Gewöhnung. Ich erreiche in Englisch inzwischen 99,9999% der Arbeitsgeschwindigkeit, die ich auf Deutsch erreiche, solange es rein ums coden und kommentieren geht. Bei Doku und Support ist es weniger, aber dort kommt man bei internationaler Kundschaft erst recht nicht um Englisch drumherum

[Artificial Mind]

Ich denke ich wäre auch Deutsch mittlerweile wesentlich ineffizienter, da mir die ganzen Benennungen der Funktionen und Variablen auf Englisch wesentlich leichter fallen. Außerdem trainiert das das Englische und das bringt sehr viel Vorteile ;)

[BeRsErKeR]

Ich programmiere übrigens komplett auf Deutsch, soweit möglich und praktisch. Ersetzt natürlich keine Englisch-Kenntnisse, die Du eh immer und überall in der Computerei brauchst, aber ich persönlich denke, dass man besser vorwärts kommt, wenn man in seiner Muttersprache arbeiten kann.

Naja ich kann besser englisch als deutsch (jedenfalls schriftlich) auch wenn meine Muttersprache deutsch ist. Von daher kann ich das schlecht nachvollziehen. Ich denke aber, dass man mit einer anderen Sprache als englisch immer irgendwann Mischmasch produziert, in dem Sinn, dass Schlüsselwörter immer englisch (oder davon abgeleitet) sind und ein Gro der Bibliotheken ebenfalls englischsprachige Interfaces nutzen. Darüber hinaus kommen zusätzliche Probleme wie Umlaute oder die Notation von Dezimalzahlen (die Literale können nicht nach der deutschen Norm geschrieben werden). Man hat vielleicht nicht den Nachteil, dass man bei unbekannten Begriffen nachschlagen muss bzw. dadurch dann Funktionen vielleicht nicht auf den ersten Blick identifizieren kann, allerdings erkauft man sich das auch dadurch, dass man teilweise ellenlange Namen hat oder Umlaute häßlich kodiert oder irgendwo inkonsistent wird.

Es wäre so einfach wenn es nur noch eine einzige Sprache geben würde. Warum können nicht einfach alle Menschen englisch sprechen?

[Biolunar]

Es wäre so einfach wenn es nur noch eine einzige Sprache geben würde.

Einverstanden.

Warum können nicht einfach alle Menschen englisch sprechen?

Warum nicht deutsch? Mein englisch ist mies.

[BeRsErKeR]

Es wäre so einfach wenn es nur noch eine einzige Sprache geben würde.

Einverstanden.

Warum können nicht einfach alle Menschen englisch sprechen?

Warum nicht deutsch? Mein englisch ist mies.

Deutsch ist viel zu umständlich. Fälle, geschlechterspezifische Endungen, usw. Außerdem könnten wir dann alle schön ASCII ohne Codepages benutzen. Und viele Leute auf der Welt können englisch im Gegensatz zu deutsch.

[kaiserludi]

Naja ich kann besser englisch als deutsch (jedenfalls schriftlich) auch wenn meine Muttersprache deutsch ist.

:o WTF :shock:
Wie schafft man das denn? Fast genauso gut, OK, aber tatsächlich besser als die eigene Muttersprache?
Dein Deutsch ist ja nun auch nicht schlecht, jedenfalls nicht so schlecht, dass mir irgendwas daran negativ aufgefallen wäre...

Es wäre so einfach wenn es nur noch eine einzige Sprache geben würde.

Einverstanden.

Warum können nicht einfach alle Menschen englisch sprechen?

Warum nicht deutsch? Mein englisch ist mies.

Deutsch ist viel zu umständlich. Fälle, geschlechterspezifische Endungen, usw. Außerdem könnten wir dann alle schön ASCII ohne Codepages benutzen. Und viele Leute auf der Welt können englisch im Gegensatz zu deutsch.

ASCII ist ganz klar ein ganz großes Argument für Englisch, endlich nur noch 8bit singlebyte strings!
Ansonsten, warum nicht Esperanto? Dann wird kein Mutterprachler bevorzugt :D