[ Blablabla @ 08.07.2011. 23:47 ] @
Sta sve treba skinuti sa neta (a da je najbolje, a besplatno ili da ima khm-khm) da programiras u C++-u?
[ plague @ 09.07.2011. 06:22 ] @
Imas top temu http://www.elitesecurity.org/t141067-Free-Compilers-IDE-amp-RAD-GUI-Libraries.

7-8 meseci od zadnjeg update-a.
[ Blablabla @ 09.07.2011. 22:46 ] @
Hmm... To u mnogome izgleda kao lista varijanti na istu stvar - ali od svega toga sta bi iskusni* programer zadrzao a sta bi zaboravio da postoji uopste?


---
* dakle: imajuci u vidu ono sto pocetnik ne poseduje -- dovoljno licno iskustvo da potpuno spozna i onda UPOREDI mogucnosti svih tih varijanti
[ Blablabla @ 09.07.2011. 22:49 ] @
...I uzgred - kako to funkcionise kod PC-a - da li kod PC-a mozes DIREKTNO da ocitavas adrese (bajtove i bitove) npr. stisnutog tastera ili razlicitih vrednosti kod misa ili svih drugih ulaznih/izlaznih naprava ili upisujes bajtove DIREKTNO u neku adresu zvucne kartice ili u neki opseg adresa DIREKTNO bre upisujes R,G i B vrednosti piksela u nekoj rezoluciji - ili da menjas mod prikaza monitora DIREKTNO upisujuci u neku adresu (kao ona 'PEEK' i 'POKE' varijanta u BASIC-u...)?

(Ako ima - onda GDE procitati nekakvu LISTU svih tih adresa (bukvalno kao sto neki stari kucni racunari imaju knjizicu sa kompletnom listom sta koja adresa radi i svaki bit u njoj sta regulise) - voleo bih da pocnem od toga posto mi je nesaglediva bulumenta kojekakvih komandi koje je ko zna ko i ko zna kada i ko zna zasto izmislio nekako odbojna (mislim - svestan sam da je sve to u smislu da ne rade svi jedno te isto svako za sebe iznova i iznova izmislja rupu na saksiji i da ubrza programiranje, ali mnogo je konfuzno za pocetnika...)... kapiram da Windows putem DirectX-a regulise sve to i programera nije briga za konkretnu graficku/zvucnu karticu i njene adrese i koji sve ne hardver nego ima univerzalna komanda a sistem onda gleda koji je konkretni hardver... pojma nemam...)

(ma ja bih bre (da imam uticaja ili mogucnost za to - sto je nerealno naravno...) napravio racunar totalno nove koncepcije i novi programski jezik sa nekim drugacijim konceptima (pre svega oko nacina na koji se oformljavaju promenljive) - imam neke koncepte povodom toga... sta god :) )
[ X Files @ 10.07.2011. 09:12 ] @
Očigledno imaš iskustva sa 8-bitnim, a možda i 16-bitnim računarima, jer vidim da pominješ PEEK, POKE, adrese specijalne namene, gađanje video memorije RGB vrednostima i sl.

Kod 8-bitnih računara, adrese su bile fiksne, a kompleksnost je dozvoljavala da ih sve zapamtiš napamet.

Kod vecine 16-bitnih računara, adrese su uglavnom bile fiksne ako se saberu sa takozvanim OFFSET-om (zbog različitih verzija biblioteka, pa su pomerene), a kompleksnost je dozvoljavala da se spisak drži na papiru i koriste po potrebi.

Zajedničko kod ovih računara je bilo to što je hardver bio "integrisan" i pod kontrolom jedne firme. Praktično, nepromenljiv.

Moram priznati da su to bila lepa vremena :)


Danas, stotine proizvođača hardvera, stotine verzija istog hardvera, stotine programa koji u pozadni rade, uz to se update-uju... teško je držati se starih koncepata i fiksnih adresa.


Memorija više ne funkcioniše kao nekada, tako da svaki program ima "svoj" blok, koji je pod kontrolom OS-a. Da nije tako, OS bi zbog sveopšteg haosa padao svakih 5 minuta, maliciozni programi bi mogli da rade šta hoće.

U praksi, garantujem ti da NIKO ne bi kucao tekst u nekom editoru, vec bi samo pisao na papiru zbog bojazni da će sve odjednom izgubiti, zbog toga što je neki loše napravljen program u nekom najnezgodnijem trenutku pregazio memoriju (buffer overflow) editora u najnezgodinijem trenutku. Bez resursa bi se ostajalo "u trenutku"...


