C++/CLI vs QT - co wybrać do aplikacji okienkowych?

Cześć,
powiedzmy, że "nauczyłem" się C++ (tzn. chodzi mi o samą składnię ;P). Teraz chciałbym napisać program okienkowy, który będzie głównie wyświetlał wiele wykresów i danych liczbowych. Mam więc dylemat w którą stronę podążyć by dokonać tego dzieła :). Mam do wyboru:

1. WinApi -> stare ale chyba w miarę proste (już coś poczytałem o tym)
2. bibliotekę QT
3. przejść na C++/CLI i korzystać z windows forms

No i pytanie do Was co Wy byście polecili i dlaczego?
Wszyscy zachwalają C# właśnie z uwagi na WinForms, więc pomyślałem sobie, że C++/CLI to może być dobry pomysł, no i mnie korci ;-).
Chciałem również zauważyć, że język C++ bardzo przypadł mi do gustu i nie chcę go zmieniać na żadne javy, C# czy inne rozwiązania.
Ohh i chyba jeszcze jedna ważna kwestia: chodzi o programowanie tylko pod windowsa - nie interesuje mnie póki co pingwinek ;-).
Z góry dzięki za wasze komentarze!

zapomniałem jeszcze dodać, że programuję w środowisku VS 2013 Express.

Nie wiem jak dla Ciebie ale dla mnie WinApi wydawało się toporne. A na pewno nie łatwe.

Natomiast Qt jest przez cały czas rozwijane. Gdybyś chciał przejść na inną platforme to masz od razu problem z głowy bo kod powinien działać tak samo na różnych targetach. Pisanie w nim (według mnie) jest znacznie przyjemniejsze niż pisanie WinApi. Do tego masz bogatą dokumentacje zebraną w jednym miejscu + liczne przykłady. Szybciej powinienieś zobaczyć satysfakcjonujące rezultaty ( a to jest jednak motywujące ;) ).

Co do C++/CLI nie mam zdania (czytaj doświadcznia :) ).

Jeśli chcesz WinForms to ja raczej bym użył C#, niż C++/CLI. C++/CLI jest pomostem pomiędzy C++ oraz językami CLI i przez to ma wiele dziwnych i nie do końca zrozumiałych elementów składni. Niezbyt też nadaje się do nauki C++.
http://4programmers.net/Forum/C_i_.NET/196733-o_naduzywaniu_c++cli

WinApi jest nieprzyjemne w pisaniu.

Dzięki za odpowiedzi.
Myślałem o używaniu C++/CLI tylko do GUI i prostej grafiki. Całą resztę chciałbym pisać w czystym C++. Natomiast C++/CLI to chyba (z tego co wiem) czysty C++ wzbogacony o pewne mechanizmy, które umożliwiają korzystanie z .NET-u. Mogę z nich korzystać, ale nie muszę. A może się mylę?
Nie chcę się już uczyć kolejnego języka, bo robię to czysto hobbystycznie i szkoda mi na to czasu.

gdybys przeczytal wszystko uwaznie to bys mial odpowiedz na swoje pytanie. Przeczytaj link od @Ktos

WMKowal napisał(a)

1. WinApi -> stare ale chyba w miarę proste (już coś poczytałem o tym)
   WinAPI jest integralną częścią Windowsa, i niemal wszystko inne (włącznie z Qt i WinForms) to biblioteki opakowujące WinAPI.
   Pisanie programów bezpośrednio w WinAPI jest niestety pracochłonne a kod jest mało czytelny.
   Za to więcej się nauczymy o bebechach Windowsa, a napisany program będzie działał szybko i mało pożerał zasobów.

WMKowal napisał(a)

Natomiast C++/CLI to chyba (z tego co wiem) czysty C++ wzbogacony o pewne mechanizmy, które umożliwiają korzystanie z .NET-u. Mogę z nich korzystać, ale nie muszę. A może się mylę?
Jeśli chcesz używać WinForms to musisz, bo WinForms to biblioteka .NETowa. A jeśli chcesz używać czystego C++ bez .NET to kompilowanie programu do CLI nie ma sensu, bo natywny program będzie wydajniejszy.

Ktos napisał(a)

i przez to ma wiele dziwnych i nie do końca zrozumiałych elementów składni
Wszystko staje się zrozumiałe, jeśli się to pozna.

Co do C++/CLI (WinForms) vs Qt: wybrałbym to pierwsze, bo lepiej znam od Qt.
Qt jest według mnie strasznie ciężką kobyłą, w ostatnich wersjach wymagającą absurdalnie wielu DLL-ek (z drugiej strony, .Net jest przecież jeszcze większy, no ale na to się nie patrzy :)).
Za to Qt jest przenośne, program można przekompilować na inną platformę. Przenośność C++/CLI jest żadna, bo na Mono nie ruszy.

