Jaki framework do aplikacje okienkowe

Witam,
od dłuższego czasu uczę się już C++. Przebrnąłem przez programowanie "liniowe", proceduralne jak i obiektowo zorientowane. Teraz chciałbym coś stworzyć "milszego dla oka" - okienkowego. Jako środowiska używam Visual C++ 2008.
Szukałem po internecie informacji na temat tego, jak rozpocząć okienkową przygodę. Znalazłem 3 główne drogi programowania okienkowego w VC++ 2008, mianowicie:
-Windows API
-MFC (Microsoft Foundation Classes)
-Windows Forms Applications

Czyste Windows API nie jest tym, co by mnie interesowało na ten moment (zbyt mała wiedza na ten temat). W przyszłości być może, chciałbym pracować jako programista. Patrząc na oferty pracy dla programistów C++ nie znalazłem nigdzie informacji odnoście wymagań przy programowaniu okienkowym.

Tutaj moje pytanie do Was bardziej zaawansowanych programistów: w co inwestować czas : MFC czy Windows Forms Applications. Może ktoś z Was pracuje jako programista C++ i mógłby powiedzieć jak w firmie, której pracuje, wygląda kwestia programowania okienkowego.

Za wszelkie porada - bardzo dziękuję :)

Znam ludzi którzy robili poważne projekty dla dużych zagranicznych firm. Wszyscy oni korzystali z MFC

O ile mowimy o tym samym Windows Forms to jest to .net, nie do konca to samo co zwykle c++.

MFC odradzam, do WinAPI to nawet z patykiem. W Visualu tak naprawde oprocz sciezki .netowej ciezko o latwopisalne okienkowe aplikacje. Kiedys MFC moze bylo latwe (bo jest - w porownaniu z WinAPI), ale w porownaniu do WinForms czy innych podobnych rzeczy wysiada. Klikanie moze i nie jest trudne, ale debugowanie takich programow to zgroza.

Niestety taka prawda, że pewna część programów - szczególnie starych - jest pisana przy użyciu MFC. Framework potworny i przestarzały, ale kiedyś był i tak fantastyczną alternatywą czystego WinAPI (inna sprawa, że twórcy i tak zakładali znajomość WinAPI u programisty używającego MFC).

Dzisiaj jeśli się tylko da - unikaj tego bagna, zanim skończysz uczelnię i zaczniesz pracę, to o MFC będą pamiętać tylko dinozaury takie jak ja, a i Windows Forms nie będzie najnowsze. Zdecydowanie od razu skacz na WM, jeśli nie chcesz później żałować kilku lat spędzonych na nauce frameworka, który dawno umarł (bo już teraz ma lata świetności za sobą).

Gdybyś rozglądał się za jeszcze innymi bibliotekami do okienków, to poleciłbym Qt4. Również ma wsparcie dużej firmy, szeroko wykorzystywany komercyjnie, cross-platform, obecnie chyba najnowocześniejsza architektura ze wszystkich dostępnych dla C++. Ale to tak na boku wspominam.

johny_bravo napisał(a)

MFC odradzam, do WinAPI to nawet z patykiem.

Wiele firm korzysta z MFC, więc warto znać, jeśli planuje się pracę na stanowisku programisty. Podstawy WinAPI mogą się przydać, w końcu od nadmiaru wiedzy jeszcze nikt nie umarł (chyba ;-P ).

Nie wiem czy mi się zdaje, ale po wielkim szumie wokół .NET, MS znów promuje MFC?

A tak nie mówiąc już o MS, okna fajnie można kodzić np. w QT

laki32 napisał(a)

Wiele firm korzysta z MFC, więc warto znać, jeśli planuje się pracę na stanowisku programisty.

Korzysta z powodow wymienionych przez Ranidesa. Ja tez na codzien w pracy pisze w MFC. Pisalibysmy w .NET gdyby tylko dalo sie tak latwo stary projekt przepisac na .NET w czasie krotszym niz 2 lata :P

Nie wiem czy mi się zdaje, ale po wielkim szumie wokół .NET, MS znów promuje MFC?

Skad takie informacje? MFC to byl niewypal i sam MS sie do tego przyznaje. Chcieli dobrze, ale polaczyli podejscie obiektowe z metodologia WinAPI i to nie bardzo mialo szanse sie udac. Gdyby bylo w pelni obiektowe, to juz byloby dobrze. A tak pisanie w tym jest meczace, zmiana i rozszerzanie aplikacji jeszcze gorsze. Da sie oczywiscie, ale dla nowego projektu w zyciu bym MFC nie polecil.

Na wikipedi (ale bez zrodla) mozna znalezc ze MS planuje wydac MFC v10. Kiedyz to zobaczylem i mnie zdziwilo, moze istotnie chca przedluzyc zywot tego cuda. Moze powiazac z .NET.

Teoretycznie jest jeszcze silnik/API WPF. Mozna tez sie pokusic o stosowanie QT albo GTK moze wxWidget. Ale srednio z klikalnoscia w visualu.

Z pewnoscia potwierdzam zdanie (osobiscie, bez poparcia), ze MFC nie warto. Jesli juz to lepiej liznac WinAPI bo MFC to tylko obudowa w klasy.

Swoja droga ciekawi mnie jeszcze pojawianie sie tej biblioteki gdzieniegdzie ?!
Moze ktos widzial jakies szersze info co z tym bedzie ale na stronach MS lub innych wiarygodnych (blogach pracownikow)?

