Klasy w C++ a WinApi

Czy znajomosc klas w C++ jest przydatne podczas programowania w WinApi? Chodzi o to ze teraz ucze sie pisac dla okienek konsolowych w Visualu, a chce przejsc na WinApi po opanowaniu podstaw. Czy klasy sa w ogole potrzebne w WinApi? Czy warto sie tego uczyc? To samo dotyczy OpenGL

Nie sa potrzebne, ale jak wiadomo programowanie obiektowe sporo ulatwia prace wiec i tak warto poznac jego tajniki :)

Ale mi chodzi o to czy one w ogole sie przydaja, czy w duzym stopniu (tak jak np. w dosowych programikach)?

To jak napiszesz program zależy tylko i wyłacznie od ciebie. Czy będą to obiekty (klasy) i metody, czy zwykłe struktury i funkcje je odrabiające to tylko i wyłacznie twoj wybor.

// A na pytanie, czy warto sie uczyc programowania obiektowego...
Z mojego punktu widzenia nie warto... Im mniej będziesz wiedział, tym mniejszą konkurencje dla mnie na rynku pracy będzisze stanowił. Z drugiej strony, jeśli choc raz uzyłes komponentu, to juz programowałes obiektowo.

Znajomosc projektowania i programowania obiektowego sie BARDZO, BARDZO, BARDZO przydaje, zwlaszcza w WinAPI i wszedzie tam, gdzie jest graficzny interfejs uzytkownika. Trudno przecenic zalety OOP. Sprawne poslugiwanie sie obiektowoscia przynosi bardzo duze korzysci - znacznie skraca czas pisania programow, zwieksza ich czytelnosc, zmniejsza podatnosc na bledy, umozliwia latwiejsza pielegnacje i rozbudowe. W przypadku aplikacji okienkowych np. w WinAPI czyste C sie bardzo slabo sprawdza. Nie znam osoby, ktora by pisala takie rzeczy w czystym C, bez klas. To narzedzie nie nadaje sie do tego celu.

Programowanie w WinApi samo w sobie jest liniowe, ale obiektowosc naprawde moze pomoc, gdy bedziesz chcial napisac jakiegos wrappera. Najlepszy bedzie przyklad:
[code]
[...]
CImage myImg;
[...]
myImg.CreateFromFile(g_Hdc, "cpp_rulez.bmp",FILETYPE_BMP);
myImg.Draw();
myImg.Delete();

[/code]
Tak mozesz zrobic dla wszystkiego, dla pior, pedzli, obslugi plikow, watkow, no po prostu dla wszystkiego, ale uzycie nie tyle samej obiektowosci co polimorfizmu moze dac naprawde wielkie mozliwosci.
Po co meczyc sie z jakimis funkcjami. Ladnie to wszystko zapakuj w rozne klasy, wrzuc do bibliotek, a pozniej dodawaj do projektow. Przy prostych aplikacja moze to i nie jest jakis duzy plus, ale przy wiekszych naprawde zrozumiesz, ze obiektowosc, to jedyna droga prowadzenia duzych projektow.

No wszystko pieknie i ładnie...

Z większością sie zgodzę poza jednym... Mamy np. komunikat... Ot choćby WM_ERASEBKGND i chcemy, żeby za tło client area robiło kilka bitmap, napis, jakis brush jeszcze w miedzyczasie. I przy każdym uzyciu klasy, stworzeniu kontekstu, drugiego kompatybilnego, przypisanie obiektu (tzn różnie to bywa, no ale przypuścmy) narysowanie i zamkniecie obu, wcześniej skopiwanie map (to jest opis wywalenia bitmapy na ekran), sporo czasu zajmie prawda? Bo o to w klasach chodzi, żeby były hermetyczne, bezpieczne, sprzątały po sobie i nie śmieciły w systemie. A gdy zrobic to 'liniowo' to okaże się, że wywołań funkcji (metod), odwołań do pamięci, tworzenia kontekstów, przypisywania im obiektow zwalniania itepe itede jest sporo mniej.

