PCSOFT

08 Nov 1989 - 22 Sep 1991

Topics

  1. bios (50)
  2. ms.dos (492)
  3. unix (322)
  4. os.2 (5)
  5. jezici (125)
  6. cccc (343)
  7. clipper (273)
  8. turbo.pascal (247)
  9. tools (219)
  10. grafika (189)
  11. programiranje (156)
  12. tekst.procesori (164)
  13. word.perfect (222)
  14. ventura (216)
  15. windows (270)
  16. spec.softver (212)
  17. virusi (255)
  18. zastita (44)
  19. knjige (61)
  20. razno (668)
  21. mreze (75)
  22. ms.word (42)
  23. nabavka (153)
  24. baze.podataka (60)
  25. radne.tabele (2)
  26. van.teme (17)
  27. 4dos (25)

Messages - cccc

cccc.1 dejanr,
Iako "mlađi" od većine konkurenata, C je među programerima zaradio ogromnu reputaciju - najveći deo svih komercijalnih programa za PC (i ne samo za PC) razvijen je upravo na C-u! Na ovom jeziku je, uzgred budi rečeno, razvijena i aplikacija koja upravo ispisuje poruku koju čitate. PC-jevci se ne nalaze samo pred dilemom da li programirati na fortranu, bejziku, paskalu, C-u ili nekom drugom jeziku već i pred dilemom na kom C-u - popularni su Microsoft C 5.1 i Turbo C 2.0 premda u inostranstvu sve više pristalica ima i objektno orijentisani C++ (zašto C++? C+ bi u C-u bila sintaksna greška a C++ je OK). Koji je vaš izbor i zašto?
cccc.2 lgavrilovic,
TC i MSC -------- Što se mene tiče koristim oba paralelno, razivijam u TC-u (V2.0) koji je brži prilikom kompajliranja i ima standalone debbuger koji mi se više sviđa (Turbo debugger 1.5) od MS-ovog. Što se rezultujućeg koda tiče zbog optimizacija, veličine koda i brzine izvođenja kapu treba skinuti MSC-u. Druge kompajlere nisam imao prilike da probam i voleo bih baš da čujem neke pikanterije od onih koji ih koriste. C uopšte -------- Čini mi se da se mnogo više psihički zamaram prišući u C-u nego u TPascalu pogotovo kad radim sa stringovima i tekstualnim fajlovima. Voleo bih da čujem Zorana, SEZAM se uglavnom zasniva na tekstu... C knjige -------- My favorite is "C: The complete Reference" from Herbert Schildt. Vrlo dobra je "C Power user's guide" od istog autora. Obe su izašle kod McGrow-Hill-a. Prvu uzmite ako zaista želite naučiti (i redovno koristiti C). Drugu uzmite ako vas mrzi da pišete prozore, menije i ostale osnovne stvari. Treća knjiga koju bih toplo preporučio svima koje interesuje 3-D, grafika , CADD i C je: "Interactive 3D computer graphic" Leendert-a Ammeraal-a u izdanju "John Wiley & Sons Limited", Distribution Centre, Shirpney Road, Bognor Regis, Sussex, PO22 9SA, England. Knjiga ima primere za Turbo C V1.5 (zbog BGI-a) a autor nudi i disketu sa kompletnim sorsovima iz kjige (od 200 do 249 str. je sve samo sors) --------------------------------------------------------------- PRO - C ------- Verziju 1.3 ProC-a dobio sam krajem Jula 1989. Program je zaista lep i lepo zamišljen, radi sa gomilom popularnih DB ekstenzija ali... Čuvajte se ove verzije. Ako imate neko izracunavanje i radite ga u promenljivoj zatim ga želite vratiti u record, nećete uspeti. Izgleda da postoji neki bug koji ni autori nisu primetili. Pošto PRO-C generiše sors u C-u logično je pomisliti da ga je lako prepraviti. NE! PRO-C je izuzetno produktivan 50-60K sorsa (po fajlu) nije ništa za njega pogotovo ako imate pointer na pointer filozofiju. I još jedna opaska: Kada završite projekat iskompajlirate ceo sors EXE datoteka će vam vrlo lako biti 100 i više K. Ako još želite da vam poruke budu na našem jeziku videćete da autori i nisu bili uvek dosledni. MSG-ovi su doduše stavljeni u jedan .H, ali iznenadićete se kada budete usanovili da su neki i u biblioteci (i to baš u onoj za koju nemate sors u workbenchu). Znate ono "dva loša ubiše Miloša"? (two bed miloš dead). Da ga ne bih suviše kudio (a ima još toga) reći ću nekoliko lepih svari: * PRO-C generiše izuzetno lep C kod. Ako neko uči C trebalo bi da pogleda kako treba da izgleda C program. Štaviše PRO-C gene- riše i komentare u sorsovima. * file I/O funckije su centralizovane u neku vrstu SHELLa pa jednostvnim menjanjem broja prebacujete se sa jednog DB sistema na drugi (u već izgenerisanom sorsu) * Vrlo lako se generišu maske za unos i preklapajući meniji. Koncipiran je tako da mogu se koristiti samo ove opcije za generisanje delova koje ćete kasnije ugraditi u svoj program. * Help je razrađen do ludila, sve se može promeniti. * Data je biblioteka rutina koje koisti PRO-C u SORSU (Workbench) i detaljno opisana svaka funkcija. * Genrisana dokumentacija je toliko detaljna da to može i da zasmeta. Sve u svemu lep program koji će vas izdati kada to najmanje budete očekivali. Nadam se da će bugovi biti ispravljeni u sledećoj verziji. p.s. Jedan Novosadski (softverski) privatnik već dugo traži finansijera za zastupništvo za PRO-C za Jugoslaviju (u šta bi ušlo prevodjenje kompletnog programa i dokumentacije na naš jezik i ispravka postojećih bagova). Kaže mi da je od Jasenica do Đevđelije tražio pomoć i da je neverovatno koliko ljudi nemaju razumevanja za ovako nešto. Zahvaljujući njemu imao sam prilike da upoznam i isprobam paket. Ovaj tekst je dobio njegovu saglasnost. ------------------------------------------------------------ C - YACC - LEX ---------------- Ima li neko kakvu dokumentaciju o YACCu i LEXu i uopšte o UNIX utilitiy-ima za programiranje u C-u? GWW p.s. Da otvorimo temu C funkcije? Kažu da ako C funkcija prelazi 20 redova treba je ponovo napisati - jednostavnije. p.p.s. Kažu da je perverzija ako imate tri zvezdice u programu (pointer na pointer na pointer na sadržaj) neki pominju sa du videli programe sa četiri i pet. Ja lično nisam upotrebio više od dve. Ima li neko sa više ?
cccc.3 zzivotic, -> #2, lgavrilovic
Sasvim se slažem - pisanje u C-u zahteva prilično koncentracije ali na kraju ispadne brže. BB zaista počiva na samo dva elementa - string i file operacijama. S obzirom da sam dugo vremena koristio Turbo Pascal mislim da mogu da procenim da bi pisanje BB-a trajalo bar duplo duže u paskalu a ne verujem da bi neke stvari mogle uopšte biti ugrađene u tom slučaju. Što se tiče konstrukcija tipa ******ptr ne vidim šta je tu neobično - dva indirektna adresiranja su svakodnevna pojava (mnogi deklarišu main( int argc, char **argv ), tri se često koristi a najveći broj sam upotrebio u BB-u - 7. Ne smatram to nikakvom perverzijom - naprotiv vrlo zgodan način za dinamičko adresiranje složenih struktura.
cccc.4 ilja, -> #3, zzivotic
7 zvezdica????? Nemoguce! Pa zasta bi tako nesto bilo potrebno?
cccc.5 vkostic, -> #1, dejanr
TURBO C (2.0) ima daleko vise funkcija nego MSC 5.0 koje omogucavaju da se lakse pisu profesionalni programi za IBM PC masine. Ja volim da pravim male izmene u programu i odmah vidim kako to izgleda - da koristim MSC 5.0 posedeo bi! Ne koristim TC nego iskljucivo TCC - ne volim mnogo sarene prozore i menije, a naj vaznije od svega, sa TCC mogu direktno da pisem na asembleru u sred C programa. Inace, odusevljen sam kako TURBO C (2.0) i MSC 5.0 generisu optimizovani kod. Svojevremeno sam za potrebe predavanja na jednom kursu masinskog jezika napisao program za igru LIFE na asembleru. Posle sam istu stvar (sa potpuno istim algoritmom) napisao na C-u. I C je radio brze! Istina, to je bio kurs za pocetnike, pa nisam koristio sve hakerske trikove u programu na asembleru, ali ipak... TURBO DEBUGER 1.0 divno zamisljen proizvod sa predivnim mogucnostima, ali i sa gomilom gluposti! Zasto ne moze da se single step-uje kroj pozive DOS-u i BIOS-u. Jeste da to obicno ne treba, ali meni je par puta bas zatrebalo da vidim sta to DOS radi. Mogo bi jos dugo da nabrajam sitne bubice u tom programu. Dali neko ima iskustva sa verzijom 1.5?
cccc.6 lgavrilovic, -> #5, vkostic
Nisam bio dugo ovde (oko 7-8 dana) pa da se priključim: 1. O pointerima na pointere: U principu više volim da pišem main(int argc,char *argvŠĆ) umesto char **argv jer meni je logičnije da smatram parametre kao niz stringova nego kao neku vrstu matrice karaktera. Dakle nisam sasvim oduševljen da razmišljam suviše "nisko" te mi se više sviđaju konstrukcije tipa ŠnĆ nego *(ptr+n). Kada se uzme u obzir ovaj drugi pristup broj "zvezdica" se naglo povećava. 2. C Ja takođe koristim TCC umesto TC-a iz razloga lakšeg rada sa bibliotekama (lepši je MAKE) a i zbog toga što moja mašina ima "samo" 512 KB. 3. Turbo debugger 1.5 Nema mnogo pobobljšanja u odnosu na 1.0 bar za C. Dodata je opcija View - Hierarhija zabog "OO" pascala. Molim Vladu da obrazloži buggove. Da se zna o čemu se radi. Ja inače koristim source i variable window, a od ostalih ponekad dump fajla i inspect. Watch mi je neprijatan, break pointi zgodni (pogotovu havtanje menjanja variable) ali više koristim kombinaciju F4, F7. 4. O debuggerima Specijalno za Vladu !! Jesi li probao Quaide Analizer. Sve vrvi od nedokumentovanih DOS poziva (i u command.com-u) recimo switch char? Možeš da patch-uješ interapte itd. Malo je nepregledan ali je prozor u mašinu. Još nešto, možeš da se zakačiš za mašinu pre DOS BOOT-a. Javi se, pozdrav od starog drugara (seti se Galaksije+, i Beogradskog sajma još kada je "Ekranski editor" bio aktuelan, i ekipe Beca, Milanče i ja) 5. Pitanja za magove C-a Prilikom pisanja funkcija sa promenljivim brojem parametara fff(...) natrčao sam na problem deklaracija, ne neki veliki jer sam uspeo da ga rešim ali bi me znaimalo neko pravilnije rešenje. Dakle ako se funkcija deklariše u istom fajlu kao recimo int fff(int pp, ...); a posle normalno definicija kao int fff(int pp, int qq, int rr) š . . ć stvar pada jer javlja redeklaraciju funkcije. Ukoliko se stvar okrene, pa se u definiciji funkcije ne navedu ostali paramteri kako im simbolički pristupiti? Padalo mi je napamet da ih nekako skidam sa steka ali nije mi se svidjalo da pravim neko psovanje na početku funkcije. Stvar je izgleđena ovako: U fajlu je nisam deklarisao, stavio sam je u biblioteku, u glavni program deklaraciju i jedina stvar koja se javlja je upozorenje prilikom kompajliranja definicije da funkcija nema deklaraciju. Uzgred i printf je deklarisan slično pa postoji mogućnost zaboravljanja variabli. Možda bi overloading funkcija rešio stvar jedva čekam da mi neki C++ padne pod ruke. U stvari nije problem da se koriste funkcije sa promenljivim brojem paramtera i istorodnim paramterima int int int ... je riste paramatere koristitie za različite operacije ali kako preneti raznorodne paramtere na pr u jednom slučaju fff(char *s,int pp, int qq) a u drugom fff(char *s,char *pp) cast ? --------------------- C izgleda voli takve dvosmislenosti pa evo još jednog sličnog i opet pitanja: Kao što sam napomenuo više volim da radim sa nizom nego sa pointer aritmetikom. U TC-u globalnih variabli ne može biti više od 64K bez obzira na memorijski model. Postavlja se problem velikih nizova. Postoje naravno linkovane liste i slična rešenja ali Q&A fajl daje još jedno rešenje: Q. How do I declare an array that's greater than 64K? A. Arrays greater than 64K must be allocated off the heap. If, for example you wanted a two-dimensional array of characters that was 1024 by 128, the declaration you would expect to write would be: char arrayŠ1024ĆŠ128Ć; But since the size of this array is greater than 64K, it must be allocated off the heap. An example of this is: #include <alloc.h> char (huge *array)Š128Ć; : main() š : array = farcalloc(sizeof(*array), 1024); : ć The array can be accessed with the same code as an array not allocated off the heap. For example: i = arrayŠ30ĆŠ56Ć; will assign "i" the value stored at the 31st by 57th element in "array". no to rešenje mi nije ogovaralo iz razloga što koristim i MSC, u njemu bi to moglo sa _fmalloc a možda ću i neki hipotetični za koji nisam siguran da će koristiti ovakve trikove. No ima još jedan štos koji je prenosan: char *ptr; main š maloc.... fff(ptr); ć fff(char arrayŠnnnĆ) š . . . ć Pitanje: Opet sam se bio izvukao uz poruku suspicious pointer conversion. Nije problem u velikim nizovima, to je ekstremni slučaj problem je u svim no char nizovima koji se alociraju po Heap-u. Dakle kako izbeći ove nedoslednosti ? GWW
cccc.7 vkostic, -> #6, lgavrilovic
Zdravo Ljubisa! Ovo je jedan primer kako se koristi funkcija sa promenljivim brojem parametra: #include<stdio.h> #include<stdlib.h> #include<stdarg.h> void main() š void test(int,...); test(5,1,2,3,4,5); test(7,1,1,1,1,1,1,1); ć void test(int c,...) š int i,x; va_list argp; va_start(argp,c); for(i=0; i<c; i++) š x=va_arg(argp,int); printf("%dĐn",x); ć va_end(argp); ć >> U stvari nije problem da se koriste funkcije sa promenljivim >> brojem paramtera i istorodnim paramterima int int int ... >> je riste paramatere koristitie za različite operacije ali kako >> preneti raznorodne paramtere na pr u jednom slučaju >> >> fff(char *s,int pp, int qq) >> >> a u drugom >> >> fff(char *s,char *pp) >> >> cast ? Koristi isti primer koji sam ti dao gore. Deklarises samo jedam parametar, a ostale vadis sa: xxxx= va_arg(argp,int); Ako hoces da uzmes int, stavis int. Ako ti treba float, stavis float, ( va_arg(argp,float); ),itd. Bar jedan parametar moras da navedes u opisu funkcije da bi funkcija na osnovu njega nekako znala koliko jos parametra sledi i kakvog su tipa. Tipican primer je printf koji na osnovu pocetnog stringa tipa "%d %f ... itd" izbroji koliko ima parametra, a onda ih zavisno od tipa skida sa va_arg(argp,int) ili va_arg(argp,int) , itd. Pozdrav, VK. P.S. Upravo se spremam da isprobam QUAIDE ANALIZER.
cccc.8 zzivotic,
Ima li neko iskustva sa blokiranjem prekida programa kompajliranog za Microsoft C u trenutku kada nastene floating-point greška? Po dokumentaciji bi trebalo zameniti lib rutinu matherr svojom u kojoj bi se greška na drugačiji način obrađivala (a ne prekidanjem programa) ali izgleda da ima problema - recimo overflow koji nastaje nakon običnog množenja izgleda da ne može da se presretne na ovaj način? Zoran
cccc.9 bjankovic, -> #8, zzivotic
U Turbo C-u handler za DivideByZero, Overflow i neke FP exceptions deklarisan je u SIGNAL.H, trebalo bi da je tako i u MSC. U TC matherr ne reaguje na integer Overflow. B.J.
cccc.10 vkostic,
U jednoj od ranijih poruka sam napisao da vise volim da koristim TURBO C nega Microsoft C. E, pa od sada jos vise volim TURBO C, a jos vise mrzim Microsoft C. Napisem program koji kompilovan sa TURBO C 2.0 radi savrseno. Kompilujem isti taj program sa Microsoft C 5.0, i tras! Program ne radi. Bug je bio u kompajleru... Jedna sekvenca programa je izgledala ovako: regs.h.ah=0x2F; intdos(&regs,&regs); Medjutim, to je Microsoft-u smetalo zato sto funkcija DOS-a 2F zabrlja DS registar. Kada sam napisao: regs.h.ah=0x2F; intdosx(&regs,&regs,&sregs); onda je sve radilo savrseno. Nemam uputstva za Microsoft C pri ruci da proverim sta kaze za intdos(), ali ja ovu glupost smatram za cist bug kompajlera. Zasto poziv neke DOS funkcije nebi smeo da smesti povratne informacije u neki segmentni registar? I sama funkcija DOS-a 2F je biser za sebe. Vraca pointer (DS:BX) na FAT ID BYTE (i pri tome zabrlja jako vazan DS registar), umesto da taj FAT ID BYTE smesti u BL i zavrsi posao. Inace, program preveden (uz speed optimizaciju) sa TURBO C 2.0 je dugacak 8360 bajta, a sa Microsoft C 5.0 9183 bajta. Pozdrav, V.K.
cccc.11 dbulat, -> #2, lgavrilovic
Long live to MSC 5.10. Oni koji ga ne vole, neka samo i dalje tako misle. Bez obzira na njegovu sporost, nisam naisao na takve probleme koji proizilaze iz neispravnosti kompajlera, dok sa TC 2.0 jesam. Na Zagreb BBS-u postoji jedan fajl sa patchevima za TC 2.0 jerbo taj kompajlet ima bagova kao pas lutalica. Za Vladu K. Steta sto si pokusavao uopce programirati u C-u tako da pozivas registre i slicne "prljavstine". Da se do sada vec nisi afirmirao kao programer, pomislio bih da si samouki haker. Pozdrav! Darko
cccc.12 vkostic, -> #11, dbulat
Zdravo Darko, MSC 5.1 ne koristime jer je hiper glomazan, a osim podrske za OS/2 nema prednosti u odnosu na 5.0 (jedino nekoliko novih pragma, i slicno). Zato jos uvek koristim verziju 5.0. Long live MSC 5.10 ????????????!!!!!!!!??????????!!!!!!!!!??????? Neki vole da posede ispred racunara kok on kompiluje! Jedini nacin da se koristi MSC za neki ozbiljniji program je RAM DISK od par megabajta. Ili razbiti program na vrlo *male* delove, pa sa MAKE... Ako mislis da sa MSC stampas na ekranu "HELLO WORLD", onda je sve OK. Ali ako mislis da radis nesto malo ozbiljnije, onda su pozivi DOS-u i BIOS-u *neophodni*. MSC 5.0 jednostavno nema funkcije koje bi adekvatno iskoristile sve resurse BIOS-a i DOS-a. Voleo to ili ne, moras da se petljas sa registrima. Pozdrav, V.K.
cccc.13 bojanp, -> #5, vkostic
Vlado, jedno pitanje za tebe: Da li ne volis da citas manual-e i on-line help-ove ili imas piratovanu verziju Turbo Debugger-a pa samim tim nemas manual-e koje bi mogao da citas? Neznam sta je u pitanju, ali kao programer nadam se da je ono prvo. (Zivim od pisanja software-a kao i ti.) U Turbo Debugger-u *mozes* da sinle step-ujes kroz funkcije DOS-a i BIOS-a. Jedino sto za to treba da koristis naredbu *Instr* (taster Alt-F7), a ne naredbu step (Alt-F7). Po meni ovo nije mana, nego prednost! Jer, ako realno gledamo kada debug-ujes program koji pise, u 99.99% slucajeva te ne zanima kako funkcija operativnog sistema sistema radi, vec sta radi, a tada ti single step-ovanje kroz funkciju ne treba. Sta pojam "bubice" podrzumeva? Da li bug-ove posle kojih se sve "raspada" ili na cudi kao sto je ovo gore (koja nije tacna)? Ko- ristim Turbo Debugger 1.0 vise od godinu dana i nisam naisao ni na jedan bug. Ako oni stvarno postoje, voleo bih da ih navedes, kako zbog mene, tako i zbog drugih koji koriste TD. Inace smatram da se Turbo Debugger ne moze porediti sa CodeView-om, od kojeg je n puta bolji (n -> +oo). Bojan P.S.: Sta mislis da se otvori tema o programerskim alatkama?
cccc.14 vkostic, -> #13, bojanp
Kada imam gresku u programu, obicno je pronalazim cisto misaonim putem. Lakse mi je da minut dva analiziram program i razmislim gde stvar skripi, nego da pola sata single step-ujem kroz program. To je bar moj stil rada. Zato TD ne poznajem previse dobro. Slazem se da u 99.99% slucajeva nema potrebe da se single step-uje kroj op. system. Ali ponekad i zatreba. U nekoliko retkih situacija kada sam koristio TD, to mi je bas trebalo. Konsulovao sam uputstva, ali za F7 je bas pisalo da ne moze da single step-uje kroj INT pozive. Nigde u blizini nije pisalo da treba pogledati ALT F7. A kada je progrm trebala da bude gotov za juce, onda nemam puno vremena da citam uputstva. Nekada sam imao TI-99/4A, knizicu od 100 strana i BASIC sa 30 naredbi. I sve sam ih naravno znao napamet. Dana ***ne mogu*** da programiram, a da nemam tone prirucnika pored sebe. Ne mogu ni da napisem tri linije, a da ne gledam u Norton guide, MS DOS technical ref, ili uputstvo za kompajler. Stotine BIOS poziva, stotine DOS poziva, hilajde funkcija C jezika, hiljade naredbi masinskog jezika, stotine opcija jednog kompajlera, pa drugog kompajlera, pa asemblera, pa debuggera,... Kako se vremena menjaju! TD je lep proizvod, ali i dalje tvrdim da nije idealan. Pre svega *guta* memoriju. Drzim da je stari dobri FSD prava stvar. Nema menije, nema prozore, nema sarene ekrane, ali radi posao. I ni jednom me nije izneverio kada sam bio u zurbi da hitno otkrijem greske u programu. Code view nisam koristio. Tema o programskim alatima? Dobra ideja! Pozdrav, V.K.
cccc.15 dejanr, -> #14, vkostic
>> Turbo Debugger guta memoriju... Na 386 mašinama Turbo Debugger može da odleti u expanded memoriju posle čega uzima 0 (dobro, par više ali zanemarljivo) bajta osnovne memorije i prema tome da debaguje proizvoljno veliki program! Mislim da mu je to jedna od jačih prednosti nad CodeView-om.
cccc.16 vkostic, -> #15, dejanr
Slazem se. To je idealno resenje za velike programe. Ali dok ne nabavim neku 386 (ili bar 386SX) masinu, memorija ostaje prblem. Mislim da je TD suvise iskomplikovan. Podrzava C i Pascal (i assembler naravno), a ta dva jezika se bitno razlikuju. Mogli su da naprave dva paketa - TD za C i TD za Pascal, i tada bi svaki bio znatno kraci od postojeceg TD. Pozdrav, V.K.
cccc.17 vkostic,
U jedoj od ranijih poruka sam pisao o glupostima MSC-a. Sada je na red dosao TC 2.0 TC za rad sa fajlovaima ne koristi FCB nego file handlere. Ispravan pristup. Samim tim, TC pretpostavlja da DTA podrucje nije od neke velike koristi, osim za funkcije DOS-a 4E i 4F. Ispravan pristup. DTA je dugacko tacno 128 bajta - tako bar kazu svi DOS prirucnici. Istina, DOS ne koristi svih 128 bajta. Ali ako Microsoft kaze 128 bajta, onda se to mora postovati. E, tu dolazi na red TC koji to ne postuje. Desilo se da je TC neke eksterne varijable smestio bas na kraj DTA podrucja! Sta mu je to trebalo, bog ce ga znati. Desilo se i to da je moj program upisivao neke vrednosti u DTA (pretposta- vljajuci da je DTA dugacko 128 bajta). Rezultat? Eksterne varijable su pocele da dobijaju neke cudene vrednosti. Eh, Borlande, postuj ono sto Microsoft kaze!
cccc.18 vkostic, -> #17, vkostic
Evo i malo dublje analize prethodne poruke. Ove je program: ------------------------------------------------------------ /* TURBO C 2.0 tcc -G -a -O -r -Z -ml TEST.C */ #include<stdio.h> #include<dos.h> #include<dir.h> int x; struct ffblk f; void main() š printf("%pĐn",getdta()); printf("%pĐn",&x); findfirst("C:ĐĐ",&f,0); printf("%pĐn",getdta()); ć ------------------------------------------------------------ A ovo su rezultati njegovog rada: 28D1:0080 2A9B:03CC 2A9B:03A0 Prvi broj (28D1:0080) pokazuje da se DTA nalazi gde treba (na offset-u 80H unutar PSP). I drugi broj - adresa eksterne varijable x - je ok. Ali posle poziva findfirst() stvari se menjaju. Treci broj (2A9B:03A0) pokazuje da je funkcija findfirst() premestila PSP u podrucje eksternih varijabli. Sada se varijabla x nalazi samo 44 bajta od pocetka DTA podrucja. A DTA podrucje ima 128 bajta!
cccc.19 lgavrilovic, -> #7, vkostic
Super! 'Prekopao' sam po .H i video kako je deklarisan printf. Često čovek od šume ne vidi stabla. Šta je sa drugim problemom ? P.S. DELBAK ? P.P.S. Čitajući raspravu o XRD-u palo mije napamet da preuredim DELBAK. Nikad nisam razmišljao o brzini njegovog izvođenja verovatno da zato što prikazuje šta radi a to već drastično usporava program. Imaš kakvo mišljenje o tome ? GWW
cccc.20 vkostic,
Opet problemi sa TC 2.0 i MSC 5.0. Ovog puta se radi o funkciji int86x(). Ne mogu da utvrdim gde je tacno problem, ali nesto sigurno nije uredu. Mislim da u jednom trenutku pobrljavi sa stekom. Sve radi savrseno, poziva se nekih 30 puta ta kunkcija, a onda 31 put odjednom se obesi sistem. Inace, sa tom funkcijom pozivam BIOS, int 13h service 02h. Kada umesto int86x() stavim int86(), onda je sve OK. Vrlo je interesantno da i TC i MSC imaju isti problem. Verovatno je krivac int 13h. Dakle, paznja ako koristite int86x() ili int 13h service 02h.
cccc.21 vkostic,
Evo jos jednog bug-a u TC 2.0. Radi se o funkciji intr(). Norton Guide za tu funkciju kaze da se poziva ovako: -------------------------------------------------------------------- intr() Alternate 8086 Software Interrupt Interface #include <dos.h> void intr(intr_num,preg); int intr_num; Interrupt number struct REGPACK preg; Pointer to structure intr() generates an 8086 software interrupt specified by 'intr_num'. The register values from 'preg' are copied into the registers before the software interrupt is executed. After the software interrupt completes, intr() copies the current register values into 'preg'. The flags are preserved. The arguments passed to intr() are: intr_num the interrupt number to be executed preg the address of a structure containing the input registers before the call, and the value of the registers after the interrupt call. The 'REGPACK' structure has the following form: struct REGPACK š unsigned r_ax, r_bx, r_cx, r_dx; unsigned r_bp, r_si, r_di, r_es, r_flags; ć; Returns: There is no return value. 'preg' contains the value of the registers after the interrupt call. -------------------------------------------------------------------- Lepo, ja sam to i uradio, ali program je krahirao. Nije me mrzelo da single step-ujem kroz program i ustanovio sam ovo: Vrednost iz regpac.r_bp se ne prenosi korektno u BP registar procesora! Sta vise, pre poziva interapta u BP se nalazi neka sasvim leva vrednost. Bug se nalazi u instrukciji: MOV BP,ŠBP-1EĆ koja se nalazi odmah ispred INT poziva. Tu se Borland preracunao, trebalo je da stoji: MOV BP,ŠBP-22Ć u tiny, small, medium, compact, i large memorijskim modelima, a MOV BP,ŠBP-24Ć u huge memorijskom modelu. Bas lepo! Neko ce reci da blagosloveni MSC 5.1 nema takav bug, ali MSC i nema funkciju intr(). U stvari, neverovatno je da se u strukturi REGS koja sluzi za funkcije int86(), int86x(), intdos(), itd, jednostavno nema registar BP. Jeste da se taj registar obicno ne koristi za prenos podataka pri INT pozivima, ali postoji bar jedan INT poziv koji bas koristi taj registar. A meni je trebao upravo taj INT poziv.
cccc.22 vkostic,
Imam problema sa huge pointerima sa MSC 5.0. O huge pointerima Norton guide kaze ovo: --------------------------------------------------------------------- huge huge─Non-Standard Type Modifier Huge pointers are similar to far pointers, in that both are 32-bit pointers containing a 16-bit segment address and a 16-bit offset. Huge pointers, however, are normalized, which means that as much of their value as possible is stored in the segment address. This means that the offset portion of a huge pointer cannot be larger than 15 (base 10), because segments start every 16 bytes (base 10). --------------------------------------------------------------------- Lepo. Probao sam da uradim ovo: void main() š char huge *p; p=(char huge *)12345678L; printf("ĐnĐn%pĐn",p); Tu su i Turbo C i Microsoft C stampali isti rezultat: 00BC:614E. Ocekivao sam da cu dobiti normalizovan rezultat 06D0:000E, ali dobro. Dalje: p++; printf("%pĐn",p); Tu je Turbo C stampao: 06D0:000F sto pokazuje da je normalizovao rezultat prilikom sabiranja. To se upravo i ocekivalo. Medutim, Microsoft je zakazao, stampao je 00BC:614F. Rezultat je ispravan, ali nije normalizovan. U cemu je onda razlika izmedju far i huge kod Microsoft-a? Dalje: p+=170000L; printf("%pĐn",p); ć Tu je Turbo C ponovo blistao: 3051:000F. Microsoft je potpuno zakazao: 00BC:F95F. Rezultat ne samo da nije normalizovan, nego je pogresan. E sada se ja pitam ko ju tu lud. Dali je moguce da Microsoft tretira huge pointer kao obican far pointer? Ili ja neznam da koristim CL? Ili Norton guide laze? Sledeci primer kompilovan sa MSC 5.0 je samo potvrdio gore iznetu pretpostavku: void main() š char huge *p; p=(char huge *)((0x4C0BL<<16L)+0x000FL); printf("Đn%pĐn",p); p++; printf("%pĐn",p); ć Program je stampao: 4C0B:000F i 4C0B:0010 sto pokazuje da MSC jednostavno ne ume da normalizuje huge pointer. Dali jos neko ima ovakva iskustva sa huge pointerima? Pozdrav, V.K.
cccc.23 vkrstonosic,
Pozdrav svim Velikim Programerima, Ja imam jedan mali problem: Radims a C-om 5.0 naravno MS, a imam herkules karticu. Pošto MS C 5.0 i QC kao i većina MS programa, ne podrzavaju herkules, molim Velike programere ako neko ima neko rešenje daŰĆ  mi pomogne. Ili ako neko ima dobar simulator CGA za herkules. Unapred zahvalan, Vladimir Krstonošić P.S. Ako imate neko rešenje, javite se ili u ovoj konferenciji ili pošaljite poruku lične prirode (PLP).
cccc.24 godza, -> #23, vkrstonosic
Helo, koristi msherc.com koji dobijes uz msc 5.1 ili bsherc.com (ili tkao nekako koji je isti fajl), koji se dobije uz quick basic pozdrav Godza ps fajl uz basic se zove qbherc.com :-)
cccc.25 cuba,
YACC, LEX UNIX utility Kome treba dokumentacija, mogu je iskopirati iz prirucnika za HP UNIX, vazi i za RATFOR, LINT, itd Cuba
cccc.26 amiler,
Pre svega zdravo svima. Koristim Turbo C 2.0 i hteo bih da postavim pitanje; hteo bih da koristim nasa slova u svojim programima i to koristeci fajlove SANS.CHR, TRIP.CHR,..., odnosno eksterne fontove zapisane u vektorskom obli- ku u ovim fajlovima. Da li neko zna "sintaksu" zapisa ili da li neko vec ima gotove fajlove koje bi ustupio? Hvala, pozdrav Alek.
cccc.27 bojanp, -> #26, amiler
Autor programa BIS (brojke i slova) koristi Borlandov BGI interface, a u programu se sasvim lepo pojavljuju i YU slova. Zato najbolje pitati njega ili nekog koje "ceprko" po BGI interface-u. Bojan
cccc.28 vkostic, -> #27, bojanp
YU slova u grafickom modu su definisana u fajlovima *.CHR. Ako je neko ceprkao po tim fajlovima i definisao YU slova, moga bi to da posalje na Sezam. Svima bi kad-tad koristilo. Pozdrav, V.K.
cccc.29 majkl, -> #27, bojanp
>> Autor programa BIS (brojke i slova) koristi Borlandov BGI >> interface, a u programu se sasvim lepo pojavljuju i YU >> slova... Priroda problema kod programa BIS nije zahtevala intervenciju na TRIP.CHR, GOTH.CHR... naša slova (ŠČĆ) se dobijaju iz slova C i S prostim docrtavanjem 'kukica' napisanim procedurama. Za druge primene ovo sigurno nije dobro rešenje. Treba 'čeprkati' ne samo po *.chr datotekama nego i po odgovarajućim *.obj fajlovima. Pozdrav, Majkl
cccc.30 majkl, -> #29, majkl
Za one koji žele menjati .CHR datoteke... Kratka analiza LITT.CHR (a slično je i sa ostalima) je pokazala sledeće: - definicija svakog slova data je u vektorskom obliku, pri čemu dužina definicije varira od slova do slova - pre samog kraja definicije slova postavlja se vektor na poziciju za sledeće slovo (tako da je lako izmeniti da ispis bude 'proportional' ili ne) - završetak definicije slova označen je sa 00h 00h - pošto dužine definicija slova variraju, postoji tabela koja ukazuje na početne bajtove definicija (kod LITT.CHR tabela počinje od adrese 90h) slova - slovo je definisano nizom parova bajtova, prvi utiče na pomeranje po X osi, a drugi na pomeranje po Y osi funkcija pojedinih bitova je otprilike sledeća: 0 - nepoznato (uvek treba da je 1) 1 - pravac vektora 0 udesno 1 ulevo 2..7 - dužina vektora 8 - 0 samo skok 1 povlači liniju od tekuće pozicije ka novoj poziciji 9 - pravac vektora 0 gore 1 dole 10..15 - dužina vektora Na kraju prilažem izmenjenu datoteku LITT.CHR koja na odgovarajućem mestu ima definisano slovo Ž. Za ovo slovo je bilo dovoljno mesta u datoteci jer je i odgovarajući ascii znak komplikovan, što nije slučaj kod zamene uglastih zagrada našim slovima - tu treba menjati i tabelu pokazivača (da li vam sve ovo zvuči poznato?). Pozdrav, Majkl litt.zip
cccc.31 amiler, -> #30, majkl
>> - slovo je definisano nizom parova bajtova, prvi utice na >> pomeranje po X osi, a drugi na pomeranje po Y osi >> funkcija pojedinih bitova je otprilike sledeca: >> 0 - nepoznato (uvek treba da je 1) >> 1 - pravac vektora 0 udesno 1 ulevo >> 2..7 - duzina vektora >> 8 - 0 samo skok 1 povlaci liniju od tekuce pozicije >> ka novoj poziciji >> 9 - pravac vektora 0 gore 1 dole >> 10..15 - duzina vektora Pokusao sam da primenim gornji opis ali mi se nista ne slaze! Na primer opis slova "L" je: 80 06 80 80 84 80 86 00 00 00. Prema gornjem opisu 8 bit oznacava "skok ili povlacenje linije od tekuce pozicije", sto bi znacilo da se slovo L ispisuje samo ska- cuci sa jednog mesta na drugo ali ne i povlacenjem bilo kakve linije. Vrlo cudno? Pozdrav Alek.
cccc.32 majkl, -> #31, amiler
>> Pokusao sam da primenim gornji opis ali mi se nista ne >> slaze! Na primer opis slova "L" je: 80 06 80 80 84 80 86 00 00 00. >> Prema gornjem opisu 8 bit oznacava "skok ili povlacenje linije od >> tekuce pozicije", sto bi znacilo da se slovo L ispisuje samo ska- >> cuci sa jednog mesta na drugo ali ne i povlacenjem bilo kakve >> linije. Vrlo cudno? Pozdrav Alek. Bitove sam označio od 0 do 15 (a ne 1..16), pa je možda to dovelo do zabune... Na primeru slova "L" to izgleda ovako: 80 06 (bit 0) = 1 (bit 2) = 0 udesno (2..7) = 0 X koordinata: 0 (bit 8) = 0 skok (bit 9) = 0 gore (10..15) = 6 Y koordinata: 6 tj. skoči na poziciju 0,6 80 80 (bit 0) = 1 (bit 2) = 0 udesno (2..7) = 0 X koordinata: 0 (bit 8) = 1 skok+ispis (bit 9) = 0 gore (10..15) = 0 Y koordinata: 0 povuci liniju do 0,0 (uspravna crta slova L) 84 80 (bit 0) = 1 (bit 2) = 0 udesno (2..7) = 4 X koordinata: 4 (bit 8) = 1 skok+ispis (bit 9) = 0 gore (10..15) = 0 Y koordinata: 0 povuci liniju do 4,0 86 00 (bit 0) = 1 (bit 2) = 0 udesno (2..7) = 6 X koordinata: 6 (bit 8) = 0 skok (bit 9) = 0 gore (10..15) = 0 Y koordinata: 0 skoči na 6,0 (pozicija za naredno slovo) 00 00 kraj def. slova "L" Pozdrav, Majkl
cccc.33 dejanr,
Izašao je Microsoft C 6.0. Pogledajte FORUM/MICROB poruka 25.70. Dejan
cccc.34 dgergelj,
Posto sam samo knjiski poznavalac C-a molim velike magove da mi odgovore na sledeca pitanja: 1. da li je moguce, a ako jeste kako linkovat object kod koga je napravio Lettice C compiler (medium ili small) model (oba imam) sa object codom koji je kompiliran za large model. Konkretno pokusavam da povezem Oracle R4.0 sa Turbo prolog-om. Za prvi paket raspolazem objectima za vezu sa lattice C-om , a drugi R1.1 moze da se linkuje sa large modelom Lattice C-a. Unapred zahvalan !!!
cccc.35 dkovac,
 ű Nemam mnogo iskustva sa C-om na PC, ali vidim da se tu nalaze ljudi koji stvaĺĚťĺuraju. Interesira me da li tko ima lib za C koji sadrzi sve rutine za rad sa dBase odnosno Clipper datotekama , te da li to uopce radi i ako radi koja su karakteristike. U Byte reklamiraju taj lib. po cijeni oko 295$ . Mene interesira da li to stvarno radi i da li tko radi sa time. Pozdrav Dejan Kovac
