[C++] Czy takie rozwiązanie doprowadzi do wycieków pamięci?
Ostatnio zmodyfikowano 2018-04-25 23:34
twoxu Temat założony przez niniejszego użytkownika |
[C++] Czy takie rozwiązanie doprowadzi do wycieków pamięci? » 2018-04-25 20:35:58 Witam. Otóż mam klasę, która zawiera wskaźnik na wskaźnik na sf::Texture (nazwijmy to C) (która musi "żyć" tak długo jak jest wykorzystywana przez sprajty). Wygląda to mniej więcej tak:
sf::Texture * B = new sf::Texture;
B->loadFromFile( "adres" );
A.C = & B;
Oczywiście tą pamięć muszę zwolnić, a destruktor klasy A się chyba do tego dość dobrze nadaje, więc ~Klasa()
{
delete &( this->C );
*( this->C ) = nullptr;
}
Niby się kompiluje, działa i nie crashuje, ale jakoś nie mam pewności co do skuteczności takiego działania. Może ktoś zdiagnozować, czy aby moje wymysły nie doprowadzą do wycieków pamięci? |
|
CommonJoe |
» 2018-04-25 20:42:16 Myślę, że zamiast: ~Klasa()
{
delete &( this->C );
*( this->C ) = nullptr;
}
wystarczy po prostu: Niech mnie ktoś poprawi jak się mylę. |
|
CommonJoe |
» 2018-04-25 20:52:37 A nie możesz wstawić kodu całej klasy ? Albo chociaż samą część z deklaracjami zmiennych, byłoby mi łatwiej zrozumieć co próbujesz zrobić. |
|
pekfos |
» 2018-04-25 22:03:09 Definitywnie niepoprawne.
sf::Texture * B = new sf::Texture;
B->loadFromFile( "adres" );
A.C = & B;
|
Tak faktycznie wygląda kod..? Trzymasz w klasie wskaźnik na wskaźnik. B jest zmienną lokalną, więc w gruncie rzeczy zwracasz adres zmiennej lokalnej. | Otóż mam klasę, która zawiera wskaźnik na wskaźnik na sf::Texture (nazwijmy to C) (która musi "żyć" tak długo jak jest wykorzystywana przez sprajty). |
I jaką rolę pełni twoja klasa? Jak po prostu ma przechowywać teksturę i sam zarządzasz czasem życia, to niekoniecznie jest sens w ogóle trzymać teksturę przez wskaźnik. Jak robisz 'lepszego sprajta', który ma zwolnić teksturę, to używasz std::shared_ptr<>. struct A
{
std::shared_ptr < sf::Texture > texture;
sf::Sprite sprite;
}; |
|
twoxu Temat założony przez niniejszego użytkownika |
» 2018-04-25 23:08:48 Pierwsza część kodu pochodzi z funkcji która tworzy instancje klasy implementującej animacje sprajtów, druga natomiast z klasy (A) która wykorzystuje animowane sprajty i wywołuje u nich przejście do następnej klatki lub zmienia animację.
Tak faktycznie wygląda kod..? Trzymasz w klasie wskaźnik na wskaźnik. B jest zmienną lokalną, więc w gruncie rzeczy zwracasz adres zmiennej lokalnej.
|
W takim razie chyba czegoś nie rozumiem. Użyłem dynamicznej alokacji pamięci, by uniknąć problemów z zakończeniem "życia" zmiennej typu sf::Texture przechowującej moją teksturę. Gdybym nie używał, czas "życia" B kończyłby się po wykonaniu funkcji, a tak jest dostępny poprzez wskaźnik C aż do destrukcji klasy (A) która go używa. |
|
pekfos |
» 2018-04-25 23:34:52 | Użyłem dynamicznej alokacji pamięci, by uniknąć problemów z zakończeniem "życia" zmiennej typu sf::Texture przechowującej moją teksturę. Gdybym nie używał, czas "życia" B kończyłby się po wykonaniu funkcji, a tak jest dostępny poprzez wskaźnik C aż do destrukcji klasy (A) która go używa. |
Czas życia B kończy się po wykonaniu funkcji. Zaalokowałeś dynamicznie teksturę, nie wskaźnik na nią. |
|
| « 1 » |