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

pytanie zadane 1 czerwca 2016 w C i C++ przez KlataMiLata Bywalec (2,120 p.)
edycja 6 czerwca 2016 przez KlataMiLata

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.

1	komentarz 2 czerwca 2016 przez Łukasz Hamowski Nowicjusz (100 p.) edycja 31 października 2018 przez Łukasz Hamowski Ttt

komentarz 2 czerwca 2016 przez KlataMiLata Bywalec (2,120 p.)

Nie widze w tym sensu. Zatrzymałem pisanie programu na tym etapie, bo wyskakiwał mi błąd. Wszystkie funkcje i konstruktory są zdefiniowane, ale są puste.

komentarz 2 czerwca 2016 przez Łukasz Hamowski Nowicjusz (100 p.)
edycja 31 października 2018 przez Łukasz Hamowski

Ttt

komentarz 2 czerwca 2016 przez KlataMiLata Bywalec (2,120 p.)

Player.cpp
#pragma once
#include "Player.h"





void Player::draw(sf::RenderTarget & target, sf::RenderStates states) const
{
}

Player::Player()
{

}


Player::~Player()
{
}

Engine.cpp

Engine::Engine(sf::RenderWindow &win)
{
	beeing_on = 1;
	start(win);
	
}


Engine::~Engine()
{
}

void Engine::start(sf::RenderWindow &window)
{
	while (beeing_on)
	{
		Clock zegar;
		Event eve;
		while (window.pollEvent(eve))
		{
			if (eve.type == Event::Closed || eve.type == Event::KeyPressed && eve.key.code == Keyboard::X || eve.type == Event::KeyPressed && eve.key.code == Keyboard::Escape)
			{
				beeing_on = 0;
			}
			if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left))
			{
		
			}
			if (eve.type == Event::KeyPressed && eve.key.code == Keyboard::Right)
			{
			
			}
			if (eve.type == Event::KeyPressed && eve.key.code == Keyboard::Space)
			{
			
			}
		}
		window.clear();
		window.display();
	}
}

Tak w tym momencie to wygląda.

komentarz 2 czerwca 2016 przez niezalogowany

A za to ja cię prosiłem o podanie numerów linijek, w których są błędy (bo podałeś tylko opis błędu) i powiedziałem ci, żebyś dodał do metody draw() słówko virtual :)

komentarz 2 czerwca 2016 przez Łukasz Hamowski Nowicjusz (100 p.)
edycja 31 października 2018 przez Łukasz Hamowski

Ttt

komentarz 2 czerwca 2016 przez niezalogowany

Za to #pragma once nie ma w plikach nagłówkowych xd

komentarz 2 czerwca 2016 przez niezalogowany

Nie musi dodawać słówka virtual

komentarz 2 czerwca 2016 przez KlataMiLata Bywalec (2,120 p.)

Nie wiem skąd tam pragma once. Numery linijek to 6 Linia pliku Engine.h, czyli deklaracja obiektu klasy Player w klasie Engine.

komentarz 2 czerwca 2016 przez niezalogowany

Nie musi, ale jeśli chce "wymalować" swój obiekt za pomocą metody draw() obiektu RenderWindow, to chyba jednak musi.

2	komentarz 2 czerwca 2016 przez niezalogowany Nie, nie musi.

komentarz 2 czerwca 2016 przez niezalogowany

W takim razie bardzo cię proszę o wytłumaczenie mi tego.

komentarz 2 czerwca 2016 przez niezalogowany

No halo, poprosiłbym o wytłumaczenie, żebym wiedział dlaczego ta funkcja może, ale nie musi być wirtualna.

@KlataMiLata - jak nic nie pomoże i nikt nie wymyśli jakiegoś pomysłu, to zrób projekt od nowa, od nowa zalinkuj SFML-a itp. Czasem to serio pomaga, ale lepiej zrób to w ostateczności (w końcu nie chodzi tutaj o SFML-a, tylko o własną klasę).

komentarz 2 czerwca 2016 przez KlataMiLata Bywalec (2,120 p.)

Już próbowałem raz tak zrobić. Moze tym razem spróbuje innego kompilatora bo z tym same problemy...

komentarz 2 czerwca 2016 przez Łukasz Hamowski Nowicjusz (100 p.)
edycja 2 czerwca 2016 przez Łukasz Hamowski