Ukratko, novi OS-ovi su totalno drugačije koncipirani...
[ Nedeljko @ 10.07.2011. 11:02 ] @
Znaš li šta su zapravo drajveri?

Svaka grafička kartica funkcioniše iu principu drugačije. Poenta je da programer koristi iste komande, koje nekako idu u komande OS-a, a koje drajver prevodi u komande konkretne grafičke kartice.
[ Blablabla @ 11.07.2011. 23:49 ] @
Citat:
X Files: Očigledno imaš iskustva sa 8-bitnim, a možda i 16-bitnim računarima, jer vidim da pominješ PEEK, POKE, adrese specijalne namene, gađanje video memorije RGB vrednostima i sl.

Kod 8-bitnih računara, adrese su bile fiksne, a kompleksnost je dozvoljavala da ih sve zapamtiš napamet.

Kod vecine 16-bitnih računara, adrese su uglavnom bile fiksne ako se saberu sa takozvanim OFFSET-om (zbog različitih verzija biblioteka, pa su pomerene), a kompleksnost je dozvoljavala da se spisak drži na papiru i koriste po potrebi.

Zajedničko kod ovih računara je bilo to što je hardver bio "integrisan" i pod kontrolom jedne firme. Praktično, nepromenljiv.

Moram priznati da su to bila lepa vremena :)


Danas, stotine proizvođača hardvera, stotine verzija istog hardvera, stotine programa koji u pozadni rade, uz to se update-uju... teško je držati se starih koncepata i fiksnih adresa.


Memorija više ne funkcioniše kao nekada, tako da svaki program ima "svoj" blok, koji je pod kontrolom OS-a. Da nije tako, OS bi zbog sveopšteg haosa padao svakih 5 minuta, maliciozni programi bi mogli da rade šta hoće.

U praksi, garantujem ti da NIKO ne bi kucao tekst u nekom editoru, vec bi samo pisao na papiru zbog bojazni da će sve odjednom izgubiti, zbog toga što je neki loše napravljen program u nekom najnezgodnijem trenutku pregazio memoriju (buffer overflow) editora u najnezgodinijem trenutku. Bez resursa bi se ostajalo "u trenutku"...


Ukratko, novi OS-ovi su totalno drugačije koncipirani...



Kazem - nesto sam razmisljao i kapiram koliko je PC danas "na tankom ledu" - ne mogu da ti opisem, preko noci sve to moze da bude za kontejner ili pak emulatore...
Mislim - samo razmisli malo sta je u srzi razloga zbog cega su se komplikovali racunari i sve ce ti biti jasno.

Kao sto rekoh - jasno mi je da je u celosti novo poglavlje racunarstva tako lako moguce i cak bih rekao 'na pomolu' i samo je pitanje ko ce prvi shvatiti i ugrabiti i upotrebiti taj novi koncept i preuzeti dominaciju nad celokupnim trzistem - e to je na foru onog izraza "sad cemo malo da promesamo spil" - sve bi krenulo ispocetka (ali ovaj put ispravno). Kapiraj kad bilo ko moze da potpuno 'preokrene igru'.
[ Blablabla @ 11.07.2011. 23:56 ] @
Citat:


Hmm... To u mnogome izgleda kao lista varijanti na istu stvar - ali od svega toga sta bi iskusni* programer zadrzao a sta bi zaboravio da postoji uopste?


---
* dakle: imajuci u vidu ono sto pocetnik ne poseduje -- dovoljno licno iskustvo da potpuno spozna i onda UPOREDI mogucnosti svih tih varijanti
[ plague @ 12.07.2011. 09:28 ] @
Hm.. Ja sam uvek programiranje zamisljao kao voznju. Kada neko hoce da nauci da vozi, prvo treba da se fokusira na sam cin voznje, a nakon sto to nauci i na auto koji vozi.

Kao pocetniku neka knjiga(cak ni ne treba, imas podosta na netu) i Code::Blocks ce ti biti sasvim dovoljni.
Ja koristim Visual Studio. Dosta njih koristi NetBeans (koji koristim iskljucivo za javu) kao i Eclipse.

P.S. Naravno da ne znam prednosti svih okruzenja i biblioteka, koliko mi je trebalo - toliko sam i ucio.
Mislim da bi i ti trebao tako, posle kada odes u neke daljine mozda ces preferirati neki IDE iz nekih posebnih razloga dok smatram da je sada u pocetku sasvim nebitno koje je okruzenje ako nije neko zastarelo tipa Dev-C++ cija je zadnja verzija izasla pre 6 godina.