cccc.36 pbeciric,
TURBO C 2.0 HELP!!! Kako da linkujem program pisan u Turbo C-u sa BGI-om? Pozdrav, Predrag Beciric
cccc.37 caka,
Jao, jao, da li bi neko mogao biti ljubazan da mi zipuje 1. stat.h 2. timeb.h 3. types.h iz Turbo C-a 2.0 i ostavi uz poruku u ovoj konferenciji. Zaista mi hitno treba, zahvaljujem najtoplije unaprijed. Caka
cccc.38 braca, -> #37, caka
Evo ti traženi fajlovi tc.zip
cccc.39 caka,
Braco, hvala ti najljep{a, BBS pokazuje svoje prave vrijednosti. Ti fajlovi idu u direktorij \SYS pa je momak zaboravio da ih kopira i tako ... Thanks again ! Caka
cccc.40 dbasaric,
Posjeduje interni modem prikljucen na COM4. Komuniciram uspijesno sa PROCOMM-om medjutim ne mogu nikako da zadajem komande modemu iz mog programa, programe sam pisao u TC,(pokusao sam da experime- ntisem iz Basic-a ali on ne podrzava COM4).Dok sam imao externi modem prikljucen na COM2 sve je uspjesno radilo. Znali neko sta treba da uradim. Denis
cccc.41 vkostic, -> #40, dbasaric
Ako je modem prikljucen na COM4, onda mu se ne moze pristupati ni preko BIOS-a, ni preko DOS-a, jer oba podrzavaju samo COM1 i COM2. >> Programe sam pisao u TC. Da, ali sta si napisao? Ako si koristio funkciju bioscomm (ili vec kako se zove), onda stvar sigurno nece raditi za COM4. A nece raditi ni ako si koristio LCOMM od Zorana. Medjutim, mozes vrlo lako da prepravis LCOMM da prodrzava COM3 i COM4 i onda je sve OK. Ja sam to uradio, pa mogu da ti posaljem prepravljenu verziju LCOMM-a. Pozdrav, V.K.
cccc.42 dbasaric, -> #41, vkostic
Hvala Vlado. Tako nesto sam i pretpostavljao jer sam iz TC radio sa bioscom samo zato sto je na HELP-u pisalo: int bioscom(int cmd, char abyte, int port); cmd values are 0 - set comm. parms to abyte 1 - send abyte out 2 - receive a char (in low 8 bits of return value ) 3 - return status +---------------------------------------+ | PORT IS 0 FOR COM1, 1 FOR COM2 ETC. | +---------------------------------------+ E, ovo ETC. je bilo problem. Sto se tice LCOMM-a bio bih zahvalan kada bi mi ga dostavio. Denis
cccc.43 vkostic, -> #42, dbasaric
>> +---------------------------------------+ >> đ PORT IS 0 FOR COM1, 1 FOR COM2 ETC. đ >> +---------------------------------------+ >> >> E, ovo ETC. je bilo problem. Da, stos je u tome sto neki BIOS-i podrzavaju COM3 i COM4, a vecina ne. >> Sto se tice LCOMM-a bio bih zahvalan kada bi mi ga dostavio. OK, saljem Zoranov LCOMM koji sam prepravio da radi sa COM3 i COM4. Pozdrav, V.K. lcomm.asm
cccc.44 dbasaric,
Da li bi neko mogao da mi zipuje TLINK ( samo da nije verzija 2.0 ). Denis
cccc.45 vkostic, -> #44, dbasaric
>> Da li neko moze da mi zip-uje TLINK? Moze, javi se na 011 426-569.
cccc.46 bjankovic,
Pokusao sam da sa programom FE (font editor za Borland CHR fontove) iz arhiva BGITOOLS koji se nalazi na MIPS-u prepravim neke BGI fontove. Program korektno učita font, editovanje ide sasvim normalno, međutim datoteka koja se snimi na disk ima potpuno haotičan header - gotovo sve je pogrešno. Da li je neko radio sa tim programom i možda zna u čemu je stvar? B.J.
cccc.47 senadm,
Da neko slučajno nema source programa za igru PREFERANS u C-u (ili nekom drugom programskom jeziku). Biću mu zahvalan ako mi ga prebaci. Dobro će doći i source-vi drugih kartaških igara. Gore navedeno potrebno za sirote studente zagrebačkog ETF-a. Seni
cccc.48 vkostic, -> #38, braca
>> Da neko slučajno nema source programa za igru PREFERANS u C-u. Adnan Smajlovic (071/37-256) ima bas sto ti treba. Pitaj ga, mozda ti da source. Pozdrav, V.K.
cccc.49 vkostic,
Danas sam dobio Microsoft C 6.0 (izvor necu da navedem posto se radi o maloj piratskoj seansi). Prvi utisci: ┌───────────────────────────┬───────────┬────────────┬─────────────┐ │ Compiler │Comp. time │ Exec. time │ Code size │ Ă═══════════════════════════ě═══════════ě════════════ě═════════════Á │ TC20 (tcc -G -O -Z -a -r) │ 16 sec │ 509 sec │ 33344 bytes │ ├───────────────────────────┼───────────┼────────────┼─────────────┤ │ MSC 6.0 (cl) │ 70 sec │ 490 sec │ 30311 bytes │ ├───────────────────────────┼───────────┼────────────┼─────────────┤ │ MSC 6.0 (cl -Ox) │ 87 sec │ --- │ 30199 bytes │ └───────────────────────────┴───────────┴────────────┴─────────────┘ Program koji sam kompajlirao se sastojao od toga da ucita fajl od 25K, zatim nesto silno mulja sa stringovima i na kraju generise izlazni fajl od 500K. Sam rad sa diskom oduzima manje oko 8% vremena. Program nije radio nista sa floating point brojevima. Rezultati iz tabele pokazuju: - Da je Turbo C pravi sampion u brzini kompilacije. Microsoft to radi pet puta sporije. - Microsoft generise malo kompaktniji i brzi kod. - Opcija -Ox (max optimizacija) je porizvela vrlo lep i kratak kod koji na zalost nije radio. Nisam se upustao u analizu gde je kompajler zabrljao. Izgleda da ce posle ovo kratke probne seanse Turbo C i dalje ostati moj omiljeni kompajler. Pozdrav, V.K.
cccc.50 dejanr, -> #49, vkostic
>> - Opcija -Ox (max optimizacija) je porizvela vrlo lep i kratak >> kod koji na zalost nije radio. Nisam se upustao u analizu gde >> je kompajler zabrljao. Jasno je da se mogu iskonstruisati situacije koje optimizator nikako ne može ispravno optimizovati (npr. do while flag - end za flag=true će svakako biti optimizovano u "ništa", ali šta ako neka interapt rutina menja fleg?) ali u normalnim situacijama nije baš zgodno da kompajler pravi takve nestašluke. Zapravo MSC pravi dobar i brz kod ali izgleda prečesto pravi brljotine dok optimizuje. Zanima me kako su napisali VAX-ov Fortran (za koji se piše da je najbolji optimizator na tržištu) na kome se (bar meni) *nikad* nije desilo da nešto pogrešno optimizuje. Kako to da na PC-ju mora da bude tako kilavo?
cccc.51 kanda, -> #50, dejanr
>> Jasno je da se mogu iskonstruisati situacije koje optimizator >> nikako ne može ispravno optimizovati (npr. do while flag - end >> za flag=true će svakako biti optimizovano u "ništa", ali šta >> ako neka interapt rutina menja fleg?) Bar za ovaj slučaj, leka ima. Dakle, promenljivu flag treba deklarisati kao volatile (službena reč), čime se prevodiocu stavlja do znanja da promenljiva flag može menjati vrednost čak i ako se to iz programa ne može zaključiti. Znači, deklarišeš volatile int flag ; ... i prevodioc neće (bar ne bi trebao !) optimizovati while u 'ništa'. Vrednost volatile promenljive (volatile = 'nestalna') se smatra nepoznatom, bez obzira na dodele vrednosti.
cccc.52 zzivotic, -> #49, vkostic
Što više radim sa ovim MSC-om (ja sam osuđen, šta da radim :( ), sve mi se čini da su u stvari zabrljali samo jednu stvar. Naime, jedno od jačih sredstava optimizije je upotreba registara umesto memorijskih lokacija. U verziji 5.0 (5.1) je sa ovim bilo problema jer se dešavalo da kompajler jednostavno "zaboravi" da je vrednost registra (naročito ES) u međuvremenu promenjena i da više ne drži pravu adresu. Nevolja je bila u tome što ova vrsta optimizacije nije bila posebno kategorizovana pa se nije mogla direktno isključiti ili uključiti bez uticaja na ostale optimizacije. U verizji 6.0 izgleda da je stvar ostala na istom (opet greši i opet taj ES!) ali sada bar postoji prekidač kojim se može ovaj tip optimizacije isključiti. Naravno, prva stvar koju sam probao kada sam dobio kompajler je da prevedem softver za novi Sezam (uključivši maksimalnu optimizaciju) i bio sam prilično iznanađen koliko je kod bio skraćen (što se brzine tiče, ova aplikacija baš nije dobar test jer nema nekih kritičnih delova po pitanju brzine izvršavanja). Program je iz prve proradio ali sam brzo otkrio i jedan smešan bag. Svaki datum koji bi zadao kao parametar neke naredbe (u formatu ddmmgg) program bi loše preveo pa bi recimo 010190 postalo 01.01.234 i slične gluposti. Rutina koja niz od ovih šest asci sifara pretvara u datum je izdvojena u funkciju koja to radi krajnje jednostavno, redom uzima po dva znaka i na "licu mesta" ih pretvori u decimalni broj (na primer date.day = (str[0]-'0')*10 + str[1]-'0') i tako tri linije jedna ispod druge za mesec i godinu - jednostavno da jednostavnije ne može biti. Kada sam pogledao kako je to kompajler preveo, zaista sam se slatko ismejao! U prvoj liniji je u ES sačuvao adresu date strukture a pošto mu je ES trebao za adresiranje stringa onda je njegov sadržaj tokom cele rutine prebacivao u razne registre "žonglirajući" da u njima ipak ostanu nekako i ofseti adresa jer se optimizator očigleno namerio da tako jednostavnu rutinu prevde bez korišćnja memorijskih promenjivih. E, tog prebacivanja je bilo toliko i to u tako fantastičnim kombinacijama da je jednostavno posle prve dve linije jednostavno morao da se saplete! S obzirom da će u "Računarima" biti prikaz ovog kompajlera, pokušaću da ponovim ovu situaciju i da dam listing - oni koji poznaju asembler će se zaista lepo zabavljati. Microsoft izgleda da i ne krije da su preterali! U dokumentaciji počinje da se pojavljuju i objašenja tipa "probajte prvo sa ovom optimizacijom koja je jako agresivna (?!?) pa ako program krahira (!) onda je isključite! Lepo je što priznaju ali bojim se da to kod većih projekata, bar što se mene tiče, ne dolazi u obzir. Pozdrav, zz
cccc.53 dejanr, -> #51, kanda
>> Bar za ovaj slučaj, leka ima. Dakle, promenljivu flag treba >> deklarisati kao volatile (službena reč), čime se prevodiocu >> stavlja do znanja da promenljiva flag može menjati vrednost >> čak i ako se to iz programa ne može zaključiti. Eh, pa nisam ja ni rekao da leka nema. Ali u tome i jeste stvar sa greškama kompajlera - on napravi glupost, ti dodaš nešto da bi ga u tome sprečio. Naravno, prethodno se namučiš da shvatiš šta je uradio...
cccc.54 dejanr,
Q12. What happened to the inportb() and outportb() inline macros in dos.h? A. They accidentally got left out. You can copy the definitions below into dos.h. BTW, there are also definitions for word IO, but they don't work correctly in this release of the compiler. void _Cdecl outportb(int portid, unsigned char value); void _Cdecl __outportb__ (int portid, unsigned char value); #define outportb(portid, v) __outportb__(portid,v)/* Byte OUT instruction */ unsigned char _Cdecl inportb(int portid); unsigned char _Cdecl __inportb__ (int portid); #define inportb(portid) __inportb__(portid)/* Byte IN instruction */ Q13. Why does varargs require that arguments be on the stack? A. I don't know, but many months ago someone from Borland asked if that would be a reasonable requirement, and no one could think of a reason why not. (Since then, someone obviously has :-). Q14. Why does linking with WILDARGS.OBJ cause my program to crash? A. There appears to be a bug using WILDARGS.OBJ and large model programs. Expect a fix shortly. Found by Hyman Rosen 74716,3415. Q15. Why does my large model program not work? A. If stack checking is enabled, turn it off. Stack check in large model is said to not work properly. Q16. What is a good book for learning C++ programming? A. C++ Primer, Stanley B. Lippman, ISBN 0-201-16487-6. Q17. Why does the linker complain about missing functions when I use C++ streams? A. If you have selected Unsigned Chars:ON, change back to off, or edit the <iostream.h> file on lines 577, 593, 597 to be (const signed char *) in place of (const char *). Q18. Where are the programs TCCNVT.EXE and PRJ2MAKE.EXE? A. These utilities were not completed in time for shipment, and should have been removed from the manuals. There is no information on future plans regarding them. Q19. Why does my program crash when I link with overlays, but work ok without them? A. Are you overlaying any modules that are data-only? Create a detailed .MAP file, and see if any of the code segments being overlayed are 0 bytes long. If so, don't overlay that module. Q20. Why doesn't the preprocessor 'stringize' my macro? This works OK in TC 2.0: #define TEMP 5 #define STR(x) #x printf("TEMP is %s\n", STR(TEMP)); A. ANSI has defined how the preprocessor converts macros. This will work: #define STR(x) STR1(x) #define STR1(x) #x Q21. Why doesn't MK_FP work the same way? A. For most arguments to the MK_FP macro you will get the same results. However, if you are passing a long value, you may get something unexpected. You should pass two integers as parameters. Q22. I'm using overlays and C++. Why does my system crash when exit() is called? A. There is a bug in c0.asm. Either don't call exit() when using overlays and C++, or make this change to c0.asm, and run BUILDC0.BAT. To change your c0.asm, follow these steps: 1) unzip the file STARTUP.ZIP in /turboc/examples 2) edit C0.ASM, moving these lines mov byte ptr cs:JA_JB,72h mov byte ptr cs:StartExit+1,0 to before the call _main 3) run the BUILD-C0 batch file 4) link with the new C0x.OBJ file Q23. Nothing seems to be working. I get crashes when compiling, or running program that seemed to work before. What's wrong? A. A common cause of mysterious crashes is using an old mouse driver. TC (and TD, TProf, etc) use some mouse driver features that old mice don't have. This allows them to share the mouse between the program being tested, and TC. An old driver can cause various problems. You can get new drivers at these locations: Mouse Systems Version (415) 683-0617 Logitech Version 4.1 ???? Microsoft Version ???? Q24. Why am I getting memory overwrites at run time? A. If you link any code that defines CONST segments this will confuse TLINK. Either you need to add CONST segments to the proper place in C0.ASM, or remove the CONST segments from your code. Q25. How can I tell if I'm linking in improper assembly routines? A. Create a detailed map file. The segment order should in general be as follows: Start Stop Length Name Class Comments 00000H 00433H 00434H _TEXT CODE One or more CODE segments 01AC5H 01D13H 0024FH TZSET_TEXT CODE 01D20H 022C2H 005A3H _DATA DATA One or more DATA segments 022CEH 022D9H 0000CH _SCNSEG DATA 022DAH 02367H 0008EH _BSS BSS The _BSS segment 02368H 02368H 00000H _BSSEND STACK Then _BSSEND with class STACK 02370H 023EFH 00080H _STACK STACK Then finally STACK Q26. TLink crashes when linking in my own ASM file? A. If you enabled debugging symbols (/zi), and have multiple symbols with the same name (@@1:, etc) this may confuse TLINK. Change the symbol names, or use the (/zd) option. If any of this information is outdated, or not correct, or if you have any suggestions for other items to cover, please let me know. I will try to update this file (and STDANS.TXT on DL5) several times a year, but only if I get the feeling it is useful to others. Don Corbitt 74017,3244 Sunnyvale, California --- Don_A_Corbitt@cup.portal.com Not a spokesperson for CrystalGraphics, Inc. Mail flames, post apologies. Support short .signatures, three lines max.
cccc.55 dejanr,
========================== borland/long.messages #9, from gmussar, 13086 chars, Tue Jul 17 23:15:06 1990 -------------------------- TITLE: Standard Answers to Frequently Asked Questions: New, Improved Turbo C++ The following text was posted to USEnet. I seems to have some origins on CI$. Don Corbitt (Not for BI) 74017,3244 This file has the goal of answering many of the common questions seen on BPROGB regarding Borland Turbo C++. I don't represent Borland, any opinions are my own. There is a similar file called STDANS.TXT in DL5 of BPROGB. It answers common questions that apply to TC++ and TC (and programming in general). This file is specific to Turbo C++ version 1.0. Overview ============== Enable warnings. Many programming errors can be diagnosed by the compiler. If you enable all warning messages you have a much better chance of writing programs that work the first time. Formatted messages When you leave messages regarding problems, please use the /POST UNFORMATTED option. Otherwise, CIS (Compuserve Information Service) will re-format your program into a jumbled mess. RTM - Read The Manual - readme and helpme!.doc Before spending $$$ on CIS, it is often useful to read the documentation. Also, look at the files README and HELPME!.DOC included with TC. They list fixes to many common programming errors. The TC++ 1.0 manuals have a lot of good information. HELP ME!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ======================================== If you're just getting started, and nothing seems to be working, see these questions first: Q23 - mouse driver incompatible Q15 - large model and stack checking Q4 - assembly code and 3rd party libraries Q24 - assembly code and 3rd party libraries Q19 - overlays and data-only modules Q22 - overlays and exit() with C++ or atexit() functions Q9 - editor hangs when copying blocks of text TAPCIS Q1. What is TAPCIS, and how does it help? A. TAPCIS is a program that calls CIS, checks for new messages, saves them on disk, and hangs up. Then it lets you examine the messages at your own pace, write replies, etc. TAPCIS then calls CIS back, and uploads replies you have written. It saves a lot on connect charges. GO TAP for more information. It is shareware, and registration is expected if you like it. Another program (ATO) is free, but I haven't used it. OS|2/Windows linking Q2. Can I use TC for OS|2 or Windows? A. Windows and OS/2 are both 'strategic areas' for Borland. This means that eventually BI's main products will work under DOS, Windows, and OS|2-PM. At this time, the outside world doesn't know what the timetable is. It doesn't do any good to ask for specific dates, because the people that know aren't allowed to say. "Borland does not pre-announce product releases." Q3. Why is this C++ program illegal? void main() { for (int i=0; i<10; i++) for (int j=0; j<10; j++) ; } A. The AT&T C++ 2.0 specification stated that variables can't be declared in such a way that the initializer may never execute, but they are still in scope. Turbo C implements this 2.0 rule. This rule was changed back in the AT&T 2.1 spec, and I expect a future version from Borland will follow C++ 2.1. A simple workaround is to add braces around the inner 'for' loop: void main() { for (int i=0; i<10; i++) { for (int j=0; j<10; j++) ; } } Q4. Why does malloc() corrupt memory? Why does my program fail in mysterious ways? Why does my program die when linked with TLINK 3.0, but work with TLINK 2.0? (etc.) A. If you are linking in any assembly code, look for the DOSSEG directive. DOSSEG was defined for a previous version of MSC compilers, and is not currently needed. In fact, it conflicts with the segment ordering of Turbo C++. Previous versions of TLINK ignored the DOSSEG record, so they (often) worked. The solution is to remove DOSSEG from your assembly source, and reassemble. If you are linking with third party libraries and don't have the source, ask them to send you a new library. If they can't/won't, try linking in the integrated environment, and find a new library vendor that is easier to work with! :-) Q5. Why does qsort() give a warning/error, when it worked fine under TC 2.0. A. TC++ 1.0 is more strict in ANSI compliance. It is warning you that your program may not work on certain computers. Two examples of correct compare functions are: /* if sorting an array of integers */ int fcmp(void const *p1, void const *p2) { const int *ip1 = p1; const int *ip2 = p2; if (*ip1 < *ip2) return -1; if (*ip1 > *ip2) return 1; return 0; } /* if sorting an array of strings */ int fcmp(void const *p1, void const *p2) { return strcmp(p1, p2); } Q6. When I use overlays, I get a linker warning that setjmp and longjmp are multiply defined. Why? A. OVERLAY.LIB includes its own setjmp and longjmp. This warning is expected, and correct. You can disable it if you wish. Q7. Why is Turbo Debugger 2.0 so much slower than TD 1.5? A. For some machines, TD2 seems much slower, but not on others. Suggestions for increasing speed are 1) disable execution history 2) update your mouse driver to latest release 3) disable use of mouse in TD Q8. Can I place third party libraries in VROOM overlays? A. Yes, if the vendor compiled with the -Y switch, or you have source and recompile with -Y. If your vendor won't do so, tell Borland and they will try to encourage them to fully support VROOM. Q9. When I try to copy a block in the IDE, the system hangs. A. There is a bug in the editor - if the file ends in Ctrl-Z, the last line is not terminated with CRLF, and there are an odd number of chars in the last line, this will happen. Workarounds are to terminate with CRLF, or remove the Ctrl-Z. TC 2.0 inserts Ctrl-Z, while simply saving the file from TC++ 1.0 will strip them. Q10. I ordered the ProPack upgrade option for $125. Why didn't I get new TASM manuals? A. Although TC++ 1.0 is _not_ an upgrade from TC 2.0, the Pro-Pack part of the package (TD, TASM) is an upgrade. TASM had very few changes, which are documented, so no new manuals were sent out. There is a new quick reference guide, which is useful. If you don't have TASM 1.0 manuals, you should have ordered the $145 special package which is for people that don't have the Propack, and need all the manuals. A few people threw a tantrum when their package arrived sans TASM manuals. Borland agreed to send them TASM 2.0 manuals, and make sure any future purchasers know what each order contains. Q11. I ordered the upgrade through Borland for $xxx, and the next week I found the same package for $xxx-10 at the local "Software Is Us"store? Why is Borland ripping off its loyal customers!!!!! A. There are two parts to this answer... 1) Take a deep breath, count to ten, exhale slowly. Now that you feel more relaxed... 2) C++ is a new product, so the special deals for past customers are not as special. Each store/distributor is free to charge what it wishes for software, including selling at or below cost. Since they buy in huge quantity, they get very good prices, and handling/postage is much lower than individual sales. So I recommend checking with your local discount house before placing an order direct to Borland. PS - Egghead Software had a typo in their advertisements. It looked like they were selling TC++ Pro Pack for $90, when it was really just TC++ 1.0, no TASM/TD/TProf, etc.
cccc.56 mdasic,
Zna li neko (hvala bogu da zna) kako da u MSC 5.0 (eventualno TC 2.0) postavim pointer (recimo long) na neku apsolutnu masinsku lokaciju (re- cimo na pocetak video memorije ili ROMa). Unapred hvala.
cccc.57 zzivotic, -> #56, mdasic
>> Zna li neko (hvala bogu da zna) kako da u MSC 5.0 (eventualno TC 2.0) >> postavim pointer (recimo long) na neku apsolutnu masinsku lokaciju >> (recimo na pocetak video memorije ili ROMa). Generalno se to radi upotrebom long vrednosti i cast operatora, recimo: unsigned far *videram = (unsigned far *)0xb0000000L; long far *timer = (long far *)0x00000470L; Pozdrav, zz
cccc.58 bojt, -> #57, zzivotic
E, da: Zorane, kolki ti je problem da mi pošalješ OBJ potprograma u MSC-u 5.0 koji bi radio sledeće: ja mu prenesem ime fajla a on mi vrati njegovu dužinu? Treba mi hitno da ga linkujem sa fortranom a nemam MSC pri ruci.
cccc.59 aleks,
Potreban mi je nacin da "navucem" skoljku na neki exe program, tj da presretnem sve console I/O funkcije i moj parent program da salje ulaze u cld exe. Disk i ostale periferije me ne interesuju. Moze li to iz TC-a sa funkcijama exec i spawn? unapred hvala, Aca.
cccc.60 ppekovic,
MS C 6.00 je jako lepa stvar. Optimizacija u MS C 6.00 još lepša. A L I !!!!!!!! Zorane (Životić), pazi sad ovo: #include <stdio.h> #include <float.h> main() š union š float broj; struct š int l1; int l2; ć dg; ć podeli; printf("Unesi broj >"); scanf("%f",&podeli.broj); printf("Ovo ne štampa %d %d",podeli.dg.l1,podeli.dg.l2); ć Posle startovanja ispiše lepo Unesi broj > Uneseš ti lepo neki broj a onda te dočeka Run-Time greškica R6002. Koja kaže nešto kao Floating point support not loaded. HA!!!!! Probao sam razne stvari da promenim u programu i došao do sledećeg zaključka: Ako definišeš neku promenljivu tipa float ali u main() funkciji ne vršiš nikakve dodele, promene vrednosti, štampanje i sl. te promenljive, onda optimizator jednostavno ne učita float.h. Naravno samo ako je ta promenljiva jedina float koja se nalazi u programu kao u gornjem primeru. Međutim nije mi jasno zašto optimizator ne proverava funkciju scanf (vidi gornji primer, opet). Napomena: sve ovo lepo radi na TC 2.0. Bubice, Bubice, Bubice ....... !!!!!!!! Paya
cccc.61 zzivotic, -> #60, ppekovic
>> Uneseš ti lepo neki broj a onda te dočeka Run-Time greškica R6002. >> Koja kaže nešto kao Floating point support not loaded. HA!!!!! ... >> Ako definišeš neku promenljivu tipa float ali u main() funkciji ne >> vršiš nikakve dodele, promene vrednosti, štampanje i sl. te >> promenljive, onda optimizator jednostavno ne učita float.h... >> Međutim nije mi jasno zašto optimizator ne proverava funkciju scanf.. Izgleda da sam se ja toliko bavio tom MSC optimizacijom da se sada sve "neobičnosti" pripisuju njoj ;) Uključivanje .H datoteke u program nije posao optimizatora niti se njenim uključivanjem uključuje floating point support - u datoteci su prosto deklaracije i uvek se obrađuju. Problem je u tome što treba iz LIB datoteka ubaciti u program deo koda koji se bavi realnim promenjivima a to se postiže tako što se na nekom mestu u programu pojavljuje bilo kakva fp operacija. To *neko mesto* mora biti dostupno kompajleru za analizu. Pošto je funkcija scanf deklarisana tako da prima *promenjiv* broj parametara, kompajler jednostavno nema načina da se upusti u analizu o kakvim se stvarno podacima radi - dovoljno je da njihove adrese prenese na stek. Ovakav stav može da se kritikuje (zar ih zaista nešto košta da provere da i neki od tih parametara nije float?, mada ako unutar format stringa nema %f onda čak i da je parametar float tipa, fp support nije potreban, znači trebalo bi analizirati i format string što bi bilo totalno ne C-ovski!) ali svakako nije bag. Pozdrav, zz
cccc.62 aleksa, -> #60, ppekovic
Klasicno resenje kod scanf i printf funkcija je da se obavezno linkuje i floating-point podrska, jer se (u principu) ne zna sta ce sve biti u format stringovima u toku izvrsavanja programa. Ovde su u Microsoft-u ocigledno pravili trikove, da izbegnu znacajno povecanje .EXE programa koji ne rade floating-point samo zbog toga sto ove (cesto koriscene) funkcije nekada koriste floating-point. Posto se u tvom programu nije pojavila nijedna floating-point operacija, nije bilo ni linkovanja. Sve je to, naravno, posledica nesposobnosti operativnog sistema. Na pristojnijim OS imas stvari kao sto je linkovanje u toku izvrsavanja. Naravno, cela prica pada u vodu ako u knjizi (knjigama?) za MS C 6.0 nigde ne stoji opis ovakvog ponasanja. Ako stoji, vazi pravilo "It's not a bug, it's a feature!". U svakom slucaju, ovo sto si opisao nije neko iznenadjenje. Kad muvas, moras da poznajes okruzenje.
cccc.63 zzivotic, -> #62, aleksa
>> Naravno, cela prica pada u vodu ako u knjizi (knjigama?) >> za MS C 6.0 nigde ne stoji opis ovakvog ponasanja. >> Ako stoji, vazi pravilo "It's not a bug, it's a feature!". Pa, po ovoj klasifikaciji, mogao bi biti i bag kompajlera, ali i bag u uputstvu ;) Naime, u uputstvu se ekplicitno pominju printf i scanf funkcije ali iz objašnjenja koje je dato sledi da linkovanja neće biti samo u slučaju kada se specifikacija *nalazi unutar* format stringa a u programu *nema ni jedne* float promenjive. Ovo je očigledna besmislica jer nema razloga da se ovim slučajem uputstvo bavi pa verujem da se ipak radi o bagu u uputstvu. Uostalom, ko ima MSC 6.0 može da proba QH R6002. Pozdrav,zz
cccc.64 vkostic,
Jedan hitam problem vezan za MSC 5.0 ili 6.0 (Chetka uporno odbija da mi vrati uputstva pa sam bespomocan): - Da li postoje funkcije za ukljucivanje/iskljucivanje interapta - nesto kao enable() i disable() kod TC-a? - Kako da masinksa rutina vrati long? 16 bita u AX, a preostalih 16 u koji registar? Pozdrav, V.K.
cccc.65 aleksa, -> #64, vkostic
> - Kako da masinksa rutina vrati long? 16 bita u AX, a > preostalih 16 u koji registar? Dosad je uvek bilo u DX. > - Da li postoje funkcije za ukljucivanje/iskljucivanje > interapta - nesto kao enable() i disable() kod TC-a? Imas bas te (prototipovi su u DOS.H, ali mislim da ti nesto i ne trebaju). Ovo je sigurno za 5.0, a valjda nisu menjali.
cccc.66 ppekovic, -> #65, aleksa
> > - Da li postoje funkcije za ukljucivanje/iskljucivanje > > interapta - nesto kao enable() i disable() kod TC-a? >Imas bas te (prototipovi su u DOS.H, ali mislim da ti nesto i ne >trebaju). > >Ovo je sigurno za 5.0, a valjda nisu menjali. Ima i na MS C 6.00 _enable() i _disable(). VladoK pogledaj help, ima čak i primer ako hoćeš. Paya
cccc.67 vkostic, -> #66, ppekovic
>> VladoK pogledaj help, ima čak i primer ako hoćeš. A odakle mi HELP? Nemam 5 MB prazno na disku da instaliram MSC, a i ne istalira mi se samo radi programa od 20 linija. Obicno koristim TC. No, stvar je resena. Chetka mi je NAJZAD vratio uputstva pa sa pogledao. _disable i _enable upravo rade stvar. Moram jos jedanput da pustim VELIKI URLIK OCAJANJA nad onim sto rade Microsoft i Borland. Zasto ne standardizuju biblioteku funkcija ??? Zasto se u TC pise enable() i disable(), a u MSC _enable() i _disable() ???? Zar nije moglo isto? A takvih primera ima jos milion. Pozdrav, V.K.
cccc.68 mknezic,
Prebacio sam arhiver LZW sa SEZAM-a. Kompajlirao sam ga pod DOS-om i pod SCO XENIX-om i to radi bez problema. Medjutim kada sam ga prebacio na VAX-a i pokušao da kompajliram javio mi je sledeću grešku: void *malloc(); %CC-E-VOIDNOTFUNC, "malloc" is not declared to be a function; only functions may be declared "void". Da li neko zna u čemu je problem? Mirko
cccc.69 alazic,
Treba mi hitno spisak datoteka koje ýp koristi Quick C iz MS C 5.1▀Ú─▀ ÚÚ─╗´Ď isto tako mi je potrebna datoteka QC.INI - imao sam tesku havariju sa disketama. Unapred hvala
cccc.70 sgoran, -> #69, alazic
Volume in drive D has no label Volume Serial Number is 1150-16E5 Directory of D:\MSC\BIN QLIB DOC 12047 03-07-88 5:10a QC EXE 326656 03-07-88 5:10a QCL EXE 28065 03-07-88 5:10a QLIB EXE 24557 03-07-88 5:10a QC HLP 50649 03-07-88 5:10a QCL HLP 1456 03-07-88 5:10a QC INI 32 03-19-90 6:19p QLIB INI 2905 03-07-88 5:10a QUICKLIB OBJ 7917 03-07-88 5:10a 9 File(s) 8034304 bytes free Javi mi kako da ti dostavim QC.INI. Pozdrav SGoran.
cccc.71 milan, -> #68, mknezic
Ko zna koji kompajler imas, mozda se malloc kod njega ne zove tako vec malloc-ove funkcije obavlja alloc ili calloc ili ko zna sta jer sve price o ANSI compatibilnosti nisu uvek tacne. Prosto pravilo glasi: IF EVERYTHING ELSE FAILS, PLEASE READ THE MANUAL ! Pozdrav, Milan
cccc.72 alazic, -> #70, sgoran
>>Javi mi kako da ti dostavim QC.INI] Molio bih te da to ucinis preko Sezama (skoro svaki dan se javljam) ako hoces kao prikacenu datoteku uz poruku ili kao licnu postu. Rekao sam da mi je stvar veoma hitnaÚ▀Ú pa ti prepustam kako god zelis. Hvala u svakom slucaju.
cccc.73 sgoran, -> #72, alazic
Izvinjenje za kasnjenje, nisam bio u BGD-u. Ali bolje ikad nego nikad. Pozdrav ( prespori) SGoran. qc.ini
cccc.75 alexa, -> #74, maleksic
>> Kako da allociram blok memorije veci od 64k: >> 1) Na ANSI C-u ?? >> 2) Na prastarom C-u koji ide uz XENIX System V ?? 2) Nikako. Alociraj više manjih blokova. Blok od 64Kb ili manje možeć alocirati pomoću brkctl() funkcije. Problem je u virtuelnom režimu rada 286 procesora. 1) Teško da to ANSI može da odredi - to pre svega zavisi od operativnog sistema. Uostalom, da li uopšte postoji ANSI standard za C? Ja sam do sada video 'ANSI C' kompajlere koji se očigledno ne slažu oko sopstvenog jezika. Zanima me da li je ANSI konačno objavio STANDARD (a ne nacrt) i da li je povukao svoju molbu da proizvođači kompajlera prestanu da se hvale kako im proizvodi podržavaju ANSI C standard, jer isti ne postoji, a nacrt se menja?
cccc.76 dejanr, -> #75, alexa
>> > Kako da allociram blok memorije veci od 64k: >> > 2) Na prastarom C-u koji ide uz XENIX System V ?? >> 2) Nikako. Alociraj više manjih blokova. Blok od 64Kb ili manje >> možeć alocirati pomoću brkctl() funkcije. Problem je u >> virtuelnom režimu rada 286 procesora. Znači, i na Unixu 64K limit :( Eh, a kako lepo radi high c... :)
cccc.77 alexa, -> #76, dejanr
>> Znai, i na Unixu 64K limit :( >> Eh, a kako lepo radi high c... :) Na UNIXu naravno limita nema, ali na 286-ici nema pomoći. Ne znam šta bi tvoj high c mogao da uradi na 286 procesoru - pretpostavljam da radi samo na 386-ici, a XENIX/UNIX na 386-ici nema nikakvih problema - ima 'ravnu' memoriju!
cccc.78 dejanr, -> #77, alexa
Sorry, nisam video da je računar AT. Pozdrav, Dejan
cccc.79 maleksic, -> #75, alexa
>> Uostalom, da li uopste postoji ANSI standard za C? Nemam pojma, moguce da jos nije skrpljen do kraja (verovatno niko ne zeli da donese neki standard koga ce vreme pregaziti za godinu dana - seti se nesrecnog "FORTRAN-a 77"); Pod ANSI standardom za sada smatram ono sto pise u drugom izdanju "The C Programming Language" - Kernighan & Ritchie (1988.). Izmedju ostalog, tamo pise da se usvajanje ANSI standarda ocekuje u 1988. godini. U jednom nasem prevodu te knjige takodje pise da je standard vec odobren!?
cccc.80 dejanr,
========== borland/long.messages #29, from tweiss, 2272 chars, Fri Dec 7 18:32:35 1990 ---------- TITLE: Code to detect graphics display type /* TITLE: Code to determine graphics adapter type. The following code will detect and report on which of the following graphics display adapters are in the current system: MDA, HGC, CGA, EGA, VGA SuperVGAs will be detected as VGAs. */ #include <stdio.h> #include <dos.h> #define UBYTE unsigned char #define USHORT unsigned int #define FAR far /* Display Types */ UBYTE DisplayType; #define DISPLAY_MONO 0x10U #define DISPLAY_COLOR 0x20U #define DISPLAY_MDA 1U #define DISPLAY_HERC 2U #define DISPLAY_CGA 3U #define DISPLAY_EGA 4U #define DISPLAY_VGA 5U USHORT FAR *ScreenPtr; #define MONO_ADDR 0xB0000000 #define COLOR_ADDR 0xB8000000 void cdecl main() { unsigned int i, holdstat; char *ptr1, *ptr2; /* Get address of screen memory */ if (peek(0x40,0x63) == 0x3B4) { ScreenPtr = (USHORT FAR *)MONO_ADDR; DisplayType = DISPLAY_MONO; } else { ScreenPtr = (USHORT FAR *)COLOR_ADDR; DisplayType = DISPLAY_COLOR; } /* Get Current Display Type: */ _BX = 0xFF10; _AX = 0x1210; geninterrupt(0x10); if (_BX != 0xFF10) /* Bios installed */ { _AX = 0x1A00; _BX =0xFFFF; geninterrupt(0x10); if (_BX != 0xFFFF) DisplayType |= DISPLAY_VGA; else DisplayType |= DISPLAY_EGA; } else if (DisplayType & DISPLAY_MONO) { holdstat = inp(0x3BA); for (i = 0; i <= 10000; i++) { if ((inp(0x3BA) & 0x80) != (holdstat & 0x80)) { DisplayType |= DISPLAY_HERC; break; } } if (!(DisplayType & DISPLAY_HERC)) DisplayType |= DISPLAY_MDA; } else DisplayType |= DISPLAY_CGA; switch(DisplayType & 0xF0) { case DISPLAY_MONO: ptr1 = "Monochrome"; break; default: ptr1 = "Color"; break; } switch(DisplayType & 0x0F) { case DISPLAY_MDA: ptr2 = "MDA (Monochrome Display Adapter)"; break; case DISPLAY_HERC: ptr2 = "HGC (Hercules Graphics Card)"; break; case DISPLAY_CGA: ptr2 = "CGA (Color Graphics Adapter)"; break; case DISPLAY_EGA: ptr2 = "EGA (Enhanced Graphics Adapter)"; break; case DISPLAY_VGA: ptr2 = "VGA (Video Graphics Array)"; break; } printf("Your adapter is set up as a %s %s\n", ptr1, ptr2); }
cccc.81 vkostic,
TC 2.0 versus MSC 6.0 --------------------- (TC glatko pobedio!!) Nameravam da napravim vrlo opsiram benchmark raznih C kompajlera - TC 2.0, TC++, MSC 5.0 i MSC 6.0. U igri su brzina kompajliranja, duzina programa i brzina izvrsavanja. Za probni program izabrao sam Z80DIS. To je inteligentni Z80 disasembler koji sam letos napisao. Program je idealan za test kompajlera, narocito za moc optimizacije. Program prvo ucita ulazni fajl (20K), zatim se samo petlja sa integer matematikom (nema nigde FP brojeva), pointerima, stringovima, nizovima i baferima. Na kraju proizvede izlazni fajl od 730K. Snimanje izlaznog fajla na disk traje relativno vrlo kratko u odnosu na to koliko vremena treba programu da izvrsi disasembliranje. Inace, Z80DIS je vrlo inteligentni disasembler koji je u stanju da sam razdvoji program od podataka, obelezi svaki pocetak potprograma, sve skokove, generise cross reference tabele, itd. Za pocetak ovo je kratak test TC 2.0 versus MSC 6.0. Evo rezultata (vrlo su zanimljivi): ┌─────────────────────────┬─────────┬───────┬────────┬─────────────────────┐ │ Compiler and │ │ │ Exec │ │ │ command line │ Compile │ Size │ time │ Rezultat rada │ Ă═════════════════════════ě═════════ě═══════ě════════ě═════════════════════Á │ TCC -G -O -Z -a -r │ │ │ │ │ │ max opt. for speed │ OK │ 45606 │ 7'30'' │ OK │ ├─────────────────────────┼─────────┼───────┼────────┼─────────────────────┤ │ CL /qc │ │ │ │ │ │ quick compile, no opt. │ OK │ 46121 │ --- │ Program blokirao │ ├─────────────────────────┼─────────┼───────┼────────┼─────────────────────┤ │ NO FLAGS │ │ │ │ │ │ default │ OK │ 41931 │ 7'50'' │ OK │ ├─────────────────────────┼─────────┼───────┼────────┼─────────────────────┤ │ CL /Ot /Gs │ │ │ │ │ │ optimize for time, │ │ │ │ │ │ remove stack probes │ OK │ 41883 │ 7'51'' │ OK │ ├─────────────────────────┼─────────┼───────┼────────┼─────────────────────┤ │ CL /Ox /Oa /Oz /Gr /Gs │ │ │ │ │ │ max_opt, fastcall con- │ │ │ │ │ │ vention, remove stack │ │ │ │ Kompajler nece │ │ probes │ ERROR │ --- │ --- │ da prevede program │ ├─────────────────────────┼─────────┼───────┼────────┼─────────────────────┤ │ CL /Ox /Oa /Oz /Gs │ │ │ │ │ │ max_opt,remove stack │ │ │ │ Jedna mala greska u │ │ probes) │ OK │ 42587 │ 7'13'' │ izlaznom fajlu │ └─────────────────────────┴─────────┴───────┴────────┴─────────────────────┘ Brzinu kompilacije nisam merio, izmericu je kada budem testirao i TC++. U svakom slucaju, po tom pitanju TC je sampion u odnosu na MSC. Sa TC 2.0 nije bilo nikakvih problema - sve je glatko radilo. Sa MSC 6.0 je bilo puno problema. Prvo, jedan pokusaj kompilacije nije uspeo. Drugo, /qc opcija je proizvela program koji je blokirao. Trece, maximalna optimizacija je prizvela neispravan izlazni fajl - bila je jedna greska. Dosta sitna greska, ali ipak greska. Sve u svemu, TC je po meni glatko pobedio: - Prevodi MNOGO MNOGO brze. - Program radi brze (rezultat 7'13'' koji je postigao MSC ne priznajem zbog greske u izlaznom fajlu). - Ne pravi nikakve brljotine za razliku od MSC-a koji je od 5 pokusaja uspeo da radi ispravno samo 2 puta. Jedino gde je MSC pobedio je duzina programa, i to ne za mnogo - 9%. Nastavak testa sa TC++ sledi cim nadjem vremena. V.K.
cccc.82 alexa, -> #81, vkostic
Sledeći put obrati pažnju na to šta znače opcije koje si zadao (tj. pročitaj priručnik) : /Oa teško da si smeo da zadaš ...; za neke druge ne znam šta znače.
cccc.83 vkrstonosic, -> #82, alexa
Vlado, da li se meni cini ili si ti testirao program koji je bio razvijan u Turbo C-u. Mi smo pravili neke testove i rezultati su bili sasvim drugaciji.
cccc.84 vkostic, -> #82, alexa
>> Sledeći put obrati pažnju na to šta znače opcije koje si zadao >> (tj. pročitaj priručnik) Procitao sam prirucnik par puta i to jos odavno. (doduse, za verziju 5.1). >> /Oa teško da si smeo da zadaš ... Nisam bas siguran da nisam smeo. Usput, program je kompilovao ddincic i nije mi bas jasno zasto je to stavljao. Ja licno izbegavam /Oa. Nameravam da izvrsim jos par testova, pa cu tacno ustanoviti dali je /Oa pravilo problema.
cccc.85 vkostic, -> #83, vkrstonosic
>> Vlado, da li se meni cini ili si ti testirao program koji >> je bio razvijan u Turbo C-u. Program jeste bio razvijan u Turbo C-u, ali to nije nikakav presudan elemenat - u programu nema *nikakvih* prljavih trikova koji bi bolje radili sa TC nego sa MSC. >> Mi smo pravili neke testove i rezultati su bili sasvim drugaciji. Sve zavisi sta program radi. Vec sam opisao sta Z80DIS radi. Za tu konkretnu aplikaciju se MSC nije bas proslavio u odnosu na TC. Mozda je MSC mnogo bolji ako se radi sa FP brojevima, na primer. Z80DIS nema nigde FP brojeve. Jednostavno, imao sam program koji je odavno gotov, testiran i radi. Interesovalo me da vidim koji ce kompajler za taj konkretan slucaj dati najbolje rezultate. Probacu jos TC++. Sve mi govori da ce na primeru Z80DIS programa TC++ dati najbolje rezultate od svih kompajlera. Inace, ja i ddincic upravo sprovodimo jos jedan benchmark, pa cemo da vidimo kako ce na tom novom primeru MSC i TC proci.
cccc.86 cuba,
Svojevremeno je neko pisao o nedovrsenosti ANSI standarda za C. E standard vise nije draft vec je usvojen, te ce biti tokom meseca na raspolaganju za sve zainteresovane. ISO standard sledi, kazu da ce izaci pocetkom godine. Izvor informacije je "The C Users Journal" januarski broj. Za zainteresovane mogu raci da ANSI C standard (X3.159-1989)? kosta USD 50. Ako ima zainteresovanih adresa je : ANSI Sales Dept. 1430 Broadway New York NY 10018 PS postatarina nije ukljucena ;> Pozdrav, Miroslav
cccc.87 vkostic,
Microsoft vs Borland - Part II ------------------------------ Znam da cu ponovo da izazovem gnev ljubitelja MSC-a! Ovo su novi benchmark rezultati. TC 2.0, TC++ i MSC 6.0 su bili na testu. Ovog puta sam merio i brzinu prevodjenja. Test program je i dalje Z80DIS. ┌────┬─────────────────────────┬─────────┬───────┬────────┬──────────────────┐ │ │ Compiler and │ Compile │ │ Exec │ │ │ No │ command line │ time │ Size │ time │ Rezultat rada │ Ă════ě═════════════════════════ě═════════ě═══════ě════════ě══════════════════Á │ │ TCC 2.0 │ │ │ │ │ │ 1 │ default │ 25'' │ 45622 │ 7'47'' │ OK │ ├────┼─────────────────────────┼─────────┼───────┼────────┼──────────────────┤ │ │ TCC 2.0 -G -O -Z -a │ │ │ │ │ │ 2 │ max opt. for speed │ 25'' │ 45606 │ 7'39'' │ OK │ ├────┼─────────────────────────┼─────────┼───────┼────────┼──────────────────┤ │ │ TCC ++ │ │ │ │ │ │ 3 │ default │ 30'' │ 44312 │ 7'23'' │ OK │ ├────┼─────────────────────────┼─────────┼───────┼────────┼──────────────────┤ │ │ TCC ++ -G -O -Z -a │ │ │ │ │ │ 4 │ max opt. for speed │ 31'' │ 44248 │ 7'30'' │ OK │ ├────┼─────────────────────────┼─────────┼───────┼────────┼──────────────────┤ │ │ CL 6.0 │ │ │ │ │ │ 5 │ default │ 2'53'' │ 41931 │ 7'51'' │ OK │ ├────┼─────────────────────────┼─────────┼───────┼────────┼──────────────────┤ │ │ CL 6.0 /qc │ │ │ │ ERROR: │ │ 6 │ quick compile │ 34'' │ 46121 │ -- │ program blokirao │ ├────┼─────────────────────────┼─────────┼───────┼────────┼──────────────────┤ │ │ CL 6.0 /Ox │ │ │ │ ERROR: greska u │ │ 7 │ max optimization │ 3'33'' │ 42555 │ 7'13'' │ izlaznom fajlu │ └────┴─────────────────────────┴─────────┴───────┴────────┴──────────────────┘ Testovi pokazuju par cudnih stvari: - U proslom benchmark testu program kompilovan sa TC uz max optimizaciju je radio 7'30'' a sada 7'39''. Odakle ova razlika nemam pojma. Mozda sam negde pogresio u menenju, mozda sam se igrao sa nekim parametrima - nemam pojma, a sada ni vremena da to proveravam. - Novi TC++ je pokazao da malo sporije prevodi od TC 2.0 ali da program radi malo brze. - Program preveden sa TC++ sa default parametrima je za divno cudo radio brze nego sa optimizacijom. To sam u cudu dva puta proveravao i zaista je tako. - MSC je jos jednom dokazao kako Microsoft to voli sporo - sporo prevodi da ne moze sporije. Ipak, svetla tacka je opcija /QC. Na zalost, Z80DIS preveden sa tom opcijom se blokirao. Ddincic me uporno ubedjuje da on redovno koristi tu opciju i da nikada nije imao problema. Poslao sam mu source za Z80DIS pa neka proveri. - MSC je uspeo da napravi kraci program od TC, a sa opcijom /Ox i vrlo brz. Na zalost, rezulta rada programa je bio neispravan. Postoji doduse parametar da se iskljuci "unsafe" optimizacija, ali nisam stigao da se igram sa time. - MSC je po svemu pokazao da je vrlo lep kompajler ali spor i dosta nesiguran. Do sada je moj omiljeni kompajler bio TC 2.0. Po mom iskustvu radi se o vrlo brzom i sigurnom kompajleru. Imao sam zaista vrlo vrlo malo problema sa njim. TC++ jos nisam koristio - trenutno ne radim nikakav projekat na C-u. Rezultati benchmark testova pokazuju da vredi preci sa TC 2.0 na TC++ ne zbog objektnog programiranja nego zbog malo vece brzine. Pitanje pouzdanosti TC++ kompajlera za mene ostaje jos uvek otvoreno. Moci cu da se izjasnim tek posle intenzivne upotrebe. MSC ne nameravam da koristim (mada ga imam instaliranog na disku) iz razloga sto je neprihvatljivo spor i nepouzdan po mom misljenju. Istina, moze se koristiti opcija /QC radi brzine kompajliranje dok se program razvija, ali pitaj boga dali ce program 100% ispravno raditi u *svim* granama kada se posle kompiluje sa /Ox. ZZ je sada preuzeo stafetu. Rezultati njegovih testova (takodje sa Z80DIS) ce biti vrlo interesantni. On ipak ima vise iskustva sa MSC od mene. V.K.
cccc.88 ljupco,
Juce mi je TC prijavio Initiall error Please report to Borland a zatim me izbacio u DOS. Na ekranu je bilo jos exit error = 3, winerror = 0 Nemam nekog iskustva sa TC-om, ali me ipak interesuje u cemu je stvar. Pogledao sam uputstvo, Appendix B, Compiler Error Messages, Fatal Errors i nisam nista nasao. Nije previse vazno, ali ako neko zna...
cccc.89 gww., -> #88, ljupco
Pretpostavljam da je u pitanju "Internal error" a ne "Initiall error". Ali nema veze. U svakom slučaju to ili je problem da je TC "ukršen", ili imas neku specijalnu kombinaciju hardvera koje TC nije mogao da shvati ili, što ume da se dešava, zbog pada ili skoka napona ti se izbombarduje memorija ili si stvarno našao rupu. Nije jasno koji je TC u pitanju, ali ako je u pitanju TC++ pogledaj kako ti je setovana EMS memorija (ako je imas). Uzgred to nije normalna greška pa je ni nema u spisku.
cccc.90 ivujanic,
Molba za bilo kojeg kolegu koji ima uputstvo za Turbo C i sat vremena. Potreban mi je opis načina doturanja parametara u funkcije. Dakle sve što je potrebno da se funkcija u asembleru "zakači" za TC. Unapred hvala strpljivom! Ivica
cccc.91 zzivotic, -> #90, ivujanic
>> Potreban mi je opis načina doturanja parametara u funkcije. Dakle >> sve što je potrebno da se funkcija u asembleru "zakači" za TC. Nije baš potrebno sat vremena :) Naime, prenos parametara kod TC-a je verovatno potpuno isti kao i kod MSC-a. Koristi se sledeći metod. Kada napišeš sledeći poziv: funkcija(a,b,c,d..) onda se to prevodi kao: push d push c push b push a call funkcija sub sp,4 a unutar funkcije se dešava sledeće: funkcija proc near push bp mov bp,sp mov ax,[bp+4] ; a mov ax,[bp+6] ; b itd. Offset +4 važi kod memorijskih modela sa near pozivima, povećava se za 2 kod far poziva jer su na steku 4 bajta povratne adrese. Dve stvari su kakteristične: - Parametri se na stek 'guraju' s desna u levo - ovim se omogućava prenos promenjivog broja parametara - Čišćenje steka *ne radi* funkcija već pozivni program (vidi ono call funkcija) iz istog razloga jer kod promenjivog broja parametara funkcija zapravo ne zna koliko toga ima na steku. Dakle, ako piše svoju funkciju na asembleru i treba iz C-a da preneseš parametre u nju, onda to izgleda ovako: ; int funkcija( int a, int b..) funkcija proc near push bp mov bp,sp push si ; ovo pos uslovom da koristiš register dekl. ili opt. push di ; u funkciji koja pozivu ovu mov ax,[bp+4] ; a .... itd, pa na kraju pop di pop si pop bp mov ax,ret_value funkcija endp Ovo je samo osnova, postoji mnogo detalja koji bojim se da ne mogu stati u poruku čak ni za sat. Moraš znati šta se dešava sa segmentnim registrima (obično je DS konstantan i pokazuje na default data seg, dok ES možeš slobodno da menjaš), kako se prenose ostale vrednosti i kako se vraćaju iz funkcije i koje registre smeš da menjaš (uglavnom ne smeju na izlazu da promene vrednost DS i BP). Ako imaš neko konkretno pitanje od ovih... Pozdrav, zz P.S. Pade mi na pamet - verujem da je i TC kao i MSC u stanju da generiše ASM program iz C programa (pogledaj opcije TCC-a). Sa malo proba brzo ćeš shvatiti kako ceo mehanizam funkcioniše.
cccc.92 ivujanic, -> #91, zzivotic
Zorane, svaka čast za brz odgovor. Puno ti hvala. A što se opcija TCC-a tiče, da imam uputstva ne bih tebe gnjavio.. :( Ali biće i to uskoro... Nego, ima li neko da predlozi nekog domaćeg distributera za C++. Znate i sami kako je sa inostranstvom kad nemaš kartice, a i ko ih ima, uglavnom ima American Express, a to je k'o i da ih nema. Dakle, trazi se distributer za C++. Ivica P.S. još jednom hvala zzivoticu.
cccc.93 zzivotic, -> #92, ivujanic
>> A što se opcija TCC-a tiče, da imam uputstva ne bih tebe gnjavio.. :( Zar TCC nema nešto poput TCC /help? Koliko se sećam jedna od prvih verzija je to imala i dobiješ spisak opcija sa sasvim pristojim objašnjenjen - negde treba da stoji i Generate Assembly Listing ili nešto poput toga. Prevedeš program sa tom opcijom i na disku se nađe čist .asm fajl. Pozdrav, zz
cccc.94 dsavic, -> #92, ivujanic
Firma Marand iz Ljubljane je generalni zastupnik Borlanda za Jugoslaviju. Oni prodaju Turbo C++, naravno, i Turbo Pascal 6.0 i sve ostalo. Inače, TP 6.0 (bez Professional verzije) košta 2.880 dinara - platiš na njihov račun i dobiješ za manje od sedam dana. Ovo je provereno - valjda bi isto bilo i sa Turbo C++. Za svaki slučaj, treba ih pozvati i pitati šta imaju na lageru. Pozdrav, Duško Savić.
cccc.95 ivujanic, -> #94, dsavic
Hvala Dušku Saviću. Za Marand sam čuo i sa njima razgovarao, ali sam ipak hteo da čujem neka praktična iskustva. Ivica
cccc.96 ljupco, -> #89, gww.
Mozda je i bio "Internal error", ne mogu biti 100% siguran jer se je ekran odmah obrisao. Medjutim ono exit error = 3 winerror = 1 je sigurno. Radi se o TC2.0, EMS memorija nije bila setovana (384K extended memorije bila su pretvorena u RAM disk pomocu vdisk.sys), a u memoriji su jos bili Ced, Backscrl i Norton Guide.
cccc.97 gww., -> #91, zzivotic
" - Parametri se na stek 'guraju' s desna u levo - ovim se omogućava " prenos promenjivog broja parametara Ne, ovim se jednostavno lakše tretiraju parametri jer se jednostavnim pop-ovanjem čitaju parametri redom (tj. s leva na desno). Zapravo, ova osobina je mnogo bitnija za portabilnost C-a. Razmislite o sledećem programu (ili još bolje prvo ga kompajlirajte i izvršite pa tek onda razmislite): #include <stdio.h> int i; main() š i=6; while (i<=15) š printf("%2d- %2d %2d %2d %2d %2dĐn",i,i--,i--,i--,i--,i--); i=i+6; ć return(0); ć Uz komentar da je ovaj program napisala moja devojka tokom jednog našeg razgovora o programiranju i dobro me bacila u razmišljanje o portabilnosti i čudnim putevima ljudskog razmišljanja. Alexa mi je potom rekao da se isti princip (push s desna u levo) upotrebljava i kod XENIXA te izgleda da je takav način generalan. Uzgred, koliko se sećam, i Turbo pascal koristi isti princip, s razlikom pascal konvencije, da pozvana funkcija čisti stek.
cccc.98 alexa, -> #97, gww.
Ipak je važniji razlog taj što se može raditi sa promenljivim brojem parametara (kao što reče zz).
cccc.99 rlazic,
Od pre par dana sam na Sezamu, pa se (tek) sada uključujem u razgovor. Pročitavši prethodne poruke, zaključio sam da se niko ne bavi C++-om (usput, ovo "-om" mi glupo deluje, pa jel' ima neko predlog?). Jedino u vezi s tim je bilo Vladino testiranje Turbo C++-a nekim programom u C-u, napisavši da će ga bolje pogledati kad bude imao vremena. Pošto imam dosta iskustva u radu sa pomenutim kompajlerom (ceo školski raspust sam proveo s njim), odlučio sam da vam prenesem neka zapažanja. Da krenem redom: Editor ima (za sada) jedan odvratan bag. Naime, kada "legnem" na neki kursorski taster, često se dešava da mi editor ubaci po neku dvojku, osmicu ili nešto slično (odgovarajući brojevi na numeričkoj tastaturi) u program, što je VRLO neprijatno. Zaista ne znam šta je u pitanju, jer mi se ni u jednom drugom programu ne dešava ništa slično. Moguće je da se Borland ponovo "hakerisao", ali je isto tako moguće da je ncc/fastkey nešto ubrljao. Svoje utiske o radnoj okolini (IDE:) sam već izneo u Svetu kompjutera, pa ne bih sada o tome. Par stvari koje valjaju je poboljšani search/replace sistem i (konačno!) ljudsko obeležavanje bloka pomoću Shift+strelice, a ne nekim tamo CtrlKB i CtrlKK. Takođe, lepa je stvar mogućnost biranja između prethodnih unosa u search/replace i ostalim dialog box-ovima. Dalje, Turbo C++-ova (opet ovo ++-) mogućnost korišćenja EMS memorije me je prilično obradovala, pa sam se zaleteo i dogurao do 70kB source fajla, na šta je kompajler pri kraju kompajliranja (pre linkovanja) odgovorio porukom Fatal error: Out of memory. To me je zaista razočaralo - izgleda da Turbo C++ koristi EMS memoriju samo za svoje swap-ovanje iz osnovnog RAM-a i time oslobodi još najviše stotinjak kilobajta, a da kompajliranje i dalje vrši u osnovnoj memoriji. Dakle, EMS vam služi samo kao brzi hard disk, jer se inače (ako nema EMS-a) Turbo C++ swap-uje na njega. Pitam se ja onda: koja je korist od 2MB EMS memorije i zašto Get Info prijavljuje 2MB EMS in use. Jedan od ozbiljnih bagova je pogrešno funkcionisanje ifstream::open funkcije (otvaranje fajla). Naime, navođenje argumenta ios::nocreate bi (prema uputstvu i help-u) trebalo da kaže funkciji da prijavi grešku ukoliko fajl ne postoji (da ga ne kreira), a da poziv uspe ako fajl postoji. Međutim, to UOPŠTE ne radi. Prilikom dibagiranja programa ugrađenim dibagerom, stvar je KRITIČNA. Nebrojeno puta mi se dešavalo da se kompajler jednostavno zablokira (ne moj program, već kompajler), ili da "u sred" rad izbaci gomilu đubreta na ekran i tek se onda zablokira (zanimljivo, a? B() - to je valjda radi vizuelnog efekta - da mi ne bude dosadno tokom rada. Pri dinamičkoj alokaciji memorije (na tome se bazirao moj program - simulator paralelnog procesiranja), Turbo C++ se (za divno čudo) dobro pokazao - to je bilo "osetljivo" mesto Turbo C-a 2.00. Moram da priznam da sam se dobro namučio sa run-time greškom Null pointer assignment, koja se javlja na kraju izvršavanja programa. U uputstvu piše: "When a program exits, a chek is made to determine if the contents of the first few bytes of whitin the program's data segment have changed. These bytes would never be altered by a working program. If they have been changed, the message "..." is displayed to inform you that (most likely) a value was stored to an uninitialized pointer. ..." To je O.K. (vrednost neinizijalizovanog pointera je NULL=0) i to je prvi put i bilo po sredi (lako sam ga naš'o). Međutim, kada mi se ova (!#$&%) poruka drugi put pojavila, bio sam siguran da program radi perfektno, pa sam se začudio. Pošto mi nikako nije uspevalo da utvrdim gde mi se "first few" lokacija data segmenta ubrlja, ubacio sam u glavnu petlju stalno testiranje prvih stotinjak lokacija, ali se NIŠTA nije dešavalo. Na kraju sam lepo uzeo Turbo Debugger 1.00 i iš'o kroz program sve dok nisam stigao do poziva exit(0) funkcije (svo vreme je sve bilo O.K) i ustanovio da je ona ta koja ubrlja data segment i posle sama prijavi grešku (da su mi sad pri ruci programeri Turbo C++-a ...). Uglavnom, stvar sam sredio pozivanjem funkcije _exit(0), koja ništa ne dira (po uputstvu), nego lepo odmah izađe u DOS. (Možda je sve ovo u vezi sa dinamičkom alokacijom memorije, nisam podrobnije pogledao.) Što se brzine kompajliranja tiče, osetno je manja u odnosu na Turbo C 2.00 (po odokativnoj proceni oko 50%). Ovo nemojte previše čvrsto da shvatite, jer nisam ništa merio - samo mi se čini. Naravno, to je i dalje daleeekooo u odnosu na MSC 6.00 :))). Na kraju, zaključio sam sledeće: Pošto se većina prosečnih korisnika razmišlja da li da pređe na Turbo C++ i nastavi programiranje u C-u, mislim da se to ne isplati - kompajler je sporiji, radna okolina ne nudi ništa revolucionarno (kako se stalno naglašava), biblioteka C funkcija nije značajnije proširena, mnoštvo bagova je prisutno, ... Što se tiče C++ programiranja, Turbo C++ predstavlja praktično jedini izbor (ostaje još Zortech C++, koji nisam imao prilike da vidim, ali smatram da nije ništa posebno). Radna okolina je (kao i kod svih Borlandovih programa) relativno konforna, biblioteka C++ funkcija je više nego bogata (posebno bih izdvojio I/O operacije). Ipak, nabrojani bagovi (verovatno njihov maaaliii deo) zaista kvare utisak i prikazuju Turbo C++ kao prilično nepouzdan kompajler, ali se sa svim tim ipak nekako (kad se već mora) može izaći na kraj. Još da kažem (tj. napišem) da se nisam previše "hakerisao", kao ni u Turbo C-u 2.00, (izuzimajući nekoliko rezidentnih programčića), pa ne mogu ništa da zaključim o pouzdanosti kompajlera prilikom DOS/BIOS poziva (brljanje registara i sl.). Takođe, na ovom mestu bih da poručim Vladi Kostiću da nije u pravu (po mom pišljenju, naravno) kad kaže (u nekoj od ranijih poruka, ne sećam se tačno broja) da ništa ozbiljnije *ne može* da se radi bez DOS/BIOS poziva. Verovatno se nas dvojica bavimo pisanjem različitih tipova programa, ali ipak nije u redu iznositi takve tvrdnje. Vlado, nemoj ovo pogrešno da shvatiš, ali meni pri pisanju već pomenutog programa (simulator paralelnog procesiranja i interpreter jednog paralelnog jezika), kog ja smatram za ozbiljniji (ako ti nešto znači, source ima oko 75kB i oko 2500 linija), ni jednom nije zatrebalo da direktno pozovem DOS ili BIOS, izuzimajući izključivanje kursora (to je zaista smešno i trivijalno). Tačno je da je tako nešto neophodno pri pisanju drajvera za tastature, možda Z80 disasemblera i sličnih stvari. U stvari, hoću da kažem da nije u redu da smatraš "ozbiljnim" programima samo taj tip programa koji ti pišeš. Programerski pozdrav, Ranko Lazić
cccc.101 alexa, -> #99, rlazic
Nisam radio sa Borlandovim C++-om, ali mi je neverovatno da sama bibliotečka funkcija exit() tek tako izbrlja po memoriji. Pretpostavljam da se u C++-u u toku završavanja rada (tj. u exit()-u) pozivaju destruktori za promenljive definisane izvan procedura. Verovatno si pogrešio u nekom destruktoru, ili si pogrešno shvatio u kom redosledu se pozivaju destruktori.
cccc.102 gww., -> #98, alexa
Ne, ponvaljam metod smeštanja parametara na stek nije bitan za prenos promenljivog broja parametara. Važna je druga osobina da program koji poziva funkciju čisti stek (tako pozivana funkcija zapravo i nezna koliko joj je parametara poslato, što će svaki C potvrditi ako nema prototipa funkcije). Jedini preduslov je da pozvana funkcija ne menja stek pointer. Metod smeštanja (s desna na levo samo omogućuje lakši rad, tj čitanje redom) U principu kod svakog procesora moguće je stek pointer prebaciti u neki indeksni registar. Ovo je karakteristično za PC kompajlere a onda praktično parametrima pristupa indeksno. Zato i nema veze metod smeštanja. Ovakav metod (s desna na levo) je lakši jer je prvi parametar na vrhu steka a drugim metodom (s leva na desno) bi se morala predati informacija o adresi prvog parametra (u nekom od indeksnih registara). No, kao što sam u primeru naveo to (s desna na levo) može doći u konflikt sa ljudskim razmišljanjem (pogotovo zapadnjaka, koji čitaju s leva u desno). P.S. Zamalo da si me "ubedio" Alexa :))