PCPROG.5

05 Jan 1995 - 02 Oct 1995

Topics

  1. algoritmi (106)
  2. comment (2)
  3. ms.dos (27)
  4. windows (332)
  5. asembler (203)
  6. basic (228)
  7. jezici (126)
  8. pascal (1085)
  9. cccc (546)
  10. cpp (117)
  11. clipper (1048)
  12. baze.podataka (194)
  13. fox (231)
  14. cavo (192)
  15. razno (593)

Messages - cccc

cccc.414 omega,
Da li neko ima ideju kako naterati Borland IDE da kada se "Use TAB character" i lupi Enter na kraju reda, kursor pozicionira u sledeci pomocu TAB-ova, a ne spejsova? O tome se inace brine "Autoindent mode", ali slabo. (iz help-a:) For example, +----- press Enter here č to put the cursor int main(void) <---+ under the i in int { float g; <------------ press Enter here to put the cursor under the f in float Znaci da kad se lupi Enter u redu "float g;", kursor predje u sledeci red i sa par TAB karaktera se pozicionira ispod 'f', a ne sa par spejsova. P.S. Da li sa BC++ v3.1 uopste mogu da se razvijaju protected mode aplikacije?
cccc.415 deimos,
Evo jednog mesovitog pitanja :) Kako proslediti iz C-a string funkciji napisanoj u asembleru. Konkretno, evo jedne f-je u C-u. int extern fileopen(char *filename); E, sad je pitanje kako da prosledim ime fajla f-ji pisanoj u asembleru. _fileopen PROC C ?????? HELP ! Vlada. ps. BOrland C & Tasm.  ű
cccc.416 mitar,
Jel ima ovde neko ko zna nesto o PRO C-u? Interesuje me sve, cak i to da li ima i gde da se kupi, kompletno ili samo literatura. Da nema mozda neka masonska loza u vezi sa istim? :)))
cccc.417 nikac, -> #415, deimos
>■ int extern fileopen(char *filename); >■ >■ E, sad je pitanje kako da prosledim ime fajla f-ji pisanoj u >■ asembleru. >■ >■ _fileopen PROC C ?????? Kao prvo ti prosledjujes pointer na string, a ne ceo string, znaci 4 byte-a, so: ; ; Caller BC, Large model, Far call ; int fileopen(char *filename) ; ; pointer se pamti kao longint, a prva dva bajta su SEG, a druga dva OFS SEGPTR EQU WORD PTR [BP+6] OFSPTR EQU WORD PTR [BP+8] fileopen_TEXT SEGEMENT byte public 'CODE' ASSUME cs:fileopen_TEXT PUBLIC _fileopen ; donju crtu dodaje C ; pri prevodjenju _fileopen PROC far push bp mov bp, sp ;da se sacuva stek ... mov ax, <result code> ; to sigurno znas mov sp, bp pop bp ret _fileopen ENDP fileopen_TEXT ENDS END Mozda je moglo i bolje, ali i ovako radi. Dakle imas u SEGPTR i OFSPTR segment i ofset tvog stringa, pa dalje valjda mozes i sam (naravno da ako menjas BP segptr i ofsptr ce izgubiti svoju vrednost, pa vodi o tome racuna). Inace cuvas sp, ako imas u okviru tvoje procedure poziv neke druge procedure koja menja sp, inace ti je to suvisak. BTW oduvek me je zanimalo kako se kodira vracanje slozene strukture, ili recimo float vrednosti, a mrzi me da kopam po kodu sa dibagerom, pa ako nekog ne mrzi da napise, ne bilo mu zapovedjeno :)
cccc.418 knight,
Kako da sa zadatom vremenskom periodom pozivam neku funkciju u mom Windows programu? Potrebno mi je, npr. da na svaka 2 minuta pozivam funkciju UradiPosao(). Pored objašnjenja dobrodošla bi mi neka linija koda. Koristim BC++ 4.0.
cccc.419 postmast,
From: Aleksandar.Glumac@f119.n111.z38.setnet.setnet.co.yu (Aleksandar Glumac) Subject: ACK & BUSY Date: Sun, 16 Jul 1995 19:13:01 Hi, prethodna poruka o strlen(); je greskom stigla do tebe, sorry :) >> Pravim neko programce u C-u za printere, pa mi bas nesto nije jasno >> postojanje dva signala: BUSY i ACK. >> ako je ACK=0 printer je spreman za prijem novog karaktera, dok za >> BUSY=0 printer ne moze trenutno da primi vise podataka(Prog. Tech. >> DOS Ref. 3.1), dok u uputstvu za STAR LC10 pise da je >> BUSY=0 kada je printer spreman da primi podatke. Kako >> sad pa ovo?????? >> Zar ne bi bio dovoljan samo jedan od ovih signala(busy ili ack) da se >> sazna da li je printer spreman ili nije?? Ovako: Sa ACK se potvrdjuje da li je podatak primljen (da nema neka greske i sl.) ,a sa BUSY se kaze da li je bafer pun tj. da nemoze vise da prima podatke i trebalo bi da je onda setovan (1). Sada mene zanima kako si uspeo da citas stanja pojedinih izvoda (pinova) ? >> dragan ĐŠč█ Pozdrav Ace B) █čŠĐ--- * Origin: ECSTASY BBS * Indjija * 022 53-884 * SETNet: (38:111/119)
cccc.420 postmast,
From: Ivan.Jocic@p5.f101.n101.z38.setnet.setnet.co.yu (Ivan Jocic) Subject: ACK & BUSY Date: Mon, 17 Jul 1995 07:56:55 AG> Neznam kako se vise moze optimizovati strlen(); , jer kada sam ja AG> pravio neki programcic ,da ne bi koristio biblioteku string, strlen AG> napravio kao : AG> for(c=0;string[c]!='\0';c+=1){} AG> Ja tu nevidim neku mogucu optimizaciju (prosvetli me ako gresim :)). Pa mozes jednu bolju optimizaciju da uradis: c=0; while(!string[c]) c++; I mozes jos boju (ali ne i najbolju): int novi_strlen(char *string){ int c; _asm{ cld les di, string xor al,al mov cx,0xffff repne scasb je nadjen :nije_nadjen jmp end :nadjen not cx dec cx mov c,cx } :end return c; } A postoji i jos bolja caka, ali je ona malo teza za implementiranje, tako da ti je ova mnoooooooooooogo brza od one tvoje. Shadow ... ///\oo/\\\ There are no more bugs. ///\oo/\\\ ///\oo/\\\ * Origin: * SETNet * Sirius BBS * 018/711-667 * Nis * (38:101/101.5)
cccc.421 postmast,
From: Dejan.Jovanovic@p5.f101.n101.z38.setnet.setnet.co.yu (Dejan Jovanovic) Subject: ACK & BUSY Date: Wed, 19 Jul 1995 00:13:31 AG> for(c=0;string[c]!='\0';c+=1){} AG> Ja tu nevidim neku mogucu optimizaciju (prosvetli me ako gresim :)). Nema tu vise neke vece optimizacije. Vreme je da iskoristis integrisani assembler (ako neznas uci obavezno) . Procitaj pomalo sta rade oni momci sa super brzim rutinama za stringove tu negde po programskim konferencijama. Aj' kad njih videh ja resih da se ubacim malo. Ovo je moj predlog (mislim da nema brzeg, ako se varam ispravite me): int mystrlen(char *str) { asm { mov cx,0xffff xor ax,ax les di,str inc di mov si,di repnz scasb sub di,si mov ax,di } } ovo za 10000 provera radi recimo 33s tvoje resenje 94s a zvanicni strlen 38s. Jesam pametan a??? DJSlo ... tagline snow * Origin: * SETNet * Sirius BBS * 018/711-667 * Nis * (38:101/101.5)
cccc.422 postmast,
From: Aleksandar.Glumac@f119.n111.z38.setnet.setnet.co.yu (Aleksandar Glumac) Subject: ACK & BUSY Date: Sun, 16 Jul 1995 12:38:02 Neznam kako se vise moze optimizovati strlen(); , jer kada sam ja pravio neki programcic ,da ne bi koristio biblioteku string, strlen napravio kao : for(c=0;string[c]!='\0';c+=1){} Ja tu nevidim neku mogucu optimizaciju (prosvetli me ako gresim :)). ĐŠč█ Pozdrav Ace B) █čŠĐ--- * Origin: ECSTASY BBS * Indjija * 022 53-884 * SETNet: (38:111/119)
cccc.423 postmast,
From: Aleksandar.Glumac@f119.n111.z38.setnet.setnet.co.yu (Aleksandar Glumac) Subject: TSR Date: Sun, 16 Jul 1995 19:12:00 Hi, na prvi pogled lici da nemas main() funkciju. Izgleda da nisi dobio sve sorseve :( Ako pak nesto uspes javi , jer se i ja lomim oko TSR-ova. BTW imas na ECSTASY (022/53-884) TSR.ZIP, ali ni on nije ispravan tako da moze da posluzi samo da se dobije neka predstava o tome sta se desava. ĐŠč█ Pozdrav Ace B) █čŠĐ--- * Origin: ECSTASY BBS * Indjija * 022 53-884 * SETNet: (38:111/119)
cccc.424 .djn, -> #416, mitar
> Jel ima ovde neko ko zna nesto o PRO C-u? > Interesuje me sve, cak i to da li ima i gde da se kupi, > kompletno ili samo literatura. Da nema mozda neka > masonska loza u vezi sa istim? :))) Koliko znam to je varianta C-a sa dodacima za pristup ORACLE-u.
cccc.425 nbatocanin, -> #416, mitar
> Jel ima ovde neko ko zna nesto o PRO C-u? > > Interesuje me sve, cak i to da li ima i gde da se kupi, > kompletno ili samo literatura. Da nema mozda neka > masonska loza u vezi sa istim? :))) Ja sam imao neku dosta staru verziju. Ako te interesuje, mogu da potražim.
cccc.426 .djn,
Ako sam dobro shvatio... U C-u postoje tekstualne i binarne datoteke. U Pascalu takodje. Osnovna razlika je u tome sto je rad sa binarnim datotekama brzi ali i rizicniji, jer je na korisniku da pravilno protumaci podatke. U Pascalu postoji i mogucnost da se u datoteku snimaju objekti odredjenog tipa nrp. bajtovi, realni brojevi, ali i citavi slogovi. Nema nikakve narocite filozofije. Jednostavno se proglasi da su u datoteci slogovi nekog tipa pa se jedan po jedan citaju. Postoje sve uobicajene komande za pristup slogu. Da li takve datoteke postoje i u C-u?
cccc.427 postmast,
From: dcolak@setnet.co.yu (Damir Colak) Subject: Ack & Busy Date: Thu, 20 Jul 1995 12:52:10 IJ> AG> for(c=0;string[c]!='\0';c+=1){} IJ> AG> Ja tu nevidim neku mogucu optimizaciju (prosvetli me ako gresim :)). IJ>Pa mozes jednu bolju optimizaciju da uradis: IJ>c=0; IJ>while(!string[c]) IJ> c++; Hej Hej Hej! :) Pa moze i bolje: c=0; while(!string[c++]); :)) Sledge DAMMIR! * Origin: Sledge HAMMER! BBS 011/163-452 22:00-07:00 (38:103/128)
cccc.428 mitar, -> #424, .djn
>>> Jel ima ovde neko ko zna nesto o PRO C-u? >> Koliko znam to je varianta C-a sa dodacima za pristup ORACLE-u. Hm, radi se o C-kod generatoru za rad sa bazama podataka, izmedju ostalih i sa Oracle-om. Ali sad si me zbunio, u jednoj knjizi o Oracle-u bilo je reci o njihovom gene- ratoru maski, dal se bese to isto zove ili je slucajnost. Ovde je rec o proizvodu firme istog naslova, sa Ontaria ili tako nesto. Mislim da imaju ispostavu negde u Hamburgu, a da imaju neko ime kao Mel itd. Problem je sto nikakvu adresu, niti telefon nemam, iako oni po readme fajlu preporucuju logovanje na njihov BBS radi preuzimanja generisanih primera. Daj pogledaj detalje oko toga iz Oracle-a pa da jurim tu knjigu, ne znam vise kako se zove samo mi se cini da bese izdanje "Tehnicke knjige". Unapred zahvalan.
cccc.429 mitar, -> #425, nbatocanin
>>> Jel ima ovde neko ko zna nesto o PRO C-u? >> Ja sam imao neku dosta staru verziju. Ako te interesuje, mogu da >> potrazim. Nije rec o verziji, problem je uputstvo, kontakt adresa ili telefon, bar telefon BBS. Moja verzija je 2.5.8. Hvala na trudu.
cccc.430 postmast,
From: KLIMENT.ANDREEV@f108.n108.z38.setnet.setnet.co.yu (KLIMENT ANDREEV) Subject: TLINK 2.0 Date: Fri, 21 Jul 1995 21:16:00 Imam jedan mali problem. Koristim Turbo C 2.0, zajedno za TLINK-om 2.0, ali nije instalaciona verzija, nego onako skinuto sa diska. E sad, napravim neki program, lepo ga iskompajliram sa tcc -mt -lt ime.c, i naravno dobijem ime.com na disku, koji sasvim ispravno radi. Ali ukoliko probam da linkujem OBJ "ruccno", t.j ne preko ttc-a, onda kucam ovako: tlink /t c:\xxx\c0t ime.c,,,c:\lib\ct c:\lib\emu i linker me pozdravlja sa porukama u stilu da je nessto nedefinirano u modulu c0t.obj. Gde gressim? 10x Chombe KAN ___ ■ OLX 2.1 TD ■ Domaccice manje zbori, da ti ruccak ne zagori. * Origin: SETNet: Struga BBS +389 96 74074 * Macedonia * (38:108/108)
cccc.431 driks, -> #419, postmast
Subject: ACK & BUSY >>> Sada mene zanima kako si uspeo da citas stanja pojedinih >>> izvoda (pinova) ? PORT:379H Read-only: Printer Status Í7┬6┬5┬4┬3┬2┬1┬0Ě ║ │ │ │ │ │0 0 0║ ËĎ┴Ď┴Ď┴Ď┴Ď┴─┴─┴─Ż bit ║ ║ ║ ║ ╚═══════ 3: -ERROR (pin 15) 0=printer signals an error ║ ║ ║ ╚═════════ 4: +SLCT (pin 13) 1=printer is selected ║ ║ ╚═══════════ 5: +PE (pin 12) 1=out of paper ║ ╚═════════════ 6: -ACK (pin 10) 0=ready for next character ╚═══════════════ 7: -BUSY (pin 11) 0=busy or offline or error Izvor: TechHelp (imas ga na Sezamu) dragan
cccc.432 janko, -> #394, mkaralic
> Nažalost, rešio sam da pišem nešto sitno za Windows, a > malo više za DOS (barem dok sam na 4MB). Zbog Windows-a me > i interesuje koji je paket bolji - MSVC ili BC++. Za 4 MB rama, nijedan nije dobar. > Fora je u tome što sam već radio sa Borlandovim > kompajlerom, pa me interesuje da li bi vredelo preći na > MSVC. > Ako si samo radio DOS, neće ti puno značiti koji je -- imaćeš ionako puno novoga. > Imam uputstvo za Borland C++ 4.0 i u njemu se spominje da > izuzeci nisu implementirani. Da li ih ima u nekoj od > sledećih verzija? Da, 4.5 ima. > Zanima me i da li BC++ 4.5 traži više memorije od BC++ > 4.0, kakve su mu mogućnosti pri razvoju Windows programa, > itd. Za male programe, živi i sa 8 MB. Za veće, nesnosan je bez 16. Mogućnosti.. velike, ali je C++ za Windows ipak NAJTEčI način razvoja aplikacija, primeren samo profesionalcima (ne računam "suvi" C i ASM, to su već "fundamentalistički" pristupi ;) ). Kome ne trebaju neke "posebne usluge" bolje da se drži nečeg manje teškog.. VB ili Delfi.
cccc.433 smarkov, -> #426, .djn
> Da li takve datoteke postoje i u C-u? > Ako sam dobro shvatio... > U C-u postoje tekstualne i binarne datoteke. C nasledjuje metod rada sa datotekama od UNIX-a. Misli se, naravno, na funkcije standardne biblioteke. UNIX predstavlja datoteke kao prost niz byte-ova. Nema dakle nikakve vise strukture, odnosno slogova specificiranog tipa. Upis/citanje proizvoljnog podatka/grupe je moguc u C-u konstrukcijama tipa: fread(fp, sizeof(var), 1, &var) fwrite(fp, sizeof(var), 1, &var) gde je 'var' promenljiva bilo kog tipa.
cccc.434 nbatocanin, -> #428, mitar
>>>> Jel ima ovde neko ko zna nesto o PRO C-u? > >>> Koliko znam to je varianta C-a sa dodacima za pristup > ORACLE-u. > > Hm, radi se o C-kod generatoru za rad sa bazama podataka, > izmedju ostalih i sa Oracle-om. Ali sad si me zbunio, > u jednoj knjizi o Oracle-u bilo je reci o njihovom gene- > ratoru maski, dal se bese to isto zove ili je slucajnost. Da, postoje najmanje dva proizvoda sa sličnim imenom: Pro*C je (koliko mi je poznato) pretprocesor za Oracle iskaze i služi za povezivanje sa Oracle-om. Ono što sam ja imao (pa izbrisao :( ) je generator programa: zadaju se razne opcije i on generiše C-kod. Verzija koju sam imao nije ozbiljnije podržavala rad sa bazama podataka. Za novije ne znam. Znam da ista firma proizvodi niz dodataka koji imaju zajednički prefiks "pro": Pro-BASIC i sl.
cccc.435 oper, -> #432, janko
>>> malo više za DOS (barem dok sam na 4MB). Zbog Windows-a me >>> i interesuje koji je paket bolji - MSVC ili BC++. >> >> Za 4 MB rama, nijedan nije dobar. Možda ipak može da posluži BC++ 3.1. Meni je sasvim lepo radio na 386/4M. >>> izuzeci nisu implementirani. Da li ih ima u nekoj od >>> sledećih verzija? >> >> Da, 4.5 ima. Kao što su imali i 4.0 i 4.2. >>> Zanima me i da li BC++ 4.5 traži više memorije od BC++ >>> 4.0, kakve su mu mogućnosti pri razvoju Windows programa, >>> itd. >> >> Za male programe, živi i sa 8 MB. Za veće, nesnosan je bez 16. Evo i malo konkretnih iskustava sa 4.02 i 4.5. Imam projekat koji se sastoji od 26 cpp nodova. Sve u svemu 6500 linija c++ koda i 1500 linija mojih hedera. Takođe se koristi Paradox Engine i Crystal Reports. Uz osrednju optimizaciju prekompajliranih zaglavlja (ceo OWL ide u .csm fajl, a ostalo se izuzima) - make posle izmene u jednom sorsu traje od 45 do 90 sec, zavisno od sorsa na mojoj DX266 mašini (Cyrix :( sa 8M RAMa i CFS540 diskovima uz 256K za keširanje. Posle startovanja Win, inače, imam 16.8M slobodne memorije uz swap od 10.000.000. Pri prevođenju i linkovanju količina memorije nikad ne pada ispod 9.8M. Ovo su podaci sa 4.02. Uz 4.5, koji, čini mi se, nešto brže kompajlira (nedavno sam instalirao i neće baš da radi kako treba :( pri identičnim uslovima slobodna memorija pada do 8.7M. Jedini pravi problem jeste što posle prevođenja treba da sačekam par sekundi da mi se pojavi message window ;) BTW, sa 4M RAMa na 486DX33 prekinuo sam kompajliranje posle 25 minuta ;) Pz, Pera...
cccc.436 postmast,
From: Mladen.Adamovic@f135.n135.z38.setnet.setnet.co.yu (Mladen Adamovic) Subject: Cccc Date: Thu, 20 Jul 1995 15:02:43 -+=+- Zoran Rilak rece : -+=+- ZR> From: zoran.rilak@rstones.durlan.co.yu (Zoran Rilak) ZR> zanimljivosti, ja imam tekst knjige gosp. Kratice sa puno zanimljivih ZR> zadataka (znate vi njega! ;) ) , ali kako je to povece cak i kad se ZR> arhivira (oko 126 Kbajata) a ja imam 2400 modem i istekla mi je VEOMA me interesuje, VEOMA. Ako ima neka dobra dusa ili Zoran ;) da mi to posalje na donje adrese bio bih mu mnogo zahvalan : Mladen Adamovic (adamm@elf.bl.ac.yu, madamovic@sezam.co.yu). Pozdrav, unapred VEOMA hvala. ... Tata, vidi .... TAG! * Origin: Sveti Sava BBS Prijedor 079 11 629 SETNet: (38:135/135)
cccc.437 janko, -> #435, oper
>>>> malo više za DOS (barem dok sam na 4MB). Zbog Windows-a >>>> me i interesuje koji je paket bolji - MSVC ili BC++. >>> >>> Za 4 MB rama, nijedan nije dobar. > > Možda ipak može da posluži BC++ 3.1. Meni je sasvim lepo > radio na 386/4M. žovek je pitao za poslednje verzije, i programiranje pod Windowsom. >>>> Zanima me i da li BC++ 4.5 traži više memorije od BC++ >>>> 4.0, kakve su mu mogućnosti pri razvoju Windows >>>> programa, itd. >>> >>> Za male programe, živi i sa 8 MB. Za veće, nesnosan je >>> bez 16. > > Evo i malo konkretnih iskustava sa 4.02 i 4.5. Imam > projekat koji se sastoji od 26 cpp nodova. Sve u svemu > 6500 linija c++ koda i 1500 linija mojih hedera. Takođe se > .. > fajl, a ostalo se izuzima) - make posle izmene u jednom > sorsu traje od 45 do 90 sec, zavisno od sorsa na mojoj > DX266 mašini (Cyrix :( sa 8M RAMa i CFS540 diskovima uz > 256K Kad me baš vučeš za jezik... Projekat na kome radim (o kome ne mogu dati detaljnije podatke osim da je to komercijalni produkt, potpuno razvijan u našoj zemlji i ne koristi druge biblioteke osim OWL) ima trenutno nekih 75.000 linija koda u oko dvesta modula. Skoro svaki modul radi include OWL-a. :( Na 486/66 Build All traje preko 50 minuta, a samo linkovanje par minuta *kada nije prevođeno debug info* (8 minuta sa debug info u svim modulima), .OBJ fajlovi, po prevođenju, zauzimaju nekih 40 MB (kada sadrže debug info), .CSM ("prekinut strateški") je preko 20 MB, aplikacija je 8 MB sa debug informacijama itd. Između ostalog, 16 MB RAM-a mu nije dosta za linkovanje. Posle Bulid All, izveštaj je "prevedeno je 3 i po miliona linija". Tek da se zna na šta mislim kada kažem "za veće programe".
cccc.438 oper, -> #437, janko
>>> Možda ipak može da posluži BC++ 3.1. Meni je sasvim lepo >>> radio na 386/4M. >> >> žovek je pitao za poslednje verzije, i programiranje pod >> Windowsom. Pa i mislio sam da mi je 3.1 radio za Win. Što se tiče najnovijih verzija, tu smo se svi složili. >> Kad me baš vučeš za jezik... Projekat na kome radim (o kome ne Izvini, možda smo ti ili ja nešto pogrešno shvatili :( >> ... >> za linkovanje. Posle Bulid All, izveštaj je "prevedeno je 3 i >> po miliona linija". >> >> Tek da se zna na šta mislim kada kažem "za veće programe". Nisam ja mislio da je ovo što ja radim "veliki" ili "mali" projekat. Samo sam želeo da kažem - "u tim i tim uslovima radi tako i tako". I fino je što sad svi znamo kako se ponaša u dva realna okruženja. Pz, Pera...
cccc.439 postmast,
From: rsasa@fon (Radetic Aleksandar) Subject: Re: cccc Date: Wed, 26 Jul 1995 05:50:40 GMT Janko Stamenovic (janko@sezam.UUCP) wrote: : 75.000 linija koda u oko dvesta modula. Skoro svaki modul radi : include OWL-a. :( Na 486/66 Build All traje preko 50 minuta, a samo : linkovanje par minuta *kada nije prevodeno debug info* (8 minuta sa : debug info u svim modulima), .OBJ fajlovi, po prevodenju, zauzimaju : nekih 40 MB (kada sadrze debug info), .CSM ("prekinut strateski") je : preko 20 MB, aplikacija je 8 MB sa debug informacijama itd. Izmedu : ostalog, 16 MB RAM-a mu nije dosta za linkovanje. Posle Bulid All, : izvestaj je "prevedeno je 3 i po miliona linija". : Tek da se zna na sta mislim kada kazem "za vece programe". Izvinjavam se zbog upada u diskusiju, ali sudeci prema ovim podacima, iskustva Laboratorije za informacione sisteme FON-a u radu sa MS VC++ 1.5 professional su mnogo bolja od Vasih sa Borland-ovim proizvodima. Windows aplikacija koja se ovde razvija "teska" je preko 100000 linija koda u 150 modula. Obavezne header datoteke su vece od 300 Kb, ali se to prilicno dobro resava pomocu PrecompiledHeader opcije. Ranije se sve to kompajliralo oko 70 minuta, a sada se RebuildAll izvrsava za manje od 10 minuta. Osim ovoga, za aplikaciju se po zavrsetku kompajliranja dobija izuzetno dobar Browse katalog (sve informacije o promenljivim, funkcijama) i sl. Za "pocetnike", a i za one druge u Windows okruzenju vrlo je pogodna stvar sto se moze izabrati Template za novi projekat (aplikaciju). MSVC automatski izgenerise kostur aplikacije. Vase je samo da je doradite i eventualno napravite nove dijaloge, ikone i ostale resurse. Pocetna aplikacija (debug) je uvek velika oko 1 Mb, ali u release modu velicina pada na 100-200 Kb, zavisno od izabranih opcija. Vrlo lako se privikava na ovo okruzenje, posto je prilicno user-friendly orijentisano, a Help je vise nego detaljan (primeri i ostalo). Pozdrav, Sasa
cccc.440 postmast,
From: rsasa@fon (Radetic Aleksandar) Subject: Re: TLINK 2.0 Date: Wed, 26 Jul 1995 05:55:28 GMT KLIMENT ANDREEV (KLIMENT.ANDREEV@f108.n108.z38.setnet.setnet.co.yu) wrote: : Imam jedan mali problem. Koristim Turbo C 2.0, zajedno za : TLINK-om 2.0, ali nije instalaciona verzija, nego onako : skinuto sa diska. : i linker me pozdravlja sa porukama u stilu da je nessto : nedefinirano u modulu c0t.obj. Pokusaj da promenis memorijski model (ne Tiny) i da setujes environment promenljive za biblioteke, a ne da ih navodis u komandnoj liniji. Cudno, ali i mene je nesto slicno zezalo. Pozdrav, Sasa
cccc.441 mitar, -> #434, nbatocanin
>> Da, postoje najmanje dva proizvoda sa slicnim imenom: Pro*C je >> (koliko mi je poznato) pretprocesor za Oracle iskaze i sluzi za >> povezivanje sa Oracle-om. Ono sto sam ja imao (pa izbrisao :( ) je >> generator programa: zadaju se razne opcije i on generise C-kod. >> Verzija koju sam imao nije ozbiljnije podrzavala rad sa bazama >> podataka. Za novije ne znam. Znam da ista firma proizvodi niz >> dodataka koji imaju zajednicki prefiks "pro": Pro-BASIC i sl. To je pravi odgovor. Blagodarim. Posto vidim da si veoma upoznat :), a sta znaci ono "nije ozbiljnije podrzavala"? Ne znam da li da pisem sta ova verzija sto ja imam moze, ali bas bi me zanimala tvoja definicija "dobrog" kod generatora za baze podataka. Imam prijatelja koji misli da zna Clipper. :) Kada je video neke od ovih C-kod generatora bio je vrlo zainteresovan za to isto ali na Clipper-u. Sta bi mu ti preporucio? Pozdrav.
cccc.442 postmast,
From: broker@setnet.co.yu (Predrag Supurovic) Subject: Nova knjiga Date: Thu, 27 Jul 1995 14:11:11 U izdanju Mikro Knjige priprema se naslov: OBJEKTNO ORIJENTISANO PROGRAMIRANJE NA JEZIKU C++ od osnovnih pojmova do naprednih tehnika Dragan Milicev 480str. Format 23,5x16,5cm Najkompletniji udzbenik na nasem jeziku za objektno orijentisano programiranje (OOP) i jezik C++. Na lagan i postupan nacin uvodi vas u osnovne principe programiranja i jezika C++, kao modernog sredstva za realizaciju softvera. Prikazuje i objasnjava sve detalje jezika, kako bi citalac bio sposoban da analizira i najslozenije tudje programe i biblioteke klasa, kao i da pise kompleksne sopstvene programe u bilo kom okruzenju. Prikazan je jezik u celini, tako da knjigu mogu citati i oni koji uopstenepoznaju jezik C. Knjiga sadrzi i prikaz jedne objektne metodologije. Na nizu primera objasnjavaju se naprednije tehnike programiranja na jeziku C++. Iako su objasnjenja jasna, potpuna i detaljna, nivo izlaganja je izuzetno visok. Knjiga polazi od pretpostavke da citalac zna osnovne pojmove tradicionalnog, strukturiranog programiranja ijezika, kao sto je, na primer, Pascal. Misljenja o knjizi "Knjiga je prvenstveno namenjena ljudima koji se profesionalno bave programiranjem a zele da se upuste u vode objektne metodologije kao nove strategijeu programiranju. Medjutim, namenjena je i mladjim, ambicioznim ljudima koji imaju smisla, sposobnosti i predznanja da se upuste u jedan nov izazov." prof. Dušan Velasavec, recezent "Pojava ove knjige je znacajan dogadjaj, jer je prvi put u literaturi na nasem jeziku spojena metodologija objektno orijentisanog programiranja i projektovanja sa samom implementacijom u jeziku C++." prof. dr. Zoran Jovanovic, recezent "Prva knjiga kod nas kja se iscrpno bavi svim detaljima jezika C++, cak i onima o kojima se nije moglo naci nista u do sada izdatim knjigama." Janko Stamenovic, saradnik casopisa Racunari ... They catched me writing on the wa... -+- OLMS 2.5 UNREG * Origin: Oreska BBS, Uzice = SF BIBLIOTEKA = SETNet: (38:101/101)
cccc.443 .djn, -> #433, smarkov
> Upis/citanje proizvoljnog podatka/grupe je moguc u C-u konstrukcijama > tipa: > > fread(fp, sizeof(var), 1, &var) > fwrite(fp, sizeof(var), 1, &var) > > gde je 'var' promenljiva bilo kog tipa. Svaka cast... Pocecu da se kunem i u C. Probao sam i radi (naravno). Upisivao sam i ucitavao jednu strukturu podataka. fread(&student, sizeof(student), 1, fp); Da li moze nekako da se odjednom ucita niz (veci broj ili bas niz) struktura? Ona jedinica (size_t n - "number of items read") sluzi za to, ali mi nije uspelo da ucitam podatke u niz jednom komandom fread.
cccc.444 nbatocanin, -> #441, mitar
> Posto vidim da si veoma upoznat :), a sta znaci ono > "nije ozbiljnije podrzavala"? Pa i nisam baš specijalno upoznat. Davno je bilo i Pro-C me je interesovao u okviru oblasti generatora programa i korisničkih interfejsa. Nisam detaljnije gledao, ali garant bi se sećao da je bila neka ozbiljnija podrška. Koliko se sećam, akcenat je bio na korisničkom interfejsu. Doduše, to me je tad više interesovalo, pa sam možda i preskočio bazu. > Kada je video neke od ovih C-kod generatora bio > je vrlo zainteresovan za to isto ali na Clipper-u. > Sta bi mu ti preporucio? Pa, izbor je veoma širok. Pošto ne koristim ozbiljno ni jedan, ne mogu dati preporuku bez rezerve. Obično se radi o razvojnim okruženjima, ne o čistim generatorima. Od onoga što sam video najpoznatiji su DBSee, Genifer, ... Po čuvenju bih isprobao UltimADE. Mada, svi oni gube prvobitni smisao sa pojavom inegrisanih vizuelnih alatki.
cccc.445 postmast,
From: nikola@fon (Nikola Mitrovic) Subject: cccc Date: Sat, 29 Jul 1995 21:08:51 GMT EKSKLUZIVNO! EKSKLUZIVNO! EKSKLUZIVNO! >> Partial DOOM Sources in C/C++ << Skoro sve rutine iz popularne igre DOOM! [sve bitne rutine: vektori, timing, scaling, grafika, delimicno zvuk, mape, konzola, i/o, joystick, sprajtovi, hi-score, main, i jos mnogo toga...] Rutine ne poseduju komentare, ali su sve varijable i funkcije vise nego jasno krstene; veliki broj 'inline' instrukcija Za sve informacije mail na: <nikola@cherokee.hobbiton.co.yu> ili <nikola@fon.fon.bg.ac.yu> DOOM! DOOM! DOOM! DOOM! DOOM! DOOM! DOOM!
cccc.446 mitar, -> #444, nbatocanin
>> DBSee, Genifer, ... Po cuvenju bih isprobao UltimADE. Mada, svi oni gube >> prvobitni smisao sa pojavom inegrisanih vizuelnih alatki. Vrlo dobro. Prenecu, mada za ovaj poslednji nikad cuo. Pozdrav.
cccc.447 postmast,
From: Vladimir.Svrkota@f119.n111.z38.setnet.setnet.co.yu (Vladimir Svrkota) Subject: Nova knjiga Date: Mon, 31 Jul 1995 11:39:01 PS> U izdanju Mikro Knjige priprema se naslov: PS> OBJEKTNO ORIJENTISANO PROGRAMIRANJE PS> NA JEZIKU C++ A cena? Sumnjam da ce biti 'sitnica' ;) ... The Truth Is Out There... * Origin: ECSTASY BBS * Indjija * 022 53-884 * SETNet: (38:111/119)
cccc.448 postmast,
From: ivica@galeb.etf.bg.ac.yu (Ivica Nikolic) Subject: Re: STA RADI... Date: Tue, 1 Aug 1995 22:02:34 GMT Jugoslav Stojanov je napisao: >> Sta treba staviti umesto znaka pitanja (?) u sledecem programu: >> ... >> printf("%?",2["ABCD"]); >> ... >> i sta ce biti ispisano ... Jesi li ti siguran da ce to da prodje kroz kompajler? Mislim, cak i ako se ona dvojka shvati kao pointer cija je integer vrednost 2, kompajleru nedostaje informacija o tipu koji gadja pointer da bi mogao da adresira pravi element niza, ciji je indeks jednak lokaciji u memoriji u koju je loader smestio literal "ABCD"? Ili se mozda zezas? -- Nisam zgodan al sam plodan
cccc.449 postmast,
From: ivica@galeb.etf.bg.ac.yu (Ivica Nikolic) Subject: Re: ACK & BUSY Date: Tue, 1 Aug 1995 22:10:15 GMT Dejan Jovanovic je napisao: >> AG> for(c=0;string[c]!='\0';c+=1){} >> AG> Ja tu nevidim neku mogucu optimizaciju (prosvetli me ako gresim :)). >> Nema tu vise neke vece optimizacije. Vreme je da iskoristis integrisani >> assembler (ako neznas uci obavezno) . Procitaj pomalo sta rade oni momci sa Ima tu jos ohoho mesta za optimizaciju i bez asemblera. Glavna nezgoda je sto ljudi zaboravljaju da C ima pointersku aritmetiku. brojacka promenljiva je sasvim suvisna, a tek adresiranje elementa niza pomocu nje! string[c] ce prvo izazvati sabiranje c-a i string-a, pa tek onda zahvatanje u memorijsku lokaciju koja se dobije sabiranjem. I posle svega, jos izvrsavas c += 1. Malocas na nekom drugom mestu u ovoj konferenciji napisah bolje resenje, ali evo sad cu da ga ponovim: size_t strlen( const char *s ) { char *local = s; while( *(local++) ) ; return local - s - 1; } Ovo je vec blizu granice brzine koja moze da se izvuce iz cistog C-a. -- Integer out of range
cccc.450 postmast,
From: ivica@galeb.etf.bg.ac.yu (Ivica Nikolic) Subject: Re: Nova knjiga Date: Tue, 1 Aug 1995 22:13:29 GMT Predrag Supurovic je napisao: >> U izdanju Mikro Knjige priprema se naslov: >> >> OBJEKTNO ORIJENTISANO PROGRAMIRANJE >> NA JEZIKU C++ >> >> od osnovnih pojmova do naprednih tehnika >> >> Dragan Milicev >> >> 480str. Format 23,5x16,5cm >> Jedno banalno pitanje: da li znas koliko kosta? -- Mala, mala, mala grupa hedera
cccc.451 mkaralic, -> #439, postmast
> From: rsasa@fon (Radetic Aleksandar) > > Izvinjavam se zbog upada u diskusiju, ali sudeci prema ovim podacima, > iskustva Laboratorije za informacione sisteme FON-a u radu sa MS VC++ > 1.5 professional su mnogo bolja od Vasih sa Borland-ovim proizvodima. Kad smo već kod toga, zanima me kakve su razlike između MSVC 1.0 i 1.5. Kod mene na 386SX/40/4MB MS VC 1.0 prilično fino radi (samo okruženje radi veoma brzo u odnosu na druge programe). Kompajliranje mi deluje malo sporo, a rezultati su sledeći: Kada napravim,pomoću Application Wizzard-a, aplikaciju koja podržava OLE, sve se bilduje oko 6 minuta, koliko i aplikacija stvorena uz pomoć App Expert-a, s tim što App Expert iz BC++ 4.0 ne podržava OLE. Inače, čini mi se da se sitniji programi brže bilduju u BC++. Zanima me još jedna stvar, a to je šta, ustvari, sadrži MFC? I još jedno. Da li su u MSVC 1.5 implementirane klase za rad sa datumima, i da li je iko radio sa ovim čudom na 4MB? Bio bih vrlo zahvalan svima koji mi odgovore. Pozdrav // Mik !!!
cccc.452 sikima, -> #450, postmast
>> knjiga OBJEKTNO ORJENTISANO PROGRAMIRANJE NA JEZIKU C++ >> izdanje Mikro knjige Koliko znam zadnja cena bila je 70 din. Knjiga treba da izadje do kraja augusta. Vise informacija na 542 516 Mikro knjiga. Puno pozdrava od Sikime P.S. Nadam se da neko ovo cita iz Mikro knjige i da ce me imati u vidu prilikom pretplate (((((:
cccc.453 nbatocanin, -> #446, mitar
> Vrlo dobro. Prenecu, mada za ovaj poslednji nikad cuo. UltimADE su na poslednjem takmičenju razvojnih timova koristile čak dve od tri prvoplasirane ekipe (ako se dobro sećam).
cccc.454 postmast,
From: broker@setnet.co.yu (Predrag Supurovic) Subject: Nova knjiga Date: Tue, 01 Aug 1995 11:27:41 PS> U izdanju Mikro Knjige priprema se naslov: PS> OBJEKTNO ORIJENTISANO PROGRAMIRANJE PS> NA JEZIKU C++ VS> A cena? Sumnjam da ce biti 'sitnica' ;) Pa i nije. U pretplati, cena je 70 dinara. Kasnije ce biti visa. ... Pusenje ili zdravlje. Odlucite sami. -+- OLMS 2.5 UNREG * Origin: Oreska BBS, Uzice = SF BIBLIOTEKA = SETNet: (38:101/101)
cccc.455 rrad, -> #453, nbatocanin
> UltimADE su na poslednjem takmicenju razvojnih timova koristile > cak dve od tri prvoplasirane ekipe (ako se dobro secam). OK, preuzimam na svom rodjenom uzeru, tj. stigao sam sa odmora. :) Posto ja nemam blagog pojma o Clipperu, dzaba mi to. No bez obzira, kako stici doticnog? Jedno uopsteno pitanje, mada nije mnogo izvan dosadasnje price, - ne odnosi se specijalno na tebe, mozda neko zna: Zbog cega je C dir najneazuriraniji direktorijum na SEZAM-u? Ili, kada ce vec jednom da stignu nove verzije DFlat-a, EasyVision-a itd? Ne zelim da budem neprijatan, ali mi se cini da smo (mi, zainteresovani za C i C++ pogotovu) malko zapostavljeni. Pozdrav, RRadovanovic.
cccc.456 smarkov, -> #443, .djn
> Da li moze nekako da se odjednom ucita niz (veci broj ili bas niz) > struktura? > Ona jedinica (size_t n - "number of items read") sluzi za to, ali mi nije > uspelo da > ucitam podatke u niz jednom komandom fread. Naravno, ali uz dele date ograde. Jezik ne garantuje da su elementi strukture složeni bez "rupa" (zbog performansi - čitanje int-a na adresi deljivoj sa četiri je na 32-bitnim mašinama obično mnogo brže nego sa adrese n*4+1). Vidi na svom kompajleru rezultat sledećeg programa: struct fali1 { int a; char c[1]; } niz[2]; main() { printf("%d\n", (char *)&niz[1] - (char *)&niz[0]); printf("%d\n", sizeof(struct fali1)); } Ako arhitektura ciljnog procesora dozvoljava da prosti podaci (char, int, long) budu na proizvoljnim adresama, za kompajler obicno postoji #pragma direktiva kojom je moguće spakovati strukture tako da nema popunjavanja (eng. padding). Kod MSC kompajlera pragma je : #pragma pack(1). Ova osobina se može kontrolisati na nivou delova izvornog koda jer #pragma pack() vraća na podrazumevano stanje. Konačno, ovakva kontrola je pored opisanog slučaja sa upisom/čitanjem podataka od značaja za komunikacioni softver (kada je tačno specificirano šta ide na "žicu").
cccc.457 postmast,
From: rsasa@fon (Radetic Aleksandar) Subject: Re: cccc Date: Thu, 3 Aug 1995 12:41:11 GMT Milorad Karalic (mkaralic@sezam.UUCP) wrote: : Kad smo vec kod toga, zanima me kakve su razlike izmedu MSVC 1.0 i 1.5. Razlika izmedju svake verzije Microsoft Visual kompajlera je u MFC-u (Mirosoft Foundation Classes). Konkretno, radi se o C++ funkcijama koje su dostupne i u source-u, a koriste se prilikom "automatskog" generisanja kostura aplikacije. Konkretno, MSVC 1.5 ima nesto poboljsane Wizard-e za klase, a razlike u MFC-u su znacajne (vece mogucnosti). Uopste, samo okruzenje je mnogo pristupacnije (lakse za koriscenje). Za klase za rad sa datumima nisam siguran (znam da postoje standardne funkcije u C-u za rad sa datumima) a osnovni problem je sto kompletan softver jedva da se mrda ispod 6 Mb RAM-a (preporucljivo je 8 Mb). Verzija 1.5 moze da generise samo 16-bitne aplikacije, dok 2.0 moze i 32-bitne. Kompletna instalacija koja moze da odradi veci deo posla oduzima 80 Mb na hardu, a full instalacija (velicina CD-a je oko 240 Mb). Pozdrav, Sasa
cccc.458 postmast,
From: Aleksandar.Glumac@f119.n111.z38.setnet.setnet.co.yu (Aleksandar Glumac) Subject: cccc Date: Wed, 02 Aug 1995 17:07:02 >>> Sada mene zanima kako si uspeo da citas stanja pojedinih >>> izvoda (pinova) ? >> PORT:379H Read-only: Printer Status >> 7 6 5 4 3 2 1 0 >> 0 0 0 >> bit >> 3: -ERROR (pin 15) 0=printer signals an error >> 4: +SLCT (pin 13) 1=printer is selected >> 5: +PE (pin 12) 1=out of paper >> 6: -ACK (pin 10) 0=ready for next character >> 7: -BUSY (pin 11) 0=busy or offline or error Thanx, vec sam provalo iz knjige PC/ROM BIOS :) , ali nema za seriske portove :( >> Izvor: TechHelp (imas ga na Sezamu) Nazalost nemam pristup sezamu (uskoro idem na fax pa mi se ne isplati), ako ga imas jevi pa da skinem od tebe ako nemas nista protiv :) >> dragan BTW sta nameravas da radis sa stampacem (grafika ili text) ? ĐŠč█ Pozdrav Ace B) █čŠĐ--- * Origin: ECSTASY BBS * Indjija * 022 53-884 * SETNet: (38:111/119)
cccc.459 postmast,
From: KLIMENT.ANDREEV@f108.n108.z38.setnet.setnet.co.yu (KLIMENT ANDREEV) Subject: TLINK 2.0 Date: Sat, 29 Jul 1995 18:07:00 RA>Pokusaj da promenis memorijski model (ne Tiny) i da setujes RA>environment promenljive za biblioteke, a ne da ih navodis u RA>komandnoj liniji. Cudno, ali i mene je nesto slicno zezalo. RA> Pozdrav, RA> Sasa Hvala na odgovoru. Sad sam pressao na BC++2.0 i sa istom sintaksom nema problema. TLINK u ovoj verziji ima i *.CFG fajl, dok u TC 2.0 (skinutoj sa diska) ovog fajla nije bilo. Chombe KAN ___ ■ OLX 2.1 TD ■ Bel Spagette. * Origin: SETNet: Struga BBS +389 96 74074 * Macedonia * (38:108/108)
cccc.460 postmast,
From: KLIMENT.ANDREEV@f108.n108.z38.setnet.setnet.co.yu (KLIMENT ANDREEV) Subject: Nova knjiga Date: Sat, 29 Jul 1995 18:07:00 PS>U izdanju Mikro Knjige priprema se naslov: PS>OBJEKTNO ORIJENTISANO PROGRAMIRANJE PS>NA JEZIKU C++ Dali znass mozzda koja cce biti cena (otprilike)? 10x Chombe KAN ___ ■ OLX 2.1 TD ■ Dragstor Maxtor. * Origin: SETNet: Struga BBS +389 96 74074 * Macedonia * (38:108/108)
cccc.461 postmast,
From: KLIMENT.ANDREEV@f108.n108.z38.setnet.setnet.co.yu (KLIMENT ANDREEV) Subject: Problem sa BP Date: Sat, 29 Jul 1995 18:09:00 Jednom sam ovde postavio pitanje, zassto prvi deo ne radi a drugi radi. Pretpostavlja se da koristite ili prvi deo ili drugi deo. #include <dos.h> #include <conio.h> struct REGPACK preg; unsigned char bukva[16]={255,255,255,255,255,255,255,255, 255,255,255,255,255,255,255,255}; main() { preg.r_ax=0x1100; preg.r_bx=0x1000; preg.r_cx=0x0001; (1 DEO) preg.r_dx=65; preg.r_es=FP_SEG(bukva); preg.r_bp=FP_OFF(bukva); intr(0x10,&preg); asm mov ax,0x1100; asm mov bx,0x1000; asm mov cx,0x0001; asm mov dx,0x0041; (2 DEO) asm push ax asm mov ax,SEG bukva asm mov es,ax asm pop ax asm mov bp,OFFSET bukva asm int 0x0010; } To je zato ssto sam kompajler koristi BP registar za svoje namene, tako da petljanje sa njim nije bass preporuccljivo. Obiccno se to mozze izbecci korissccenjem nekog drugog registra, ali u ovom primeru mora da postoji bass BP registar, possto funkcija za redefinisanje slova trazzi BP registar kao parametar za ofset. Zato ako koristite BP registar, obavezno to treba da bude asemblerska instrukcija. Jedino mi nije jasno zassto MSC 5.1 ne podrzzava uopsste korisccenje BP registra. Dali je to "popravljeno" u nekim narednim verzijama? Chombe KAN ___ ■ OLX 2.1 TD ■ ENVER LYNN - Albanski porno glumac * Origin: SETNet: Struga BBS +389 96 74074 * Macedonia * (38:108/108)
cccc.462 visnja, -> #455, rrad
> Zbog cega je C dir najneazuriraniji direktorijum na SEZAM-u? > Ili, kada ce vec jednom da stignu nove verzije DFlat-a, > EasyVision-a itd? Verovatno sto je i C najneazurniji jezik :)
cccc.463 smarkov, -> #448, postmast
>>> Sta treba staviti umesto znaka pitanja (?) u sledecem programu: >>> ... >>> printf("%?",2["ABCD"]); >>> ... >>> i sta ce biti ispisano ... > > Jesi li ti siguran da ce to da prodje kroz kompajler? Mislim, cak i ako se > ona dvojka shvati kao pointer cija je integer vrednost 2, kompajleru > nedostaje informacija o tipu koji gadja pointer da bi mogao da adresira > pravi element niza, ciji je indeks jednak lokaciji u memoriji u koju je > loader smestio literal "ABCD"? Ili se mozda zezas? Sve je u redu. Specifikacija jezika kaže da je konstrukcija a[b] ekvivalentna sa *(a+b). Ovo se induktivno proširuje i na višedimenzonalne nizove. Time je 2["ABCD"] "ABCD"[2] = 'C' = 67.
cccc.464 postmast,
From: glisin@orao.etf.bg.ac.yu (Ivan Glisin) Subject: cccc Date: Fri, 4 Aug 1995 13:11:43 GMT WARNING!!! Pre nekoliko meseci sam primetio da Turbo C (TC) 2.00 pogresno alocira blokove u Large u Huge modelu i da brka segment:offset ukoliko je ukupno alocirani prostor veci od 64K (naravno za razlicite pointere: recimo, imate niz od deset pointera na karaktere i za svaki zakacite po 10K * 10 pointera = 100K => TC 2.00 se sludi nacisto!). Eh, juce mi covek javlja da se slicno desava i sa BC++ 2.0. Pretpostavljam da je stvar ista i sa BC++ 1.0. Ukoliko se cudite zasto vam program brljavi na TC 2.00 i na BC++ 2.0 promenite kompajler!!! Posto ja koristim K&R C pa mi je TC sasvim dovoljan, probao sam i problema nema na TC 2.01. Ne znam za BC++ 3.x ++. Problema nema ni na Microsoft C 5.0 (verujem ni na ostalim). Uzgred, verzija TC se prikaze u boksu koji se javi ukoliko nema TCCONFIG.TC fajla, a ukoliko nema boksa pokusajte da pozovete TCC i on ce ispisati verziju. Ukoliko imate TC 2.00 menjajte odmah sa TC 2.01 !!!!
cccc.465 postmast,
From: KLIMENT.ANDREEV@f108.n108.z38.setnet.setnet.co.yu (KLIMENT ANDREEV) Subject: Nova knjiga Date: Sat, 29 Jul 1995 18:07:00 PS>U izdanju Mikro Knjige priprema se naslov: PS>OBJEKTNO ORIJENTISANO PROGRAMIRANJE PS>NA JEZIKU C++ Dali znass mozzda koja cce biti cena (otprilike)? 10x Chombe KAN ___ ■ OLX 2.1 TD ■ Dragstor Maxtor. * Origin: SETNet: Struga BBS +389 96 74074 * Macedonia * (38:108/108)
cccc.466 postmast,
From: anubis@ELF.bl.ac.yu (Igor Loncarevic) Subject: password hasher (crypt()) replacement Date: Sat, 5 Aug 1995 01:32:09 GMT [ Article crossposted from sci.crypt,comp.os.linux.development ] [ Author was Cees de Groot ] [ Posted on 1 Aug 1995 23:46:09 +0200 ] Hi all, I've been working on a better password hasher for Linux, because I think standard crypt() is a kind of an anachronism for this system. I think I came up with something workable, but I would like to have the opinion of other people before I start patching half the system. The new system will have a version indicator in the first byte of the hashed password and a standard compare function; this will make implementing other (better) algorithms much easier. The basic idea was to use MD5 for quality hashing, and a very slow random number generator for bringing speed to it's knees (MD5 is far to fast in order to be useable as a password hasher). I'll post the main loop here in order to illustrate the code I have written until now: --------------------------- char * crypt_md5 (const char *key, const char *salt) { MD5_CTX ctx; unsigned char digestbuf[16]; char *resbuf, *resptr; unsigned int saltlen, keylen; unsigned long randval; int i, rounds; /* * Sanity checks. We put _some_ limits on the fun: */ if (key == NULL || salt == NULL) return NULL; saltlen = strlen (salt); keylen = strlen (key); if (keylen > 0xf000 || saltlen > 0xf000) return NULL; /* * Set-up stuff for the loops */ MD5Init (&ctx); resptr = malloc (saltlen + keylen + 10); if (resptr == NULL) return NULL; /* * Do a couple of rounds of sending data to MD5 */ for (rounds = 0; rounds < 5; rounds++) { /* * Hash password and salt */ MD5Update (&ctx, key, keylen); MD5Update (&ctx, salt, saltlen); /* * Attach salt and password to each other, and * seed the LFSR generator with it. */ sprintf (resptr, "%04X", rounds); strcat (resptr, key); strcat (resptr, salt); lfsr_seed (resptr, strlen (resptr)); /* * Hash password and salt, but now byte by byte, alternating with * random numbers from the LFSR generator. */ for (i = 0; i < keylen; i++) { MD5Update (&ctx, key + i, 1); randval = lfsr_rand (); MD5Update (&ctx, (char *) &randval, sizeof (randval)); } for (i = 0; i < saltlen; i++) { MD5Update (&ctx, salt + i, 1); randval = lfsr_rand (); MD5Update (&ctx, (char *) &randval, sizeof (randval)); } /* * Repeat for a second time, with slight differences. */ sprintf (resptr, "%04X", 9999 - rounds); strcat (resptr, salt); strcat (resptr, key); lfsr_seed (resptr, strlen (resptr)); for (i = 0; i < saltlen; i++) { MD5Update (&ctx, salt + i, 2); randval = lfsr_rand (); MD5Update (&ctx, (char *) &randval, sizeof (randval)); } for (i = 0; i < keylen; i++) { MD5Update (&ctx, key + i, 2); randval = lfsr_rand (); MD5Update (&ctx, (char *) &randval, sizeof (randval)); } } MD5Final (digestbuf, &ctx); /* * Look how long the result will be and calloc a buffer for it * 2 + the salt + the MD5 key. */ resbuf = calloc (4 + saltlen + 24, 1); if (resbuf == NULL) return NULL; /* * Fill the buffer with: length of salt, salt, MD5 digest * * For easier access, we don't compress the salt length. Note that * we store the salt length in a host-independent format. */ resbuf[0] = CRYPT_METHOD_MD5; resbuf[1] = ((saltlen & 0x000f) ) + 'A'; resbuf[2] = ((saltlen & 0x00f0) >> 4) + 'A'; resbuf[3] = ((saltlen & 0x0f00) >> 8) + 'A'; resbuf[4] = ((saltlen & 0xf000) >> 12) + 'A'; strcat (resbuf, salt); resptr = resbuf + strlen (resbuf); tobase64 (digestbuf, 16, resptr); /* Could delete two zeroes here... */ return resbuf; } ----------------- (you can get the latest version as ftp.lake.de:/homepages/s2449/passwd-0.xy.tar.gz, where xy is a version number) Comments: - MD5 is the standard implementation; I took it from PGP; - lfsr_rand is my (hopefully correct) implementation of an alternating stop-and-go combination of three LSFR's, which has the nice property of being slow (BBS would probably be an even better candidate here, but I don't know the legal status of that one). The seed function just mixes up the bits from the input a little bit and feeds the registers with them. - In this implementation, salt is a 72bit number represented in base64 notation; it can have any length but that is what my salt-generator generates. What I would like to have as feedback: A) On the algorithm: - Does this method make cryptological sense? Is my slow-down with the RNG undermining MD5, maybe ? - Tentative here is that one can simply increase the loop count in order to slow down attacks. With the current loopcount, it already performs 10 times slower than standard crypt(). But again: does it make sense, does it make the algorithm any weaker, when I increase the loopcount (I was thinking of increasing it so you need at least around a second for one hash on an average 486) ? B) On the implementation (you probably want full sources for this): - I did my best to implement a reasonable fast version of the algorithm in order to try to prove that this algorithm is inherently slow (ie., isn't vulnerable to attacks with better algorithms like fcrypt()). Are there _BIG_ optimizations I overlooked ? C) To the Linux community: - Do you care for such a new system? Do the guys who have developed stuff like login/passwd/ftpd/telnetd/... care to build this in? Thanks for any comments. If you respond through a follow-up, I would be very glad with the Cc: per mail, because my news-connections are quite flaky this time of year (I got two NNTP and one UUCP connection, none of them works :-(). If you don't have FTP access, I'll be glad to send a copy of the sources by mail (it's only 18k as gzipped, uuencoded tar. small enough to post?). And you Linux guys: please follow-up only to comp.os.linux.development if you have comments on point C). Regards Cees -- Cees de Groot, OpenLink Software <cg@bofh.lake.de> PGP26ui: 14 C4 B3 B6 97 7F CA 4F FC 7D E8 B1 AB 25 03 19 [Key on servers] -- -+- Igor Loncarevic, anubis@elf.bl.ac.yu
cccc.467 iznogud, -> #455, rrad
:: Zbog cega je C dir najneazuriraniji direktorijum na SEZAM-u? :: Ili, kada ce vec jednom da stignu nove verzije DFlat-a, :: EasyVision-a itd? I ja se pridružujem vapaju :))) BTW, pre nekog vremena je Maksa u temi razno (čini mi se) okačio jedan prilično dobar help za C/C++. Ima li šanse da se taj help prebaci u INFOPROG, pošto su tamo prilično dobro dati odgovori na većinu pitanja u ovoj konferenciji? BTW 2: Koliko često se usklađuju direktorijumi Sezama i Sezama PRO? Pre neki dan sam se prilično neprijatno iznenadio... :( (primer: Telix4Win, SuperPad...)
cccc.468 dejanr, -> #467, iznogud
>> BTW 2: Koliko često se usklađuju direktorijumi Sezama i Sezama PRO? >> Pre neki dan sam se prilično neprijatno iznenadio... :( Ne usklađuju se uopšte, osim što Bulaja ponekad prenese neki zanimljiv fajl. Gledaću da tokom sledeće nedelje ponovo prenesem kompletno stablo kataloga na test sistem, tako da će onda biti sinhronizovani.
cccc.469 mkaralic, -> #457, postmast
> Razlika izmedju svake verzije Microsoft Visual kompajlera je u MFC-u > (Mirosoft Foundation Classes). Konkretno, radi se o C++ funkcijama Da li si radio nešto više sa ovim? Uspeo sam malo da se snađem sa Help-om i našao sam neke klase CTime i CTime??? (ovde ide neka reč koja asocira na vremensku razliku). Uključio sam afx.h i stvorio objekat datog tipa, ali program nije hteo uopšte da se izlinkuje :(. Linkej javlja više grešaka >>Unresolved External<<. Inače, uključena mi je opcija MFC, ali ništa ne vredi, a što je još luđe, kada ovo podesim da da DOS EXE, javi mi da ne može da pronađe neke biblioteke. Da li je iko imao iskustva sa ovim? Bio bih zaista srećan kada bih mogao da rešim problem. Pozdrav // Mik !!!
cccc.471 postmast,
From: KLIMENT.ANDREEV@f108.n108.z38.setnet.setnet.co.yu (KLIMENT ANDREEV) Subject: cccc Date: Mon, 07 Aug 1995 14:21:00 IG>Pre nekoliko meseci sam primetio da Turbo C (TC) 2.00 pogresno IG>alocira blokove u Large u Huge modelu i da brka segment:offset IG>ukoliko je ukupno alocirani prostor veci od 64K (naravno za IG>razlicite pointere: recimo, imate niz od deset pointera na IG>karaktere i za svaki zakacite po 10K * 10 pointera = 100K => IG>TC 2.00 se sludi nacisto!). Interesantno! Ja joss ne radim u Large i Huge modelima, ali desio mi se sliccan problem. (TC2.0) Naime, dobio sam neki source koji treba da pravi prozore koji mogu da se preklapaju. Sve je bilo OK, ali ako zatvorim prozor i otvorim opet isti, umesto sadrzaja prozora dobijam na ekranu djubre. Lepo sam analizirao program i gresske nije bilo. Onda sam umesto malloc stavio calloc i sve je proradilo. Chombe KAN ___ ■ OLX 2.1 TD ■ IF X YOK 10 SURGUN 30 - T°˘§ýŕ BASIC * Origin: SETNet: Struga BBS +389 96 74074 * Macedonia * (38:108/108)
cccc.472 postmast,
From: glisin@orao.etf.bg.ac.yu (Ivan Glisin) Subject: Re: cccc Date: Thu, 10 Aug 1995 13:56:00 GMT KLIMENT ANDREEV pise: >> analizirao program i gresske nije bilo. Onda sam umesto >> malloc stavio calloc i sve je proradilo. Aha! Znaci 'malloc' je lose napisan, u tome je stvar. Svejedno, 'malloc' radi ocito dobro na TC2.01. Uzgred, simptomi koji su se pokazali kod tebe su tacno ono sto sam ja primetio: meni je snimao posle alokacije djubre na disk iako sam ja punio blok ispravnim sadrzajem, tebi je pucao djubre na ekran, a sve u pocetku izgleda da radi kako treba. To je tacno to. :-)
cccc.473 varsic,
Da li neko moze da mi da Windows.h datoteku za Borland C v2.0 ! Vlada
cccc.474 ikordic, -> #371, zormi
RE: BC vs. MSC => 2.0, exception handling...), MS ima bolju prateću biblioteku funkcija =>( MFC - Microsoft Foundation Classes). Oba zauzmu po 50-70 MB na disku =>( BC 4.5 vs. MS VC 1.5), tako da je bolje imati help i primere na CD-u. Da napomenemo da postoji jedna strašna stvar koja će ozbiljnim koderima neviđeno olakšati život. Zove se Microsoft Developers Network, periodično CD izdanje slavne (ili "slavne" ;)) kuće iz Redmonda. Sadrži kompletna uputstva za sve izdate alatke za razvoj u čitljivoj i printabilnoj formi (C, Basic, MASM, Fortran, ...), najnovije novosti po pitanju bug-lists, API dogradnje, tips 'n' tricks, totalno izkrosreferencirana, kompletne knjige ("Programing Windows", Petzold) itd. zzivotic je o pisao o starijem izdanju u "Računarima" pre nekog vremena. MS-ov, Borland-ov i Watcom-ov help je nula u poređenju sa ovime. Iako može da se koristi i uz BC, meni sasma dovoljan razlog da se prešaltam preko... Nemam puno OWL koda, a dosta ti govori o odnosu firme prema kupcu i tome kako će ga ubuduće podržavati.
cccc.475 iznogud, -> #474, ikordic
Re: Re: MS vs BC :: Iako može da se koristi i uz BC, meni sasma dovoljan razlog da se :: prešaltam preko... Nemam puno OWL koda, a dosta ti govori o odnosu firme :: prema kupcu i tome kako će ga ubuduće podržavati. Izgleda da MS i Borland različito shvataju odnos prema kupcu. Sa jedne strane je Borland, koji nudi savršeno ušminkane i manje zahtevne programe, uz cenu da ispod te šminke nije uvek najsjajnija 'mašina' (engine). Sa druge strane je MS, čiji programi zahtevaju enormne resurse (ko ima para za mašinu na kojoj MSVC 'leti', verovatno ne živi od programiranja ;))), ali je kasniji odnos prema kupcu bez greške. BTW, kad smo već kod biblioteka, ima li uopšte nekog ko radi sa MFC?? OWL poklonika još i može da se 'nahvata' ;)) a rad bih bio da čujem neke uporedne utiske.
cccc.476 szdravko,
szdravko Interesuje me jedan problem. U dodatku racunara "Moja skola C-a" Z. Zivotic navodi da je pogodno globalno vidljive promenljive grupisati u header file i ukljucivati ih svuda gde treba da su vidljivi. Medjutim, rekose mi neke kolege da se negde u Stroustrup-u moze procitati da ovo i nije najbolja praksa. Sta je od svega ovoga tacno? Inace, mislim da bi bilo korisno da izadje nastavak Zivoticeve skole
cccc.477 pyramid, -> #476, szdravko
>> Interesuje me jedan problem. U dodatku racunara "Moja skola C-a" Z. >> Zivotic navodi da je pogodno globalno vidljive promenljive grupisati u >> header file i ukljucivati ih svuda gde treba da su vidljivi. Medjutim, >> rekose mi neke kolege da se negde u Stroustrup-u moze procitati da ovo >> i nije najbolja praksa. Sta je Mislim da je najveci problem sto Zivotic pise o C-u, a Stroustrup o C++ jeziku. U principu, u C-u se skoro uvek globalne promenljive grupisu u header file (primer je standardna C biblioteka i standardni header-i), a logika objektnog programiranja izbegava globalne promanljive...
cccc.478 janko, -> #477, pyramid
>>> Interesuje me jedan problem. U dodatku racunara "Moja >>> skola C-a" Z. Zivotic navodi da je pogodno globalno >>> vidljive promenljive grupisati u header file i >>> ukljucivati ih svuda gde treba da su vidljivi. Medjutim, >>> rekose mi neke kolege da se negde u Stroustrup-u moze >>> procitati da ovo i nije najbolja praksa. Sta je > Mislim da je najveci problem sto Zivotic pise o C-u, a > Stroustrup o C++ jeziku. U principu, u C-u se skoro uvek > globalne promenljive grupisu u header file (primer je > standardna C biblioteka i standardni header-i), a logika > objektnog programiranja izbegava globalne promanljive... Ne baš... Nekada su se pravili mali programi, i bila je praksa da se sve što treba svi da vide strpa u isti heder. Međutim, to obavezno dovodi do izuzetno velike međuzavisnosti modula. Cilj je imati module koji se, jednom napisani, mogu iskoristiti i u drugom programu BEZ IZMENA. To se postiže time što u svakom modulu ili, čak, grupi modula, treba uočiti funkcije INTERFEJSA i razlikovati ih od onih implementacije. Samo INTERFEJS modula prema drugim modulima treba da ide u heder. Dakle umesto jednostavnog koncepta "heder za sve" treba razraditi podelu nadležnosti delova sorsa tako da niko ne izlaže javnosti ono što javnost ne mora da zna. To važi i za C i za C++, kada neko želi da kvalitetno programira.
cccc.479 postmast,
From: vvlada@orao.etf.bg.ac.yu (Vladimir Vucinic) Subject: Re: Nova knjiga Date: Wed, 16 Aug 1995 21:53:36 GMT ivica@galeb.etf.bg.ac.yu (Ivica Nikolic) wrote: >>> U izdanju Mikro Knjige priprema se naslov: >>> >>> OBJEKTNO ORIJENTISANO PROGRAMIRANJE >>> NA JEZIKU C++ >>> >>> od osnovnih pojmova do naprednih tehnika >>> >>> Dragan Milicev >>> >>> 480str. Format 23,5x16,5cm >>> Uz rizik da ne polozim nekoliko ispita, ja mislim da je knjiga prilicno 'bliska' Stroustrup-ovom II izdanju knjige Programming language C++. Dobro je sto je knjiga na nasem jeziku, takve knjige kod nas jos nema, to je svakako pozitivno. Uostalom, kod C++ i ne moze nesto novo da se izmisli. Vladimir Vucinic ETF Beograd vvlada@orao.etf.bg.ac.yu
cccc.480 szdravko,
Zahvaljujem se kolegama Pyramid-u i Janku Stamenovic-u na odgovorima na moje pitanje. Uzgred, sta biste preporucili od literare za++?
cccc.481 evlad, -> #464, postmast
TO: glisin@orao.etf.bg.ac.yu (Ivan Glisin) <> Uzgred, verzija TC se prikaze u boksu koji se javi ukoliko nema <> TCCONFIG.TC fajla, a ukoliko nema boksa pokusajte da pozovete TCC <> i on ce ispisati verziju. Ukoliko imate TC 2.00 menjajte odmah <> sa TC 2.01 !!!! Za TC 2.0 Shift+F10 daje box sa verzijom :)
cccc.482 iznogud, -> #480, szdravko
:: Uzgred, sta biste preporucili od literare za++? Ako znaš engleski, 'The C++ Programming Language - second edition', od samog autora jezika. Za razliku od drugih knjiga o C++-u koje sam imao u rukama, ova obrađuje i stvari koje su tek sada uvrštene u ANSI/ISO standard (recimo, namespaces i sl.). Nije zanemarljiv ni deo o objektnom dizajnu u C++-u. Takođe, knjiga u sebe uključuje i čuveni ARM kao dodatak.
cccc.483 szdravko,
:: Iznogud-ov odgovor Da li je to ona knjiga sa Margaret *? Da li je mogla nekako da se nabavi kod Sta mislis o knjizi Stanley Lipman-a? Da li postoji neka knjiga koja daje primere primene na tehnicke sisteme. Meni C++ izmedju ostalog treba da radim neke simulacije u okviru doktorata koji radim na Masinskom faksu. Bilo bi pogodno da mogu da utvrdim kako su dristili C++ u takvom kontekstu (nije vazno u kojoj oblasti tehnike). Hvala na odgovoru!
cccc.484 pyramid, -> #478, janko
>> Nekada su se pravili mali programi, i bila je praksa da se sve sto treba >> svi da vide strpa u isti heder. >> >> Medutim, to obavezno dovodi do izuzetno velike meduzavisnosti modula. Ko kaze da se radi o malim programima? Zasto bi ukljucivanjem externe definicije neke globalne promenljive iz drugog modula javila zavisnost medju modulima? >> ih od onih implementacije. Samo INTERFEJS modula prema drugim modulima >> treba da ide u heder. Dakle umesto jednostavnog koncepta "heder za sve" >> treba razraditi podelu nadleznosti delova sorsa tako da niko ne izlaze >> javnosti ono sto javnost ne mora da zna. "heder za sve"? Ako iz nekog modula hoces da iskoristis _globalnu promenljivu_ (a to s vremena na vreme _moras_ u C-u da uradis) ukljucices njegov header file. Tako je i nastalo nesto sto se zove header file. U tom file-u se nalaze sve _public_ definicije - znaci javne - koje jedan modul zeli da ponudi drugim modulima. To ukljucuje funkcije, enum-e, konstante i _globalne promenljive_. Podvlacim ovo "globalne promenljive" jer se samo njihovim izbacivanjem moze smanjiti medjuzavisnost koda, ne samo od ostalih modula tog programa, vec i ostalih koji rade na OS (kod pravih multitasking sistema)... Ovo sto si napisao je, sa druge strane, tacno i u potpunosti se slazem, ali to je i bio razlog za nastajanje Cpp-a...
cccc.485 maksa, -> #483, szdravko
>> Da li postoji neka knjiga koja daje primere primene na tehnicke >> sisteme. Meni C++ izmedju ostalog treba da radim neke simulacije >> u okviru doktorata koji radim na Masinskom faksu. Bilo bi pogodno >> da mogu da utvrdim kako su dristili C++ u takvom kontekstu (nije >> vazno u kojoj oblasti tehnike). Postoji, u knjizi Roberta Lafora ima primer za water-distribution sistem. Može da posluži kao ideja/model za druge aplikacije koje imaju veze sa kontrolom procesa, na pr. hidrauličke sisteme u mašinstvu, i sl.
cccc.486 iznogud, -> #483, szdravko
:: Da li je to ona knjiga sa Margaret *? Da li je mogla nekako da se nabavi Ne, ta Margaret je kol'ko se se sećam (mrzi me sada da preturam ;) ) bila jedan od koautora ARM-a, tj. reference jezika koja je, praktično, više bila namenjena piscima kompajlera nego bilo kom drugom te jako teška za čitanje. 'The C++ Programming Language - second edition' je, kako mu i ime kaže, dopuna prvog izdanja čiji se prevod pojavio i kod nas, u izdanju Mikro Knjige. Mnoge stvari su u drugom izdanju izmenjene i osavremenjene (između ostalog i citati ispred svakog poglavlja ;) ), a, kao što rekoh, uključuje i neke stvari koje se tek sada pojavljuju u ISO C++. Za mašinstvo ne znam, bilo bi lepo da se javi neko sa MF. žuo sam da se tamo dosta radi u C++.
cccc.487 postmast,
From: smilic@fon (Sasa Milic) Subject: Re: cccc Date: Fri, 18 Aug 1995 08:49:01 GMT Zdravko Stojanovic (szdravko@sezam.UUCP) wrote: : Zahvaljujem se kolegama Pyramid-u i Janku Stamenovic-u na odgovorima na moje : pitanje. Uzgred, sta biste preporucili od literare za++? Pokusaj negde (fon, ubbg, ...) da pronadjes 'FAQ about C++' (ima i za C). Sasa
cccc.488 postmast,
From: damir@osmeh.fon.bg.ac.yu (Damir Barjaktarevic) Subject: Re: Nova knjiga Date: Fri, 18 Aug 1995 16:32:42 GMT > U izdanju Mikro Knjige priprema se naslov: > > OBJEKTNO ORIJENTISANO PROGRAMIRANJE > NA JEZIKU C++ > > od osnovnih pojmova do naprednih tehnika > > Dragan Milicev > > 480str. Format 23,5x16,5cm > A jel su u knjizi objasnjeni izuzeci, rtti i sabloni(templates)? Vozdra, Damir -- damir@unitop.elfak.ni.ac.yu
cccc.489 janko, -> #484, pyramid
>>> Nekada su se pravili mali programi, i bila je praksa da >>> se sve sto treba svi da vide strpa u isti heder. >>> >>> Medutim, to obavezno dovodi do izuzetno velike > meduzavisnosti modula. > > Ko kaze da se radi o malim programima? Zasto bi > ukljucivanjem externe definicije neke globalne promenljive > iz drugog modula javila zavisnost medju modulima? Nisi razumeo šta sam pisao. Ja jedno, ti drugo. Da li si ikada gledao tuđe velike C programe? Koliko veliki C program si sam napisao? Koliko je imao linija, a koliko heder fajlova? Kako su bili organizovani heder fajlovi? Ovo pitam samo da bih znao koliko detaljno da objašnjavam, pošto očigledno nisi shvatio šta sam hteo da kažem... pogotovu mogu imati dobar uvod u tvom odgovoru na posledenje pitanje...
cccc.490 pyramid, -> #489, janko
>> Nisi razumeo sta sam pisao. Ja jedno, ti drugo. Da li si ikada gledao >> tude velike C programe? Koliko veliki C program si sam napisao? Koliko >> je imao linija, a koliko heder fajlova? Kako su bili organizovani heder >> fajlovi? Ovo pitam samo da bih znao koliko detaljno da objasnjavam, >> posto ocigledno nisi shvatio sta sam hteo da kazem... pogotovu mogu >> imati dobar uvod u tvom odgovoru na posledenje pitanje... Mozda stvarno nisam razumeo. Koliko sam ja razumeo, hteo si da kazes da je pogresno ukljucivati definicije globalnih promenljivih u header file jer kod velikih programa to dovodi do medjuzavisnosti modula. Moj odgovor je trebalo razumeti: Da, dolazi do medjuzavisnosti, ali to nije posledica ukljucivanja definicije globalne promenljive u header file vec samo postojanje globalnih promenljivih. Globalna promenljiva je po samoj svojoj definiciji (pa i imenu) - globalna, sto znaci da se koristi medju vise funkcija koje mogu biti u vise razlicitih modula (K&R su zamislili da je svaka funkcija jedan modul, sto znaci da svaka funkcija ukljucuje odredjeni header file). Sama namena header file-ova je da definise nesto sto je u nekom drugom modulu deklarisano. Zato mi veoma ruzno zvuci pominjati male i velike programe, jer ja ne pravim razliku izmedju manjih i vecih programa. Samo koriscenje funkcija standardne biblioteke pretvara mali program u veliki jer time ukljucujem funkcije i _globalne_ promenljive stdlib-a koje te funkcije koriste. Ako ovako nesto nazivas medjuzavisnosti (a sa tim se ne bih slozio prvo zato sto rec medjuzavisnost znaci da su oba subjekta u radnji zavisna medju sobom) onda je tvoja konstatacija tacna i to ne sporim (ako sam je, naravno, ja dobro shvatio). Ali sa druge strane moj programcic je zavistan od standardne biblioteke, ali ona nikako nije zavisna od mog programa. U projektovanju programa, ja UVEK gledam na zavisnost modula po hijerarhiji, sto znaci da zavisnoscu ne mogu nazvati kada jedan modul viseg hijerarhiskog nivoa (kao sto je moj program u prethodnom primeru) koristi _BILO KOJI_ resurs modula nizeg hijerarhijskog nivoa (u primeru standardna biblioteka). Ne znam da li C++ objekte mozda nazivas medjuzavisnim. Sama sintaksa i nacin pisanja objektno orjentisanih programa te navodi da stvaras zavisnost nekog objekta viseg hijerarhijskog nivoa od objekta cije je osobine nasledio. Cak sta vise, sama rec "naslediti" mene asocira na zavisnost. Najveci program koji sam sam napisao u C-u bio je sastavljen od 106 .c file-ova, 107 header file-ova (svaki .c ima svoj .h + defs.h sa standardnim definicijama). Ne znam za broj linija, to sam davno prestao da brojim...
cccc.491 janko, -> #490, pyramid
>>>>> Nekada su se pravili mali programi, i bila je praksa da >>>>> se sve sto treba svi da vide strpa u isti heder. >>>>> >>>>> Medutim, to obavezno dovodi do izuzetno velike >>> meduzavisnosti modula. >>> >>> Ko kaze da se radi o malim programima? Zasto bi >>> ukljucivanjem externe definicije neke globalne >>> promenljive iz drugog modula javila zavisnost medju >> modulima? >> >> Nisi razumeo šta sam pisao. > > Mozda stvarno nisam razumeo. Koliko sam ja razumeo, hteo > si da kazes da je pogresno ukljucivati definicije > globalnih promenljivih u header file jer kod velikih > programa to dovodi do medjuzavisnosti modula. Kao što se vidi, ja nisam govorio o "definicijama globalnih promenljivih". Pričao sam o principu "jedan heder za sve". Recimo, aplikacija se zve "drn", onda imaš "drn.h" i recimo dvadeset ".c" Ovo, opet da ponovim, vodi do toga da svaki ".c" može da iskoristi bilo šta iz bilo kog drugog ".c". Kod malog programa, to nije kritično. Kod velikih, to znači da osim "podele na funkcije" nije urađena nikakva globalnija podela nadležnosti delova programa. Sličan efekat postižu i programeri i dizajneri programa i danas, čak i kada ne naprave baš "jedan .h". To postižu na sledeći način: Unutar svagog .h ugrade seriju "include" naredbi, a unutar, recimo, prvi.c urade samo "include prvi.h". Ti si dao ilustraciju svog programa: 100 .c, 100 .h. To je zdraviji koncept, no... Ne znam složenost problema koji se rešava u programu, ali se, za neke probleme, u praksi događa da i to nije dovoljno dobar dizajn. Recimo da je unutar .c neki složeni podsistem, jedan od elemenata celog programa. Taj .c je blisko vezan za još dva .c, a neke njegove servise koristi veći deo aplikacicije (još pedeset .c). Očigledno je da ona dva blisko vezana .c treba da znaju puno više o podsistemu, od onih ostalih pedeset .c Ako si za podsistem napravio samo jedan .h, onda će i onih pedeset .c imati na raspolaganju servise koje ne bi smeli da imaju. "Ali ja ih nigde neću koristiti u onih pedeset .c" ćeš možda reći. Ako već nećeš, zašto se to onda ne bi videlo iz samog koda? Jer sva pravila koja su upisana kao "komentar" se lako krše. Cilj je program koncipirati tako da pri prevođenju budu otkrivene SVE bitne greške, pa čak i ovakve -- onemogućiti ono što po prirodi stvari ne sme da se dogodi. U dobro dizajniranom programu, makar on bio napisan i u C-u, mora da se prepoznaje da je dizajner mislio o INTERFEJSIMA, IMPLEMENTACIJAMA i PODSISTEMIMA. To što jezik nema takve jezičke konstrukcije ne sme da bude opravdanje za dizajnera da izbegne da uopšte razmišlja o tim konceptima. Ali, opet da ponovim, sve ovo ne mora da se radi kada je program dovoljno mali. Mada je i tada korisno, jer se tako povećava šansa da će u nekom drugom programu moći da se iskoristi neki čitav PODSISTEM iz onog prvog, bez izmene u tekstu celog podsistema. > U projektovanju > programa, ja UVEK gledam na zavisnost modula po > hijerarhiji, sto znaci da zavisnoscu ne mogu nazvati kada > jedan modul viseg hijerarhiskog nivoa (kao sto je moj > program u prethodnom primeru) koristi _BILO KOJI_ resurs > modula nizeg hijerarhijskog nivoa (u primeru standardna > biblioteka). Vidiš, problem i jeste taj, da ne možeš ni svoj program uvek gledati kao jedan jedini hijerarhijski nivo, pogotovu ako je program dovoljno veliki. Da li smo se sada razumeli?
cccc.492 madamovic, -> #385, postmast
> From: arhimedčlucid.junis.ni.ac.yu (Bogdan Kecman) > VIVA MODULA 2 (M3 mi se ne svidja) Ma modula-x mi se ne sviđa, čim sam saznao da se "raspoloživi kompajler za modulu-3 može naći (u obliku C sorsa) na ftp*******" VIVA C(++).
cccc.493 pyramid, -> #491, janko
>> Kao sto se vidi, ja nisam govorio o "definicijama globalnih >> promenljivih". Pricao sam o principu "jedan heder za sve". Recimo, OK. Tu si upravu. Oduvek sam se jezio kad vidim all.h koji ukljuci sve ostale header-e. Doduse, ne znam odakle sad diskusija o "jednom header-u za sve"? Koliko se secam, sve je ovo pocelo pitanjem - da li je pametno ukljucivati definicije globalnih promenljivih u header file. >> Slican efekat postizu i programeri i dizajneri programa i danas, cak i >> kada ne naprave bas "jedan .h". To postizu na sledeci nacin: Unutar >> svagog .h ugrade seriju "include" naredbi, a unutar, recimo, prvi.c >> urade samo "include prvi.h". Upravo sam ovo pomenuo. Jedna stvarno idiotska stvar koja se sasvim kosi sa samom namenom header file-ova. >> Ti si dao ilustraciju svog programa: 100 .c, 100 .h. To je zdraviji >> koncept, no... Ne znam slozenost problema koji se resava u programu, ali >> se, za neke probleme, u praksi dogada da i to nije dovoljno dobar >> dizajn. ? Kada se dogadja da i to nije dovoljno dobar dizajn? >> Recimo da je unutar .c neki slozeni podsistem, jedan od elemenata celog >> programa. Taj .c je blisko vezan za jos dva .c, a neke njegove servise >> koristi veci deo aplikacicije (jos pedeset .c). Ocigledno je da ona >> dva blisko vezana .c treba da znaju puno vise o podsistemu, od onih >> ostalih pedeset .c Ako si za podsistem napravio samo jedan .h, onda >> ce i onih pedeset .c imati na raspolaganju servise koje ne bi smeli da Velika greska u projektovanju! To se u (po meni) dobro projektovanom sistemu ne moze dogoditi... Zasto? Zato stoservise onog prvog .c file-a (.c najnizeg nivoa) NE MOGU koristiti jos 50 .c visokog nivoa. Oni bi mogli koristiti neki treci .c koji je samo veza izmedju 1. i npr. 3. hijerarhijskog nivoa. >> imaju. "Ali ja ih nigde necu koristiti u onih pedeset .c" ces mozda >> reci. Ako vec neces, zasto se to onda ne bi videlo iz samog koda? Jer >> sva pravila koja su upisana kao "komentar" se lako krse. Cilj je program Ako bih krsio takve stvari, mogao bih to bez obzira na to kako su uredjeni .h file-ovi (jednostavno lokalno definises externu promenljivu)... >> sva pravila koja su upisana kao "komentar" se lako krse. Cilj je program >> koncipirati tako da pri prevodenju budu otkrivene SVE bitne greske, pa Tako je, ali ovoga puta govoris o programu, a ne o header file-ovima... Nikada ne mozes otkriti sve bitne greske. Ja sam, doduse, mislio da pricamo o organizaciji .h file-ova, a time se samo otkrivaju neke manje greske koje nastaju usled npr. kreiranja promenljivih istog imena i sl. >> U dobro dizajniranom programu, makar on bio napisan i u C-u, mora da se >> prepoznaje da je dizajner mislio o INTERFEJSIMA, IMPLEMENTACIJAMA i >> PODSISTEMIMA. To sto jezik nema takve jezicke konstrukcije ne sme da >> bude opravdanje za dizajnera da izbegne da uopste razmislja o tim >> konceptima. Ako mislis na jezicke konstrukcije unit, implementation i interface iz pascala, C ima te konstrukcije i zovu se: library, object & header files. Slozio bih se sa "podsistemi" i "interfejsi", ali samo u smislu programskog projekta, a ne jezickih konstrukcija. Tu bi recimo podsistem bio grupa funkcija (struktura, promenljivih itd.) koje vrse odredjenu namenu, a interfejsi - funkcije (strukture itd.) za vezu medju podsistemima (naveo sam primer ranije - pravi se .c file koji bi predstavljao vezu izmedju hijerarhijskih nivoa)... >> Vidis, problem i jeste taj, da ne mozes ni svoj program uvek gledati kao >> jedan jedini hijerarhijski nivo, pogotovu ako je program dovoljno >> veliki. To nikada nisam pomenuo (da je moj program jedan hijerarhijski nivo). Jedan PROBLEM, u vecini slucajeva jeste, mada se on opet moze deliti na vise problema - hijerarhijskih nivoa... Nebojsa
cccc.494 postmast,
From: poki@efnis.elfak.ni.ac.yu (Dragoljub Pokrajac) Subject: C vs. FORTRAN Date: Wed, 23 Aug 1995 23:48:22 GMT Ima li neko nekakve podatke o uporednom testiranju C-a i FORTRANA na numerici Hvala
cccc.495 postmast,
From: Ilija.Djorgoski@f108.n108.z38.setnet.setnet.co.yu (Ilija Djorgoski) Subject: Turbo C 4.5 Date: Mon, 21 Aug 1995 16:15:59 NEW ! NEW ! NEW ! NEW ! NEW ! NEW ! NEW ! NEW ! NEW ! NEW ! NEW ! NEW ! NEW ! Izasao je novi Turbo C kompjajler ver. 4.5 Ima li neko ovaj kompjaler ? -+- OLMS 2.5 UNREG * Origin: SETNet: Struga BBS +389 96 74074 * Macedonia * (38:108/108)
cccc.496 postmast,
From: Aleksandar.Glumac@f119.n111.z38.setnet.setnet.co.yu (Aleksandar Glumac) Subject: obj Date: Tue, 22 Aug 1995 19:33:03 Hi. Posto pojedine f-je za grafiku nerade u modovima sa 256 boja, mislio sam da izvadim iz graphics.lib obj fajl koji sadrzi tu f-ju i da je izmenim. Mene zanima da li to moze i kako da dobijem spisak svih .obj u biblioteci ? ĐŠč█ Pozdrav, Ace B) █čŠĐ--- * Origin: ECSTASY BBS * Indjija * 022 53-884 * SETNet: (38:111/119)
cccc.497 iznogud, -> #495, postmast
:: Izasao je novi Turbo C kompjajler ver. 4.5 Ima li neko ovaj kompjaler ? Borland je odavno prestao da priozvodi C 'kompjajlere' ;), i prebacio se na C++ (kao i svi ostali proizvođači softvera, uostalom). A BC++ 4.5 je izašao već odavno. Na šta konkretno misliš?
cccc.498 sikima, -> #497, iznogud
> Turbo C 4.5 Covek je u pravu.U PC magazinu video sam reklamu za Turbo C 4.5. Koja je razlika u odnosu na Borland C++ 4.5 stvarno ne znam. Puno pozdrava od Sikime
cccc.499 janko, -> #493, pyramid
>>> Recimo da je unutar .c neki slozeni podsistem, jedan od >>> elemenata celog programa. Taj .c je blisko vezan za jos >>> dva .c, a neke njegove servise koristi veci deo >>> aplikacicije (jos pedeset .c). Ocigledno je da ona dva >>> blisko vezana .c treba da znaju puno vise o podsistemu, >>> od onih ostalih pedeset .c Ako si za podsistem napravio >>> samo jedan .h, onda ce i onih pedeset .c imati na > raspolaganju servise koje ne bi smeli da > > Velika greska u projektovanju! To se u (po meni) dobro > projektovanom sistemu ne moze dogoditi... Zasto? Zato > stoservise onog prvog .c file-a (.c najnizeg nivoa) NE > MOGU koristiti jos 50 .c visokog nivoa. Oni bi mogli > koristiti neki treci .c koji je samo veza izmedju 1. i > npr. 3. hijerarhijskog nivoa. Otkud ti sad treći nivo? >>> Vidis, problem i jeste taj, da ne mozes ni svoj program >>> uvek gledati kao jedan jedini hijerarhijski nivo, >>> pogotovu ako je program dovoljno veliki. > > To nikada nisam pomenuo (da je moj program jedan > hijerarhijski nivo). Jedan PROBLEM, u vecini slucajeva > jeste, mada se on opet moze deliti na vise problema - > hijerarhijskih nivoa... Normalno. >>> Ti si dao ilustraciju svog programa: 100 .c, 100 .h. To >>> je zdraviji koncept, no... Ne znam slozenost problema >>> koji se resava u programu, ali se, za neke probleme, u >>> praksi dogada da i to nije dovoljno dobar dizajn. > > ? Kada se dogadja da i to nije dovoljno dobar dizajn? Sam si odgovorio. :) Zašto bi jedan modul imao samo jedan interfejs, ako je za njega prirodno da ih ima, recimo, dva? Razmišljaj malo šire. > header-e. Doduse, ne znam odakle sad diskusija o "jednom > header-u za sve"? Pa na to si mi replicirao, ja ni o čemu drugom nisam ni pisao, što sam ti DVAPUT citirao, a ti nisi ni primetio. :(
cccc.500 janko, -> #494, postmast
> Ima li neko nekakve podatke o uporednom testiranju C-a i > FORTRANA na numerici C nema rad sa kompleksnim brojevima. C++ ima. Treba njih porediti.
cccc.501 pyramid, -> #499, janko
>> >>> Recimo da je unutar .c neki slozeni podsistem, jedan od >> >>> elemenata celog programa. Taj .c je blisko vezan za jos >> >>> dva .c, a neke njegove servise koristi veci deo >> >>> aplikacicije (jos pedeset .c). Ocigledno je da ona dva >> > Velika greska u projektovanju! To se u (po meni) dobro >> Otkud ti sad treci nivo? Treci (cetvrti, peti itd.) nivo su onih "pedeset .c" file-ova. Prvi nivo bi bio "slozeni podsistem" koji bi po meni morao da bude razbijen na dva hijerarhijska nivoa (prvi i drugi za vezu), a drugi nivo su "dva .c" file-a sa kojima je "slozeni podsistem blisko vezan". >> >>> Ti si dao ilustraciju svog programa: 100 .c, 100 .h. To >> >>> je zdraviji koncept, no... Ne znam slozenost problema >> > >> > ? Kada se dogadja da i to nije dovoljno dobar dizajn? >> Sam si odgovorio. :) Zasto bi jedan modul imao samo jedan interfejs, ako >> je za njega prirodno da ih ima, recimo, dva? Razmisljaj malo sire. Podrzaumevao sam da se misli na organizaciju header file-ova. Tacnije, ako bi trebalo da postoje dva interfejsa, postojalo bi dva .c file-a, kao i dva .h file-a (koji bi cinili interfejs (vezni modul))... Tako bi opet dobili 102 .c i 102 .h file-a... Nebojsa
cccc.502 szdravko,
Zahvaljujem se kolegama koji su poslali odgovore na moja pitanja i ujedno izvinjavam sto se pre nisam javio (bio sam na odmoru). Sto se tice MAKSA-inog odgovora, sjajno! Ja se upravo bavim hidraulickim sistemima. Gde bi Lafor-ova knjiga mogla da se nabavi? Sto se IZNOGUD-ovog odgovora rtice, nazalost mislim da se pored mene C++ na Masincu bave jos samo 2-3 coveka (Sasa Markovic, koji povremeno pise za Racunare i Mateja Opacic, koji se bavi neuralnim mrezama, kao i kolege sa Katedre za Matematiku, ali su njihove oblasti interesovanja drugacije od moje). Sto se tice pitanja o poredjenju C i FORTRAN-a, koliko ja znam time se na mom faksu bavio Dr N. Mladenovic, koji je obicno dobijao rezultate da je FORTRAN brzi za oko 10-15% u numerici (FORTRAN 5.1 vs. MSC , ali ne pretenduje na to da se radilo o BENCHMARK testovima - samo o onome sto je njemu bilo konkretno potrebno. Mislim da poredjenje ima smia samo ako se resavaju problemi "ciste" numerike. U problemima kojima se sada bavim FORTRAN bas nije prihvatljiv zbog jer se u simulacijama gubi predstava o tome sta se desava - samo objektno programiranje tu moze da pomogne, kako se programerskog stanovista, tako i sa stanovista razumevanja fizickog proce. Cak i kada bi FORTRAN bio brzi 100% (sto sigurno nije), u takvim situacijama ga nije smisleno primenjivati (nazalost, sam sam to probao).
cccc.503 maksa, -> #502, szdravko
>> Sto se tice MAKSA-inog odgovora, sjajno! Ja se upravo bavim >> hidraulickim sistemima. Gde bi Lafor-ova knjiga mogla da se >> nabavi? Ne verujem da je kod nas negde ima u prodaji (eventualno da probaš kod CET-a, no oni deru tako bezobrazno da ja kod njih ne bi ni kokice kupio ;). Od mene možeš uvek da je dobiješ na kopiranje. Kad poželiš, javi se mailom.
cccc.504 rrad,
Treba mi mala pomoc. Pre izvesnog vremena naleteo sam u nekoj od interapt lista ű Hna opise poziva interapta za semafore ispod Novela, ali sada ne mogu iste da iskopam. Da li bi neko bio ljubazan, ako mu je pri ruci da mi okaci to ovde ili na majl. Pozdrav, RRadovanovic
cccc.505 postmast,
From: Mladen.Adamovic@f135.n135.z38.setnet.setnet.co.yu (Mladen Adamovic) Subject: Re: Cccc Date: Sat, 02 Sep 1995 12:22:26 -+=+- Zoran Rilak rece : -+=+- ZR> From: zoran.rilak@rstones.durlan.co.yu (Zoran Rilak) ZR> manje vaznog u datom momentu). Ako se radi o implementacijama jezika, ZR> opet je FORTRAN superiorniji zbog istog razloga: njegove ZR> "promatematicke" orijentisanosti. Ne, podatke o testiranju nemam ;) Hm, ... ja bih rekao da bi C trebao da ga sije, jer je C jezik srednjeg nivoa, koji ima sposobnost da se spusti do najnizeg nivoa, i takodjer koji se koristi za sistemsko programiranje. Kao jezik koji se koristi za sistemsko programiranje, smesno je da bude u matematickim operacijama sporiji od Fortrana... Pozdrav, Mladen Adamovic (adamm@elf.bl.ac.yu). ... MA> Obavezan si da ukrades ovaj TAG. * Origin: Sveti Sava BBS Prijedor 079 11 629 SETNet: (38:135/135)
cccc.506 postmast,
From: ivica@galeb.etf.bg.ac.yu (Ivica Nikolic) Subject: Re: Paradox Engine Bug! Date: Mon, 4 Sep 1995 12:14:47 GMT Riste Panovski je napisao: >> Neko vreme radim sa PXEngine + BC++ 3.1 i danas sam otkrio da aplikacija >> na koju radim mesec dana ne radi svakog 31-vog u mesecu. >> Posle nekoliko sata singl'stepovanja sorsom otkrio sam da je problem u >> PX funkciji PXDateEncode(); >> Koju verziju Engine-a koristis? Po BBS-ovima moze da se nadje bug-fix za verziju 3.0, novi LIB-ovi i DLL-ovi sa verzijom 3.01 (sve to bas i nije tako novo, ti update-ovi su iz marta '93.) -- I only dream in infrared
cccc.507 postmast,
From: ivica@galeb.etf.bg.ac.yu (Ivica Nikolic) Subject: Re: Paradox Engine Bug! Date: Mon, 4 Sep 1995 12:17:44 GMT Riste Panovski je napisao: >> >> Neko vreme radim sa PXEngine + BC++ 3.1 i danas sam otkrio da aplikacija >> na koju radim mesec dana ne radi svakog 31-vog u mesecu. >> Posle nekoliko sata singl'stepovanja sorsom otkrio sam da je problem u > PX funkciji PXDateEncode(); >> Koju verziju Engine-a koristis? Po BBS-ovima moze da se nadje update sa verzije 3.0 na 3.01, koji bi trebalo da ima sredjene neke bagove. -- Integer out of range
cccc.508 postmast,
From: glisin@orao.etf.bg.ac.yu (Ivan Glisin) Subject: Re: cccc Date: Sun, 27 Aug 1995 20:29:32 GMT Janko Stamenovic pise: >> C nema rad sa kompleksnim brojevima. C++ ima. Treba njih porediti. Ne razumem? Shvatam da se radi o operator-overloading za tipove complex koji se uvedu naknadno, kao i overload na kraju krajeva, ali zasto bi to bilo presudno u komparaciji FORTRAN i C jezika? Kompleksni brojevi na kraju krajeva mogu da se naprave i u C-u (i ima takvih biblioteka) pa ne vidim nikakvu prednost C++ jezika u tom slucaju. Covek pita sta mu bolje resava problem, a da li se resenje pise R = A*B r := a*b; r = mul (a, b); (setq r (times a b)) to ga verovatno ne interesuje, jer pitanje nije bilo sta od biblioteka koji jezik ima, nego koji je bolji sa numerikom. Ne u smislu da li je ovaj ili onaj jezik 1-1 svodljiv na neki drugi, nego u smislu numericke preciznosti rada sa brojevima u pokretnom zarezu (greske kod rada sa skupom racionalnih brojeva koji treba da zamene realne). Tu je FORTRAN i dalje #1, i sto je najlepse, medjusobno su kompatibilni po pitanju rezultata jer postoji jasan standard za implementaciju numerike jezika.
cccc.509 postmast,
From: milos.tomic@shadow.herkules.co.yu (MILOS TOMIC) Subject: Prinf() Date: Tue, 25 Jul 95 01:21:00 +0100 Da li neko zna kako se prosledjuju podaci printf funkciji, odnosno kako se ista moze pozvati iz asemblera recimo da odstampa float. Milos ... Back up my hard disk? I can't find the reverse switch! 2.12
cccc.510 postmast,
From: Riste.Panovski@f132.n108.z38.setnet.setnet.co.yu (Riste Panovski) Subject: Paradox Engine Bug! Date: Fri, 01 Sep 1995 01:51:07 Neko vreme radim sa PXEngine + BC++ 3.1 i danas sam otkrio da aplikacija na koju radim mesec dana ne radi svakog 31-vog u mesecu. Posle nekoliko sata singl'stepovanja sorsom otkrio sam da je problem u PX funkciji PXDateEncode(); Originalna dekalracija je: // encodes a date value to a long value in Paradox format PXFUNC PXDateEncode( int month, // month value to encode int day, // date value to encode int year, // year value to encode TDATE far *adate); // encoded date value Ova funkcija daje sasvim blesave rezultate za svakog 31-vog u mesecu. Totalno ssasavo, zna li neko u ccemu je problem ? I ako zna, ccare je ? :) Unapred hvala, PaNtaRiSTo -+- OLMS 2.5 UNREG * Origin: SETNet: ĆMemory Master BBS +389/91-164-877ž SKOPJE (38:108/132)
cccc.511 postmast,
From: Petar.Djukic@f123.n103.z38.setnet.setnet.co.yu (Petar Djukic) Subject: Find Date: Thu, 31 Aug 1995 06:26:11 Jel nije tesko nekom da napise prg u C ili C++ -u koji pretrazuje datoteku i ispituje koliko se puta string pojavljuje u datoteci npr c:\trazi a.txt racunari Hvala PeTaR ... Drop your carrier ... we have you surrounded! ___ ■■ANGEL■■/QWK v2.12 * Origin: HELLAS BBS (Tel 28-31-387) Belgrade SETNET (38:103/123)
cccc.512 postmast,
From: KLIMENT.ANDREEV@f108.n108.z38.setnet.setnet.co.yu (KLIMENT ANDREEV) Subject: obj Date: Mon, 28 Aug 1995 02:55:00 AG>Hi. AG>Posto pojedine f-je za grafiku nerade u modovima sa 256 boja, AG>mislio sam da izvadim iz graphics.lib obj fajl koji sadrzi tu f-ju i AG>da je izmenim. AG>Mene zanima da li to moze i kako da dobijem spisak svih .obj u AG>biblioteci ? Mozzda cce ti ovo pomocci. If you want to see what functions are in library, use this basic TLIB command: TLIB library_name, outputfile.lst Notice that the comma is essential in this command. Chombe ___ ■ OLX 2.1 TD ■ ӭńÓ­÷ ĆÓ˘ý ŕ üÝŠý Ľ÷Š­Ó. * Origin: SETNet: Struga BBS +389 96 74074 * Macedonia * (38:108/108)
cccc.513 postmast,
From: SETN@f101.n101.z38.setnet.setnet.co.yu (SETN) Subject: Statistics Date: Thu, 31 Aug 1995 09:04:00 Maintaned by CONFERENCE STATISTICS SHELL - (c)1995 by Predrag Supurovic ======================================================================= Conference NET.C-LANG maintained on 03.08.95. for 28 days backward. QRATIO Mail Statistics V1.9 by Act Of Impulse. ---------------------------------------------- Total messages found in this area : 112 Number of messages covered in report: 45 Processed period from: 3-8-1995 to 27-8-1995 ------------------------------------------------------------------------------ Blacklist-Top 5 of the Quoters. Nr Total Quoted Quote Name Address Msg Lines Lines: Ratio: ---- ------- --- ----- ------ ------ 1. Damir Barjaktarevic...... 38:103/120 1 18 11 61.11% 2. "Janko Stamenovic"....... 38:103/120 4 150 74 49.33% 3. Vladimir Vucinic......... 38:103/120 1 23 11 47.83% 4. "Vladislav Erdelji"...... 38:103/120 1 9 4 44.44% 5. "Milos Visnjic".......... 38:103/120 1 7 3 42.86% ------------------------------------------------------------------------------ Top 5 of the writers. Total Average Quote Name Msgs: Pct. Byte/Msg Ratio: ---- ----- ----- -------- ------ 1. "Nebojsa Mihovilovic" 5 11.1% 2008 37.74% 2. "Aleksandar Petrovic" 5 11.1% 652 0.00% 3. "Janko Stamenovic" 4 8.9% 1876 49.33% 4. "Zdravko Stojanovic" 4 8.9% 694 0.00% 5. Ivan Glisin 3 6.7% 934 5.36% ------------------------------------------------------------------------------ Top 2 of the receivers. Total Name Msgs: Pct. ---- ----- ----- 1. All 44 97.8% 2. Ivan Glisin 1 2.2% ------------------------------------------------------------------------------ Top 5 of the subjects. Subject Nr. ------- --- 1. cccc........................................................ 39 2. Nova knjiga................................................. 2 3. password hasher (crypt()) replacement....................... 1 4. Turbo C 4.5................................................. 1 5. obj......................................................... 1 ------------------------------------------------------------------------------ Average posting frequency per week: Day Msgs Pct. Graph Sunday 6 13.3% *********************** Monday 5 11.1% ******************* Tuesday 3 6.7% *********** Wednesday 3 6.7% *********** Thursday 13 28.9% *************************************************** Friday 10 22.2% *************************************** Saturday 5 11.1% ******************* ------------------------------------------------------------------------------ Average posting frequency per day: Interval Msgs Pct. Graph -------- ---- ----- ----- 0:00- 1:59 3 6.7% ******************* 2:00- 3:59 3 6.7% ******************* 4:00- 5:59 6 13.3% *************************************** 6:00- 7:59 2 4.4% ************* 8:00- 9:59 5 11.1% ******************************** 10:00-11:59 1 2.2% ****** 12:00-13:59 3 6.7% ******************* 14:00-15:59 3 6.7% ******************* 16:00-17:59 8 17.8% **************************************************** 18:00-19:59 2 4.4% ************* 20:00-21:59 4 8.9% ************************** 22:00-23:59 5 11.1% ******************************** ------------------------------------------------------------------------------ * Origin: Oreska BBS, Uzice = SF BIBLIOTEKA = SETNet: (38:101/101)
cccc.514 postmast,
From: dusan.djordjevic@rstones.durlan.co.yu (Dusan Djordjevic) Subject: Re: cccc Date: Wed, 30 Aug 1995 10:02:00 CET QWK To: Sasa Sikimic SS> Covek je u pravu.U PC magazinu video sam reklamu za Turbo C 4.5. Koja SS> je SS> razlika u odnosu na Borland C++ 4.5 stvarno ne znam. Pa u samom imenu pise Turbo C i Borland C++, i toliko o tome... Ako se secas starijih verzija kompajlera, Turbo su obicno bili oni manji, a Borland oni profesionalniji... ... Svako uspesan ima padove, ali svaki pad ne znaci uspeh. --- Blue Wave/Max v2.12 [NR] * Origin: Rolling Stones BBS (2:382/105.5)