Popularna etyka programistyczna mówi, że bibliotek nie należy się uczyć na pamięć. Od tego są te wszystkie dokumentacje. W imię tej zasady nie musisz znać na pamięć wszystkich nazw, np. trybów otwarcia: std::ios::app.
Wraz z ilością zrealizowanych projektów i korzystania z biblioteki nazwy same będą wchodzić do głowy.
Należy też zaznaczyć, że korzystanie z bibliotek, np. pisanie aplikacji w C#, w technologii .NET i korzystanie z Windows Forms to nadal tylko programowanie w C#. Nauka o tym jak stworzyć okienko windowsowe z progress barem nie ma nic wspólnego z nauką języka programowania.
Nauka bibliotek to całkowicie inna bajka. Dużo ciężej jest opanować w pełni jakąś bibliotekę niż poznać i zrozumieć składnię jakiegoś języka programowania. Głównie dlatego, że wszystkie języki programowania mają cechy wspólne. Pętla for w C++ to pętla for w Pythonie.
Z bibliotekami nie jest już tak łatwo. W bibliotece Qt masz "jakieś" sloty i sygnały do obsługi wydarzeń. Pisząc w C#, w Windows Forms czy WPF korzystasz z delegatów. W bibliotece SFML są już całkowicie inne funkcje do odbierania takich wydarzeń W skrócie: napisanie pętli for w 2 innych językach to kwestia jednokrotnego spojrzenia na składnię i już umiesz. Natomiast obsłużenie kliknięcia myszy w innych bibliotekach, to już musisz się zaczytać w dokumentację i zrozumieć jak obsługiwać wydarzenia.
Ogólnie jeśli umiesz bardzo dobrze C++, to możesz już teraz pisać w C# czy w Javie z pomocą Google. Teraz może Ci się wydawać to nieprawdopodobne, ale można najpierw wybrać bibliotekę / silnik w którym chce się programować, a dopiero do niego "douczyć" się języka. Tak było w moim przypadku z Unity, do którego skrypty pisze się w C# oraz animacje Flash, które oskryptowuje się w JavaScripcie.
Dochodzimy tutaj do bardzo ważnej kwestii. Znajomość samego języka jest bezużyteczna z praktycznego punktu widzenia. Co komu po znajomości składni? Twoim zadaniem jako programisty jest wydawanie poleceń komputerowi. Biblioteki graficzne DirectX, OpenGL czy API Windowsa zostały stworzone, aby pośredniczyć w wydawaniu tych poleceń. Dlatego biblioteki trzeba znać i będziesz się ich uczył całe życie :-)
Bibliotek jest multum, niektórzy chcą tylko liznąć po trochę każdej, a inni masterują jedną ulubioną technologię. Sposobem na naukę jest oczywiście tworzenie własnych projektów. Umiejętność pracy z dokumentacją jest tutaj wskazana.
Czy trzeba się uczyć języków programowania tak że np. aby zapisać plik należy dodać bibliotekę (...) i napisać (...)
Jeśli umiesz dobrze C++, to wystarczy, że zaglądniesz na stronę dokumentacji jakiejś biblioteki: przykład
i tam jest wyraźnie zaznaczone, że klasa obsługująca zapis / odczyt z pliku znajduje się w #include <QFileDialog>. Niżej jest lista wszystkich funkcji do obsługi wraz z opisami i przykładami użycia. Zapytasz: a skąd mam znać tę nazwę QFileDialog? No ja 5 minut temu jej też nie pamiętałem. W Google wpisałem: "Qt save file" i już mam na tacy. Tak właśnie wygląda uczenie się nowych bibliotek :-)
Tym samym odpowiadam na ostatnie Twoje pytanie. Ja się właśnie tak uczę programowania. Dokumentacje to kopalnia wiedzy, ale żeby było jasne: nie zawsze wystarczające. To nie oznacza, że książki i podręczniki traktujące o obsłudze jakiejś biblioteki są bezużyteczne. Książki wyjaśniają temat bardziej szczegółowo, przystępniej z praktycznymi przykładami i niekiedy opisują możliwe do napotkania problemy. Najlepiej jak wyuczysz się C++ do perfekcji. Wtedy obiektowe języki pokroju C# / Java nie będą żadnym wyzwaniem. Powiesz sobie, że chcesz napisać program okienkowy w bibliotece WPF i wtedy "przy okazji, po drodze" nauczysz się C#. Ja tak zrobiłem i co prawda nie znam pewnie nawet w połowie możliwości oferowanych przez ten język, ale jestem w stanie w nim programować z różnymi bibliotekami.
Pozdrawiam.