Podaj bloga

Podobno dzisiaj – czyli 31 sierpnia – obchodzimy międzynarodowy BlogDay. Piszę ‘podobno’, bo oficjalna strona tej inicjatywy pamięta jeszcze zeszły rok, ale chociażby ruch na Twitterze sugeruje, że nie jest to zupełnie zapomniane wydarzenie. A skoro tak, to pozwolę sobie również je zauważyć :)

Jego celebracja w założeniu polega na napisaniu notki, w której polecamy swoim czytelnikom pięć innych blogów – na przykład takich, które regularnie czytujemy. Nic prostszego, prawda? Wystarczy przecież spojrzeć na listę w swoim czytniku RSS – i już…
Cóż, niezupełnie – a przynajmniej nie w moim przypadku. Chociaż bowiem lista nie jest pusta, to nie wydaje mi się, żebym mógł się nią jakoś specjalnie chwalić. Widnieją na niej głównie klasyki, które powinny być wszystkim znane – takie jak Coding Horror czy Joel on Software – lub wyspecjalizowane blogi poświęcone wąskiemu tematowi – jak blog Nicka Johnsona o Google App Engine. Nie widzę specjalnego sensu w szczegółowym opisywaniu któregokolwiek z nich. Mógłbym co najwyżej wspomnieć o rzadko aktualizowanych perełkach w stylu Linux Hater’s czy Hyperbole and a Half, ale wolałbym nie obdarzać was zbyt wielką liczbą narzędzi wspomagających prokrastynację ;)

Dlatego też postanowiłem odwrócić “tradycję” Dnia Blogowania i poprosić czytelników o polecenie innych blogów podobnych do niniejszego – lub nawet zupełnie odmiennych, o ile tylko zachowamy ustalone proporcje (4 do 1). Przy odrobinie szczęścia długość powstałej w ten sposób listy interesujących blogów powinna o wiele rzędów wielkości przekroczyć 5 :)

Prezentacja nt. programowania UI w Androidzie

W sobotę wziąłem udział w pierwszej konferencji Appspirina – wydarzeniu poświęconemu tworzeniu aplikacji mobilnych. Ta pierwsza edycja była współorganizowana przez polski GTUG i tematycznie była związana z platformą Android, więc przypadkowo w całości pokrywała się z moimi zainteresowaniami ;)
Cieszę się więc, że mogłem tam wystąpić, prezentując wykład na temat niektórych co bardziej zaawansowanych aspektów programowania interfejsu użytkownika w Androidzie. Omówiłem tam nieco rzadziej spotykane przypadki użycia takich typowych narzędzi jak zasoby (resources), układy kontrolek (layouts) czy też różne sposoby powiadamiania użytkownika o istotnych i mniej istotnych zdarzeniach.

Na facebookowej stronie inicjatywy powinno się już pojawić kilka zdjęć, a wkrótce powinien też zostać udostępniony film z każdego z (trzech) wykładów. Póki co zamieszczam dla potomności slajdy ze swojej własnej prezentacji :)

  Zaawansowane programowanie UI na platformie Android [PL] (762.0 KiB, 13,402 downloads)

Sprzątanie śmieci nie zapobiega wyciekom

Mogę się mylić, ale wydaje mi się, że potoczne wyobrażenia na temat odśmiecaczy pamięci (garbage collectiors) obejmują przekonanie, iż zapobiegają one każdemu problemowi właściwemu dla ręcznego zarządzaniu pamięcią. Jasne, wprowadzają przy tym swoje własne – jak choćby nieustalony czas życia obiektów – ale przynajmniej zapewniają nam, że nigdy nie “stracimy” zaalokowanego kawałka pamięci… Krótko mówiąc, garbage collectory podobno chronią nas całkowicie przed zjawiskiem wycieku pamięci.

Wiadomo, że nie jest to do końca prawdą. Wspominałem o tym chociażby w swoim artykule opisującym implementację w C++ odśmiecacza opartego o zliczanie referencji. Taki mechanizm nie potrafi posprzątać obiektów powiązanych zależnościami cyklicznymi (). Jest tak dlatego, gdyż podbijają one wzajemnie swoje liczniki referencji i żaden z nich nie może w ten sposób osiągnąć zera. Nawet więc jeśli taki cykl nie jest dostępny z żadnego widocznego miejsca w programie, jego wewnętrzne odwołania będą utrzymywać go przy życiu.
To jednak dość znany przypadek, który występuje tylko w stosunkowo najprostszym mechanizmie odśmiecania. Bardziej wyrafinowane rozwiązania w rodzaju mark & sweep nie mają tej wady. Tam każda struktura odłączona od reszty programu będzie nieosiągalna dla algorytmu odśmiecacza i zostanie uprzątnięta. Z założenia eliminuje to więc wszystkie przypadki, które przy ręcznym zarządzaniu pamięcią kwalifikowałyby się jako jej wyciek.