filipekczek7 - Ta metoda nie musi mieć przydomka virtual, ale jest to dozwolone. Dlaczego nie musi mieć? Dlatego, że klasa Player nie jest klasą abstrakcyjną i można tworzyć jej obiekty. Przydomek virtual tutaj nie ma większego znaczenie dlatego, że funkcja Draw nie jest czysto wirtualna.

komentarz 2 czerwca 2016 przez niezalogowany

@badbullpl - widzę, że sam nie wiesz czemu... Albo akurat cię nie ma, co jest akurat mało prawdopodobne.

@KlataMiLata - ja też od wczoraj mam także Visual Studio i gdy chciałem przenieść cały kod z projektu z Code::Blocks'a do VS, to musiałem robić poprawki typu zamienianie int na float, dodawanie const albo przeniesienie paru linijek trochę wyżej. Różne kompilatory, różne problemy, ale ten na pewno da się jakoś rozwiązać.

Wpisałem drugi opis błędu w Google http://lekka.cba.pl/c++/cpp_error_missing_type_c4430.htm Nie widzę podobnego problemu u ciebie, ale czy ten błąd jest także w linijce 6? A jeśli chodzi o pierwszy błąd, to czy plik nagłówkowy klasy Player jest we właściwym miejscu? Czy jest właściwie "stworzony" (nie wiem jak to inaczej nazwać)? Może kompilator nie widzi tego pliku. Aczkolwiek patrząc po opisie błędu na Google tak to nie wygląda.

komentarz 2 czerwca 2016 przez niezalogowany

@Łukasz Hamowski - więc w takim razie dlaczego w dokumentacji jest ten przydomek virtual? Musiałbym sobie sprawdzić, czy bez tego przydomka program by działał i bardziej się nad tym zastanowić.

komentarz 2 czerwca 2016 przez Łukasz Hamowski Nowicjusz (100 p.)
edycja 31 października 2018 przez Łukasz Hamowski

Ttt

komentarz 2 czerwca 2016 przez niezalogowany

Nie nie, nie o to mi chodzi. Wiem, czym jest polimorfizm, ale w dokumentacji jest o tym, że gdy się tworzy obiekt i chce się go narysować na ekranie, to trzeba zrobić wirtualną metodę. Z resztą, co będę tłumaczyć, proszę http://www.sfml-dev.org/tutorials/2.3/graphics-vertex-array.php#creating-an-sfml-like-entity

komentarz 2 czerwca 2016 przez Łukasz Hamowski Nowicjusz (100 p.)
edycja 31 października 2018 przez Łukasz Hamowski

Ttt

komentarz 2 czerwca 2016 przez niezalogowany

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.

komentarz 3 czerwca 2016 przez KlataMiLata Bywalec (2,120 p.)

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

komentarz 3 czerwca 2016 przez niezalogowany

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

komentarz 3 czerwca 2016 przez niezalogowany

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

3 odpowiedzi

odpowiedź 1 czerwca 2016 przez C☺ndzi Stary wyjadacz (12,100 p.)

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

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

Może pomoże :).

komentarz 1 czerwca 2016 przez KlataMiLata Bywalec (2,120 p.)

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

komentarz 2 czerwca 2016 przez C☺ndzi Stary wyjadacz (12,100 p.)

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

komentarz 2 czerwca 2016 przez KlataMiLata Bywalec (2,120 p.)

Tak :<

komentarz 2 czerwca 2016 przez C☺ndzi Stary wyjadacz (12,100 p.)

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

odpowiedź 1 czerwca 2016 przez MetGang Nałogowiec (34,360 p.)

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.

komentarz 1 czerwca 2016 przez C☺ndzi Stary wyjadacz (12,100 p.)

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

komentarz 1 czerwca 2016 przez KlataMiLata Bywalec (2,120 p.)

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

komentarz 2 czerwca 2016 przez Łukasz Hamowski Nowicjusz (100 p.)
edycja 31 października 2018 przez Łukasz Hamowski

...

komentarz 2 czerwca 2016 przez niezalogowany

Błąd byłby wtedy calkowicie inny.

komentarz 2 czerwca 2016 przez KlataMiLata Bywalec (2,120 p.)

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.

odpowiedź 2 czerwca 2016 przez niezalogowany
edycja 2 czerwca 2016

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.

Pokaż 6 poprzednich komentarzy

komentarz 2 czerwca 2016 przez niezalogowany

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.

komentarz 2 czerwca 2016 przez niezalogowany

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 :)

komentarz 2 czerwca 2016 przez niezalogowany

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

komentarz 2 czerwca 2016 przez niezalogowany

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).

komentarz 2 czerwca 2016 przez niezalogowany

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.