na MSofcie dostepny jest miniframework WTL, obcenie chyba ver. 8.0 - to jest taki potomek ATL'a, calkiem przyjazny.. wzglednie.. ale nie jest tak rozbudowany jak normalny MFC.. nie wiem czy mozna je krzyzowac zeby korzystac w WTL z komponentow MFCowych, pewnie tak.. ale nie wiem czy nie beda sie gryzly

reichel napisał(a)

Jesli juz to lepiej liznac WinAPI bo MFC to tylko obudowa w klasy.

Dobrze napisane - WinAPI obudowane w klasy, bo obiektowosci w MFC sie nie dopatrzysz. Jak kilka osob wyzej, rowniez polece QT4. Darmowa, rowniez do wykorzystania komercyjnego, posiada mnostwo ficzerow i co najwazniejsze ostatnio jej rozwoj ruszyl z kopyta, jak Nokia zainwestowala w nia swoje pieniadze.

Biblioteka tych od gumiaków/wxWidgets/GTK+. MFC to dinozaur, WinAPI jeszcze większy, Windows Forms niezbyt przenośne.

ah tak.. bo MFC i WinApi czy WinForms* sa w ogole chociaz troche przenosne?:)

*nie tykam tematu Mono:)

quetzalcoatl napisał(a)

ah tak.. bo MFC i WinApi czy WinForms* sa w ogole chociaz troche przenosne?:)

*nie tykam tematu Mono:)
Pamiętajcie, że to nie tylko wada. Dzięki temu na Windowsach WinForms zachowuje się lepiej niż inne przenośne frameworki. Jeśli celujemy w Windowsy to rozwiązania Microsoft'u zazwyczaj będą lepsze.

W sumie to tak, a i pod mono całkiem ładnie działa (od niedawna siedzę sobie pod linuchem i winda czuje się niekochana :D). Ale trzeba pamiętać, że jeśli nie to...

Dziękuję wszystkim za odpowiedzi.
Z tego co tu radzicie, wybrałem Qt4.
Jedynie czego nie mogłem odnaleźć to, co zasugerował Ranides:

Ranides napisał(a)

Zdecydowanie od razu skacz na WM, jeśli nie chcesz później żałować kilku lat spędzonych na nauce frameworka, który dawno umarł (bo już teraz ma lata świetności za sobą).

Po wpisaniu w googlach WM odnalzałem tylko informacje o Windows Mobile, nie wiem czy to miałeś na myśli czy może źle szukam [???] .

Nie no, bez paniki, nie chciało mi się pisać po raz n-ty pełnej nazwy: Windows Forms i skróciłem - myślałem, że w kontekście pytania (WinForms, MFC,WinAPI) skrót będzie jasny ;)

Ja osobiście preferuję GTK+ ( GTKmm ) bo siedzę na GNOME i podobają mi się jego "obłości". A co do Qt to nie nie mogę się do tego przekonać, że za każdym razem trzeba tworzyć signal dla każdego przycisku :/

mmm...ale ten mechanizm swietnie sie nadaje do tworzenia aplikacji opartej o mvp

No dobra, ale WinForms jest chyba dla C# a w czym oprocz w QT robic pod C++

GTKmm lub wxWidgets. Osobiście preferuję to 1.

W GTK, wxWidgets też trzeba dołączać do programu dlle, jak w Qt?
Też z tego powodu zrezygnowałem z Qt (aplikacja 500kB, dlle ponad 10MB).

@up: A jak wyobrazasz sobie framework z cudami bez bibliotek?

Wierze w cuda :D

uwierz w statyczne linkowanie - wyjdzie exec większy niż 500 KiB, ale mniejszy niż 10 MiB ;)

hck napisał(a)

W GTK, wxWidgets też trzeba dołączać do programu dlle, jak w Qt?
Też z tego powodu zrezygnowałem z Qt (aplikacja 500kB, dlle ponad 10MB).

Biblioteki od MS Ci nie straszne bo nie wiesz, ile ich tak naprawde jest? :]

Nie, nie muszę ich dawać razem z aplikacją.

ma ktoś może statyczne libki qt (4.4)? Kompiluje się od 4 godzin i skompilować nie może ;/

Jeśli kompilujesz za pomocą g++ to masz flagę -lm i wtedy łączy statycznie.

wxWidgets statycznie i bez runtime Visuala skompilowany w Visual C++ 2008 to ~1 MB, po upx ~400 kB minimalnie.
Z tym ze na rozmiar raczej bym nie zwracal uwagi, jak ci zalezy na rozmiarze to pisz w winapi w C (Pelles C - rozmiar exeka 2 KB :P), a jeszcze lepiej w asm.

Moglibyście coś więcej na temat tego statycznego linkowania powiedzieć?
Kompiluję tak:

g++ -lm -L D:\qt\lib -I D:\qt\include -lQtGui4 -lQtCore4 -lqtmain -o prog main.cpp

Ale dalej potrzebuje DLL'a.

Co do MFC to wcale nie jestem pewien ze tak sie z tego wycofuja, skoro dodawane sa nowe funkcje, na przykład możliwość tworzenia interfejsu opartego na wstążkach (jak w Office 2007), czego nawet pod .NET nie ma. I w ogole wydaje mi sie, ze dodali to dopiero w SP1 dla Visual Studio 2008 - wczesniej nie bylo, ale jezeli sie myle to niech mnie ktos poprawi.