S obzirom na stvari o kojima si pricao u trecem postu, savetujem ti da se fokusiras na samo programiranje jer se dosta razlikuje od tvog iskustva. Posle ce doci IDE, framework i slicno.
[ Blablabla @ 18.07.2011. 19:55 ] @
'EJ DA! Umalo da zaboravim --- ima li smisla u tome da se odmah uhvati C# umesto baviti se C++-om?
[ X Files @ 18.07.2011. 20:50 ] @
Ako mene pitaš - ima smisla, mada je sve relativno.
[ Nedeljko @ 19.07.2011. 09:11 ] @
Ima smisla, mada bih ja svakome preporučio da u okviru osnova programiranja savlada barem C, da bi znao kako programi zapravo rade.
[ Mihajlo Cvetanović @ 19.07.2011. 09:30 ] @
Odma C#. Ako vežbaš C bićeš bolji u C-u. Ako vežbaš C# bićeš bolji u C#-u. Jedno nije podskup drugog, nego su dovoljno različiti da ti veliki deo stečenog znanja u jednom ne pomaže u drugom. Osnove programiranja možeš da stičeš u bilo kom jeziku, uključujući i C#.
[ Nedeljko @ 19.07.2011. 11:38 ] @
Pa, ne znam koliko C# omogućava da se razumeju stvarin na nižem nivou. Nisam ja ni mislio da je C potrebno predznanje za C# ili njegov podskup, već deo obrazovanja koji će kasnije razlikovati ozbiljnog programera od amatera.
[ Mihajlo Cvetanović @ 19.07.2011. 13:57 ] @
Ne znam tačno kakvo je to znanje niskog nivoa, koje bi moglo da poboljša umeće programiranja na višem nivou. Pokušavam da pronađem primer nekog znanja koje je lakše steći u C/C++ nego u C#, a da je korisno i za C#, i za sada mi ne ide. To je otprilike i moja poenta, pa ako znaš neki takav primer navedi ga, jer bi to bio kontra-argument mom stavu. Naravno, jedan primer nije dovoljan da okonča raspravu, ali daj šta daš...

