Dlaczego kontenery STL są preferowane w porównaniu z kontenerami MFC?

Question

Poprzednio używałem klas kolekcji MFC, takich jak CArray i CMap. Po pewnym czasie przełączyłem się na pojemniki STL i używam ich przez jakiś czas. Chociaż znajduję STL znacznie lepiej, nie jestem w stanie wskazać dokładnych przyczyn. Niektóre z uzasadnieniem takich jak:

1. Wymaga MFC: nie posiada, ponieważ inne części mojego programu korzysta MFC
2. Jest to platforma zależne. Nie posiada, bo uruchomić mojej aplikacji tylko na oknach (Nie potrzebne do przenoszenia)
3. to jest zdefiniowane w standardzie C++: OK, ale pojemniki MFC nadal pracować

jedynym powodem mogę wymyślić to, że można używać algorytmów na pojemnikach. Czy jest tu jakikolwiek inny powód, którego tu brakuje - co sprawia, że ​​kontenery STL są lepiej dostępne niż kontenery MFC?

Answer 1

Ronald Laeremans VC++ kierownika jednostki produktu, nawet said to use STL w czerwcu 2006 roku:

I szczerze zespół daje tę samą odpowiedź. Klasy kolekcji MFC są dostępne tylko w celu zapewnienia kompatybilności wstecznej. C++ ma standard dla klas kolekcji i jest to biblioteka standardów C++. Nie ma technicznych wad w używaniu dowolnej standardowej biblioteki w aplikacji MFC.

Nie planujemy wprowadzania istotnych zmian w tym obszarze.

Ronald Laeremans
Działając jednostkę produktu Menedżer
Visual C++ zespołu

Jednak w pewnym momencie w którym się pracuje na jakimś kodem, który biegł na etapie instalacji systemu Windows, nie wolno było używać pojemników STL , ale powiedziano mi, żeby zamiast tego używał kontenerów ATL (a właściwie w rzeczywistości CString, który, jak sądzę, nie jest w rzeczywistości pojemnikiem). Wyjaśnienie było takie, że kontenery STL miały zależności od bitów środowiska wykonawczego, które mogą nie być faktycznie dostępne w czasie, w którym kod musiał zostać wykonany, podczas gdy te problemy nie istniały dla kolekcji ATL. Jest to raczej specjalny scenariusz, który nie powinien wpływać na 99% kodu tam.

Answer 2

Faktycznie you can use STL algorithms on some of MFC containers as well. Jednak kontenery STL są preferowane z innego bardzo praktycznego powodu: wiele bibliotek zewnętrznych (Boost, arabica, Crypto ++, utf-cpp ...) jest zaprojektowanych do pracy ze STL, ale nie ma pojęcia o kontenerach MFC.

Answer 3

Jest to przypadek, w którym narzędzia działają w odniesieniu do pracy, którą chce się wykonać, a "lepiej" jest terminem subiektywnym.

Jeśli potrzebujesz używać kontenerów z innym zgodnym z normami kodem, lub jeśli kiedykolwiek będzie to kod współużytkowany na różnych platformach, kontenery STL są prawdopodobnie lepszym rozwiązaniem.

Jeśli masz pewność, że Twój kod pozostanie w MFC-land, a pojemniki MFC będą działać dla Ciebie, dlaczego nie będziesz ich nadal używać?

Kontenery STL nie są z natury lepsze niż kontenery MFC, jednak ponieważ są częścią standardu, są bardziej przydatne w szerszym zakresie kontekstów.

Answer 4

kontenery STL:

• Czy wydajność gwarantuje
• Może być stosowany w algorytmach STL które również mają gwarancje wykonania
• można wykorzystać przez stronę trzecią C++ bibliotek, takich jak Boost,
• Are standardowe i prawdopodobnie przeżyją zastrzeżone rozwiązania.
• Zachęcaj do generycznego programowania algorytmów i struktur danych. Jeśli napiszesz nowe algorytmy i struktury danych zgodne ze STL, możesz wykorzystać to, co STL zapewnia już bez żadnych kosztów.

Answer 5

• kompatybilności z innymi bibliotek (jak impuls) w składni współdziałaniem i paradygmatu. To niebanalna korzyść.
• Użycie STL rozwinie zestaw umiejętności, który będzie bardziej przydatny w innych kontekstach. MFC nie jest już tak szeroko stosowane; STL to.
• Użycie STL rozwinie nastawienie, które może (lub nie musi) okazać się przydatne w kodzie, który sam napiszesz.

Używanie czegoś innego niż STL nie jest jednak z natury złe.

Answer 6

