U C-u ne možeš dobiti ASCII kod nekog znaka. Jedini način je da sam napraviš tabelu.

Ali ako staviš

char c = 'A';

promenljiva c će dobiti vrednost koda za znak A. Koji tačno broj se dobija zavisi od toga kako sistem na kom radiš kodira znake (ne nužno ASCII, o tome treba voditi računa!!!)Pritom ovo nije nikakva funkcija, 'A' je tipa char.

Postoji funkcija toascii() kao BSD i SVID ekstenzija (man 3 toascii) ali to naravno nije standard.

f

mozes npr ovako

cout << int('a') << endl;

time pozivas konstruktor za integer tip, preko char tipa,
sve u svemu char i nije mnogo razlicit od integera (osim po opsegu) samo se drugacije interpretira

igor

pa zar char nije isto što i int...



Karakter: 65

Valjda nije. :)



ali



f

zato što je opseg manji, tj ne možeš reći "char a=32000" ali se u char opsegu ponašaju sasvim indentično...

mozes da kazes char a=32000; i dobices neki broj od -127 do 127
ja cesto koristim char kada mi ne trebaju veliki brojevi, recimo za true i false, zgodni su jer stedis memoriju, zasto da zauzmes 4 bajta sa int, kad mozes i samo jedan bajt

Od takve uštede slaba je vajda.

Zbog načina na koji procesori pristupaju memoriji, tj. zbog uravnavanja (alignment), čak i jedan jedini char bude veliki celu reč u rezultujućem kodu (4 bajta na primer). Čak i u slučaju nizova znakova (char*), kod kojih standard propisuje da se ne smeju razmicati i uravnavati, iz memorije se ipak čita reč po reč - neiskorišćeni delovi reči odnosno preostala 3 bajta čekaju svojih pet minuta u kešu (cache).

f

pa napravis 4 char-a (bool-a), i eto :)
od viska glava ne boli, mozda ti nekad zatrebaju ostala 3 char-a :)

Hmmm. Može biti i da ćeš da uštediš koji bajt, ali takve "optimizacije" ti se pre ili kasnije obiju o glavu. Treba slediti jedno prosto pravilo: gledaj najpre da ti program bude funkcionalan, tj da radi ono za šta je pravljen, potom gledaj da kod bude jednostavan i čitljiv, a optimizacijom se bavi jedino ako i kad bude potrebno. Najčešće nikad.

Tako je razmišljao i Micro Soft pa pogledaj dokle smo došli.

100 puta jači kompjuteri u odnosu na one od pre par godina, a čemu? Za mnogo šminke i ne puno veću funkcionalnost. Pričam o desktop platformama.

Ali to pokreće komp. industriju, neefikasan softver i neefikasni programeri. Mora tako, šta ćeš..

Polako ljudi :)
Tata i Filip su u pravu, znam da se odvaja 4+4+4... gledao sam to pre koji mesec.
Alli, ako se nekad desi da imate potrebu za vise od jednog 'prekidaca' - onda je char b[4]; dosta korisna stvar, umesto da zauzme 16, zauzece 4...

http://www.codeproject.com/tips/optimizationenemy.asp

"Some many years ago, as I indicated in the introduction, I worked on a large (16-processor) multiprocessor system. We were using custom-modified PDP-11 minicomputers, which were relatively slow. We were programming them in Bliss-11, which as far as I've been able to tell still holds the record for the world's tightest optimizing compiler (although I've seen some quite impressive optimizations in Microsoft C/C++). After doing some performance measurement, we determined that the paging algorithm was the outstanding performance bottleneck. So our first assumption was that the paging algorithm was faulty. We examined the code, and the paging algorithm maintainer rewrote it, taking our performance data into account, and had a new, and much faster, page management algorithm installed within a week.