Širina znanja van C# je korisna utoliko da bi znao da je nešto moguće uraditi u nekom drugom programskom jeziku, a implementacija u C# je manje efikasna, ili prosto nemoguća. S druge strane znanje van C# te može navesti da u samom C# radiš nešto na pogrešan način, jer znaš da je tako rađeno u drugom jeziku. Kad se sve sabere mislim da ako neko planira da radi u C# onda treba da počne od C#.
[ Blablabla @ 24.08.2011. 20:34 ] @
Hmm... Sad vidim da je .NET zapravo programski jezik (je l' tako?). Sta onda - C++/C# ili .NET - ako su oni uopste uporedivi (u smislu: mozda je .NET programski jezik na daleko visem nivou i brzinom (sporoscu) izvrsavanja i (ne)fleksibilnoscu se ne moze porediti sa c++/c#)?


[Ovu poruku je menjao Blablabla dana 25.08.2011. u 15:20 GMT+1]
[ Mihajlo Cvetanović @ 25.08.2011. 10:36 ] @
.NET nije programski jezik nego platforma. Na najjednostavnijem nivou recimo da je to skup biblioteka i osnovnih struktura podataka (postoji samo jedan tip podatka string i on se koristi u svim jezicima na isti način). .NET se oslanja na CLR, Common Language Runtime. Prosto rečeno CLR je okruženje koje omogućava izvršavanje virtuelnog mašinskog koda zvanog CIL, Common Intermediate Language, i sve što se na nekom programskom jeziku kopajlira za .NET mora na kraju da se pretvori u taj CIL da bi se izvršavalo u CLR-u. Glavni programski jezici za .NET su Visual Basic i C#, i unekoliko C++/CLI (što nije isto što i C++, koji nema veze sa .NET). Postoje i drugi programski jezici koji kao rezultat daju .NET kod. Ono što je lepota čitave ove postavke je da biblioteku napravljenu u jednom programskom jeziku možeš skoro bez problema da koristiš iz aplikacije napravljene u drugom.

Konkretni odgovori na pitanja: C++ je jezik koji nema veze sa .NET. C# i C++/CLI su jezici koji imaju veze sa .NET. .NET nije jezik nego platforma (framework). .NET je izuzetno fleksibilan i osećaj koji recimo ja imam kad programiram u C# je kao da sklapaš lego kockice. Gubitak na brzini u odnosu na ekvivalentni optimizovani C++ kod je zanemariv (a i treba napomenuti da uglavnom treba da rodiš mečku da bi napravio ekvivalentni optimizovani C++ kod).
[ Nedeljko @ 25.08.2011. 11:01 ] @
.NET je platforma u smislu svega što je Mihajlo Cvetanović napisao + virtuelne mašine koja izvršava takav .NET bajt kod.

Što se odnosa brzine i tiče, Mihajlo je u pravu u nekom jednostavnim situacijama, ali nisam čuo da je industrija video igara prešla ca C++-a na nešto drugo ili da se multimedijalni kodeci rade u nečemu što nije C/C++ ili da se vodeće aplikacije tipa Adobe PhotoShop itd. rade u nečemu drugom.
[ Mihajlo Cvetanović @ 25.08.2011. 11:34 ] @
Da, u pravu si, mislio sam na obične poslovne aplikacije. Game engini i video kodeci se ne pišu u .NET-u, ali Nomad.NET (Total Commander klon) i Paint.NET sasvim lepo rade.
[ Blablabla @ 25.08.2011. 14:29 ] @
Citat:
Nedeljko: ...ali nisam čuo da je industrija video igara prešla ca C++-a na nešto drugo ili da se multimedijalni kodeci rade u nečemu što nije C/C++ ili da se vodeće aplikacije tipa Adobe PhotoShop itd. rade u nečemu drugom.


Zasto nisu presli? Zato sto su navikli na C++ i mrsko im je da predju na C# ili .NET ili zato sto program u C#/.NET ne bi bio dovoljno efikasan (kao u C++-u)?
[ Nedeljko @ 25.08.2011. 14:51 ] @
Jednostavno ostala rešenja nisu toliko efikasna kao C/C++ inače bi vrlo rado prešli na .NET. Postoji takođe mogućnost da ono glavno, što troši resurse odradiš u C/C++-u, a ostalo u .NET-u Java-i itd.
[ mmix @ 25.08.2011. 16:38 ] @
Mislim da smo vec imali jednom raspravu ove vrste i da je na nekoliko primera izmerenoda C++ aplikacija nije nista brza od c# aplikacije na MS JITu.

Predrasude, predrasude :)

Sto se tice igrica, polako i to prelazi na XNA, predrasude padaju polako. Magicka, Sol Survivor, AI Wars, itd. Iako XNA jos ima neke probleme moore ce se vec postarati oko toga.

[Ovu poruku je menjao mmix dana 25.08.2011. u 18:08 GMT+1]
[ Blablabla @ 25.08.2011. 18:23 ] @
Hmm... XNA je 3D. A ako hoces neku komplikovanu fotorealisticnu 2D - je l' bi i onda radilo bez problema?
[ mmix @ 25.08.2011. 19:38 ] @
Sto ne bi? Bitblt operacije nisu vise problem, svaka iole novija 2d igrica danaj je zapravo surface na 3D povrsini, klasicne 2D igrice o kojima ti pricas vise ni ne postoje niti ima smisla praviti ih i forsirati CPU based bitblt. Najveci bottleneck kod modernih igrica koliko sam ja shvatio je PCIe propusna moc i u osnovi procesna moc GPUa. CPU je sad tu uglavnom samo da hrani zver i koordinira input a to je nesto sto managed kod moze da odradi sasvim fino. Tako da igrice i nisu neki rezon, vise je tu u pitanju inercija nego bilo sta drugo.



[ Nedeljko @ 26.08.2011. 12:07 ] @
Citat:
mmix: Mislim da smo vec imali jednom raspravu ove vrste i da je na nekoliko primera izmerenoda C++ aplikacija nije nista brza od c# aplikacije na MS JITu.

Predrasude, predrasude :)


O tim predrasudama dovoljno govori sam MS, koji zabranjuje objavljivanje rezultata merenja performansi .NET-a.
[ deerbeer @ 26.08.2011. 12:40 ] @
Citat:
mmix: Mislim da smo vec imali jednom raspravu ove vrste i da je na nekoliko primera izmerenoda C++ aplikacija nije nista brza od c# aplikacije na MS JITu.

Predrasude, predrasude :)

Sto se tice igrica, polako i to prelazi na XNA, predrasude padaju polako. Magicka, Sol Survivor, AI Wars, itd. Iako XNA jos ima neke probleme moore ce se vec postarati oko toga.

