Witam z racji ,że rok szkolny zbliża się dużymi krokami chciałem zasięgnąć pewnej porady.Starsi koledzy podpowiedzieli mi ,że z takiego przedmiotu jak programowanie w języku c++ aby uzyskać jakąś lepszą ocenkę(np piątke:P) trzeba będzie zaprogramować w okienkach z użyciem jakiejś biblioteki wybrany problem algorytmiczny(lub w jednym ze środowisk Visual albo Builder).Zacząłem coś czytać Winapi.Nie wiem czego się czepić co było by w porządku na początek.Moglibyście mi coś poradzić??
WinAPI sobie odpuść. Jeśli chodzi o okienka to opcji jest dużo, te popularne i dość łatwe do nauki to choćby:
Builder, Visual, Qt + QtCreator, wxWidgets
Ale proponuję nauczyć sie jednak programować, zabawa w okienka później nie powinna być trudna. W odwrotną stronę już tak miło nie jest ;)
Zbyt dużego doświadczenia w tym nie mam, ale na początek dobre będzie MS Visual Studio i aplikacje MFC. Okienko dialogowe sobie budujesz z klocków, oprogramowujesz tylko konkretny problem.
http://rapidshare.com/files/413478565/MFC1.pdf.html - tutaj masz pdf z mojej uczelni do podstaw programowania, ćwiczenia z MFC z łopatologicznymi instrukcjami.
W WinAPI napisałem jeden program i powiem tyle: nigdy więcej...
Jeśli chcesz koniecznie pisać sam, a nie budować z klocków, to podobno QT jest dobre, ale do celów szkolnych MFC wystarczy w zupełności.
Jeżeli chodzi o programowanie to bawię się tym około roku spoj i różne problemy algorytmiczne ale do tej pory tylko konsolowe programiki...Dzięki za porady
Nie tykaj MFC, gorszej biblioteki zwyczajnie nie ma, jakiś fanatyk Smalltalka dorwał się do C++. O masie chorych ograniczeń nie wspominam. Zresztą to tylko WINAPI przerobione ze struktur i uchwytów na klasy, zamiast przesyłać jako piewszy argument to wywołuje się na jego rzecz metody...
Do podstawowych programów, gdzie GUI jest potrzebne tylko do wprowadzenia 2-3 liczb i wyprowadzenia wyniku chyba i MFC się nada. A tak na marginesie, ciekawe w czym pisane są komercyjne programy. Ktoś się orientuje? Pasuje kiedyś się nauczyć i bardziej profesjonalnych rozwiązań :)
Praktycznie wszystko co popularne się stosuje, od VCL i MFC po Qt i WPF. Kwestia doświadczenia, umiejętności i konkretnych wymagań. MFC, tak jak i Qt, to więcej niż tylko lib do GUI, to pełny framework, jednak jego filozofia jest 'nieco' chybiona.
W tym momencie skłaniałbym się w stronę .NET, ten framework to obecnie de facto standard pod Windows. Jak już musi być C++ to sięgnąłbym po Qt, ma spore możliwości i bindingi dla wielu języków (więc doświadczenie z nim może się przydać później), w tym Pythona (ten zaś dzięki boost::python świetnie się z C++ integruje).
Ja mogę polecić Buildera - w VCL naprawdę fajnie się pisze, szczególnie w porównaniu do winapi...
pozwolę sobie ponarzekać:
Builder
Brak darmowego, poza tym VCL powstało dla Delphi i w C++ wygląda trochę na protezę...
Visual
o MFC już powiedziano, a WinForms i WPF powstały dla C# i w C++ wyglądają gorzej niż VCL
Qt + QtCreator
trochę dziwne środowisko, biblioteka cudna na początku ale potem robi się dziwaczna - bardzo odbiega od nawyków z VCL i WinForms. aplikacja wymaga ogromnych dll-ek.
wxWidgets
nie znam, nie widziałem :-)
@up - swego czasu Builder 6 personal był dołączony do jakiejś gazety, a ja nadal na nim jadę, więc myślałem że da się go zdobyć (prawie)darmo. A do VCL w C++ zastrzeżeń nie mam - owszem, mniej kompinentów bo bcb6 już mocno stary, ale zawsze można coś znaleźć w necie lub przepisać z delphi... A samo przystosowanie biblioteki do cpp - cóż... Wolisz winapi??
Pomijając fakt, że BCB samo w sobie nie trzyma się wytycznych Microsoftu co do tworzenia oprogramowania pod Windows to implementacja VCL też swoje odchylenia i niekompatybilności ma. Poza tym architektonicznie to straszny burdel i kupa dziwnych rozszerzeń C++ aby jakoś to na chodzie utrzymać.
olo16 napisał(a)
@up - swego czasu Builder 6 personal był dołączony do jakiejś gazety, a ja nadal na nim jadę, więc myślałem że da się go zdobyć (prawie)darmo.
Było i dużo nowsze Turbo C++, okrojona wersja środowiska 2006. Ale nie da się już tego aktywować: kto miał i zdążył, ten ma.
owszem, mniej kompinentów bo bcb6 już mocno stary, ale zawsze można coś znaleźć w necie lub przepisać z delphi...
przepisywać to chyba nie trzeba, komponent dla Delphi powinien się w BCB zainstalować.
deus napisał(a)
Pomijając fakt, że BCB samo w sobie nie trzyma się wytycznych Microsoftu co do tworzenia oprogramowania pod Windows to implementacja VCL też swoje odchylenia i niekompatybilności ma. Poza tym architektonicznie to straszny burdel i kupa dziwnych rozszerzeń C++ aby jakoś to na chodzie utrzymać.
Ja nie mam z nim problemów, a samą bibliotekę lubię, ale to już kwestia indywidualna. Natomiast co do wytycznych, to się nie znam, ale patrząc na przykład winapi to chyba ktoś inny powinien im robić wytyczne...
deus napisał(a)
i kupa dziwnych rozszerzeń C++ aby jakoś to na chodzie utrzymać.
A microsoftowy C++/CLI to samo, tylko inaczej... zresztą VCL i WinForms tworzył ten sam człowiek.
Zresztą z czystym C++ coś jest bardzo nie tak, jeśli wszyscy robią do niego rozszerzenia (BCB, C++/CLI, Qt)...
@olo16 - pierwszy z brzegu przykład, tworzenie plików tymczasowych w Program Files, od zawsze w Windows NT zapis do PF wymaga uprawnień administratora (od czegoś jest katalog tymczasowy per user), zaś ustawienia powinny być składowane w folderze użytkownika (bądź HKCU).
Co masz do WINAPI? Wbrew pozorom jest naprawdę dobrze zaprojektowane (pomijając kompatybilność z kodem co ma 20 lat...) niskopoziomowe API, służące za podstawę dla bibliotek wysokopoziomowych.
@Azarien, nieprecyzyjnie napisałem - sugerując .NET nie sugerowałem C++/CLI, ogólnie języki .NET. C++ powoli staje się językiem niszowym, poza tym zwyczajnie nie da się go opanować.
1Jeśli chodzi o pliki tymczasowe w program files, to rzeczywiście jest to jakaś niedoróbka, ale mi nie przeszkadza pracowanie na adminie (argumanty typu "jak wejdzie wirus to z wyższymi uprawnieniami" są dla mnie śmieszne).
deus napisał(a)
Co masz do WINAPI? Wbrew pozorom jest naprawdę dobrze zaprojektowane (pomijając kompatybilność z kodem co ma 20 lat...) niskopoziomowe API, służące za podstawę dla bibliotek wysokopoziomowych.
To może by tego jednak nie pomijać? C już trochę wyszło z mody. A co masz w winapi? Wszędobylskie uchwyty do wszystkiego, których nie rozróżnisz, bo musisz je co chwila rzutować. Wszędzie funkcje globalne, bo oczywiście nie ma klas. Za to jest mnóstwo typedefów i #define żeby programistom zrobić mnogość typów. Cokolwiek samemu zrobisz, musisz usunąć, bo nie ma destruktorów, przez co z funkcji main robi się niezły śmietnik. Nie wspominając o idiotycznie zrobionej kolejce wiadomości - co 2 wiadomość musisz przepuścić przez specjalną funkcję tłumaczącą!
API oznacza "interfejs programowania aplikacji", a nie "interfejs programowania bibliotek". Jeśli chodzi o biblioteki, rzeczywiście jest to dobra podstawa. Ale programów w tym pisać nikomu bym nie życzył. Winapi w swojej roli po prostu się nie sprawdza.
olo16 napisał(a)
deus napisał(a)
Co masz do WINAPI? Wbrew pozorom jest naprawdę dobrze zaprojektowane (pomijając kompatybilność z kodem co ma 20 lat...) niskopoziomowe API, służące za podstawę dla bibliotek wysokopoziomowych.
To może by tego jednak nie pomijać? C już trochę wyszło z mody. A co masz w winapi? Wszędobylskie uchwyty do wszystkiego, których nie rozróżnisz, bo musisz je co chwila rzutować. Wszędzie funkcje globalne, bo oczywiście nie ma klas. Za to jest mnóstwo typedefów i #define żeby programistom zrobić mnogość typów. Cokolwiek samemu zrobisz, musisz usunąć, bo nie ma destruktorów, przez co z funkcji main robi się niezły śmietnik. Nie wspominając o idiotycznie zrobionej kolejce wiadomości - co 2 wiadomość musisz przepuścić przez specjalną funkcję tłumaczącą!
Właśnie Winapi odstraszyło mnie od pisania aplikacji okienkowych w C++. Weź sobie w internecie wyszperaj jak wygląda zwykłe okienko z buttonem 'hello world' zapisane za pomocą Winapi, a jak za pomocą Qt ;) Efekt ten sam, jednak kodu w Qt dużo mniej i jest bardziej zrozumiały.
Mimo wszystko ja i tak wole Jave i pakiety Swing'a :P
olo16 napisał(a)
To może by tego jednak nie pomijać? C już trochę wyszło z mody.
API systemu ma być niezależne od języka programowania, z 'C' są 'zgodne' praktycznie wszystkie.
olo16 napisał(a)
Wszędobylskie uchwyty do wszystkiego, których nie rozróżnisz, bo musisz je co chwila rzutować.
I tutaj masz właśnie programowanie obiektowe, tak, WINAPI to pod wieloma względami OOP. Poza tym uchwytów się nie rzutuje.
olo16 napisał(a)
Za to jest mnóstwo typedefów i #define żeby programistom zrobić mnogość typów.
Po to właśnie masz aliasy typów żeby operować na konkretnych wartościach, nie 'jakimś incie'. W tak dużym środowisku aliasowanie to konieczność. Jeżeli wartości nie są ze sobą powiązane to powinny mieć inne typy, przynajmniej leksykalnie. Popisz np. w Haskellu, może zrozumiesz.
olo16 napisał(a)
Cokolwiek samemu zrobisz, musisz usunąć, bo nie ma destruktorów, przez co z funkcji main robi się niezły śmietnik.
Masz problemy z dekompozycją i odstawiasz tony spagetti code, nad WINAPI spokojnie można zapanować pisząc w sposób przemyślany. Poza tym robić coś więcej w funkcji main? Żartujesz?
olo16 napisał(a)
Nie wspominając o idiotycznie zrobionej kolejce wiadomości - co 2 wiadomość musisz przepuścić przez specjalną funkcję tłumaczącą!
No tak, jakiś Ty biedny, że musisz przekleić 3 linijki z dokumentacji... Poczytaj co te funkcje tak naprawdę robią - przede wszystkim zapewniają elastyczność.
olo16 napisał(a)
Winapi w swojej roli po prostu się nie sprawdza.
Nie sprawdza? Ze wszystkich systemów operacyjnych, z którymi miałem styczność to API podsystemu Windows sprawdza się zdecydowanie najlepiej. Może czas odstawić BCB rozejrzeć się po świecie.
Ad aplikacje okienkowe - no właśnie, bo to niskopoziomowe operacje udostępniające wszystkie możliwości okien, lepiej tego zrealizować się nie da. Nikt nie mówi, że w gołym WINAPI trzeba GUI składać. Qt ma głęboko zaszyte w sobie analogiczne operacje, pod toną abstrakcji.
Zacznijmy od tego, że nie mówię, że winapi jest całkowicie złe, tylko że nie sprawdza się jeśli chodzi o pisanie w nim konkretnych programów.
-
Tego że winapi jest zgodne z C nie można określić inaczej niż: partactwo. Panowie z M$ mogli przygotować odpowiednią wersję do C++. Ale oczywiście to bylo dla nich bez sensu.
-
OOP zapobiega myleniu typów. A tutaj prawie każdy uchwyt to typ hwnd. A jak podasz uchwyt do złej funkcji to co się stanie? Wyjątku na pewno nie wygeneruje, więc co? Wysypie program/system? I weź tu potem programisto szukaj, gdzie pomyliłeś "typy" uchwytów, skoro prawie wszystkie mają jeden typ. Ale zdarzają się takie co mają inne typy (coś z zasobami), i wtedy trzeba rzutować!
-
Tak, tylko jeśli masz 10 różnych aliasów dla char i 20 dla char* to można się w tym tylko pogubić. A gbyby zamiast typedefów bały klasy, to by spałniało swoje zadanie.
-
Fajnie, że przez tą dekompozycję do programu dochodzi kilkaset linijek.
-
Elastyczność? Gdzie tu elastyczność? I tak wszystko się przewala przez tą pętlę... Przeciwko samej pętli wiadomości nie mam nic, ale to jak została zrealizowana w winapi...
-
Mówiłem. Winapi sprawdza się jako podstawa do bibliotek, natomiast pisanie w tym programów to masochizm. Przy czym wszystkie moje argumenty dotyczą właśnie pisania programów - bo jeśli tworzysz bibliotekę, to winapi jest jedyną możliwością i sprawdza się dobrze.
Podsumowując: winapi powstało z myślą o bibliotekach, więc rzucanie nowicjuszy na głeboką wodę jest złym pomysłem - lepiej niech piszą w jakiejkolwiek bibliotece, czy ti VCL, czy qt, czy MFC czy cokolwiek co jest wysokiego poziomu.
olo16 napisał(a)
- Tego że winapi jest zgodne z C nie można określić inaczej niż: partactwo. Panowie z M$ mogli przygotować odpowiednią wersję do C++. Ale oczywiście to bylo dla nich bez sensu.
W czym Ci C przeszkadza i co by Ci dalo C++ takiego, czego C nie da w przypadku WinApi ? Pominmy fakt, ze kompilatora zgodnego z ISO ze swieca szukac, wiec jakie jeszcze "zalety" C++ mozesz wymienic wzgledem C w przypadku tego zastosowania ?
W d*pach się wam poprzewracało...
- Tego że winapi jest zgodne z C nie można określić inaczej niż: partactwo. Panowie z M$ mogli przygotować odpowiednią wersję do C++. Ale oczywiście to bylo dla nich bez sensu.
Ale przeciez skoro cały core systemu (czyli biblioteki udostepniajace główne funkcje zarządzania oknami) eksportują funkcje zgodnie z konwencją C. Gdyby eksportowane były bezpośrednio klasy, to byłoby jeszcze gorzej - bo nie dałoby się tego użyć z żadnym kompilatorem oprócz kompilatora MS.
Więc niskopoziomowe api i tak musi być zgodne z C. Więc "wersja do C++, której partacze nie przygotowali" to i tak by była nakładka na to niskopoziomowe api. Więc jednak jest - najpierw było mfc, teraz .net więc o co chodzi?
I tak, zgadza się - WinApi jest może dość skomplikowane, ale gdyby przyszło ci programować w api X-ów pod linuksa to byś wiedział o czym deus pisze..
othello napisał(a)
Więc niskopoziomowe api i tak musi być zgodne z C. Więc "wersja do C++, której partacze nie przygotowali" to i tak by była nakładka na to niskopoziomowe api. Więc jednak jest - najpierw było mfc, teraz .net więc o co chodzi?
Teraz o nic. Mówiłem a winapi, a nie o mfc i .net. I o ile winapi nie jest dobrym pomysłem do pisania aplikacji, to mfc i .net na tym polu spełniają swoje zadanie.
Mimo to z racji uprzedzeń wolę się trzymać z dala od microsoftowych rozwiązań, i jednak zostanę przy VCL (tak, wiem, to też jest nakładna na winapi. Jak każda biblioteka wysokiego poziomu.)