Więc moja konkluzja jest taka... Gdzie można klasy stosować, to można, a gdzie nie trzeba, to po co na siłe, jesli będzie na pewno wolniej i z większą ilościa uzytaj pamieci? To nie jest kwestia, czy stosować, czy nie, tylko kwestia gdzie i dlaczego. Bo można dla jednej linii tworzyc cały komponent, wywoływać konstruktory, metody, destruktory, ale po co?

// Fakt trzeba się starać, gdy się pisze 'liniowo' (ten cudzysłów jest cały czas specjalnie, bo to nie ma nic wspólnego z propramowaniem liniowym, to programowanie strukturalne), a w właściwie strukturalnie, trzeba sie bardziej starać i więcej przykładać, ale efekty bywają o niebo lepsze ;p

I przy każdym uzyciu klasy, stworzeniu kontekstu, drugiego kompatybilnego, przypisanie obiektu (tzn różnie to bywa, no ale przypuścmy) narysowanie i zamkniecie obu, wcześniej skopiwanie map (to jest opis wywalenia bitmapy na ekran), sporo czasu zajmie prawda? Bo o to w klasach chodzi, żeby były hermetyczne, bezpieczne, sprzątały po sobie i nie śmieciły w systemie. A gdy zrobic to 'liniowo' to okaże się, że wywołań funkcji (metod), odwołań do pamięci, tworzenia kontekstów, przypisywania im obiektow zwalniania itepe itede jest sporo mniej.

No to odpowiem Twoimi slowami: Nikt Ci nie kaze zle programowac.
W C++ takie rzeczy robi sie wlasnie duzo lepiej niz w czystym C.

Więc moja konkluzja jest taka... Gdzie można klasy stosować, to można, a gdzie nie trzeba, to po co na siłe, jesli będzie na pewno wolniej i z większą ilościa uzytaj pamieci?

Kolejny mit o C++ rozpowszechniany przez niedoszlych programistow C++. Wlasnie okienkowe interfejsy graficzne to jest jedno z najwlasciwszych zastosowan programowania obiektowego. Jakie dodatkowe zuzycie pamieci? W praktyce jest ono pomijalnie male i zwykle rekompensowane przez mozliwosc uzycia Garbage Collectora, ktory gwarantuje, ze nie masz wyciekow pamieci. Jaki narzut czasowy? Na co? Wywolanie metody zajmuje tyle samo czasu co zwyklej funkcji w C.

To nie jest kwestia, czy stosować, czy nie, tylko kwestia gdzie i dlaczego.

Prawda. Tylko w takim razie gdzie wg Ciebie obiektowosc sie sprawdza?

Bo można dla jednej linii tworzyc cały komponent, wywoływać konstruktory, metody, destruktory, ale po co?

Zeby kod wygladal ladnie, byl przejrzysty, mial mniej bugow i zeby przede wszystkim SZYBCIEJ SIE PISALO. Po prostu, ZEBY MIAL WYZSZA JAKOSC.

Kolejny mit o C++ rozpowszechniany przez niedoszlych programistow C++. Wlasnie okienkowe interfejsy graficzne to jest jedno z najwlasciwszych zastosowan programowania obiektowego. Jakie dodatkowe zuzycie pamieci? W praktyce jest ono pomijalnie male i zwykle rekompensowane przez mozliwosc uzycia Garbage Collectora, ktory gwarantuje, ze nie masz wyciekow pamieci. Jaki narzut czasowy? Na co? Wywolanie metody zajmuje tyle samo czasu co zwyklej funkcji w C.

A wiesz w ogóle co to jest debugger i jak sie go uzywa ? Wiesz, że zanim wywołasz metodę, to zawsze jest wywoływany konstruktor, a przy nieszczeniu obiektu destruktor (nawet jesli obiekt jest stayczny) ?

