private class c++?

...komplette Frage anzeigen

5 Antworten

Mmmh, also wie man Getter und Setter baut, haben die anderen ja schon geschrieben, hier nochmal eine Zusammenfassung:

#include <iostream> // cout, endl

class Foo {
public:
Foo() : bar_ {} {}

int bar() const noexcept {
return bar_;
}
void bar(const int b) /* noexcept */ {
bar_ = b;
}

private:
int bar_;
};

int main(void) {
using namespace ::std;

Foo foo;
cout << foo.bar() << endl;

foo.bar(123);
cout << foo.bar() << endl;
}

Da du aber von Referenzen sprichst, geht das natürlich auch damit:

#include <iostream> // cout, endl

class Foo {
public:
Foo() : bar_ {} {}

int & bar() noexcept {
return bar_;
}
const int & bar() const noexcept {
return bar_;
}

private:
int bar_;
};

int main(void) {
using namespace ::std;

Foo foo;
cout << foo.bar() << endl;

foo.bar() = 123;
cout << foo.bar() << endl;
}

Beachte bitte vor allem die unterschiedliche Art der Zuweisung innerhalb von main()! Für beide Varianten gibt es gute Gründe, aber auch Gründe warum man sie in bestimmten Situationen möglichst vermeiden sollte. Es gibt sogar noch andere Varianten! Das alles auszuführen wäre jetzt aber viel zu viel. Am besten, du besorgst dir ein gutes Lehrbuch!

Zu den anderen Punkten bzw. Fehlern sage ich jetzt nichts, weil dir ja die anderen schon genügend Hinweise gegeben haben und ich jetzt nicht den Rahmen sprengen will!

Aber gewöhne dir auf jeden Fall an, deine Quelltexte ordentlich in Header und Implementierung aufzuteilen! Das spart dir später viel Arbeit und erleichtert viele Dinge enorm! :)

Naja, schönen Tag noch! :)

1) Befindet sich deine Klasse in der main.cpp oder hast du den Code nur für pastebin temporär zusammengelegt? Wenn nein, dann lege die Klasse in eine Header-Datei ab, denn da gehört sie hin.

2) gplayer ist wie von LeonardM bereits erwähnt, eine Methode. Es fehlt also die Argumentenliste (bzw. die runden Klammern).

Take.gplayer()

Genauso verhält es sich mit gx und gy.

Nein, meine Klasse befindet sich in der main.cpp. 

Ich wusste nicht das es besser ist diese in einer header zu definieren.

Bin ich hiermit richtig beraten? http://www.cplusplus.com/forum/articles/10627/

oder gibt es noch andere gründe welche in meinem verlinkten artikel nicht aufgeführt sind?

0
@braunbaer95

Ergänzung meinerseits:

Durch die Trennung zwischen Interface und Implementierung besteht auch eine bessere Trennung zwischen Doc-Kommentaren und Code. Beim fertigen Programm besteht eine einfache Einsicht in die vorhandenen Funktionen der einzelnen Klassen, doch nicht in die direkte Implementierung.

2

Möchtest du x und y nicht per this ansprechen?

ausserdem sind gx und gy funktionen. du solltest sie bei der implementierung auch so behandeln.

0

habe noch nicht mit pointer gearbeitet, und nach dem was ich gerade gelesen hat ist this ja nichts anderes als ein zeiger, oder?

0

das problem liegt meiner Ansicht nach beim gültigkeitsbereich. und ja this ist ein zeiger.

0
@LeonardM

x und y wird sich später verändern und soll so die neue Position von dem spieler sein, also ist es möglich die privat deklarierten variablen per user input zu verändern und dann mit this abzurufen?

falls ja dann mach ich mich mal an die arbeit mir das alles durchzulesen. 

0
@braunbaer95

(...) also ist es möglich die privat deklarierten variablen per user input zu verändern (...)

Ja, das ist möglich, sofern von außen irgendeine Art Interface besteht, um die inneren Variablen des Objekts zu verändern. Eine solche Schnittstelle stellen Setter-Methoden dar:

public:
 void setX(const int x){
   this->x = x;
 }

Mit this operiere ich hier allerdings nur aus dem Grund, weil ich die Instanzvariable x ansprechen möchte. Würdest du den Parameter anders benennen (z.B. value), bräuchtest du this gar nicht:

x = value; 

Letztendlich wäre es nur noch notwendig, die Nutzereingabe auszulesen und an die Setter-Methode weiterzugeben:

int input = //... read user input
take.setX(input);

Über eine Getter-Methode, wie du sie bereits definiert hast (gx), kannst du den Wert wieder abrufen.

1

ja das ist möglich. du hast aber mit x und y noch nichts gemacht. ich hab bisher nur mini programme in cpp geschrieben ohne klassen. du kannst ja mal probieren oder lesen oder auf andere antworten warten.

0

1.: Klassen auf eine Headerdatei und eine Quelldatei aufteilen. 

Ansonsten, du hast da mehrere Fehler drin. 

1.)  Das Object "Take" wird nicht konstruiert. (GameFunctions Take;) 

2.) Du behandelst Funktionen wie Variablen (Take.gx anstelle von Take.gx() oder Take->gx() ). 

https://pastebin.com/qBXsJcYL


 

Hab aus Take *Take gemacht. Finde ich net sonderlich schön, aber es funktioniert und allzu groß ist deine Anwendung ja nu auch nicht. 

Welchen Sinn hat das? -> https://pastebin.com/CLm0SKq2

Das Object "Take" wird nicht konstruiert. (GameFunctions Take;)

Doch, die Instanz wurde erstellt. Es muss nicht alles dynamisch mit new angelegt werden, wenn die Variable nur in einem bestimmten Scope erreichbar sein muss.

2

die do while schleife ergibt jetzt noch garkeinen sinn :D wird aber später nunmal gebraucht, da es sich um ein kleines spiel handeln soll.

1

Ich bin mit deiner Antwort aus verschiedenen Gründen leider gar nicht einverstanden, sorry! :)

Wie regex9 schon geschrieben hat, wird das Objekt sehr wohl initialisiert. Es wird der Standardkonostruktor in Zeile 67 aufgerufen. (C++ ab Version 11 vorausgesetzt.)

Und eine Instanziierung auf dem Heap mit new ist ungefähr 2000 mal langsamer, als auf dem Stack, da der Speichermanager bemüht werden muss.

Gerade bei Spielen sollte man sparsam mit der Speicheralloziierung umgehen, und wenn es unbedingt sein muss, lieber mit Placement-New auf einem Thread-Lokalen Speicherpool arbeiten, bzw. gleich eigene Allokator-Klassen bemühen. (Das ist dann im Endeffekt fast so schnell wie auf dem Stack! Google mal nach "first fit allocator".)

Wie auch immer, nach einem "new", sollte man das "delete" nicht vergessen, und gerade WEIL das schnell mal passiert, sollte man sich Smart-Pointer angewöhnen.

Außerdem enthält der Zugriff über Zeiger immer eine Indirektion mehr, weshalb der "Punktoperator" schneller ist. (Bei wiederholtem Zugriff findet die CPU zwar alles in den Cache-Lines, was dann keinen Unterschied mehr macht, aber bei großen Spielen mit vielen Objekten macht sich die Geschichte irgendwann bemerkbar, wenn eine Addition zweier Member plötzlich nicht mehr einen, sondern 100 bis 200 Takte verbrät!)

Als letzten Punkt muss ich sagen, dass do-while-Schleifen eigentlich immer auf ein suboptimales Design hindeuten. Zwar nicht so schlimm wie goto, geht aber in die selbe Richtung. (Auch wenn goto durchaus seine Daseinsberechtigung hat, allerdings nicht bei Einsteigercode!) :)

2

Vielen dank schon einmal an alle User.

Auch wenn ich nicht auf alles antworte, habe ich doch alles zur Kenntnis genommen, und mein Kopf ist gerade dabei die ganzen Informationen zu verarbeiten (lach)

Was möchtest Du wissen?