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ć??
0
0
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 ;)
0
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.
0
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
0
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...
0
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ń :)
0
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).
0
Ja mogę polecić Buildera - w VCL naprawdę fajnie się pisze, szczególnie w porównaniu do winapi...
0
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 :-)
0
@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??
0
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ć.
0
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ć.
0
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...
0
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)...
0
@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ć.
0
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.
0
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
0
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.
0
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.
0
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 ?
0
W d*pach się wam poprzewracało...
0
- 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..
0
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.)