// Jakość kodu to nie ładny tekst, tylko wysoka efektywność. I zejdż już ze mnie, oki? Klasy... eh, szkoda gadać w ogóle z tobą, dobra, niech ci będzie napisze... sa jak najbardziej spoko, gdy masz komunikację z urządzeniami, gdzie i tak czekasz na dane, ale nie tam, gdzie trzeba wykonać coś w jak najkrótszym czasie. EOT (End Of Topic i będe tego rygorystycznie przestrzegał, jesli jeszcze raz przyczepisz sie do mnie, to usuwam post). Ty idziesz swoją drogą, kupujesz lepszy sprzet, jesli ci program za wolno chodzi, a ja walczę o każdy bajt i piszę programy takie, które mają szanse zadziałac na 386 (bo Warszawa to nie cały świat, po za nia ludzie jeszcze wciąz mają 'wynalazki', nawet u ciebie na wydziale na zwierzyńcu podejrzewam, że wciąz są te same komputery, na których ja sie uczyłem), więc niech tak będzie, twoj i moj wybór, ale dyskusję uważam za zakończoną.

Poczytaj sobie C++ bez cholesterolu http://www.intercon.pl/~sektor/cbx/ to moze zrozumiesz zamiast chrzanic o konstruktorach i destruktorach. Palnales niezla bzdure z tymui staticami i chyba to wlasnie Ty nie umiesz uzywac debuggera, a co gorsze nie masz pojecia o C++ i tylko gadasz, zeby inni mysleli jaki Ty madry.

Ja juz nie mam do Ciebie sily.
EOT.

//od flabry

1. Masz tylko 3 odpowiedzi (nie pytania, o ich poziomie merytorycznym nawet nie wspomne) w tym dziale, które zawieraja jakikolwiek kawałek kodu, reszta to wodolejstwo. To nie jest forum literatów.
2. Czepiasz sie cudzych odpowiedzi, a sam nie odpowiadasz na temat.
3. Jeśli juz zaczynasz dyskusje, ta twoim obowiązkiem jest wytaczać logiczne argumenty, a ty z postu na post piszesz coraz większe dyrdymały.
4. Ja nie opuszczę forum, a ktoś w związku z tym, że nie możesz sie odczepić, musi.
5. Nie masz siły, forum cię wyczerpuje, więc nie przychodz tu

Zastanów sie, czy warto wracać, a jesli wrócisz, to zacznij odpowiadać na pytania autorów postów i to w sposób konkretny.
// Co do c++ bez cholesterolu... Mam pozwolenie autora na skopiowanie i publikacje na swojej stronie, jak chcesz dowód, to ci maila wysle.
// Next one chory argument? Coś ty sobie znów wykoncypował nowego? Jakie 'static'? Czy ja o tym kiedykolwiek wspomniałem? Czy w ogóle wiesz do czego słuzy static? [mf]

//croolik, powaznie, mimo ze nie znam jezyka C i C++ to wyczuwam w twoich postach czysta teorie ksiazkowa. Nawet jezeli znasz te jezyki to jest to tylko sama teoria, ja jak czegos nie znam to milcze :)
Ludziom na forum malo potrzebne sa teorie i wodolejstwo..to oferuja nam na studiach
Zauwaz ze posty flabry to w 90% kody zrodlowe...
BTW przejrzalem wszystkie twoje posty i nigdzie nie zauwazylem konkretnej odpowiedzi... np:

"(...)Palnales niezla bzdure z tymui staticami i chyba to wlasnie Ty nie umiesz uzywac debuggera(...)"
, i co to ma oznaczac? dlaczego palnal bzdure? - lofix

Panowie, przginacie.

Powiedzmy, ze programowanie obiektowe to gry/programy 3D, a strukturalne to 2D. Jak spojrzymy na rynek gier to 3D jest wszedzie wrzucane. Ma niesamowite zalete: jest piekne dla oka i zazwyczaj bardzo wygodne. Ale ten, kto z was probowal desktopu 3D wie, ze do tego sie ono nie nadaje. A moze edytor tekstowy takze w 3D?