Ale to jeszcze nie oznacza, że jakiekolwiek wycieki pamięci nie mają prawda się tu zdarzyć. Przeciwnie, są one jak najbardziej możliwe – i to ze zgoła przeciwnych powodów niż przy zarządzaniu wymagającym ręcznego zwalniania obiektów.

C++11 est arrivé!

O ile tylko ktoś nie spędził zeszłego tygodnia na Antarktydzie, w amazońskiej dżungli czy w innym podobnie odciętym od cywilizacji miejscu, z pewnością słyszał najważniejszą nowinę ostatnich lat. A już na pewno wspomnianego tygodnia – bo przecież jak tu ją nawet porównywać z takimi błahostkami jak choćby zakup Motoroli przez Google. Przecież mówimy tutaj o pomyślnym końcu procesu rozpoczętego w czasach, gdy Google nawet nie istniał! To musi robić wrażenie… I nawet jeśli owym wrażeniem jest głównie: “No wreszcie; co tak długo?!”, to przecież w niczym nie umniejsza to rangi wydarzenia.

Tak, mamy w końcu nowy standard C++! I to w sumie mogłoby wystarczyć za całą notkę, bo chyba wszystko, co można by powiedzieć na temat kolejnej wersji jednego z najważniejszych języków programowania, zostało już pewnie dawno powiedziane w dziesiątkach serwisów informacyjnych, tysiącach blogów i milionach tweetów. Znaczącą ich część zajmują omówienia nowych możliwości języka, dostępnych zresztą od jakiegoś czasu (acz w niepełnej formie) w kilku wiodących kompilatorach. Możliwości tych jest całkiem sporo i dlatego nie mam zamiaru nawet wyliczać ich wszystkich. Zdecydowałem, że w zamian przyjrzę się bliżej tylko trzem z nich – tym, które uważam za najbardziej znaczące i warte uwagi.

Nie mów mi, co jest naturalne

Powszechny stereotyp sugeruje, że programiści uwielbiają spierać się co do zalet i wad używanych przez siebie rozwiązań: języków, frameworków, bibliotek czy nawet narzędzi takich jak edytory. Zapewne jest w tym spore ziarno prawdy. Nie ma oczywiście nic złego w rzeczowej dyskusji, w której używane są racjonalne i mające podstawy argumenty. Z tym jednak nie zawsze jest tak różowo.

Jednym z często używanych, ogólnych i pasujących niemal wszędzie “argumentów” jest wspominanie o naturalności danego rozwiązania – lub o jej braku. Mam osobiście duży problem z określeniem zarysów jakichkolwiek użytecznych granic dla tego pojęcia. Nawet więcej: jest ono na tyle niedookreślone, że z niemal równym powodzeniem można by mu przypisać dwa dokładnie przeciwstawne znaczenia. Oba byłyby wprawdzie ścisłe i pozwalały jednoznacznie powiedzieć, czy coś faktycznie jest naturalne czy nie. Problem w tym, że dla wszystkich rozważanych rzeczy odpowiedź byłaby taka sama – a to już jest bezużyteczne. Predykat, który zwraca zawsze true lub zawsze false nie niesie ze sobą żadnej informacji.

Jak więc wyglądają te dwie przeciwstawne postacie?… Z jednej strony trudno zareagować inaczej niż śmiechem na wszelkie próby doszukiwania się pierwotnej Natury w takich zjawiskach jak języki programowania. Życzę powodzenia każdemu, kto próbowałby znaleźć paralele między alternatywą w rodzaju “pętla for czy funkcja map” a decyzjami, jakie musieli podejmować nasi przodkowie na afrykańskiej sawannie jakieś 200 tysięcy lat temu. Tak pojmowana naturalność wyklucza oczywiście wszystkie te rzeczy, o które tak przyjemnie jest się spierać. Pocieszmy się przynajmniej tym, że porażka w używaniu któregoś z nich nie oznacza skończenia jako posiłek dla lwa.
Z drugiej strony jednak nie widać powodu, dla którego dowolne wytwory człowieka nie miałyby być uważane za w pełni naturalnie, jeśli nie odmawiamy tego miana mrowiskom, gniazdom ptakom czy pajęczynom. To znów tworzy nam dobrze określony, jednoznaczny predykat… który jednak zawsze zwraca true, co redukuje jego przydatność do zera.

