Czy porzucenie STL w rozwoju C ++ jest praktyczne? [Zamknięte]

Wiem, że w niektórych obszarach (na przykład w branży gier) STL nie jest zalecane. Więc moje pytanie brzmi: czy naprawdę dobrą praktyką jest nie używanie STL w niektórych przypadkach? Jeśli tak, jakie są główne powody, dla których nie używamy STL nowoczesnego C ++?

• Mogę wymyślić tylko jeden ważny powód i to naprawdę rzadkie: ciężko w czasie rzeczywistym. Wiele elementów w standardowej bibliotece przydziela pamięć wewnętrznie i nie jest to wystarczająco deterministyczne w przypadku trudnych aplikacji w czasie rzeczywistym, więc należy ich unikać. Aplikacje te są zwykle dość proste, choć ich opracowanie zajmuje nieproporcjonalnie dużo czasu ze względu na bardzo rygorystyczny przegląd i testy.

• Mogę wymyślić jeden nieprawidłowy, ale bardzo częsty powód: programiści, którzy nie rozumieją złożoności obliczeniowej, niewłaściwie używają STL, a następnie obwiniają bibliotekę.

  STL jest zwykle szybszy w czasie wykonywania niż rozwiązania w stylu C z wskaźnikami oddzwaniania lub rozwiązania oparte na polimorfizmie z metodami wirtualnymi ( patrz też główna uwaga Bjarne Stroustrupa ). Jednak gdy deweloper nie rozumie podanych specyfikacji złożoności i niewłaściwie wykorzystuje bibliotekę, tworząc coś w rodzaju wektora wektorów niektórych złożonych obiektów (w C ++ 11 to już nie jest problem!), Powoduje problem z wydajnością i broni się z „widzisz, wektory są raczej wolne”, może powodować wrażenie, że standardowa biblioteka jest wolna. A kiedy menedżerowie uzyskają taką percepcję, może żyć bardzo długo w organizacji.

• Oczywiście nie możesz użyć niczego, czego nie obsługuje platforma, na którą celujesz. Jednak obecnie celujemy w cztery najpopularniejsze platformy mobilne (Android, iOS, Bada i stary WinCE) i na wszystkich z nich korzystamy ze standardowej biblioteki i niektórych części Boost .

  Znaczna część standardowej biblioteki była wcześniej nieobsługiwana przez Microsoft we wczesnej fazie WinCE (iostreams IIRC pojawił się tylko w Visual Studio 2005), ale zamiast tego można było używać STLport na długo wcześniej. I zwykle można to zrobić, aby skompilować z czymkolwiek. Dlatego też nazwałbym ten powód nieważnym.

  Poza tym od dłuższego czasu nie jest to „STL”, ale biblioteka standardowa ANSI C ++. Jest zdefiniowany przez ten sam standardowy dokument, który definiuje sam język. Wszystko, co go nie obsługuje, tak naprawdę nie zasługuje na miano C ++.

Używam STL i boost już od wielu lat. Gdybym chciał to porzucić i użyć niestandardowych narzędzi, motywacja byłaby następująca:

1. Skrócenie czasu kompilacji (75%). Wystarczy dołączyć iostreams, aby dodać 1 milion linii kodu do modułu. Tak, prekompilowane nagłówki bardzo pomagają, ale wciąż spowalnia kompilację w dużych projektach. Na dłuższą metę marnuje dużo czasu na każdego, kto nad tym pracuje.
2. Występ. (25%) STL jest napisany do pracy ogólnie, ale możesz zoptymalizować swoje struktury, aby działały dokładnie tak, jak chcesz. Na przykład możesz mieć struktury danych z milionami krótkich ciągów. Może być znacznie szybsze użycie niestandardowej klasy ciągów opartych na zasadzie boost :: small_vector (mały statyczny lokalny wektor danych, dynamiczny przydział tylko dla większych ciągów), takie zmiany mogą sprawić, że krytyczne sekcje kodu będą działały wielokrotnie szybciej.

Jest jeden ważny ważny powód, aby nie używać standardowej biblioteki szablonów C ++: Jedna z twoich platform docelowych nie ma jej w pełni zgodnej implementacji (lub wcale jej nie ma) i wiesz, że nie otrzyma takiej w ciągu najbliższych lat.

Nie wiem o złożoności (wydajności implementacji), ale używam pojemników i ciągów Qt intensywnie zamiast standardowych i działają one dobrze. Uważam również, że implementacja zestawów i list Qt jest łatwiejsza w użyciu.

Dlatego może być praktyczne porzucenie STL, jeśli możesz użyć innej biblioteki, która odpowiada twoim potrzebom.

Patrick wymienił powód, dla którego nie należy korzystać z całego STL, a mianowicie, że twoja platforma (platformy) nie ma takiego.

Podsumowując, myślę, że pytanie nie ma sensu. Przeważnie nie jest to decyzja typu wszystko albo nic, ale decyzja typu „wybierz i wybierz”. Możesz zdecydować się na użycie kontenerów i algorytmów, ale zdecyduj się użyć czegoś poza standardową biblioteką lib dla ciągów i we / wy.

Nie jest to praktyczne, chyba że istnieje ku temu poważny powód. Niektóre z takich powodów, które mogę wymyślić, to tylko częściowa lub brak implementacji STL (lub jakiejkolwiek innej części standardowej biblioteki) lub ograniczenie zasobów (pamięć, szybkość procesora, pamięć, ...), które musisz obejść rozwijając własne narzędzia zgodne z tym, co musisz osiągnąć.

W branży gier większość (nawet do pewnego stopnia mniejszych) studiów ma swoje biblioteki wewnętrzne i implementacje wielu standardowych części bibliotecznych, które są wysoce dostosowane do platformy docelowej, aw niektórych przypadkach są ukierunkowane na inżynierię, a nawet samą grę. Mówiąc wprost, przy opracowywaniu gry na konsole sprzęt jest bardzo ograniczony przez dzisiejsze standardy. Istnieją tysiące linii ręcznie wykonanego montażu z jednego powodu. Bardzo ważne jest zminimalizowanie wszelkiego rodzaju śladów zasobów w kodzie, aby gra działała szybciej, co pozwala na więcej treści w świecie gry (lub na przykład w większym świecie), co, miejmy nadzieję, skutkuje lepszym produktem.

„Każda udana gra zaczyna się od wprowadzenia własnej implementacji połączonej listy”.