Do tych co tu piszą w C++

W dniu 2012-01-26 10:31, snipped-for-privacy@poczta.fm pisze:

Polemizowalbym. Basic jest banalnie prosty, do tego ma fantastyczny MSDN i cala mase tutoriali. No i oczywiscie w wersji Express (ktora mi do wszystkiego wystarczala) jest zupelnie darmowy. W Qt tez probowalem cos pisac, jednak pewnych przyzwyczajen nie jestem w stanie przezwyciezyc i szlo mi strasznie ciezko.

Marek Borowski snipped-for-privacy@borowski.com.nospam> napisał(a):

A frameworki bywają już wbudowane w system...

Podaj choć jeden powód dla którego miało by to być:

a) argumentem w tej dyskusji

b) argumentem w dowolnej dyskusji po roku 2000.

Zdawalo mi sie iz temat jest o sensnownosci uzywania winapi. Wiec pisze iz jako UZYTKOWNIK: zdecydowanie WOLE programy w winapi w opisanych juz przeze mnie przyczyn. Dodam jeszcze szczatkowe utilzacje pamieci. Jako programista - wiem doskonale o i ile latwiej i szybciej sie pisze z uzyciem bardziej wysokopoziomowych bibliotek.

Pozdrawiam

Marek

... do pisania małych duperelek korzystajacych z portu COM.

Jesli masz na myśli GC to postęp się poczynił na tyle duży że warto przemysleć stare argumenty. Ponadto Qt nie używa GC. W ogóle dobra abstrakcja nie musi mieć GC. Tu o abstrakcję nad API tylko chodzi.

O co zapewne chodzi autorowi wątku zamiast rozwiązywać zagadki z czeluści MSDNa.

Z punktu widzenia programisty faktycznie nie ma sensu. Zrobienie sensownej oblugi COMow w C# to chwila moment. Zas w czystym winapi sama ich enumeracja zajmuje kilkaset lini. (Sam oba warianty przerabialem).

Piszac o pamieci mialem na mysli wiecej zaladowanych biliotek, wiecej danych. Popatrz sobie na programy Marka Russinovicha to jest dla mnie wzorzec pisania pod windows. Nawet najbardziej rozbudowane programy sa linkowane do kilkunastu dll gdzie hello world pod frameworka moze miec ich ponad setke.

Moze i masz racje.

Pozdrawiam

Marek

Nie, ale idąc tym tropem wychodzi że to cały Windows jest zły. W sumie jest w tym też trochę racji ... :-)

Prawdę mówiąc nie chciał bym pracować z człowiekiem który by nie wiedział ile bajtów ma DWORD. Przy okazji dochodzimy do innego problemu. Po co programista ma w ogóle wiedzieć jak działa komputer? System? Wystarczy że wie w jakiej kolejności trzeba wystukać komendy na klawiaturze (albo gdzie i jak kliknąć myszką) żeby pojawiło się okienko i guzik. Co zrobi taki programista któremu "coś" nie zadziała? Pewnie poszuka innych komponentów/bibliotek, tylko gorzej jak nie znajdzie. Zresztą ten problem nie tylko tyczy się informatyki.

Zacznij uzywać środowisk *obiektowych* a zobaczysz gdzie jest

Ah te obiektowe środowiska... ile rzeczy można zrobić myszką... :-) swoją drogą używam i też lubię. Natomiast do pisania pod WinAPI nie potrzebuję wymówki.

pozdrawiam,

Nie idź dalej tym tropem. WinAPI jest złe. Jest ciężkie, niespójne, zagmatwane, czerpie całymi garściami z lat 80, ma się nijak do nowych języków i technik programistycznych. To niskopoziomowe API systemu, nie istnieje żaden argument aby z niego korzystać wprost poza jakimiś promilami aplikacji wymagającymi ekstremalnych szybkości w brzegowych zastosowaniach.

Prawdę mówiąc nie chciałbym pracować z człowiekiem dla którego napisanie prostego programu do komunikacji po COM wymaga znajomości szczegołów definicji DWORD. *Abstrakcja* jest ważniejsza od znajomości szczegołów implementacji choćby z powodu przenośności, ba, nawet w samym Windowsie.

Przesadzasz. Rzecz w tym po co programista ma wiedzieć jak działa allokator pamięci i co zrobic żeby strcpy się nie wysypało. Otóż nie powinien zaprzatać sobie głowy duperelami bo jego celem jest napisanie kodu który działa. Wydajność, zajętość pamięci są trzeciorzędne, szczególnie dla początkujących. Wazniejsze jest posiadanie zestawu działających kontenerow, obiektowej biblioteki GUI, łatwych do użycia komponentów, bibliotek zapewniających wsparcie w konkretnych zadaniach.

