@BartoSAS: Wyjmę z komentarza dla lepszej widoczności, ponieważ ostatni raz coś pół poważnego robiłem w Qt wersji 4.6 i wolałbym, żeby ktoś zweryfikował, albo odniósł się do tego, co napiszę.
cons Qt: "uses ancient paradigms" - wiesz może o co mu chodzi?
Nie wiem, choć się domyślam. Pisząć w Qt ma się wrażenie, jakby autorzy bardzo chcieli sprawić, by programista czuł się jakby programował w javie. Wielgachne klasy z dwucyfrową liczbą metod, wszystkie niemal klasy będące któryś tam listkiem w drzewku dziedziczenia i wszystkie ze wspólnym przodkiem - QObject, klasy typu QAbstract* żadnych namespace'ów (EDIT: Qt5 jakieś się pojawiły), zautomatyzowanie zwalniania pamięci poprzez relację rodzic - dziecko obiektów pochodzących od QObject i przez to rzucające się wszędzie w oczy surowe wskaźniki. Nawet konwencja nazewnictwa jest javowa.
No i jest to trochę nie ce plus plusowe podejście obecnie, silnie obiektowe wzorce i wielkie klasy to nie droga do wydajnego korzystania z tego języka. Podejście Qt jest jeszcze całkiem naturalne jeśli zamkniemy się tylko w obrębie gui (guziki, layouty, dialogi itp.), ale był czas, że każdy feature miał być zamknięty w jednej wielkiej klasie (np. nieobecne już QHttp). Dzisiaj programiści C++ skupiają się raczej by ich kod był bliżej danych na których operują, bez żadnych fikuśnych abstrakcji. Stąd wzrost popularności bibliotek gui typu immediate mode jak dear imgui albo nuklear.
Czy to powód, żeby odrzucać Qt? Oczywiście że nie. Można psioczyć, że kobyła, że wielkie dllki, ale prawda jest taka, że Qt nie ma konkurencji jeśli chodzi o feature'y, wsparcie czy społeczność. Ma też tą, przyjemną cechę, że mimo swojego romiaru próg wejścia jest niski - możesz nie wiedzieć za co odpowiedzialne jest 3/4 frameworka a i tak zrobisz swoje własne gui ;)
No i razem z Qt dostaliśmy QtCreatora, bardzo niedocenianie IDE, które poleciłbym nawet w projektach, gdzie nie używa się Qt.
C++ 
szybki_procesorszybki_procesor