O buvo taip. Turėjau plaukus, maždaug tokius:

Pradėjo užknist juos prižiūrėt ir vat brolis morališkai skatino apsikirpti:

Tai nuo šiandien mano plaukai atrodo maždaug taip:

Ir labai džiugu.
w00t w00t
Liepa 27th, 2005 — Nuotraukos, gyvenimas
O buvo taip. Turėjau plaukus, maždaug tokius:

Pradėjo užknist juos prižiūrėt ir vat brolis morališkai skatino apsikirpti:

Tai nuo šiandien mano plaukai atrodo maždaug taip:

Ir labai džiugu.
Liepa 22nd, 2005 — Kompiuterija
Būtent taip vadinsis naujieji Windowsai, iki šiol vadinti Longhorn. Na visiems mulkiams dėl kažin kažko nekenčiantiems “M$” tai bus naujas būdas pravardžiuoti – “M$ višta”. Jo. O šiaip jau, naujieji windowsai bus, drįstu sakyt, geriausias jų pagamintas produktas. Visi pranašaujantys “greitą M$ mirtį” ir linuxų dominavimą aišku ir toliau sakys ką sakę, bet realybė tokia, kad Windowsai tik dar labiau įsitvirtins userių desktopuose. Unix lieka manjakams ir serveriams.
Liepa 18th, 2005 — Kompiuterija
Šiuo metu mokausi .NET/C#, t.y. noriu būti developeris ant bangos :) Priešingai, nei daugelis, Microsoft produktų pagal default’ą nelaikau evil, todėl tik šiek tiek panaudojęs minėtus dalykus drįstu pareikšti savo nuomonę. .NET framework’as yra nuostabus dalykas, geresnių nebūna – yra beveik viskas, ko tik gali prireikti ir viskas suderinta tarpusavyje. C++ ir iki tol buvusių framework’ų/lib’ų minusas buvo tas, kad reikėjo viską derinti tarpusavyje, o iš to dažnai nieko gero nesigaudavo, pvz., su boost::filesystem prasiiteruoji per kokį tais katalogą, rezultatus surašai į std::vector’ių ir galiausiai sudedį į kokį nors wx::ListBox’ą. Nieko čia gero, žodžiu.
O dabar apie C#. Aš šiaip jau esu mokslo žmogus ir iki šiol į mano svajonių kalbą panašiausia yra C++. C# yra gerai, nes ištaiso kai kurias blogąsias C++ sąvybes, bet deja, neturi daugumos gerųjų C++ sąvybių (na C# 2.0 žada kažkiek tai pataisyti).
O dabar apie vieną tokį dalyką plačiau – garbage collectinimą. Jei trumpai – aš, būdamas kalbos dizaineriu, būčiau daręs viską kitaip. Pati idėja automatiškai trinti nebenaudojamus objektus yra gera, bet turi trūkumų. Štai pavyzdys:
void func()
{
Bitmap b = new Bitmap(“file.bmp”);
}
Labai išsamus toks :) Bet jis turi problemą. Kadangi objektas yra sukurtas ant managed heap’o – niekas nežino, kada jis bus sunaikintas. Dėl to prasmės kaip ir netenka toks dalykas, kaip destruktorius. Šiuo atveju problemos kaip ir nėra, nes bitmapas nadoja atmintį, kuria ir rūpinasi GC. Tikra problema atsiranda naudojant kitokius resursus, pvz., visokius font’us brush’us ir t.t. – grafinius resursus. Jie atminties nenaudoja, tai GC su jais gali ir nesiskubinti. O realybėj, tokie resursai yra labai brangūs. Kitas pavyzdys, tarkim su duomenų baze. Atidarius ją ir palikus likimo valiai, niekas nežino, kada ji bus uždaryta. Dėl to C# programose dažnai galima sutikti krūūūvas .Dispose() kvietimų prieš uždaromąjį riestinį skliaustą. Yra sprendimas, kuris tinka jei naudoji vieną tokį brangų resursą:
using(Bitmap b = new Bitmap(“file.bmp”))
{
b.doSmth();
} // b sunaikintas čia, TIKRAI.
Aišku taip nieko nebus, jei bus daug tokių objektų.
Dauguma programerių linkę mainyti tokį kodą į nesaugų C/C++ pointerių pilną kodą. Dabar mano nuomonė: C programeriai taip sakyti gali, o C++ – ne. C++ turi alternatyvą, gal net geresnę, nei GC – smart pointeriai. Yra daug jų variantų, bet geriausiai GC atstoja ref counted smart pointeris (pvz. boost::shared_ptr). Biški apie jo veikimą. C++’e objektai, sukurti lokaliai (ant stack’o), sunaikinami, kai išeina iš scope’o – iškviečiamas jų destruktorius. Jei objektas sukurtas ant heap’o (su new), tai jį reikia pačiam sunaikinti. Čia ir buvo problema. Smart pointerių sprendimas: sukuriamas lokalus mažas objektukas ant stack’o, kuris savyje laiko pointerį, kuris rodo į didesnį objektą, sukurtą su new. Šis objektukas destruktoriuje sunaikina tą didesnį objektą. Maždaug taip:
void func()
{
boost::shared_ptr<Bitmap> bitmap
= new Bitmap(“file.bmp”);
} // iškviečiamas bitmap destruktorius,
// kuris atrodo maždaug taip:
// ~shared_ptr { delete ptr; }.
// taigi, bitmapas sunaikintas.
Shared pointeris reiškia tai, kad objektas saugo referencų skaičių, t.y. jei nori naudoti šį bitmapą, susikuri refereną į jį. Reference count padidėja iki 2, abu naudojaties objektu. Objektas nebus sunaikintas, kol refenece count > 0. Kai tik niekas juo nebesinaudoja, jis sunaikinamas. Pvz.:
void func()
{
boost::shared_ptr<Bitmap> bitmap
= new Bitmap(“file.bmp”);
func1(bitmap);
} // lokalus func1 bitmapas sunaikintas pasibaigus
// funkcijai, niekas nebesinaudoja
// bitmapu – sunaikinam jį patį.
void func1(boost::shared_ptr<Bitmap> bitmap)
{
bitmap->doSmth();
} // sunaikintas lokalusis bitmap,
// tačiau ne pats bitmapas.
Taigi, atminties, ar kokio nors kito resurso nutekėjimas praktiškai neįmanomas. Dar vienas tokio sprendimo privalumas – nebereikia finally bloko. Čia dar vienas C# minusas, ten juos reikia rašyti ir dažnai. Pvz:
SqlConnection conn = new SqlConnection(“blah”);
try {
conn.Open ();
}
finally {
conn.Close ();
// Šito gabalo reikia, nes
// neduok Dieve gausim exceptioną -
// DB liks neuždara iki pakol GC to užsinorės.
}
O štai, kaip šis kodas atrodytų naudojantis smart pointeriu:
boost::shared_ptr<SqlConnection> conn
= new SqlConnection(“blah”);
conn->Open();
Finally bloko nereikia, nes jei kodą pertrauktų exception’as – būtų išvalomas stack’as, t.y. visi lokalūs objektai būtų sunaikinti, taigi ir būtų iškviestas conn destruktorius, kuris atlaisvintų atmintį IR SqlConnection destruktorius atsijungtų nuo duomenų bazės.
Kai jau papasakojau, kaip yra, dabar nuoširdžiai prisipažinkit – kas kuria daugiau objektų su new, nei ant stack’o ? Tikrai ne aš. Mano sprendimas šiuo klausimu, dizaininat C# būtų buvęs toks: jei objektas kuriamas paprastai, jis padedamas ant stack’o, jei su new – ant stack’o kuriamas shared pointeris, kuris tvarko ant heap’o sukurtą objektą. Žinoma, būtų naudojami destruktoriai. Viso to pasekoje kalboje nebūtų tokio daikto kaip finally blokai, using() { } konstrukcijos (nes galima tiesiog sukurti naują scope’ą naudojantis {}, tačiau to nebereikia), nebeliktų resursų leakinimo.
Galbūt praleidžiu kažką svarbaus, kodėl toks sprendimas blogesnis už GC (matyt viskas daryta dėl greičio), tačiau grynai IMHO: developeriams lengviau viską kurti ant heap’o ir niekuo nesijaudinti. Tuo tarpu C++ communitis labai sėkmingai naudojasi smart pointeriais, nors ir jie turi trūkumų. Tačiau manau, jei jau jie būtų buvę kalbos dalimi, tai trūkumus būtų buvę galima panaikinti.
Tai štai va tokie mano pamąstymai.
Liepa 17th, 2005 — Nuotraukos, gyvenimas
Vieną kartą su nuotraukom pagaidino biški fotopic’as ir jų nieks nepamatė, o dabar, kai turiu 200Mb, galiu jų kraut tonom. Tai va, čia keletas fotkių iš praeito įrašo:




Na o čia, kai sakiau, dalis esmės, kodėl ten yra jėga važiuoti:

O čia naujesnių keletas, labai jaučiau tokį inspiration’ą fotkint gamtą. Čia biškis vyšnios related:



Dar biškis gamtos:



Ir šiek tiek gyvos gamtos:

(Jautries žmonėms, kuriuos gali supykinti žuvų viduriai – nežiūrėti)

(Na čia irgi gyva gamta…)

Ir čia dar, introducing sistemą anti-kurmis:

Vat tiek to kaimo, išvažiuojam.

Liepa 16th, 2005 — Įvairūs
Po ilgų planavimų pasiemiau 200Mb + domain’ą iš e-vaizdo – labai jau visi rekomenduoja, o į užsienį nenorėjau keltis. Ta proga ir patį blog’ą paleidau ant wordpress’o. Biški perkeliant įrašus problemų su koduotėm buvo, bet viskas dabar atrodo gerai. Teko pasinaudot Ginto vertimu ir temą dar pačiam paverst ir pakustomaizinti. Dabar beliko sulaukt, kol Lietblog’uose būsiu atnaujintas ir kai sakant the transformation is complete.
Liepa 11th, 2005 — gyvenimas
Gyvenam pirmam aukšte, o tai turi savų minusų, pvz. šiandien buvau prižadintas du kartus. Iš savo skaudžios patirties net sąrašą galiu surašyti kaip tai daroma:
Pvz., šiandien efektyviai buvo panaudoti metodai #2 ir #3.
Bent jau džiugu, kad Vilniuj ramesniam rajone gyvenu, ten tik vieną kartą per metus teko būti pažadintam žoliapjovės.