Tak działa Delphi. Początkujący, pozostawiony na pastwę tego środowiska zaczyna pisać ciało funkcji w onclikach i tak juz mu zostaje. Dlatego nie wolno pokazywac go początkującym uczącym się samodzielnie bo uczy mimowolnie złych praktyk.

Wiele rzeczy może, ale w WinAPI znacznie częściej nie będzie mu działać i znacznie gorzej będzie debugować dlaczego.

Pomyliłeś programowanie obiektowe z RAD.

Albowiem?

Przesadzasz :-) WinAPI nie jest złe a już na pewno nie jest niespójne. Bywa czasem upierdliwe, wymaga użycia innych technik programowania i sporej wiedzy o systemie. To są chyba główne powody dlaczego wielu go nie lubi.

O ile dane będą przesyłane otwartym tekstem, to może takiemu programiście udało by się coś napisać.

No tak. Nie ważne jak, ważne że działa. Potem niech się ewentualnie martwi ten co po nim ten kod przejmie. Nie przekonasz mnie że programista nie musi mieć choćby minimum wiedzy komputerze. No chyba że mówimy o programiście HTML'a czy PHP'a.

Nie tylko Delphi, aczkolwiek pisząc to przypomniała mi się pewna sytuacja której byłem świadkiem. W wielkim skrócie człowiek nie był wstanie wdrożyć pewnej funkcji do programu bo komponent z którego korzystał nie oferował takiej funkcjonalności.

Zawsze można zrobić błąd. Jeżeli człowiek umie napisać kod wykorzystujący bezpośrednio WinAPI to z debugowaniem tym bardziej nie będzie mieć problemu.

Napisałeś "obiektowe środowiska". Natomiast nie widzę związku z brakiem możliwości połączenia programowania obiektowego i WinAPI

Programuję w tym od lat, napisałem sporo różnych aplikacji, uzbierałem sobie pokaźną bibliotekę przeróżnych klas (do tego typu programów używam C++, dawniej MASM32), w związku z tym do pisania prostych (i brzydkich) programów nie potrzeba mi nic więcej.

Podsumowując nie jestem wrogiem nowocześniejszych technik programowania, nie zgadzam się tylko że WinAPI jest złe i że programista nie musi znać się na tym co robi.

pozdrawiam,

Bzdura. WinAPI to wpływ wielu koncepcji posklejanych gumą do zucia wliczając w to różne wartości true/false czy funkcje żywcem wyrwane z posixa/unixa wstydliwie chowane w czeluściach msdn. Spójne? Może mam różne definicje.

Programowanie wymagające sporej wiedzy o systemie to promil zagadnień. Zazwyczaj dąży się aby wiedza o systemie była minimalna. Idealnie - programy są niezależne od systemu. *Nawet* na mikrokontrolerach widać taką tendencję.

Wielu nie lubi bo doskonale wie że można za darmo lepiej pod *każdym* względem.

I nie przekonuje. Przekonać jednak mogę że wiedza co to jest DWORD jest

*zbędnym* śmieciem wciskanym przez system operacyjny nie mającym żadnego sensu w programowaniu ogólnym. Każdy rozsadnie napisany program odizoluje typy WinAPI aby nie zanieczyszczały kodu. Qt jest takim przykładem izolacji WinAPI od logiki kodu.

Piszesz o tym że jest wielu miernych programistów. No jest. I co z tego? I co z tego że większość z nich programuje w onklikach w RADach?

Zaryzykuje że *NIGDY* nie pisałeś niczego większego, czyli przynajmniej kilkanaście KLOCów w zespole. Nie trzeba mieć umiejętności programowania WinAPI aby pisać wydajne, skomplikowane aplikacje. Gorzej: wydaje i skomplikowane aplikacje nie biorą się z doskonałej wiedzy hakerskiej o DWORD tylko z algorytmów, wzorców, technik przy których WinAPI jest na poziomie głupawego, płaskiego interfejsu OS który tylko przeszkadza. Z taki wlasnie płaskim, gównianym interfejsem namęczysz się kilka razy więcej pisząc mały programik do odbierania znaków niż z byle-jakim środowiskiem obiektowym.