[Ovu poruku je menjao mmix dana 25.08.2011. u 18:08 GMT+1]


Jel to na primeru fibonacija ? :) Realan svet je nesto sasvim drugo .

Skoro sam pricao sa jednim programerom iz domace (poznate) softverske kuce ciji se posao uglavnom zasniva na .NET tehnologiji .
Softver pisan u .NET im je radio tako sto su svako malo dokupljivali jos memorije jos procesorske snage i ne znam cega jos ,
i to je je na kraju ispalo da vise nisu imali gde da dodaju novi hardver , tj. upgrade im je dostigao svoj maximum.

Evo zadnjih 2 godine jedino sto rade je da peglaju i optimizuju kod i broje dobijene mikrosekunde .

Znam da ces sada da kazes da je to do programera i da ne poznaju dovoljno arhitekturu .NET bajtkod , CLI i sta jos da bi se jos optimizovao kod ,
ali ako sve te tajne frejmvorka treba da poznaje prosecan programer da bi pisao optimalan/optimizovan kod
kojih po pravilu u velikim firmama i kompanijama kao sto je gore pomenuta ima opravdano mnogo onda stvarno ne znam zasto je .NET toliko popularan .



[ Nedeljko @ 26.08.2011. 12:46 ] @
Nije bio Fibonači, nego broj na 100,000 decimala.
[ Mihajlo Cvetanović @ 26.08.2011. 13:27 ] @
Citat:
deerbeer: Evo zadnjih 2 godine jedino sto rade je da peglaju i optimizuju kod i broje dobijene mikrosekunde .


Kakav je to projekat, daj malo više detalja. Može li kolega da kaže u čemu je konkretno problem? Ovako uopšteno mogu samo da kažem da se te mikrooptimizacije uglavnom ne isplate, i da bi se trebalo orijentisati na redizajn sistema. Ako je dizajn u startu bio slab onda nema te naknadne optimizacije koja će ga ojačati.
[ Nedeljko @ 26.08.2011. 13:34 ] @
Sve je to tačno, ali prodaje se priča kako u .NET-u mogu da rade wanabe programeri. Karikiram, ali čak si i ti napisao kako je ne znam koliko lakše raditi u .NET-u, a da su razlike u performansama zanemarive.

Tamo gde su performanse nebitne, radi kako hoćeš. Ja ne nalazim da je C++ naročito težak kada se koriste njegove osnovne mogućnosti. Kada su performanse bitne, potrebno ti je pakleno znanje šta god da izabereš.
[ Mihajlo Cvetanović @ 26.08.2011. 13:40 ] @
Okej, ali sad imamo podpitanje kakve bi bile performanse koleginog sistema da je pisan u C++. Moja teza je da ako bi kod bio preveden u C++ "1 prema 1", bez izmena u dizajnu, onda bi i taj C++ projekat patio od problema sa performansama.
[ Nedeljko @ 26.08.2011. 16:49 ] @
OK Mihajlo, shvatam poentu i prilično se slažem sa tobom, samo da dopunim svoj prethodni post.

Zamisli da npr. pravim podršku za intervalnu algebru (šta god to značilo). Svaka računska operacija zahteva najmanje dva poziva funkcije fesetround(). To je jedna mašinska naredba. E, sad, šta ako to nije pokriveno Java/.NET API-jem? Možda ovo jeste, ali naći će se nešto što nije. Ovo uzimam samo kao primer. Pa, ništa, ja moram da izađem iz Jave (isto važi i za .NET) preko JNI poziva koji su vrlo skupi za tako kratke pozive. što znači da treba da razmišljam da li će mi se platforma obiti o glavu tako što će me sačekati na nekoj krivini. Kada cepam C/C++, ne razmišljam o tome. Omogućava mi da pišem onoliko brz kod, koliko je mašina brza i koliko imam znanja, želje i resursa da se time bavim. Nema sačekuša na krivini.

Da Mihajlo, najviše zavisi od programera, ali C i C++ čine da sve zavisi od programera i hardvera i niodčega više.
[ mmix @ 26.08.2011. 17:16 ] @
Najveca greska koju ljudi prave kad sude o .NETu je da ga posmatraju kroz prizmu Jave. ".NET NIJE JAVA, P/Invoke NIJE JNI", ovo treba uramiti velikim slovima! Ne svidja ti se kako JIT obradjuje odredjenu operaciju, to je sasvim ok, C++/CLI je tu po ceni lokalnog poziva. Nemas potrebe da CEO program pises u C++u zato sto odredjena operacija nije izvedena po zelji. Niti su sve operacije kriticne da zahtevaju bas odredjenu implementaciju, niti, budimo iskreni, programeri u redovnoj upotrebi imaju ikakvu predstavu o tome da li je njihova implementacija bolja od JITove kao sto nemaju ideju o tome da li je C++ native code bolji od JITovanog. Ako hoces taj nivo kontrole tu je asembler jedina sigurica, a to je vec teski overkill za 99.99+% upotrebe danasnjeg softvera.