Azarien napisał(a):

WMKowal napisał(a)

Natomiast C++/CLI to chyba (z tego co wiem) czysty C++ wzbogacony o pewne mechanizmy, które umożliwiają korzystanie z .NET-u. Mogę z nich korzystać, ale nie muszę. A może się mylę?
Jeśli chcesz używać WinForms to musisz, bo WinForms to biblioteka .NETowa. A jeśli chcesz używać czystego C++ bez .NET to kompilowanie programu do CLI nie ma sensu, bo natywny program będzie wydajniejszy.

Dzięki @Azarien za nieco bogatszą wypowiedź ;)
A czy to nie jest tak, że w C++/CLI jest tak, że mogę używać kodu natywnego i zarządzanego jednocześnie a więc mogę również korzystać z czystego C++?
Bo chodzi mi tylko o stworzenie GUI programu w CLI a całą resztę chciałbym napisać już w czystym C++. Tzn. okienka, przyciski i wykresy mają być w WinForms a reszta, cały mechanizm (obliczenia) programu (główna klasa zadeklarowana globalnie), w czystym C++.
Niestety nie wiem o co chodzi ze spadkiem wydajności - co się w tym zawiera. Wydaje mi się, że kompilacja do CLI nie powinna mieć wpływu na szybkość wykonywanych obliczeń, bo program ma służyć do analizowania danych (dużych ilości). Przykładowo program ma otworzyć plik w którym będą zapisane zmienne do analizy - np. 10 zmiennych po 100 000 danych liczbowych każda i program ma policzyć korelację dla wszystkich par. Czy taki program szybciej się wykona w C++ natywnym niż w CLI? (chodzi o same obliczenia a nie korzystanie z GUI).
pozdrawiam

WMKowal napisał(a):

Bo chodzi mi tylko o stworzenie GUI programu w CLI a całą resztę chciałbym napisać już w czystym C++. Tzn. okienka, przyciski i wykresy mają być w WinForms a reszta, cały mechanizm (obliczenia) programu (główna klasa zadeklarowana globalnie), w czystym C++.

To "mechanizm programu" napisz w C++ i umieść w bibliotece dll, a program z GUI napisz w C++/CLI (chociaż łatwiej i wygodniej w C#).

Przykładowo program ma otworzyć plik w którym będą zapisane zmienne do analizy - np. 10 zmiennych po 100 000 danych liczbowych każda i program ma policzyć korelację dla wszystkich par. Czy taki program szybciej się wykona w C++ natywnym niż w CLI? (chodzi o same obliczenia a nie korzystanie z GUI).

Taki kod może się szybciej wykonać w czystym C++.

A czy to nie jest tak, że w C++/CLI jest tak, że mogę używać kodu natywnego i zarządzanego jednocześnie a więc mogę również korzystać z czystego C++?

Dla każdego pliku .cpp w projekcie można osobno ustawić, czy ma być kompilowany jako C++/CLI czy natywne C++. (prawym na pliku w Solution Explorerze, Properties).

W obrębie jednego pliku (kompilowanego jako C++/CLI) można też sterować dyrektywami #pragma managed i #pragma unmanaged.

Czy taki program szybciej się wykona w C++ natywnym niż w CLI?
Trudno wróżyć, różnica może być żadna, może być 5%, a może być 5×, wszystko zależy od kierunku wiatru.

Ogólna tendencja jest taka, że kod natywny jest szybszy. Z dwóch przyczyn: jedna to większa weryfikacja kodu zarządzanego podczas działania (np. kontrola indeksów tablic) a druga to brak czasu na agresywniejszą optymalizację: kompilator natywny może sobie żuć plik przez kilkanaście sekund, programista poczeka. Kompilator JIT maszyny wirtualnej ma najwyżej ułamek sekundy – właściwa kompilacja ma miejsce dopiero podczas uruchamiania programu, a user by się wkurzał że program tak wolno się ładuje.

Azarien napisał(a):

WinAPI jest integralną częścią Windowsa, i niemal wszystko inne (włącznie z Qt i WinForms) to biblioteki opakowujące WinAPI.

Taki mały offtop. Qt jeszcze do niedawna nie używał natywnych kontrolek, widget'y były rysowane tak żeby wyglądały jak natywne. Stąd takie wynalazki jak QPaintEngine itp. Dopiero od niedawna, dokładnie nie orientuje się od której wersji, zaczęto używać natywnych kontrolek i w sumie nie jestem pewien czy już całkowicie zrezygnowali z rysowania nawet tam, gdzie są dostępne natywne.