Konwersja listy klas pochodnych na listę klas bazowych.

Question

Witam, piszę pewien projekt, mam klasę bazową FlockingAlgorithm::FlockingObstacle oraz pochodną SeparationBall.

Taka konwersja jest możliwa:

FlockingAlgorithm::FlockingObstacle obj = *(obstaclesList.begin()); 

Natomiast ten zapis powoduje już błąd kompilacji:

std::list<FlockingAlgorithm::FlockingObstacle> lst(obstaclesList);

obstaclesList:

std::list<SeparationBall> obstaclesList; 

Występuje komunikat:

żadne wystąpienie konstruktora "std::list<_Ty, _Alloc>::list [gdzie _Ty=FlockingAlgorithm::FlockingObstacle, _Alloc=std::allocator<FlockingAlgorithm::FlockingObstacle>]" nie jest zgodne z listą argumentów   

Wiem że rzutowania mogę dokonywać dla każdego elementu listy z osobna, zależy mi jednak by zrobić to jedną instrukcją ponieważ lista obstaclesList jest przekazywana jak argument dla pewnej funkcji.

Dodam jeszcze że wcześniej obecna klasa pochodna nie dziedziczyła z niczego i konwersji dokonywałem tak:

std::list<FlockingObstacle> tempObstaclesList;
		std::transform(obstaclesList.begin(), obstaclesList.end(),
			std::front_insert_iterator<std::list<FlockingObstacle>>(tempObstaclesList),
			std::mem_fn(&SeparationBall::convertToFlockingObstacle));

to jednak jest chyba za mało wydajne za każdym obiegiem pętli wykonywać ten kod...

Będę wam bardzo wdzięczny za pomoc i pozdrawiam :)

Comments

Może przyczyną tego problemu jest to, że klasa szablonowa "list" z parametrem klasy podstawowej i ta sama klasa z klasą pochodną jako parametr to klasy które nie są ze sobą powiązane tak samo jak klasa dziedziczna z klasą podstawową? - czyste przypuszczenie.

Answer 1

 

to jednak jest chyba za mało wydajne za każdym obiegiem pętli wykonywać ten kod...

W Twoim przypadku nie da się inaczej. SeparationBall jest "większym" i (z punktu widzenia języka) nietrywialnie różnym typem od FlockingObstacle, więc nie da się tak po prostu "za darmo" traktować kontener jednego jak kontener drugiego. Również sam fakt, że przechowujesz same obiekty, sprawia, że nie masz innej możliwości niż "mało wydajnie" przepisywać ich zawartości.

Czemu przy czymś, co wygląda jak polimorfizm, "ucinasz" obiekty przechowując je same (zamiast wskaźników na klasę bazową/dziedziczącą)?

Boczne pytanie: dlaczego std::list zamiast std::vector?

Comments

Dziękuje za odpowiedź, początkowo się rozpisałem o tym dlaczego to wszystko tak wygląda a nie inaczej, jednak pisząc to stwierdziłem że gdybym ja to czytał to i tak bym nic z tego nie zrozumiał ;). Do tego uzmysłowiłem sobie ważny fakt w moim projekcie, który praktycznie uniemożliwia mi zastosowanie dziedziczenia od FlockingObstacle. Cały projekt jest dość duży i sam się ze wszystkim pogubiłem , może przez to że zamiast zadowolić się działającym algorytmem grupującym to zachciało mi się z niego zrobić uniwersalną bibliotekę ( a zapomniałem o moich nikłych umiejętnościach ).

Powiem może jedynie dlaczego zastosowałem std::list... Mianowice często będzie tu stosowane dodawanie i usuwanie obiektów na dużą skalę ( a z tym ponoć lista radzi sobie lepiej ). Za to raczej nie będę potrzebował dostępu swobodnego do obiektów.

Najwyżej dam linka do repozytorium ( zaznaczam że dla tego projektu użyłem Gita po raz pierwszy, wykorzystuje go na razie tylko jako kopia zapasowa więc nie dorobiłem żadnych ładnych opisów itd... ( tak samo tymczasowo znajdują się tam wszystkie pliku projektu ) więc z góry przepraszam jeśli będzie on "raził  w oczy" :/ )

https://github.com/Jakub1010/Flocking-Algorithm-Project

* najważniejsze pliki to Flocking.h i Flocking.cpp