Flabra ma racje co do tego, ze nie wszedzie powinno uzywac sie obiektowosci. Tam gdzie zalezy nam na szybkosci i rozmiarze lepiej sprawdza sie programowanie strukturalne. Faktem jest, ze stosujac techniki programowania obiektowego sa znacznie mniejsze szanse na popelnienie bledow. Obiektowosc stawia na pierwszym miejscu bezpieczenstwo i niezawodnosci, to czego nam caly czas brakuje w programach. Strukturalnosc stawia na szybkosc. I jakby nie patrzec programowanie obiektowe zazwyczaj generuje wolniejszy i wiekszy kod. To jest koszt, jaki trzeba poniesc, aby miec czytelny latwy do refaktoryzacji kod. Przy duzych projektach, w ktorych czas i rozmiar (z natury rzeczy) nie gra tak wielkiej roli programowanie obiektowe jest niezastapione. Ale pisanie np. sterownikow czy systemu operacyjnego ma praktycznie tylko jedna droge: programowanie strukturalne (nie licze asm, ktory daje znacznie wieksza swobode i mozna uzywac zarowno obiektowosci jak i strukturalnosci, lub w ogole co sie chce).

croolik prezentuje postawe jednego z moich wykladowco: Java jest szybka... u mnie na procku 2000. A my na zajeciach meczymy sie z nia na 500 :(
Flabra jest blizszy mojemu wariactwu: wykorzystac sprzet w 101% Program na 386 ma smigac.
A prawda jest taka, ze warto znac podstawy roznych metodologii programowania i dobierac je zaleznie od problemu i wlasnych zamilowan. Bo zaden Garbage Collector nie wyreczy programisty w pilnowaniu swojego kodu i nie zawsze warto jest meczyc sie 2 razy dluzej nad pisaniem superwydajnego kodu, jezeli program jest do jednorazowego uzytku.

C++ nie wprowadza narzutow. Programisci wprowadzaja narzuty nie umiejac korzystac z udogodnien C++. Dyskusja jest bezsensowna. Nie padl ani jeden argument za tym, ze kod w C++ wykonuje sie wolniej niz w C. Dlatego drech: nie marnuj czasu na pisanie tysiecy linii w WinAPI. Naucz sie C++, sciagnij sobie obiektowe biblioteki do robienia okienek (QT, GTK, VCL, wxWidgets) albo sam sobie takie napisz na bazie WinAPI tak jak polecil Ci w tym watku Anonim. Zaoszczedzisz sobie sporo czasu, a przy okazji nauczysz sie czegos pozytecznego.

C jest dla tych co nie potrafia programowac w C++ i dla studentow bo musza
pisac na zaliczenie jakies pierdulki. Winapi jest do d***.
Nawet Microsoft w tym nie pisze tylko używa MFC i.NET. Z Waszym
uwielbieniem dla programowania strukturalnego jestescie 100 lat za Murzynami.
Pozdrowienia dla croolika.

// Będę złośliwy... Ty też nie potrafisz odróżniać c od c++ ? [mf]

Jest wolniejsze tylko wtedy, gdy uzywamy gotowych uniwersalnych klas.
Za uniwersalnosc trzeba placic i szybkosc oraz rozmiar kodu jest tutaj ta cena. Oczywiscie, ze korzystajac z podejscia obiektowego i piszac wlasne obiekty mozemy w duzym stopniu uzyskac tak dobry kod jak przy strukturalnym programowaniu (zreszta w wielu przypadkach znacznie efektywniej jest skorzystac z obiektowosci). Nikt tutaj nie mowi, zeby nie uczyc sie programowania obiektowego. Przeciez pierwszy post Flabry to byla ironiczna wypowiedz. Ale chodzi o to, ze odpowiedzia na pytanie zadane w tym temacie jest "nie trzeba uzywac klas", bo taka jest prawda (chociaz jak wiadomo ulatwiaja pisanie).
A co do MFC... to ja rzeczywiscie wole juz WinAPI. VCL tak, Qt tak, ale nie MFC. Moze to tylko ja sie tak o tego zrazilem, ale strasznie mi sie ono nie podoba.

Nawet Microsoft w tym nie pisze tylko używa MFC i.NET.

MFC tesh się opiera na Winapi i bez znajmości Winapi nawet obrazka nie wczytasz