Myślę, że sprowadza się to do prostego pytania: komu bardziej ufasz? Jeśli masz zaufanie do firmy Microsoft, kontynuuj korzystanie z wariantów MFC. Jeśli ufasz branży, użyj STL.

Głosuję za STL, ponieważ kod działający w systemie Windows może być jutro przeniesiony na inną platformę. :)

Answer 7

Zawsze wolę używać więcej standardowych/kompatybilnych bibliotek, ponieważ mogę mieć przyszłe projekty, w których mogę ponownie wykorzystać część kodu. Nie mam pojęcia, z jakich bibliotek będą korzystać przyszłe projekty, ale mam większe szanse na ponowne wykorzystanie kodu, jeśli używam standardowych/kompatybilnych rzeczy.

Im więcej korzystam z biblioteki, tym szybciej i wygodniej. Jeśli mam poświęcić czas na naukę biblioteki, chcę się upewnić, że pozostanie ona w pobliżu i nie jest powiązana z konkretną platformą lub strukturą.

Oczywiście, mówię o tym wszystkim, zakładając, że moje wybory są dość podobne, jeśli chodzi o wydajność, funkcje i łatwość użytkowania. Na przykład, jeśli klasy MFC są wystarczająco znaczącą poprawą w tych obszarach, użyłbym ich zamiast tego.

Answer 8

• STL ma więcej rodzajów zbierania niż MFC
• Visual Studio (2008+) debugger wizualizuje STL znacznie lepiej niż MFC. (AUTOEXP.DAT magia może naprawić - ale jest to ból Nic podobnego debugowania debugger kiedy przykręcić ...)

Jedna dobra rzecz z MFC jest to, że nadal istnieje duży korpus Kod MFC tam. Inne odpowiedzi mówią o kompatybilności z innymi firmami. Nie zapomnij o materiałach innych firm opartych na MFC.

Answer 9

Kontenery MFC pochodzą z CObject i CObject, ponieważ operator przypisania jest prywatny. Znalazłem to bardzo denerwujące w praktyce.

std::vector, unlinke CArray gwarantuje, że blok pamięci jest ciągłe, więc można współdziałanie z interfejsów programowania C prościej:

std::vector<char> buffer; 
char* c_buffer = &*buffer.begin(); 

Answer 10

Ponieważ biblioteka, która wykorzystuje iteratory łączenie sekwencji jakiegokolwiek rodzaju z algorytmami tak, że A) wszystkie sensowne permutacje są możliwe, a B) uniwersalne, to (kiedy myślisz o swojej koncepcji biblioteki kontenerów, tak jak było 15 lat temu), taki niesamowicie zadziwiający pomysł, że został prawie całkowicie zdominowany wody wszystko inne w ciągu mniej niż dziesięciu lat?

Poważnie, STL ma swoje wady (dlaczego nie ma zakresów zamiast iteratorów?) I że idiom typu "usuń-usuń" nie jest całkiem ładny, ale jest oparty na genialnym pomyśle i istnieją bardzo dobre powody, dla których nie musimy się uczyć nowa biblioteka kontenerów/algorytmów za każdym razem, gdy rozpoczynamy nową pracę.

Answer 11

Oprócz wspomnianych aspektów: dobrze obsługiwany, dostępny w standardzie, zoptymalizowany pod kątem wydajności, przeznaczony do użycia z algorytmami, mogę dodać jeszcze jeden aspekt: ​​bezpieczeństwo typu i mnóstwo kontroli podczas kompilacji. Nie możesz sobie nawet wyobrazić, jak wyciągnąć double z .

Answer 12

Nie odrzucałbym całkowicie argumentu przenośności. Tylko dlatego, że używasz MFC dzisiaj, nie oznacza, że ​​zawsze będziesz. I nawet jeśli piszesz głównie dla MFC, niektóre z twoich kodów mogą być ponownie wykorzystane w innych aplikacjach, jeśli są bardziej ogólne i oparte na standardach.

Myślę, że innym powodem do rozważenia STL jest to, że jego konstrukcja i ewolucja skorzystała z bibliotek, które miały wcześniej, obejmują MFC i ATL. Tak wiele rozwiązań jest czystszych, bardziej użytecznych i mniej podatnych na błędy. (Chociaż wolałbym, żeby mieli lepszą konwencję nazewnictwa.)

Answer 13

Zakłada się obecnie, że twórcy C++ są co najmniej przelotnie zaznajomieni ze STL. Nie dotyczy to kontenerów MFC. Jeśli więc dodasz nowego programistę do swojego zespołu, łatwiej będzie Ci znaleźć takiego, który zna STL niż kontenery MFC, dzięki czemu będzie mógł wnieść swój wkład natychmiast.