Do STL or!STL, oto jest pytanie

Główne powody, dla których nie należy używać STL to:

1. twoja implementacja C++ jest stara i ma straszną obsługę szablonów.
2. nie można używać dynamicznej alokacji pamięci.

Oba są bardzo rzadkimi wymaganiami w praktyce.

W przypadku długoterminowego projektu zwijanie własnych kontenerów, które nakładają się na funkcjonalność z stl, zwiększy koszty konserwacji i rozwoju.

Jest tak wiele zalet korzystania z stl. W przypadku projektu długoterminowego korzyści przewyższają koszty.

1. nowi programiści są w stanie zrozumieć kontenery od pierwszego dnia, dając im więcej czasu na poznanie drugiego kodu w projekcie. (zakładając, że znają już STL jak każdy kompetentny Programista C++)
2. naprawianie błędów w kontenerach jest do bani i marnuje czas, który można poświęcić na ulepszanie logiki biznesowej.
3. najprawdopodobniej ich nie napiszesz podobnie jak stl jest zaimplementowany tak czy inaczej.

To powiedziawszy, kontenery STL w ogóle nie zajmują się współbieżnością. Tak więc w środowisku, w którym potrzebujesz współbieżności, użyłbym innych kontenerów, takich jak Intel TBB concurrent containers. Są one znacznie bardziej zaawansowane przy użyciu drobnoziarnistego blokowania, tak że różne wątki mogą być modyfikowane kontenera jednocześnie i nie trzeba serializować dostępu do kontenera.

Zwykle uważam, że najlepszym rozwiązaniem jest użycie stl z niestandardowymi alokatorami zamiast zastępowania kontenerów stl ręcznie zwijanymi. Fajną rzeczą w STL jest to, że płacisz tylko za to, czego używasz.

Wydaje mi się, że to typowy scenariusz build vs buy. Myślę jednak, że w tym przypadku prawie zawsze bym "kupował" i używał STL - lub lepszego rozwiązania (może coś z Boosta), przed zrolowaniem własnego. Powinieneś skupić większość swojego wysiłku na tym, co robi Twoja aplikacja, a nie na elementach składowych, których używa.

Raczej nie. Tworząc własne kontenery, starałbym się nawet uczynić te kompatybilnymi z STL, ponieważ moc algorytmów generycznych jest zbyt wielka, aby z nich zrezygnować. STL powinien być przynajmniej nominalnie używany, nawet jeśli wszystko, co robisz, to piszesz swój własny kontener i specjalizujesz się w każdym algorytmie. W ten sposób można wywołać każdy algorytm sortowania sort (C.begin (), C.end ()). Jeśli specjalizujesz się w sortowaniu, aby mieć ten sam efekt, nawet jeśli działa inaczej.

Kodowanie dla Symbiana.

STLPort obsługuje Symbian 9, więc sprawa przeciwko używaniu STL jest słabsza niż kiedyś ("it' s not available " to całkiem przekonujący przypadek), ale STL jest nadal obcy wszystkim bibliotekom Symbiana, więc może być więcej kłopotów niż robienie rzeczy po Symbianie.

Oczywiście na tej podstawie można argumentować, że kodowanie dla Symbiana nie jest " projektem programistycznym C++".

Większość projektów, nad którymi pracowałem, miała bazę kodową o wiele starszą niż jakakolwiek naprawdę użyteczna wersja STL - dlatego zdecydowaliśmy się nie wprowadzać jej teraz.

Jedna z sytuacji, w której może to nastąpić, to sytuacja, w której używasz już zewnętrznej biblioteki, która zapewnia już potrzebne możliwości z STL. Na przykład, moja firma rozwija aplikację w obszarach o ograniczonej przestrzeni i już używa Qt dla zestawu narzędzi do okien. Ponieważ Qt dostarcza klasy kontenerów podobne do stl, używamy ich zamiast dodawać STL do naszego projektu.

Znalazłem problemy z używaniem STL w kodzie wielowątkowym. Nawet jeśli obiekty STL nie są współdzielone między wątkami, wiele implementacji używa konstrukcji bezpiecznych dla wątków (np. ++ do zliczania referencji zamiast stylu przyrostu z blokadą, lub przy użyciu alokatorów innych niż bezpieczne dla wątków).

W każdym z tych przypadków nadal zdecydowałem się użyć STL i naprawić problemy(jest wystarczająco dużo hooków, aby uzyskać to, czego chcesz).

Nawet jeśli zdecydujesz się na tworzenie własnych kolekcji, dobrym pomysłem byłoby stosuj styl STL dla iteratorów, dzięki czemu możesz używać algorytmów i innych funkcji STL, które działają tylko na iteratorach.

Głównym problemem, jaki widziałem, jest konieczność integracji ze starszym kodem, który opiera się na operatorze non-throwing new.

