obiekty klasy pochodnej dodawane do wektora bez new?

0

Witam
W grze komputerowej (zaznaczam grze, czyli można przeczytać między słowami że szybkość wykonywania kodu jest dla mnie najważniejsza kosztem quality kodu) mam wektor któremu po naciśniściu przycisku podaje się klasę Plan a ta z kolei przybiera parametry. Chodzi o to że uzytkownik naciśka przycisk i w odpowiedzi mój kod ustala co postać na ekranie komputera zrobi, np. obróci się zgodnie ze strzalkami a następnie pobiegnie przez 2 sekundy.
Jakby nie zależało mi na szybkości działania programu i nie miał C++11 to bym zadeklarował wektor tak:

vector<plan*> mPlannedState; mPlannedState.push_back(new PlanObrotu(TURN_OVER)); mPlannedState.push_back(new PlanBiegniecia(RUN, 2_S)); //TURN_OVER i RUN należą do tego samego enuma ``` Zależy mi na szybkości, toteż mam 1 klasę, akurat dla planu obrotu zmienna czasu jest nieużywana no i mogę pozbyć się operatora new: vector<plan> mPlannedState; mPlannedState.push_back(Plan(TURN_OVER)); mPlannedState.push_back(Plan(RUN, 2_S)); ``` Mam C++11 to przekształcam kod do szybszej wersji: vector<plan> mPlannedState; mPlannedState.emplace_back(TURN_OVER); mPlannedState.emplace_back(RUN, 2_S); ```

Czy da radę jednak jakoś mieć tutaj 2 klasy planObrotu i biegnięcia i nie używać operatora new, ani też inteligentnych wskaźników no bo wiadomo wywołanie operatora new kosztuje czas?

3

Mam wrażenie, że trochę się naczytałeś średnio poprawnych opinii, masz pewne domysły jak to działa i na tej podstawie wysnuwasz wnioski. new jako takie nie ma specjalnego narzutu wydajnościowego (alokacja ma mocno amortyzowany koszt), dużo droższy często jest brak cache locality. Ale od takich rzeczy są benchmarki.

Jeśli chodzi o smart pointery, unique_ptr generuje identyczny kod co poprawnie napisana ręczna obsługa delete, więc jakiekolwiek twierdzenia, że spowalnia są bzdurą (no chyba, że mowa o czasie kompilacji - ale tutaj wracamy do benchmarków).

Jeśli chodzi o samo pytanie: jeśli masz różne klasy to właściwie masz następujące wybory:

  1. boost::variant i trzymanie ich przez wartość w wektorze. Więcej pisania bo wszędzie musisz pisać apply dla wariantów
  2. interfejs, metody wirtualne, w wektorze trzymasz unique_ptr<Plan>
  3. łamiesz SRP i sprowadzasz obie klasy do jednej

Które rozwiązanie chcesz podjąć zdecyduj sam, ale zanim podejmiesz karkołomne decyzje - benchmarkuj.

0

Jeżeli potrzebujesz szybkiej alokacji pamięci (używasz new tylko raz, na początku działania programu do zalokowania jakiegoś dużego kawałka, a potem pobierasz kawałki tej pamięci), to przeczytaj sobie ten artykuł http://www.gamedev.net/page/resources/_/technical/general-programming/c-custom-memory-allocation-r3010. Na dłuższą metę taka "customowa" alokacja pamięci zadziała lepiej niż new i delete.

0

wybiorę jednak rozwiązanie z operatorem new (smart pointerem) bo sobie przemyślałem, że przecież takie wywołanie będzie jedynie w momencie naciśnięcia klawisza + delete w momencie zakończenia zaplanowanej animacji, więc to nie będzie jakiś tam nie wiadomo jaki koszt a łatwiej będzie zarządzać tymi wszystkimi planami animacji mając wyspecjalizowane klasy pochodne niż wszystko trzymać w jednej. Co do customowego pobierania pamięci to tez jest w sumie rozwiązanie, można zadeklarować 100 obiektów wyspecjalizowanych klas pochodnych i potem jedynie pobierać wskaźniki do wektora i przestawiać dane obiekty że użyty i po wykonaniu animacji przestawiać used na false dzięki czemu obiekt może znowu zostać pobrany. W sumie ma to sens.:)

2

Powiem tak: jako początkujący chcesz optymalizować coś na podstawie plotek i pseudo mądrości innych początkujących.
Skończy się ne tym, że będziesz optymalizował coś co jest wykonywane przez 1% czasu, a problem w pozostałych 99% pozostanie.
Nieważne, czy ten 1% zoptymalizujesz by się wykonywał 1000 razy szybciej, program i tak najwyżej przyspieszy o ten jeden procent.
Ergo zanim zmarnujesz czas na optymalizowanie czegokolwiek, naucz się korzystać z profiler-a i użyj go do zlokalizowania źródła problemu.

Na razie za mało masz umiejętności by myśleć o opisanych przez ciebie optymalizacjach, które na dodatek prawie na pewno nie są ci potrzebne.

1 użytkowników online, w tym zalogowanych: 0, gości: 1