(Solved)Problem z klasą dziedziczącą po klasach sf::transformable/sf::drawable(SFML)

Question

Zacząłem ostatnio próbować swoich sił w bibliotece SFML. Jako pomocy używam kursów z bloga szymonsiarkiewicz.pl. Mój problem polega na tym, że mam dwie klasy Player i Engine. Klasa Player dziedziczy od klas sf::drawable i sf::transformable. Może będzie prościej jak napiszę definicje tej klasy: 

#include <SFML/Graphics.hpp>
class Player :public sf::Drawable,
	sf::Transformable
{
	sf::Texture texture;
	sf::Sprite sprite;
	void draw(sf::RenderTarget &target, sf::RenderStates states) const;
public:
	Player();
	~Player();
};

Oraz jak wcześniej wspomniałem mam też klasę Engine, która posiada obiekt klasy player.

#include "Player.h"
class Engine
{
	Player player;
	bool being_on = 0;
public:
	Engine(sf::RenderWindow &);
	~Engine();
	void start(sf::RenderWindow &);
};

Kompilator wyrzuca mi błąd

.

Solved. Rozwiązaniem problemu w tym przypadku było zapisanie dwóch klas w jednym pliku.

Comments

Ttt

---

No tak tak, nie jezt czysto wirtualna. Czyli że nie ma sensu, żeby tam stał przydomek virtual? Kto będzie dziedziczył to dziedziczył? Hm, dziwne trochę, bym musiał to sprawdzić. OK, na dzisiaj chyba temat zamknięty.

---

Dzięki wszystkim za wlaczenie się w dyskusję. Jakby komuś jeszcze przyszło coś do glowy proszę o komentarz.

---

@filipekczek7 Wyobraź sobie, że mnie nie było. Nie siedzę na tym forum cały czas.

---

Ja też, tylko że wydawało mi się to mało możliwe, żebyś mi dwa razy nie odpowiedział na pytanie.

Answer 1

Zapomniałeś dopisać public przy class Player, powinno być:
 

class Player :public sf::Drawable,
    public sf::Transformable

Może pomoże :). 

Comments

Niestety nic się nie zmienia. Z tego co wiem to nie miało znaczenia bo przez domniemanie była przyjmowana wartość private.

---

A jak usuniesz dziedziczenie po sf::Transformable to nadal ten błąd się pojawia?

---

Tak :<

---

Czyli pewnie trzeba nadpisać jakąś metodę, sprawdź jak to wygląda u innych / w dokumentacji.

Answer 2

Ach ten Visual i jego zrozumiałe komunikaty. GCC wywala jaśniejszą odpowiedź.

Player();
~Player();

Nie posiadają ciała funkcji i kompilator nie może utworzyć obiektu o danym typie.

Comments

No tak, jakby robił kreatorem klas to by mu się stworzył pusty konstruktor i destruktor i by nie było problemu.

---

Konstruktory posiadają ciało. Na razie są puste, bo staram się znaleźć błąd w programie.

---

...

---

Błąd byłby wtedy calkowicie inny.

---

Używam tej dyrektywy, ale uznałem, żę wstawianie jej do kodu podpiętego pod ten temat jest niepotrzebny. Tak czy inaczej w swoim projekcie używam tej dyrektywy i to w żaden sposób nie rozwiązuje problemu.

Answer 3

Po pierwsze, metoda draw() powinna być wirtualna i const, czyli virtual void draw(argumenty)const. Po drugie, podaj proszę linie, w których są te błędy.

Comments

A czy ty znasz SFML-a?

Tak, znam. Po prostu  zwróciłem uwagę że metoda draw już jest wirtualna. Ale teraz widzę, że edytowałeś i dodałeś(bo chyba tego wcześniej nie było?), że musi być stała i tu się zgadzam.

---

Tak, bo po przejrzeniu drugiego linka, którego napisałem, przypomniałem sobie o tym, że ta metoda powinna być const, więc to trochę moja wina :)

---

A jaka jest różnica pomiędzy const, a nie-const metodą wirtualną? W tym przypadku, czyli metodą draw() SFML-a.

---

Jeśli obiekt jest const to jakakolwiek metoda wywoływana na rzecz tego obiektu też musi być const. Nie ma żadnej różnicy między non-const metodą wirtualną i const(no może oprócz sygnatur).

---

No, to to wiem, ale dlaczego akurat metoda draw() z SFML-a ma być const? Bo w końcu po tym, jak zauważyłeś, że napisałem o tym, że ma być jeszcze const, to powiedziałeś, że teraz się zgadzasz.