Citat:
Nedeljko: O tim predrasudama dovoljno govori sam MS, koji zabranjuje objavljivanje rezultata merenja performansi .NET-a.


Gde zabranjuje? Mi ovde okacismo rezultate, niko nas nije jurio zbog toga. Ne vidim ni kako bi mogli da zabrane tako nesto, ni pravno ni tehnicki.
[ Nedeljko @ 26.08.2011. 19:09 ] @
Citat:
mmix: C++/CLI je tu po ceni lokalnog poziva.


Jesi li 100% siguran u ovo?

Citat:
mmix: Gde zabranjuje? Mi ovde okacismo rezultate, niko nas nije jurio zbog toga. Ne vidim ni kako bi mogli da zabrane tako nesto, ni pravno ni tehnicki.


Pa, evo ovde piše da zabranjuje.

mmix, koliko raspoložive memorije možeš da koristiš iz .NET programa, obzirom da GC-u mora da ostane dovoljno za pravljenje grafa?
[ mmix @ 26.08.2011. 20:43 ] @
Cuj, korporacije pisu svakakve gluposti, to i dalje ne znaci da je odrzivo na sudu, sto je u doticnom linku i navedeno.

Da, managed/unmanaged transition kroz C++/CLI je local call (mada, pazi, imas prvo call u c++ managed pa u c++ unamanged, tj zarpravo imas dva call-a). U tom pogledu je C++/CLI privilegovan u odnosu na recimo cisti C# PInvoke jer se sav marshaling vec resava na nivou kompajlera i ne-standardnih CLI ekstenzija (u tome je zapravo trik, mada mislim da i Mono recimo podrzava isti set ekstenzija). Iz tog razloga recimo ti asembliji ne mogu da se markiraju kao pure managed jer i nisu 100% CLS compliant.

Sto se tice raspolozive memorije mozes koliko hoces, sam graf ne zauzima bas toliko mesta, sve su to pointeri u osnovi. Mozemo da isprobamo pa da vidimo, ako postoji performance counter za to jer je to ipak deo internog rada GCa. Ali nesto mi govori da je ta vrednost daleko manja od prostora izgubljenog fragmentacijom. Probacu sve ovo da ti proverim sad za vikend,, tu gde sam sada nemam VS.


[Ovu poruku je menjao mmix dana 26.08.2011. u 21:59 GMT+1]
[ Nedeljko @ 26.08.2011. 21:08 ] @
Kada imaš mali broj velikih objekata (nekoliko dugih nizova npr.), onda je GC jeftin, ali kada imaš mnogo malih objekata, nešto mi govori da ćeš iskoristiti do 50% slobodne memorije.
[ mmix @ 26.08.2011. 21:41 ] @
Tu generacije dolaze do izrazaja, GC uvek i samo zapocinje collect kad se napuni poslednji 16Mb segment u kojem se nalazi Gen0 i samo za njega pravi graf i samo njega kompresuje i propmovise prezivele u Gen1. Ako to ne oslobodi dovoljno mesta onda ide Gen1, pa tek na kraju Gen2 i to ne uvek (u zavisnosti od tempa alokacije GC moze da zakljuci da mu je jeftinje da odmah prosiri Gen0 za jos 16Mb umesto da ulazi u skuplje Gen1/2 kolekcije). Samim tim u vecini kolekcija graf ce biti napravljen maksimalno za 16Mb alociranog prostora, Nek je alocirano po 1 bajt to (16 mil/9) pointera tj oko 7.3Mb (zaboravih overhead od 8b po alokaciji)
[ Nedeljko @ 29.08.2011. 15:47 ] @
I šta bi sa testovima? Nisi dobio MS-ovu dozvolu za objavljivanje.
[ mmix @ 29.08.2011. 15:55 ] @
Izvini, decekalo me dosta posla. Sutra
[ Nedeljko @ 29.08.2011. 22:33 ] @
Ma, šalim se, ali pripazi ti ipak na zabranu, pa kontaktiraj MS.