Meanwhile, up at MIT, MULTICS was still running. They traced a serious performance problem to the paging system. Because it was written in a PL/1 like language, EPL, the assumption was that because it was written in a high-level language, the code was suboptimal, so they launched an effort to rewrite the page management algorithm in assembly code. A year later, the code was working, and was put into the production system. Performance dropped 5%. Upon inspection, it was found that the fundamental algorithm was at fault. They took the EPL code, rewrote the algorithm, and had the improved algorithm working and installed in a few weeks. The lesson: don't optimize something that is not the problem. Understand the problem first. Then, and only then, do the optimization. Otherwise, the optimization is a waste of time and may even make the performance worse.
"

Evo još citata, ovaj put u glavnoj ulozi Donald Knut: http://www.cookcomputing.com/blog/archives/000084.html

Pa sta moze da natera nekog da plati nekoliko stotina/hiljada dolara za Office/Windows/VStudio/Photoshop/AutoCAD itd ako upravo ne veca funkcionalnost?? Dokle smo to dosli sa Microsoftom? Dotle da svaki prosecan covek moze da ima racunar u kuci, a ne da ga se boji i bezi od njega. Lose ? Jeste, ako neko voli da izigrava pametnjakovica.
Ako cemo da cepidlacimo oko cuvanja resursa, najbolje da se vratimo na busene kartice jer tamo je svaki bit dragocen pa se i postupalo u skladu sa tim. Neke tehnologije su skoro :( izumrle - sa razlogom (evo ja licno ti predlazem IBM AS/400 i 'programiranje' u RPG, pa cemo da pricamo.. :).



[Ovu poruku je menjao degojs dana 26.04.2003. u 03:08 GMT]

Znači hoćeš da kažeš da je super pisati neoptimizovan kod i da samo tako treba i dalje da se radi?

Drugo, na onom linku što je Dragi Tata dao se napominje da ne treba "gubiti vreme" na optimizaciji GUI-ja. Pa ako nešto cenim to je superbrzi GUI, pa makar čekao i nešto duže na ostale funkcije programa. Ali daje barem kontrolni interfejs brz i "responsive"..

A on priča tamo kako je mozak spor na reakciji i računa koliko milisekundi treba nervnom impulsu da prođe kroz telo itd.. totalno bez veze tekst.. ne optimizovati gui. ne mogu da verujem još uvek šta sam pročitao. Kuda ovi kompjuteri idu, jee.. :(

Pa mogu onda i da se koriste bitpolja pa imas
osam bool u bajtu ( ili bitset klasa) ali MS nije za
dzabe ubacio svuda gde fali "force DWORD".
Valjda je lakse da ide po 4 bajta.
PS ne dirajte u mr. Newcomera

_{// upozorenje! previše dugačko, i pitanje koliko poučno ;)}


gojko, ne pričaj svašta.. kako možeš da tvrdiš da je m$ kriv zato što softverska industrija kaska za hardverskom.

mislim, znam, i meni je činjenica da radim na 200 puta bržem kompjuteru nego što je bio moj prvi pc (ajde da ne računam c64) gnusna, i da mogu samo da poželim da sam samo 20 puta produktivniji nego pre nekoliko godina, a ne 200. ali kriviti jednu firmu, pa makar i m$ (neko će reći naročito m$) za tako nešto je smešno. da li je linux/unix/umetni-tvoje-omiljeno-parče-softvera-ovde 200 puta napredniji nego pre neku godinu. not by a long shot. (fali mi jednako jak prevod ;)

čak šta više, možda bih se i složio da je možda m$ i zaslužan zašto ja sebi mogu da priuštim računar čija se brzina računa meri u gigahercima. (ne da podržavam m$, ali budimo realni).


dalje, problem sa softverom nije u stvari problem te prirode, jer upoređujemo babe i žabe. brzinu hardvera podiže potražnja tako što opravdava nova ulaganja u sve veće i automatizovanije pokretne trake koje proizvode sve jeftinije i jeftinije čipove. (i sporedni efekat sa većim brojem jeftinih čipova je brzina)

na takav ili sličan način, potražnja ne može da utiče na kvalitet softvera. ne postoje roboti koje bi mogli da napravimo (ma koliko para uložili, i ma kako to bilo opravdano), koji bi mogli da pišu revoluciono bolji softver.

nema revolucije u softverskoj industriji. ima samo brže ili sporije evolucije. isto kao što ni hardverska industrija odavno nije doživela revoluciju, već samo ubrzanu Evoluciju.

a hteo to da priznaš ili ne, evolucija u softveru upravo jeste ka sve višim nivoima, tj sve manjem obraćanju pažnje na optimizaciju, i ujedno udaljavanje od hardvera. (znači trenutni korak je i zvanično sa .net-om Java-olik, polu-interpreterski, ma kako se nemanja borio protiv toga ;)


a što se konkretno optimizacije tiče, i to si pogrešno razumeo. onaj text ima jako dobre primere, kada čak i bolji algoritam može da da mnogo lošiji rezultat (straničenje memorije) zbog drugih okolnosti na koje ne može da se utiče iz programa.



neverovatno koliko je ovo tačno, tj koliko se slažem sa ovim. ja ne bih mogao bolje da objasnim moje mišljenje ;) (ne da se poredim sa bilo kim po iskustvu, ali stvarno ;)


eto šta iskustvo znači u programiranju. kada sam radio na jednom srednje velikom projektu (100k+ linija koda), i kada je došlo do tačke razno, pod-tačke "zašto se pobogu toliko vuče program", ja se zaleteo odmah ja ću da optimizujem ovo i ono, pa ću ovo, pa ču ono..

dok sam ja dva sata samo prolazio kroz kod i pravio analizu šta od toga svega treba optimizovati, na koji način, etc, malo stariji (bitnije iskusniji) kolega je već bio skinuo dva profilera sa neta, probao oba, jedan nije bio dobar (problem opisan u nemanjinom linku, merio je ukupno vreme potrošeno na izvršavanje svake linije koda, ne uzimavši u obzir koliko je puta ona pozvana), i sa drugim programom otkrio da je problem u delu koda koji pristupa sql serveru.

problem je opet bio u prečestom pristupanju istim podacima, kada su vrlo lako mogli da budu keširani (u stvari, samo da nisu oslobađani iz memorije) uz utrošak samo par stotina K memorije...

a najveći fazon je što ja to nikad ne bih otkrio/ispravio, jer ja nisam imao nikakve veze sa kodom za bazu (to je radio DBA), i tamo ne bih ni gledao.. (bio sam ubeđen da je moja greška ;)



_{// elem, moram da prestanem da se ovoliko zanosim kada pričam o programiranju... c c c ... ko me sledeći vidi da počinjem ovako dug post, neka me slobodno udari preko prstiju... ;)}

Onako uzgred.

Ali, dont vori da je sve programiranje postalo kliktanje po gumbićima sa kodiranjem po principu što na um, to na drum. Kolega za stolom preko puta se zezuje sa simulatorom integrisanih kola i cedi svaki atom snage iz računara (a računari su 4 sunca -- tj. SUN -- vezana u klaster sa 4GB RAM po glavi, i ne, nije java nego C:). Krckanje je prošle nedelje trajalo dan, sad vec su spali na oko 20 sati i tako. Za neumorne optimizatore ko što vidite još ima posla. :)

f

Prvo sam naucio TurboC, potrebe skole, osnove programiranja i sl. potom sam naucio VB. Imao sam averziju prema njemu, MS produkt valjda zato?! ne znam. ali Dopala mi se njegova sintaksa, lakoca ucenja itd. Stekao sam solidno znanje, uradio par projekata itd. Krenuo sam da radim PHP, u pocetku sam imao utisak da je on pun poltergejsta (falio mi je valjan debuger verovatno), mislio sam da je nepredvidiv a sad se pitam zasto nisam ranije poceo da ga rabim. Sad sam poceo da ucim C++, JOOOOOJ...ala je ovo frustrirajuce...Ala cu ga voleti ako ga savladam.
Sto vise znoja to vise postovanja, mislim.

A sad pitanje: Kako vi u C++ uopste poredite dva stringa(ne vekora vec char* a i char* b) posto meni nije bas to nesto jasno?

Ne vidim gde sam to rekao.
Treba jednostavno izvagati koliko dobivas optimizacijom a gubis na citljivosti/lakoci odrzavanja i obrnuto.

Pa nisi direktno, ali podržao si Dragog Tatu koji je rekao da se optimizacija radi - NAJČEŠĆE NIKAD. Eno piše to još uvek par poruka iznad.

Ja samo sa takvom izjavom ne mogu nikako da se složim, i nisam za optimizacije po svaku cenu na svakom mestu. Ali GUI je sigurno nešto što bi moralo biti visokooptimizovano i brzo.

Gojko, nisam se uopšte osvrnuo na ono sto je DT napisao, nego na ono sto si ti rekao: po običaju, trešuješ MS i pritom često pričaš stvari koje veze nemaju ni sa temom a ni sa stvarnim svetom (ej bre.. gde ti je bila pamet kad si napisao da kompjuteri/programi danas nemaju vecu funkcionalnost.. auuu.. posle sam pomislio da namerno zezaš i zadirkuješ, pa sam se nasmejao sam sebi što sam se 'primio' ali sad vidim da je baš ono -- bedak).

Verovatno za primer optimizacije koda, za koju se toliko zalažeš, može da se uzme i sam ES koji je nedavno proradio sa novom, optimizovanom, verzijom skripte, ovaj hardvera :) Kriv je MS.

Auu, bre. Ovo će da završi u Advocacy, vidim ja.

Moj komentar se odnosio na sledeće: Peca je pričao o uštedi memorije kada se koristi char umesto int-a. Takva optimizacija po pravilu vodi do problema, a često ne daje nikakve rezultate, i upravo o tome govori članak na koji sam ostavio link. Primer sa GUI-jem koji je posebno iznervirao Gojka suštinski kaže da ne treba da potrošiš tri meseca na ubrzanje koje korisnik neće da primeti.

Ne pada mi napamet da tvrdim da je svejedno kako programi troše resurse. Međutim, treba imati na umu:

1) Dobre performanse se postižu pre svega dobrim dizajnom, a ne optimizacijama na nivou koda. Ako si izabrao dobre algoritme i strukture podataka, velika je verovatnoća da nikad nećeš imati potrebe za optimizacijom.