Obiektowe środowiska to Qt, .NET, Java. Żadne z nich nie wymaga używania RADów. Za to każde wymaga używania obiektów. Dostarczają kilka rzędów wielkości więcej funkcjonalności niż WinAPI. W tym również taką jaką zainteresowany jest autor wątku (łatwe thready, signal-slot, wrapowane Comy).

Oczywiście że nie widzisz. MS tez nie widział i powstalo g... o nazwie MFC. Jesli masz zacięcie do archeologii to możesz dalej tego używać. Pomogło dopiero solidne odizolowanie WinAPI od programisty aby mogły powstać wygodne środowiska .NET. *SOLIDNA* izolacja od kretynizmów WinAPI stoi u podstaw sukcesu C# - wszystko jest spójne bo wreszcie ktoś to zaprojektował.

Wpadleś w typową studnie potencjalu: to co mam jest wystarczające, a więc jest najlepsze, nie ma sensu robić nic lepszego, przecież asm wystarczy do wszystkiego. Porozgladaj się do okoła. Mozna napisać program z tego wątku używają kilku linijek pod warunkiem użycia wlaściwego narzedzia. Nie jest nim niskopoziomowy zestaw funkcji OS jakiegoś systemu operacyjnego. To *najgorszy* wybór ze wszystkich innych, nawet od Delphi.

Trudno. Mamy inne punkty wyjścia do dyskusji. Przy czym ja nigdzie nie pisałem o tym że programista ma się nie znać. Problem w tym, że jeśli programista *naprawdę* dobrze się zna na programowaniu docenia inne rzeczy niż hakerskie zagrywki z 30-letnim WinAPI (w tym roku mamy jubileusz ogłoszenia Win1.0 a wiele funkcji pochodzi koncepcyjnie z tamtych lat).

Staram się przekonać tylko autora, że WinAPI jest rozwiązaniem którego nie powinien nawet kijem dotykać ponieważ *większośc* problemów rozwiazuje mu .NET kilka razy mniejszym nakładem środków.

Pokaż mi gdzie występują te różne wartości dla true/false. Wogóle gdzie Ty tu widzisz POSIX'a??? Te czeluści MSDN to jedna z lepiej opracowanych i ułożonych dokumentacji jakie widziałem.

Oczywiście że można wygodniej, ale nie koniecznie lepiej

Bo ideą Qt jest wieloplatformowość i przenoszalność. Tam nie ma miejsca na niskopoziomowe API w żadnym systemie.

Nie koniecznie musi być miernym programistą. Brak mu podstaw żeby rozwiązać samodzielnie problem na niższym poziomie. To nie nadmiar wiedzy przeszkadza tylko jej brak.

Nie rozmawiamy tu o mnie i niech tak zostanie.

Nie trzeba mieć umiejętności programowania

Jak sam wcześniej zauważyłeś jest to niskopoziomowe API z przed 30 lat. Sam się nie wiele rozwinął od tego czasu, rozwijają się za to framweworki które się na nim opierają. Jeżeli komuś one nie wystarczają, albo ma taki kaprys to niech sobie pisze w WinAPI.

Jeżeli nie masz doświadczenia to na pewno tak

No a cała ta funkcjonalność bierze się z WinAPI. Akurat do komunikacji z peryferiami jak naprzykład COM nie ma nic lepszego od WinAPI. Czym wogóle są łątwe wątki?

A co ma MFC do obiektowości??? Albo nie rozumiesz czym jest obiektowość albo mnie podpuszczasz.

Nic nie stoi na przeszkodzie żebyś w C# pisał pod WinAPI. Sukces C# wynika bardziej z sukcesu .NET no i usunięciu upierdliwości związanych z zarządzaniem pamięcią na którą narzekałeś wcześniej.

Mylisz się. Używam narzędzi i technik adekwatnych do zadania. WinAPI nie jest jedynym co znam. Nawet na 8 bitowych mikrokontrolerach staram się unikać asm'a o ile to możliwe.

Porozgladaj się do okoła. Mozna napisać

Można. W WinAPI myślisz że to zajmie więcej linijek?

To *najgorszy* wybór ze wszystkich

Zgadzam się, natomiast to czy WinAPI nie powinien dotykać kijem niech sam oceni.

pozdrawiam

Po pierwsze masz dwa typy BOOL i BOOLEAN.

Po drugie od groma funkcji ma odwrócona logike, pierwsza z brzegu:

Zwracanie bledu nie tłumaczy w tym przypadku niczego bo nie należy z niego korzytać. Mozna odczytać sobie jakieś pole dodatkowo żeby mieć pewność. Nie można użyć GetLastError - bo nie. Spójność pełną gębą. Przez pół MSDNa.

