NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jak efektywnie synchronizować komunikację z miernikiem RLC w C++ WinAPI?
Goto page Previous 1, 2, 3, 4 Next
Sebastian Biały
Guest
Guest
Fri Jan 27, 2012 8:35 pm
On 2012-01-27 19:09, Robert Zemła wrote:
Quote:
Przesadzasz 
WinAPI nie jest złe a już na pewno nie jest niespójne.
WinAPI nie jest złe a już na pewno nie jest niespójne.
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.
Quote:
Bywa czasem upierdliwe, wymaga użycia innych technik programowania i
sporej wiedzy o systemie.
sporej wiedzy o systemie.
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ę.
Quote:
To są chyba główne powody dlaczego wielu go
nie lubi.
nie lubi.
Wielu nie lubi bo doskonale wie że można za darmo lepiej pod *każdym*
względem.
Quote:
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.
martwi ten co po nim ten kod przejmie. Nie przekonasz mnie że
programista nie musi mieć choćby minimum wiedzy komputerze.
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.
Quote:
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.
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.
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?
Quote:
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.
wykorzystujący bezpośrednio WinAPI to z debugowaniem tym bardziej nie
będzie mieć problemu.
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.
Quote:
Pomyliłeś programowanie obiektowe z RAD.
Napisałeś "obiektowe środowiska".
Napisałeś "obiektowe środowiska".
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).
Quote:
Natomiast nie widzę związku z brakiem
możliwości połączenia programowania obiektowego i WinAPI
możliwości połączenia programowania obiektowego i WinAPI
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ł.
Quote:
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.
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.
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.
Quote:
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.
nie zgadzam się tylko że WinAPI jest złe i że programista nie musi znać
się na tym co robi.
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.
Robert Zemła
Guest
Guest
Sat Jan 28, 2012 7:46 pm
W dniu 27-01-2012 20:35, Sebastian Biały pisze:
Quote:
On 2012-01-27 19:09, Robert Zemła wrote:
Przesadzasz WinAPI nie jest złe a już na pewno nie jest niespójne.
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.
Przesadzasz
WinAPI nie jest złe a już na pewno nie jest niespójne.
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.
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.
Quote:
Bywa czasem upierdliwe, wymaga użycia innych technik programowania i
sporej wiedzy o systemie.
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ę.
To są chyba główne powody dlaczego wielu go
nie lubi.
Wielu nie lubi bo doskonale wie że można za darmo lepiej pod *każdym*
względem.
Oczywiście że można wygodniej, ale nie koniecznie lepiej
Quote:
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.
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.
Bo ideą Qt jest wieloplatformowość i przenoszalność. Tam nie ma miejsca
na niskopoziomowe API w żadnym systemie.
Quote:
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.
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?
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.
Quote:
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.
Zaryzykuje że *NIGDY* nie pisałeś niczego większego, czyli przynajmniej
kilkanaście KLOCów w zespole.
Nie rozmawiamy tu o mnie i niech tak zostanie.
Nie trzeba mieć umiejętności programowania
Quote:
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.
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.
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.
Quote:
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.
więcej pisząc mały programik do odbierania znaków niż z byle-jakim
środowiskiem obiektowym.
Jeżeli nie masz doświadczenia to na pewno tak
Quote:
Pomyliłeś programowanie obiektowe z RAD.
Napisałeś "obiektowe środowiska".
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).
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?
Quote:
Natomiast nie widzę związku z brakiem
możliwości połączenia programowania obiektowego i WinAPI
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ć.
A co ma MFC do obiektowości??? Albo nie rozumiesz czym jest obiektowość
albo mnie podpuszczasz.
Quote:
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ł.
powstać wygodne środowiska .NET. *SOLIDNA* izolacja od kretynizmów
WinAPI stoi u podstaw sukcesu C# - wszystko jest spójne bo wreszcie ktoś
to zaprojektował.
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.
Quote:
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.
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.
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ć
Quote:
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.
wlaściwego narzedzia. Nie jest nim niskopoziomowy zestaw funkcji OS
jakiegoś systemu operacyjnego.
Można. W WinAPI myślisz że to zajmie więcej linijek?
To *najgorszy* wybór ze wszystkich
Quote:
innych, nawet od Delphi.
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.
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.
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.
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.
Zgadzam się, natomiast to czy WinAPI nie powinien dotykać kijem niech
sam oceni.
pozdrawiam
Sebastian Biały
Guest
Guest
Sat Jan 28, 2012 10:57 pm
On 2012-01-28 19:46, Robert Zemła wrote:
Quote:
W dniu 27-01-2012 20:35, Sebastian Biały pisze:
On 2012-01-27 19:09, Robert Zemła wrote:
Przesadzasz WinAPI nie jest złe a już na pewno nie jest niespójne.
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.
Pokaż mi gdzie występują te różne wartości dla true/false.
On 2012-01-27 19:09, Robert Zemła wrote:
Przesadzasz
WinAPI nie jest złe a już na pewno nie jest niespójne.
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.
Pokaż mi gdzie występują te różne wartości dla true/false.
Po pierwsze masz dwa typy BOOL i BOOLEAN.
http://msdn.microsoft.com/en-us/library/aa383751(v=vs.85).aspx
Po drugie od groma funkcji ma odwrócona logike, pierwsza z brzegu:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762164(v=vs.85).aspx
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.
Quote:
Wogóle gdzie
Ty tu widzisz POSIX'a???
Ty tu widzisz POSIX'a???
http://msdn.microsoft.com/en-us/library/ms741394(v=vs.85).aspx
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
Quote:
Te czeluści MSDN to jedna z lepiej opracowanych
i ułożonych dokumentacji jakie widziałem.
i ułożonych dokumentacji jakie widziałem.
Dokumentacja != API.
Quote:
Bo ideą Qt jest wieloplatformowość i przenoszalność. Tam nie ma miejsca
na niskopoziomowe API w żadnym systemie.
na niskopoziomowe API w żadnym systemie.
Przyznałeś wreszcie ze to niskopoziomowa API. A tu się okazuje ze autor
watku ma napisać wysokopoziomową aplikację. Zonk.
Quote:
Jeżeli komuś one nie wystarczają,
albo ma taki kaprys to niech sobie pisze w WinAPI.
albo ma taki kaprys to niech sobie pisze w WinAPI.
Autorowi wątku wystarczają. Tylko jeszcze o tym nie wie.
Quote:
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).
No a cała ta funkcjonalność bierze się z WinAPI.
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).
No a cała ta funkcjonalność bierze się z WinAPI.
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.
Quote:
Akurat do komunikacji z
peryferiami jak naprzykład COM nie ma nic lepszego od WinAPI.
peryferiami jak naprzykład COM nie ma nic lepszego od WinAPI.
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.
Quote:
Czym
wogóle są łątwe wątki?
wogóle są łątwe wątki?
Dwulinijkowym ich wytworzeniem. Są tak proste, wygodne i oczywiste że
nie znam lepszego słowa niż "latwe" do okreslenia ich konstrukcji.
Quote:
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ć.
A co ma MFC do obiektowości???
MFC. Jesli masz zacięcie do archeologii to możesz dalej tego używać.
A co ma MFC do obiektowości???
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."
Quote:
Albo nie rozumiesz czym jest obiektowość
To możliwe, jeszcze nie nauczylem się smalltalka.
Quote:
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.
Można. W WinAPI myślisz że to zajmie więcej linijek?
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.
Można. W WinAPI myślisz że to zajmie więcej linijek?
Tak. Sama inicjacja portu com zajmuje kilkadziesiąt.
Quote:
Zgadzam się, natomiast to czy WinAPI nie powinien dotykać kijem niech
sam oceni.
sam oceni.
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.
Robert Zemła
Guest
Guest
Sun Jan 29, 2012 6:33 pm
W dniu 28-01-2012 22:57, Sebastian Biały pisze:
Quote:
On 2012-01-28 19:46, Robert Zemła wrote:
W dniu 27-01-2012 20:35, Sebastian Biały pisze:
On 2012-01-27 19:09, Robert Zemła wrote:
Przesadzasz WinAPI nie jest złe a już na pewno nie jest niespójne.
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.
Pokaż mi gdzie występują te różne wartości dla true/false.
Po pierwsze masz dwa typy BOOL i BOOLEAN.
W dniu 27-01-2012 20:35, Sebastian Biały pisze:
On 2012-01-27 19:09, Robert Zemła wrote:
Przesadzasz
WinAPI nie jest złe a już na pewno nie jest niespójne.
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.
Pokaż mi gdzie występują te różne wartości dla true/false.
Po pierwsze masz dwa typy BOOL i BOOLEAN.
Różnią się tylko rozmiarem. Wartości dla true/false przyjmują takie same.
Quote:
http://msdn.microsoft.com/en-us/library/aa383751(v=vs.85).aspx
Po drugie od groma funkcji ma odwrócona logike, pierwsza z brzegu:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762164(v=vs.85).aspx
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.
No dobra, występuje kilka dziwadeł. Ten uchował się conajmniej od Win95.
Z tego co piszą niema tego od Visty.
Quote:
Wogóle gdzie
Ty tu widzisz POSIX'a???
http://msdn.microsoft.com/en-us/library/ms741394(v=vs.85).aspx
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.
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.
Quote:
Jak Cie nie przekonuje to sprawdź jakie krasnoludki zainstalowaly Ci ten
katalog:
C:\Windows\System32\drivers\etc
To tylko katalog. Jest sobie od Windowsów NT
Quote:
Te czeluści MSDN to jedna z lepiej opracowanych
i ułożonych dokumentacji jakie widziałem.
Dokumentacja != API.
Zgadza się, ale nie rozumiem o co chodzi.
Quote:
Bo ideą Qt jest wieloplatformowość i przenoszalność. Tam nie ma miejsca
na niskopoziomowe API w żadnym systemie.
Przyznałeś wreszcie ze to niskopoziomowa API. A tu się okazuje ze autor
watku ma napisać wysokopoziomową aplikację. Zonk.
Jeżeli komuś one nie wystarczają,
albo ma taki kaprys to niech sobie pisze w WinAPI.
Autorowi wątku wystarczają. Tylko jeszcze o tym nie wie.
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).
No a cała ta funkcjonalność bierze się z WinAPI.
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.
Akurat do komunikacji z
peryferiami jak naprzykład COM nie ma nic lepszego od WinAPI.
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.
To też masz w WinAPI. Tryb OVERLAPPED i wywołanie event'a plus jeden
wątek. Utworzony za pomocą jednej linijki.
Quote:
Czym
wogóle są łątwe wątki?
Dwulinijkowym ich wytworzeniem. Są tak proste, wygodne i oczywiste że
nie znam lepszego słowa niż "latwe" do okreslenia ich konstrukcji.
Zupełnie tak jak w WinAPI :-)
Quote:
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ć.
A co ma MFC do obiektowości???
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."
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.
Quote:
Albo nie rozumiesz czym jest obiektowość
To możliwe, jeszcze nie nauczylem się smalltalka.
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.
Można. W WinAPI myślisz że to zajmie więcej linijek?
Tak. Sama inicjacja portu com zajmuje kilkadziesiąt.
No gdzieś trzeba wpisać choćby podstawowe parametry.
Quote:
Zgadzam się, natomiast to czy WinAPI nie powinien dotykać kijem niech
sam oceni.
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.
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,
Sebastian Biały
Guest
Guest
Sun Jan 29, 2012 9:49 pm
On 2012-01-29 18:33, Robert Zemła wrote:
Quote:
[ciach]
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.
Grzegorz Niemirowski
Guest
Guest
Sun Jan 29, 2012 9:52 pm
Sebastian Biały <heby@poczta.onet.pl> napisał(a):
Quote:
On 2012-01-29 18:33, Robert Zemła wrote:
[ciach]
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.
[ciach]
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.
Tylko niech uważa na popsute frameworki. Może się okazać, że trzeba coś
dorzeźbić w WinAPI.
http://zachsaw.blogspot.com/2010/07/net-serialport-woes.html
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 4 days, 18 hours, 38 minutes and 41 seconds
Michoo
Guest
Guest
Sun Jan 29, 2012 11:10 pm
W dniu 29.01.2012 18:33, Robert Zemła pisze:
Quote:
W dniu 28-01-2012 22:57, Sebastian Biały pisze:
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.
No dobra, występuje kilka dziwadeł. Ten uchował się conajmniej od Win95.
Z tego co piszą niema tego od Visty.
Ja bardzo lubię "WinExec":
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.
No dobra, występuje kilka dziwadeł. Ten uchował się conajmniej od Win95.
Z tego co piszą niema tego od Visty.
Ja bardzo lubię "WinExec":
Note This function is provided only for compatibility with 16-bit Windows.
--
Pozdrawiam
Michoo
venioo@interia.pl
Guest
Guest
Sun Jan 29, 2012 11:17 pm
W dniu 2012-01-29 21:52, Grzegorz Niemirowski pisze:
Quote:
Tylko niech uważa na popsute frameworki. Może się okazać, że trzeba coś
dorzeźbić w WinAPI.
http://zachsaw.blogspot.com/2010/07/net-serialport-woes.html
MASZ U MNIE BROWARA!!!!!!!!! Po nocach nie śpie myśląc czemu mi się
jeden projekt (w sumie już wdrożony) losowo wysypuje, co spie..lem i jak
naprawic!!! A tu juz wszystko jasne... DZIĘKI!!!
--
venioo -> GG:198909
Sprzedam AUDI 100 C4 '91 AAR 2.3 LPG
http://tablica.pl/oferta/audi-100-c4-czarna-gaz-lpg-mafia-look-IDvheh.html
Grzegorz Niemirowski
Guest
Guest
Sun Jan 29, 2012 11:22 pm
venioo@interia.pl <venioo@interia.pl> napisał(a):
Quote:
MASZ U MNIE BROWARA!!!!!!!!! Po nocach nie śpie myśląc czemu mi się jeden
projekt (w sumie już wdrożony) losowo wysypuje, co spie..lem i jak
naprawic!!! A tu juz wszystko jasne... DZIĘKI!!!
projekt (w sumie już wdrożony) losowo wysypuje, co spie..lem i jak
naprawic!!! A tu juz wszystko jasne... DZIĘKI!!!
Proszę :)
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 4 days, 20 hours, 8 minutes and 38 seconds
John Kołalsky
Guest
Guest
Mon Jan 30, 2012 11:48 pm
Użytkownik "Robert Zemła" <mojejapko@gmail.com>
Quote:
Pomyliłeś programowanie obiektowe z RAD.
Napisałeś "obiektowe środowiska".
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).
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?
Za chwilę nie będzie WinAPI
Grzegorz Niemirowski
Guest
Guest
Tue Jan 31, 2012 12:41 am
John Kołalsky <john@kowal.invalid> napisał(a):
Quote:
Za chwilę nie będzie WinAPI
Wszystko będzie w HTML5 i JavaScript, łącznie z obsługą portów
szeregowych...
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 5 days, 21 hours, 28 minutes and 24 seconds
Jacek Radzikowski
Guest
Guest
Tue Jan 31, 2012 2:59 am
On 01/30/2012 06:41 PM, Grzegorz Niemirowski wrote:
Quote:
John Kołalsky <john@kowal.invalid> napisał(a):
Za chwilę nie będzie WinAPI
Wszystko będzie w HTML5 i JavaScript, łącznie z obsługą portów
szeregowych...
Za chwilę nie będzie WinAPI
Wszystko będzie w HTML5 i JavaScript, łącznie z obsługą portów
szeregowych...
Już jest. Nazywa się node.js
pzdr.
j.
Artur M. Piwko
Guest
Guest
Tue Jan 31, 2012 1:38 pm
In the darkest hour on Sun, 29 Jan 2012 18:33:52 +0100,
Robert Zemła <mojejapko@gmail.com> screamed:
Quote:
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.
Pokaż mi gdzie występują te różne wartości dla true/false.
Po pierwsze masz dwa typy BOOL i BOOLEAN.
Różnią się tylko rozmiarem. Wartości dla true/false przyjmują takie same.
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.
Pokaż mi gdzie występują te różne wartości dla true/false.
Po pierwsze masz dwa typy BOOL i BOOLEAN.
Różnią się tylko rozmiarem. Wartości dla true/false przyjmują takie same.
I to jest Twoim zdaniem spójne?
Quote:
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.
No dobra, występuje kilka dziwadeł. Ten uchował się conajmniej od Win95.
Z tego co piszą niema tego od Visty.
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.
No dobra, występuje kilka dziwadeł. Ten uchował się conajmniej od Win95.
Z tego co piszą niema tego od Visty.
"No dobra, ale co dla nas zrobili Ci Rzymianie?"
Quote:
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.
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.
Niezła spójnośc, nie? Pewno im się kilku developerow zatrudniło od bsd i
jakoś tak wyszło.
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.
Ale jest POSIX czy nie?
Quote:
Jak Cie nie przekonuje to sprawdź jakie krasnoludki zainstalowaly Ci ten
katalog:
C:\Windows\System32\drivers\etc
To tylko katalog. Jest sobie od Windowsów NT
katalog:
C:\Windows\System32\drivers\etc
To tylko katalog. Jest sobie od Windowsów NT
A plik hosts w nim to tylko plik.
Quote:
Bo ideą Qt jest wieloplatformowość i przenoszalność. Tam nie ma miejsca
na niskopoziomowe API w żadnym systemie.
Przyznałeś wreszcie ze to niskopoziomowa API. A tu się okazuje ze autor
watku ma napisać wysokopoziomową aplikację. Zonk.
na niskopoziomowe API w żadnym systemie.
Przyznałeś wreszcie ze to niskopoziomowa API. A tu się okazuje ze autor
watku ma napisać wysokopoziomową aplikację. Zonk.
OMG...
Quote:
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.
To też masz w WinAPI. Tryb OVERLAPPED i wywołanie event'a plus jeden
wątek. Utworzony za pomocą jednej linijki.
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.
To też masz w WinAPI. Tryb OVERLAPPED i wywołanie event'a plus jeden
wątek. Utworzony za pomocą jednej linijki.
Przeskalowywać widgety też możesz za pomocą jednej linijki?
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:229B ]
[ 13:34:15 user up 13064 days, 1:29, 1 user, load average: 0.50, 0.28, 0.15 ]
Advanced design: Upper management doesn't understand it.
Artur M. Piwko
Guest
Guest
Tue Jan 31, 2012 1:42 pm
In the darkest hour on Thu, 26 Jan 2012 21:29:22 +0100,
Grzegorz Niemirowski <gnthexfiles@poczta.onet.pl> screamed:
Quote:
Venioo- jaki MS - Visual ??? Duzo lepsze jest QT Nokia i do tego
free. SUPER !
polecam http://qt.nokia.com/
Tak jakby Visual nie był i nie można było pisać w QT pod Visualem.
free. SUPER !
polecam http://qt.nokia.com/
Tak jakby Visual nie był i nie można było pisać w QT pod Visualem.
I męczyć się z bugami VCC? (przesadzam, wiem...:)
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:235B ]
[ 13:41:48 user up 13064 days, 1:36, 1 user, load average: 0.50, 0.28, 0.15 ]
Life doesn't imitate art, it imitates bad television. -- Woody Allen
Artur M. Piwko
Guest
Guest
Tue Jan 31, 2012 1:46 pm
In the darkest hour on Thu, 26 Jan 2012 21:52:05 +0100,
venioo@interia.pl <venioo@interia.pl> screamed:
Quote:
Venioo- jaki MS - Visual ??? Duzo lepsze jest QT Nokia i do tego
free. SUPER !
polecam http://qt.nokia.com/
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.
free. SUPER !
polecam http://qt.nokia.com/
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.
Tak samo ja. Zakończyło się na pierwszym "End If".
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:218B ]
[ 13:45:57 user up 13064 days, 1:40, 1 user, load average: 0.50, 0.28, 0.15 ]
Weekends were made for programming.
elektroda NewsGroups Forum Index - Elektronika Polska - Jak efektywnie synchronizować komunikację z miernikiem RLC w C++ WinAPI?