2) Prvo meri pa onda seci - nikad ne optimizuj kod dok merenjem ne utvrdiš gde je "bottleneck".

To je suština moje primedbe, a mislim i članka na koji sam ostavio link, a nikako shvatanje da su performanse "nevažne".

Verovatno se nismo dobro razumeli. Ono za funkcionalnost je preterano naravno, ali morao sam malo. ;) Možda pre stoji da je funkcionalnost porasla nesrazmerno malo u odnosu na ubrzanje hardvera, a sve to zbog loše pisanog softvera. Neoptimizovanog drugim rečima. Pod optimizacijom sam mislio da se smatra i dobar dizajn i algortimi, ne znam od kad se to odnosi samo na optimizaciju na nivou koda i brojanje instrukcija i vreme izvršavanja istih, na primer, ako to spada u code level optimizaciju.

A taj tekst protiv optimizacija i primer za GUI onda svakako nije jasno napisan. Pre će navesti budućeg programera da pomisli da ne treba uopšte brinuti o performansama. Mislim da nije dovoljno jasno naglašeno to što si ti sada izvukao - da ne treba gubiti vreme na optimizacijama koje se ne primećuju i ne donose nikakvu dobit.

Iako su moje prve poruke u ovoj temi malo neozbiljne i u šali, ovo već postaje obavezno. Da se na onako posećenom sajtu nađe takav članak, pa to razara omladinu ljudi.