Szyk <s...@o...pl> napisał(a):

> Drogi FiĹźe, wielki generale Kenobi, czcigodny profesorze Kibonte...
>
>
> > ktos moze udzielic jakiejs porady (glownie uwzgledniajace to co
> > powiedzialem: bez dodatkowych libow i rownolegly dzwiek najlepiej
> > z mala latencja) - zna chocby jakies dobre materialy do
> > dokumentacji itp?
>
>
> Zdaje się, że święcie wierzysz w:
> 1) boskość WinApi (szybkość, funkcjonalność, poprawność koncepcyjną)
> 2) nie omylność M$ (zwłaszcza jego WinApi jako dzieła więczącego rozwój
> systemĂłw operacyjnych)
> 3) wyższość programowania proceduralnego (język C)
>
> Podczas gdy nawet M$ nie wierzy w 1) i 2) ani nawet w 3):
>
> ad 1) wkrótce po premierze Windows 95 okazało się, że do gier jest
> potrzebne coś lepszego niż WinApi - więc szybko dokręcono zestaw
> bibliotek DirectX. Nie wiem czemu unikasz DirectX skoro (OIMW) są to
> biblioteki C obecne we wszystkich windach od 1998 roku. OIMW DirectX
> góruje zarówno szybkością jak i funkcjonalnością nad WinApi. OIMW w
> nowszych windach pod WinApi śmiga DirectX.
>
> ad 2) Brnięcie w zaparte w technologie M$ może być uzasadniane a)
> stabilnością i b) funkcjonalnością oferowaną przez windę które
> przewyższają konkurencję. I faktycznie przewaga M$ Windows jest ogromna
> i raczej nie zagrożona. Tym nie mniej ograniczanie się do jednego
> systemu to brnięcie w kanał. Można zrozumieć też pogląd że nie warto
siÄ
> ™
> zajmować systemami które nie rokują jako alternatywa wobec Windows (na
> ile poważne jest Kubuntu: ostatnie wyszło w kwietniu a do września nie
> działały sterowniki NVidia Geforce 2MX (chyba dla pozostałych Geforców
> też nie działały bo widziałem podobne nagłówki na liście błędów) bo
> jakieś tam ABI nie grało i dopuki odpowiednia ilość użytkowników nie
> potwierdziła tego błędu nikt się tym nie zajmował). Dlatego moim zdaniem
> rozsądną strategią obronną przed dominacją M$ i przed brnięciem w nie
> rokujące systemy są biblioteki wieloplatformowe. Konkretnie mam na
> myśli, że zamiast WinApi czy DirectX raczej bym brnął w SDL lub OpenGL i
> OpenAL (jeśli już się trzymać czystego C i robienia dem czy gier).
>
> ad 3) Pewną zaletą czystego C jest to, że jest większa świadomość jakie
> funkcje się wywołuje, oraz łatwość wywołania dowolnej metody. Jednak pod
> względem architektury programu stosowanie C to praktycznie ciągła pogoń
> za cechami C++. Plik źródłowy *.c opisuje zawartość pliku *.o w którym
> oprócz funkcji często znajdują się również "zmienne globalne" konieczne
> by przechowywać dane robocze programu. Więc czym jest taki plik *.o? No,
> jest on po prostu obiektem typu singleton. I cały program to seria tych
> singletonów zakodowanych w języku C. Więc wybierając język C nie ma
> ucieczki przed obiektówką jeśli chodzi o architekturę programu. Dlatego
> moim zdaniem naiwnością jest wypieranie się obiektówki rzekomo przez
> kodowanie w czystym C. Natomiast łatwość wywołania jakiejś metody ma
> znaczenie tam gdzie projekt programu jest zły i trzeba stosować triki.
> Przyznam, Ĺźe to jest problem z bibliotekami w C++ - kiedy nie wszystko
> mogę zrobić po swojemu, albo zgodnie z jakimś najnowszym trendem. Tym
> nie mniej te problemy raczej nie przekonają mnie by wyprzeć się
> stringĂłw, kontenerĂłw i uogĂłlnionych algorytmĂłw oraz reszty oferowanej
> przez takie biblioteki jak Qt.
>
> W sumie ja mogę zrozumieć dlaczego ktoś brnie w C i WinApi. Może być
> tak, Ĺźe z projektowaniem programĂłw nie najlepiej sobie radzi i go to nie
> interesuje i chce poćwiczyć WinApi (zwłaszcza gdy wymaga tego pracodawca
> czy uczelnia). W tym wypadku - ok - jest to świadoma decyzja.

co do c++/oo wypowiadalem sie juz gruntownie i nie mam checi powtarzac
tego kolejny raz bo boje sie przymulac wlasną osobe (zawsze wole pogadac
o czyms chocby banalnym ale dla mnie nowym) <- sam ten komentarz jest
juz troche przymulasty bo tez go powtarzam ktorys raz

co do winapi to wcale nie jestem takim fanem mS, (winapi nie jest za ladne,
np to przekazywanie struktur ktore nie wiadomo czy sa wewnetrznie kopiowane
i mozna je zwolnic, co idzie w ktora strone itp (jest to swojego rodzaju
koszmarne naduzycie c), pozatym brzydkie nazwy itp,
z kolei np com, directx, albo c# sa chyba jeszcze gorsze )

ale generalnie jak juz programuje to lubie 'niskopoziomowe' fundamentalne
rozwiazania, ktore daja mi prosty interfejs i pozwalaja duzo zrobic samemu,
chyba nie ma tu o czym za duzo gadac,

to co lubie to ladne i cienkie 'layery' nad hardware - np mozna uznac
za takie layery c nad procesorem, ogl nad gpu i winapi nad systemem -
naturalnie kieruje sie wlasnie ku takim layerom of my choice

(kiedys mialem ambicje by lepiej nauczyc sie winapi ale obecnie
po prostu mam zalozony szkielet aplikacji i winapi sie praktycznie
wogole nie zajmuje, podobnie mam zreszta z ogl ktore opanowalem tylko
w podstawie)

poszukuje teraz wlasnie takiego niskiego interfejsu w domenie obslugi
dzwieku pod winda (i troche topornie mi idzie z braku dostatecznego info -
olalem chwilowo ai i od dwu dni szukam i czytam o ew api do odgrywania
rownolegle dzwiekow pod winda, dowiedzialem sie sporo nowego ale poki co nie
dosc by elegancko zrobic sobie taki fundament

nie wiem w jakim kierunku pojdzie rozwoj komputeryzacji na swiecie itp
ale specjalnie sie tym nie przejmuje, mam w domu windowsa to pisze pod
winapi, [ linuxem sie specjalnie nie interesuje raczej po prostu z lenistwa,
zreszta jak kiedys spytalem kolege archetypicznego linuksiarza czy linux
jest szybszy od windy to powiedzial ze niestety nie (gdyby byl szybszy
to moze bardziej by mnie zachecal) ]

tak wogole to watek o dzwieku pod winda i akurat teraz tym tematem jestem
najbardziej zainteresowany,

co do visualstudio/c++/oo/gcc/java itd itp to niespecjalnie interesuje mnie
jakiekolwiek naklanianie kogokolwiek by tego uzywal badz nie uzywal, ja pisze
na takie 'niskie layery' i tyle





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/