Re: C++/CCitat:
Ivan Dimkovic je napisao:
Ovako
1. VB ima jako los kompajler koji se ne moze porediti sa boljim C++ kompajlerom - nema to veze sa tajmerima, VB jednostavno generise SPOR KOD :)
To ti je prvo sto ti lomi koplje za implementaciju nekog iole tezeg algoritma u VBu (npr: G723, G729, MPEG, 3D rendering API, speech processing, image processing, DSP, i jos mnogo toga...)
Ovako
1. VB ima jako los kompajler koji se ne moze porediti sa boljim C++ kompajlerom - nema to veze sa tajmerima, VB jednostavno generise SPOR KOD :)
To ti je prvo sto ti lomi koplje za implementaciju nekog iole tezeg algoritma u VBu (npr: G723, G729, MPEG, 3D rendering API, speech processing, image processing, DSP, i jos mnogo toga...)
Poenta sa real-time poslovima je da se oni moraju tako izvrsavati i ako je racunar sporiji, pa prema tome i te razlike u generisanom kodu do 30% uticu isto kao i da uzmemo 30% sporiji racunar na kojem mora da radi algoritam. Prema tvojim izjavama, vidim da ne razumes koncepte u vezi real-time procesa. Zato cu da konstatujem kratko: real-time algoritam je onaj koji moze da pokrece i "zivot-ili-smrt" uredjaj. Cim se uvidi zakasnjenje (da li je zbog sporijeg koda na kome ti insistiras, ili zbog sporije masine, ili zbog glomaznog multiprogramiranja), preskacu se neobradjene informacije da bi se moglo pristupiti obradi novih. Ne mozes ti na XT-u da napravis real-time aplikaciju koja prepoznaje glas pomocu trenutno poznatih algoritama, ali prava real-time aplikacija mora da bude u mogucnosti da radi i na XT-u, zato sto se svakom sistemu moze desiti da VEOMA uspori.
Citat:
2. VB ne podrzava inline assembly
Dakle, ako ti hoces da neki kod (npr: kvantizacija kod G.7xx, brza matematika kod 3D rendering) optimizujes tu ces dobro da se namucis u VB-u, nema to nikakve veze sa tajmerima - tvoj alogirtam nece ni zavrsiti posao u real-time
Vidi iznad, ne postoji pravo resenje za real-time (osim "brzi, brzi, brzi, brzi,..." racunar), "nebitne" informacije se moraju preskociti. Ukoliko procesiramo snimak video kamere, i procesor ne moze da stigne da isprocesira 50fps, preci ce na 10fps, necemo iskljuciti racunar i ubaciti 5 puta brzi procesor (recimo kod sigurnosnih uredjaja, posto ce i 10fps moci da primeti "uljeza", a ukoliko isprocesira svih 50fps posle 5 minuta, moze biti "malo" kasno). Zato se i zovu real-time.
Citat:
3. Sto se misa tice, pa mozes ti u C++ napisati kernel-mod servis za Windows NT koji se izvrsava u kernel modu i ima prioritet nad bilo kakvim misem i ostalim glupostima. To u VB-u neces moci da izvedes. Ovo isto vazi i za Windows 95/98 gde mozes lepo napisati VxD drajver.
Nisam siguran, VB omogucava pravljenje i EXE i DLL fajlova, a i sami VXD su obicni izvrsni fajlovi sa nekoliko "opcija". Ne poznajem tacno izgled svakog, al pretpostavljam da se moze uz pomoc nekih caka isto to uraditi i u VB-u. Naravno, u vezi ovoga nisam siguran, pa je lako moguce da si u pravu, medjutim, to je vise vezano za linker nego za sam kompajler.
Citat:
4. IE nije "real-time" ali je primer jedne optimizovane aplikacije koja ni u snu ne bi mogla da se napise u VB-u.. tj. mogla bi ali bi radila kao puz.
Ali zasto, kada je moguce koristiti iste API pozive bez uopste upotrebe VB runtime-a??? Jos ce ispasti kako je Basic sintaksa automatski sporija od C sintakse, nebitno od toga kakav se kod generise.
Citat:
5. VB JE JEBENO NEPORTABILAN - znaci, ti napises code base od 1000000 linija koda i tvoja kompanija odluci da predje na nesto drugo (Linux, Unix, MacOS, tralala) i ti onda dobijes posao da bacis 1000000 linija u djubre i napises novih 1100000 linija u C++ koje ce biti portabilne...
i tako, ad infinitum :)
Hm, postoje i Basic kompajleri za POSIX/SUSv2+/BSD platforme, pa je situacija ista i sa C, i sa Basic kodom. C kod koji poziva WinAPI je jednako portabilan kao i Basic kod koji koristi VB runtime. Zasto su Delphi programerima trebali meseci da od Delphi-a naprave Kylix (pretpostavljam da su oba pisana u C/C++-u, posto nema u cemu drugom da se pise).
Zato sto se portabilnosti tice, ja ne znam ni jednog Win programera koji je napisao program koji se moze istovremeno kompajlirati i na POSIX platformama (tu iskljucujemo programe tipa "hello svete"). Promena okruzenja od MFC, WinAPI, ili neceg treceg na POSIX platforme, garantuje i veliku izmenu koda koji se bavi korisnickim interfejsom i upotrebom sistemskih servisa, nezavisno od jezika koji se koristi (Basic, C, Pascal...).
Ne treba pricati o necemu sto se ne poznaje dovoljno (citaj: realtime), i dalje na osnovu toga izvoditi zakljucke (ma kakvi bili). Slazem se da VB ima nesto sporiji kompajler, ali to ne utice na njegovu mogucnost da se sa njime prave realtime aplikacije, isto toliko koliko i sa C-om na istoj platformi (Win). Cak ni Linux ni vecina Unix sistema nije prilagodjeno real-time aplikacijama (mada sigurno postoji neki patch za real-time-linux ili tako nesto). Potpuno druga stvar su aplikacije za koje bi bilo pozeljno da rade real-time, ali nece doci do eksplozije ako ne ispune zahteve (recimo speech-processing radi izdaje komande racunaru, ukoliko zakasni obrada, zakasnice i komanda, ali desktop korisniku nece biti odsecena glava zbog toga).
Nadam se da sam pojasnio sta je real-time proces, i zasto je svejedno o kom se jeziku radi.
A sto se tice same teme, neko je konstatovao kako je C++ brzi, ali ne vidim kako bi to moglo biti istina kad je komplikovaniji. Dobar C kompajler moze generisati samo brži ili jednako brzi mašinac kao i dobar C++ kompajler.
Toliko.
Možda se moje mišljenje promenilo, ali ne i činjenica da sam u pravu.