Zacząłem programować C w około 1984 roku i nigdy nie używałem STL. Przez lata zwijałem własne biblioteki funkcyjne i ewoluowały i rosły, gdy STL nie był jeszcze stabilny i brakowało wsparcia między platformami. Moja wspólna biblioteka rozrosła się do kodu innych (głównie rzeczy takie jak libjpeg, libpng, ffmpeg, mysql ) i kilku innych i wolałbym ograniczyć ilość zewnętrznego kodu do minimum. Jestem pewien, że teraz STL jest świetny, ale szczerze mówiąc jestem zadowolony z elementy w moim zestawie narzędzi i nie widzę potrzeby w tym momencie, aby załadować go więcej narzędzi. Ale z pewnością widzę wielkie skoki i granice, które nowi programiści mogą zrobić za pomocą STL bez konieczności kodowania wszystkiego od zera.

Standard C++ pozwala implementacjom niektórych operacji iterator na wyrzucanie WYJĄTKÓW. W niektórych przypadkach taka możliwość może być problematyczna. Możesz zatem zaimplementować swój własny prosty kontener, który gwarantuje, że nie wyrzuci wyjątków dla krytycznych operacji.

Wprowadzenie:

STL jest świetną biblioteką i przydatną w wielu przypadkach, ale definitywnie nie rozwiązuje wszystkich sytuacji. Odpowiadam na STL lub !STL jest jak odpowiedź " czy STL spełnia Twoje potrzeby, czy nie?"

PLUSY STL

• W większości sytuacji, STL ma pojemnik, który pasuje do danego rozwiązania.
• jest dobrze udokumentowane
• jest dobrze znany ( Programiści zwykle już o tym wiedzą, wejście do projektu jest krótszy)
Jest testowany i stabilny.
• to jest crossplatform
Jest ona dołączana do każdego kompilatora (nie dodaje trzeciej zależności od biblioteki)
• STL jest już zaimplementowany i gotowy
• STL jest błyszczący, ...

Contras of STL

Nie ma znaczenia, że potrzebujesz prostego wykresu, Czerwono-czarnego drzewa lub bardzo złożonej bazy danych elementów z AI zarządzającej współbieżnym dostępem przez komputer kwantowy. Faktem jest, że STL nie i nigdy nie rozwiąże wszystkiego.

Następujące aspekty to tylko kilka przykładów, ale zasadniczo są konsekwencją tego faktu: STL jest prawdziwą biblioteką z ograniczeniami.

• Wyjątki: STL relay na wyjątkach, więc jeśli z jakiegokolwiek powodu nie możesz zaakceptować WYJĄTKÓW( np. safety critical), nie możesz użyć STL. Racja! wyjątki mogą być wyłączone, ale nie rozwiązuje to konstrukcji przekaźników STL na nich i ostatecznie spowoduje awarię.

• Potrzeba specyficznych (jeszcze nie dołączone) struktura danych: Wykres, drzewo, itp.

• Specjalne ograniczenia złożoności: możesz odkryć, że kontener ogólnego przeznaczenia STL nie jest najbardziej optymalny dla Twojego kodu wąskiego gardła.

• Uwagi dotyczące współbieżności: albo potrzebujesz współbieżności, a STL nie zapewnia tego, czego potrzebujesz(np. blokada reader-writer nie może być (łatwo) używana z powodu dwukierunkowego [] operator). Albo możesz zaprojektować kontener, korzystając z wielowątkowości za dużo szybszy dostęp/wyszukiwanie / wstawianie / cokolwiek.

• STL musi pasować do Twoich potrzeb, ale revers jest również prawdą: musisz zaspokoić potrzeby STL. Nie próbuj używać std::vector w wbudowanym mikro-kontrolerze z 1K niezarządzanej pamięci RAM.

• Kompatybilność z innymi bibliotekami: może się zdarzyć, że z przyczyn historycznych używane biblioteki nie akceptują STL (np. QtWidgets intensywnie korzysta z własnej listy QList). Konwersja kontenerów w obu kierunkach może nie być najlepsza rozwiązanie.

Implementacja własnego kontenera

Poprawne wdrożenie kontenera staje się bardzo szybko ogromnym zadaniem: nie chodzi tylko o zaimplementowanie czegoś działającego, być może będziesz musiał:

• udokumentuj to głęboko, w tym ograniczenia, złożoność algorytmu itp.
• spodziewaj się błędów i rozwiązywanie ich
• przychodzące dodatkowe potrzeby: wiesz, brak tej funkcji, ta konwersja między typami itp.
• Po jakimś czasie możesz chcieć refaktorować I zmienić wszystkie zależności (za późno?)
• ....

Kod użyty tak głęboko w kodzie jak kontener jest definitywnie czymś, co wymaga czasu i powinno być jednak ostrożne.

Korzystanie z biblioteki stron trzecich

Nie STL nie koniecznie oznacza zwyczaj. W sieci jest wiele dobrych bibliotek, niektóre nawet z licencją open-source.

Dodanie lub nie dodatkowej biblioteki stron trzecich to kolejny temat, ale warto go rozważyć.