To wszystko jest oczywiście podejrzane. Jeśli pojęcie ‘naturalny’ nie służy do przekazania nawet jednego bitu użytecznej informacji, to nie powinno być w ogóle używane. Ale jest; to sugeruje, że jego cel jest inny. Może być nim na przykład ukrycie braku rzeczywistego argumentu i próba przemycenia subiektywnego punktu widzenia pod przykrywką obiektywnie brzmiącej etykiety. Słówko ‘naturalny’ brzmi bowiem lepiej niż nawet ‘intuicyjny’. Wydaje się być znacznie precyzyjniejsze (intuicje są przecież mgliste) i sprawia wrażenie odwoływania do pozornie uniwersalnych kryteriów (w przeciwieństwie do subiektywnych intuicji).
Zwykle jednak to tylko złudzenie, ukrywające brak dobrego uzasadnienia dla swoich twierdzeń. Zatem nie mów mi, co jest naturalne. Magiczne zaklęcia nie zastąpią braku rzetelnych argumentów.

Etykiety też mają adresy

Natrafiłem niedawno na kapitalną ciekawostkę, sponsorowaną przez literkę C – język C, rzecz jasna. A jeśli już o C mowa, to jednym z pierwszym skojarzeń są oczywiście wskaźniki; prawdopodobnie nie jest ono zresztą specjalnie pozytywne ;) Wśród nich mamy wskaźniki na funkcje, które znane są z kilku nieocenionych zastosowań (weźmy na przykład funkcję qsort), ale przede wszystkim z pokrętnej i niezbyt oczywistej składni.

Zalecam jednak przypomnienie jej sobie, bo dzisiaj będzie właśnie o wskaźnikach na funkcje, tyle że pokazujących na… etykiety. Tak, te właśnie etykiety (labels), które normalnie są celem instrukcji goto – złej, niezalecanej, i tak dalej. Okazuje się bowiem, że etykiety też mają swoje adresy, które w dodatku można pobrać i wykorzystać jako wskaźniki:

Wymagany jest do tego podwójny znak ampersandu (&), co można traktować jako osobny operator lub rodzaj specjalnej składni… W każdym razie jest on konieczny, aby kompilator wiedział, że następująca dalej nazwa jest etykietą. Mają one bowiem swoją własną przestrzeń nazw, co oznacza, że możliwe jest występowanie np. zmiennej start i etykiety start w tym samym zasięgu.
Przykładowym wynikiem działania programu jest poniższa linijka:

first = 0x4004f8, second = 0x4004f8, last = 0x400519

Pierwsze dwa adresy są sobie równe i nie powinno to właściwie być zaskakujące. Jak można się bowiem łatwo domyślić, adresy etykiet to w istocie adresy instrukcji, które są nimi opatrzone. Dla osób programujących w asemblerze powinno być to dziwnie znajome :) W powyższym przykładzie zarówno first, jak i second mają adresy odpowiadające położeniu w pamięci kodu wywołania funkcji printf.

Wróćmy jednak do wspomnianych wcześniej wskaźników na funkcje. Mając bowiem pobrany adres etykiety, możemy go przypisać do takiego właśnie wskaźnika. Dzięki temu możemy etykiety możemy “wywoływać”, i to nawet z innych funkcji!
Jak to jednak w ogóle działa? Ilustruje to poniższy przykład, w którym funkcja wywołuje w ten sposób sama siebie:

Po pobieżnym przyjrzeniu się widać, że jest to zwykłe liniowe przeszukiwanie tablicy, w dodatku w sposób który wygląda na rekurencyjny… Jest to jednak specjalny rodzaj tzw. rekurencji ogonowej (tail recursion). Występuje ona wówczas, gdy wywołanie rekurencyjne jest ostatnią instrukcją funkcji. Taki przypadek może być wówczas zoptymalizowany przez co sprytniejsze kompilatory poprzez wyeliminowanie konieczności ponownego odkładania argumentów na stos. Kolejny poziom rekursji wykorzystuje po prostu te same argumenty – jest to możliwe, o ile nie ma konieczności rekurencyjnych powrotów i składania kolejnych wyników.
W powyższym przykładzie rekursja ogonowa występuje jednak niezależnie od jakichkolwiek optymalizacji, gdyż jest ona zawarta w “wywołaniu” etykiety top. Chociaż pozornie wygląda to jak wywołanie funkcji, nie powoduje utworzenia dodatkowej ramki stosu ani ponownego odłożenia na nim argumentów. Docelowa “funkcja” operuje na istniejącym stosie. W istocie więc mamy tu do czynienia z pewną wersją instrukcji goto, czyli zwykłego skoku.

Ciekawiej zaczyna się robić wtedy, gdy spróbujemy “wywołać” etykietę z innej funkcji, co – jak wspomniałem – jest zupełnie możliwe. Możliwe jest wówczas gładkie przekazanie jej wszystkich parametrów oraz zmiennych lokalnych, co automatycznie podpada pod kategorię Rzeczy Podejrzanych i Potencjalnie Niebezpiecznych :) Niemniej jednak jest to możliwe:
#include

int foo = 1, i;

typedef int (*args_func)(int argc, char* argv[]);
args_func process(int argc, char* argv[]) {
if (foo == 1) {
return &&inside;
}
if (foo == -1) {
inside:
for (i = 1; i < argc; ++i) printf("Arg #%d: %s\n", i, argv[i]); } return 0; } int main(int argc, char* argv[]) { process(0, NULL)(0, NULL); // sic }[/c] Powyższy program przekazuje swoje argumenty do funkcji process (która je wypisuje) mimo iż zupełnie tego nie widać w jej wywołaniu. Zresztą normalne wywołanie tej funkcji jedynie zwraca adres jej etykiety, pod który później skaczemy z maina bez dokładania nowej ramki do stosu.

W tym kodzie jest też kilka innych smaczków (jak chociażby rola zmiennej foo), których odkrycie pozostawiam jednak co bardziej dociekliwym czytelnikom :) Zaznaczę tylko, że cała ta (chyba) niezbyt praktyczna zabawa z pobieraniem adresów etykiet jest w gruncie rzeczy rozszerzeniem GCC i nie jestem pewien, czy będzie działać w jakimkolwiek innym kompilatorze.

Implementacja przeciągania

Przedstawię dzisiaj dość elementarną technikę, związaną z szeroką pojętym programowaniem grafiki – a zwłaszcza interfejsów użytkownika. Chodzi o nic innego jak przeciąganie (dragging), czyli przemieszczanie różnych elementów za pomocą myszy czy innego urządzenia wskazującego (np. palca ;]). Celowo nie dodałem tutaj drugiej połowy procesu znanego jako drag & drop – czyli upuszczania – bo nie mam w ogóle na myśli potencjalnie zaawansowanej logiki związanej z wymianą danych reprezentowanych przez przeciągany obiekt. Przeciwnie; chodzi mi wyłącznie o samo przesuwanie go po ekranie. Rezultatem (niekoniecznie jedynym, rzecz jasna) ma być po prostu zmiana jego położenia.

W zaawansowanych systemach GUI rozwiązanie sprowadza się najczęściej do instrukcji w rodzaju obj.Draggable = true;, a cała reszta odbywa się “automagicznie”. Załóżmy jednak, że nie mamy zaawansowanego systemu GUI i dysponujemy jedynie możliwością rysowania oraz odbierania zdarzeń od wskaźnika myszy. Nie jest to wcale rzadka sytuacja: żeby nie szukać daleko, wystarczy cofnąć się o tydzień do opisu elementu <canvas> z HTML5 :) W ogólności dotyczy to jakiejkolwiek “czystej” biblioteki graficznej: OpenGL, DirectX, SDL, itp.
Doprecyzujmy jeszcze to, iż “odbieranie zdarzeń od myszy” obejmuje tak naprawdę poniższe trzy zdarzenia (lub ich odpowiedniki dla innych – np. dotykowych – sposobów wskazywania):

• wciśnięcie przycisku myszy – zdarzenie odbierane zwykle jako MouseDown
• ruch wskaźnikiem – MouseMove
• zwolnienie przycisku – MouseUp

Nietrudno zauważyć, że całkowicie wystarczają one do implementacji przeciągania. Jak więc miałaby ona wyglądać?