hint: zwróc uwagę na wszystkie nazwy funkcji pisanych mała literą. Niezła spójnośc, nie? Pewno im się kilku developerow zatrudniło od bsd i jakoś tak wyszło.

Jak Cie nie przekonuje to sprawdź jakie krasnoludki zainstalowaly Ci ten katalog:

C:\Windows\System32\drivers\etc

Dokumentacja != API.

Przyznałeś wreszcie ze to niskopoziomowa API. A tu się okazuje ze autor watku ma napisać wysokopoziomową aplikację. Zonk.

Autorowi wątku wystarczają. Tylko jeszcze o tym nie wie.

Bzdura. *Wiekszość* ficzerów bierze się z cieżkich KLOCow napisanych przez ich autorów. Zapoznaj się z kodem Qt. To nie jest tylko wrapper na winapi. To jest coś o rzędy wielkości większe.

Mylisz pojęcia. WinAPI dostarcza wszystkie narzedzia. Framework składa je do kupy i wystawia za fasadą/abstrakcją która powoduje że programista nie musi babrac się w g...

Dodatkowo dostajesz za friko zupelnie nowe ficzery jak np. signal-slot na porcie COM co powoduje że pisanie staje się trywialne.

Dwulinijkowym ich wytworzeniem. Są tak proste, wygodne i oczywiste że nie znam lepszego słowa niż "latwe" do okreslenia ich konstrukcji.

O bosz... nawet na głupiej wikipedii jest od razu w drugim zdaniu:

"MFC ... Jest to biblioteka napisana w języku C++, która stanowi obiektową (i uproszczoną) wersję Microsoft Windows API."

To możliwe, jeszcze nie nauczylem się smalltalka.

Tak. Sama inicjacja portu com zajmuje kilkadziesiąt.

Aby poprawnie to ocenić musiał by mieć rozeznanie. Jak wynika z maila ma słabe. Szkoda więc by było żeby sobie samodzielnie wybił zęby na tym cudzie techniki.

Różnią się tylko rozmiarem. Wartości dla true/false przyjmują takie same.

No dobra, występuje kilka dziwadeł. Ten uchował się conajmniej od Win95. Z tego co piszą niema tego od Visty.

To o czym piszesz nazywa się "Berkeley sockets" - taki standard API do komunikacji w sieci co by łatwiej było kod przenosić. Jest nawet implementacje pod Amigę. Niektóre języki wysokiego poziomu jak na przykład python mają to zaimplementowane w formie wrapperów. W każdym razie Windows oferuje też swoje mechanizmy, nieco ciekawsze.

To tylko katalog. Jest sobie od Windowsów NT

Zgadza się, ale nie rozumiem o co chodzi.

To też masz w WinAPI. Tryb OVERLAPPED i wywołanie event'a plus jeden wątek. Utworzony za pomocą jednej linijki.

Zupełnie tak jak w WinAPI :-)

MFC to tylko wrapper minimalizujący kilka upierdliwości no i miał na celu ułatwić tą nieszczęsną obiektowość. Ale nawet w javie da się napisać nie obiektowy program i równie dobrze w asemblerze można napisać obiektowy program.

No gdzieś trzeba wpisać choćby podstawowe parametry.

Ano szkoda, z drugiej strony jak mu się uda to może za kilka lat zatrudni go jakaś korporacja i będzie pisał na przykład sterowniki za niezłą kasę :-)

pozdrawiam,

Znudziło mi się, EOT. Mam nadzieje że autor wątku widząc przydługie dyskusje nie na temat *przynajmniej* dwa razy zastanowi się zanim ruszy w kierunku dziobania w 30-letnim API mając pod ręką kilka razy łatwiejsze języki i frameworki. Ide cos polutowac, żeby nie było aż takie OT.

W dniu 29.01.2012 18:33, Robert Zemła pisze:

Ja bardzo lubię "WinExec": Note This function is provided only for compatibility with 16-bit Windows.

snipped-for-privacy@interia.pl snipped-for-privacy@interia.pl napisał(a):

Proszę :)

Użytkownik "Robert Zemła" snipped-for-privacy@gmail.com

Za chwilę nie będzie WinAPI

John Kołalsky snipped-for-privacy@kowal.invalid napisał(a):

Wszystko będzie w HTML5 i JavaScript, łącznie z obsługą portów szeregowych...

Już jest. Nazywa się node.js

pzdr. j.