Pętla ‘for each’

W bardzo wielu językach dostępna jest dodatkowa postać pętli for, znana powszechnie jako foreach. Jak jej nazwa wskazuje, służy ona do przeglądania elementów jakiejś kolekcji. Różnica pomiędzy tą konstrukcją a dowolną inną pętlą jest taka, iż przeglądanie to jest zrealizowane w sposób najprostszy z możliwych:

W szczególności nie potrzeba się posługiwać żadnymi indeksami ani też jawnie stosowanymi iteratorami. Dostęp do poszczególnych elementów zbioru odbywa się za pośrednictwem symbolicznej zmiennej, która przyjmuje wartości równe tymże elementom. Proste i skuteczne.
Zresztą, niektórym twórcom języków tak się ta koncepcja spodobała, że… całkowicie zrezygnowali z tradycyjnej postaci pętli for (w wersji od-do, jak w Pascalu, lub start-warunek-inkrement, jak w językach C-podobnych).Tak jest chociażby w Pythonie; można tam jednak uzyskać identyczny efekt pętli “liczbowej” w taki oto zabawny sposób:

Ogółem jednak pętla foreach wydaje się bardzo zgrabnym wynalazkiem. Świadczy o tym chociażby istnienie takich makr jak BOOST_FOREACH, które to ładnie adaptuje cały pomysł do kontenerów STL w C++, tablic i nie tylko.
Jest jednak pewne ‘ale’. foreach sprawdza się świetnie, jeśli tylko kolekcję przeglądamy, bez dokonywania w niej zmian. Jeśli musimy przy okazji coś do niej dodać lub usunąć, lub nawet tylko zmienić wartość jakiegoś elementu, to nagle pętla taka przestaje nam wystarczać. Z doświadczenia wiem, że po tym, jak radośnie i bez wysiłku wpisuję pętlę foreach, w 80% muszę w którymś momencie i tak zmienić ją na zwykły for :-)

Sąd nad sondami

Parę tygodni temu na Warsztat powróciły sondy, dzięki czemu dołączył do zdecydowanej większości dużych (a także nieco mniejszych) serwisów, których takie ankiety są integralną częścią. A skoro to taki powszechny obrazek w Internecie, to pewnie ma on swoje uzasadnienie i sondy generalnie być powinny… No właśnie, czy aby na pewno?

Bardzo dawno temu (czyli mniej więcej na przełomie stuleci) sondy były – obok np. księgi gości – jednym ze standardowych “aktywnych” elementów stron. W czasach, gdy przeglądający sieć mogli właściwie tylko czytać i oglądać strony WWW, należały one do jednych z niewielu przejawów interaktywności innej niż same tylko linki. Wówczas pytanie o ich sens byłoby zupełnie nie na miejscu: w końcu liczy się tu fajność, a fajne jest to, w co można kliknąć ;)
Ale teraz, jak wiemy, serwisy internetowe wyglądają zupełnie inaczej i nikogo raczej nie ekscytuje kilka okrągłych przycisków i odpowiedzi, z których można wybrać jedną. Mimo tego sondy wcale nie umarły śmiercią naturalną i nadal trzymają się mocno. Dlaczego?

To chyba dosyć proste. Wystarczy sobie uświadomić, że takie ankiety mają pewne istotne cechy:

• Zazwyczaj nie dotyczą szczególnie istotnych spraw, więc nie zmuszają głosujących do wielkiego wysiłku umysłowego.
• Ich bieżące wyniki są zawsze dostępne, ale jednocześnie końcowe rezultaty rzadko mają jakiekolwiek konsekwencje – może z wyjątkiem niektórych sond dot. treści i formy serwisu, na którym są zamieszczane.
• Umożliwiają wyrażenie swojej opinii – czegokolwiek by ona nie dotyczyła – a więc pozostawienie jakiegoś ‘śladu’ na stronie przez odwiedzających.
• Nie mają wiele wspólnego z poważnym badaniem statystycznym, bo głosujący w nich prawdopodobnie nie są próbką odpowiednio losową dla danego pytania. I tak w sondach zamieszczanych na portalach ogólnych głosują tylko ci, co mają dostęp do sieci, podczas gdy w przypadku dominujących w takich ankietach “życiowych” pytań należałoby zapytać także osoby niekorzystające z Internetu, aby uzyskać jakieś istotne wyniki. Podobnie w serwisach tematycznych głosują jedynie ci, co dany serwis odwiedzają – a więc niekoniecznie reprezentatywna większość ludzi interesujących się daną tematyką.

Mamy zatem bezmyślność, interaktywność, współtworzenie i nieistotność. Toż to niemal słowa-klucze całej filozofii stojącej za Web 2.0 :) Nic dziwnego, że sondy, jako elementy w gruncie rzeczy wyprzedzające swoją epokę, dotrwały do dziś i nadal trzymają się świetnie.
A czy to dobrze, czy źle? Na takie pytanie odpowiedzieć może chyba tylko… odpowiednia sonda ;-)

Rejestracja na konferencję IGK nr 5

Od wczoraj można już korzystać z internetowej rejestracji uczestników V Ogólnopolskiej Konferencji Inżynierii Gier Komputerowych, która odbędzie się na początku kwietnia. Wprawdzie jak co roku pojawia się mnóstwo pytań i wątpliwości – dodajmy jeszcze, że zwykle tych samych: czy można płacić przelewem elektronicznym, co z noclegiem po ostatnim dniu konferencji, itd. – ale zazwyczaj były one wyjaśniane w odpowiednim czasie przez organizatorów. Miejmy nadzieję, że tak będzie i tym razem :)
Tymczasem zainteresowanych zachęcam do tego, aby nie zrażać się dziwnie wyglądającą “maskotką” konferencji i dokonać rejestracji. Jak wiadomo, ilość miejsc ograniczona ;)

Konstruktory bywają złe

Konstruktor to taka dziwna funkcja składowa, która jest wywoływana w trakcie tworzenia obiektu. Jest więc w zasadzie odpowiedzialna za jego przygotowania do użytku, czyli odpowiednią inicjalizację. Tak przynajmniej jest w teorii.
W rzeczywistości jednak konstruktor powinien robić jak najmniej. Jest tak z kilku powodów:

1. Konstruktor działa na nie w pełni utworzonym obiekcie, co sprawia, że nie zachowuje się on do końca tak, jak inne metody. Najlepszym przykładem jest to, że w konstruktorze nie działają polimorficzne wywołania funkcji wirtualnych dla obiektu, który jest tworzony.
2. Jeżeli w konstruktorze coś pójdzie źle, i zostanie wyrzucony wyjątek, to destruktor nie zostanie wywołany, aby nasz niekompletny obiekt posprzątać. Jest tak właśnie z tego powodu, że ów obiekt będzie wtedy “niezupełnie skonstruowany”, zaś destruktory w założeniu mają zwalniać tylko w pełni zainicjowane obiekty.
3. Konstruktory są wywołane w wielu różnych sytuacjach i czasami trudno jest śledzić, kiedy. Do takich sytuacji należą wszelkie instrukcje wprowadzające zmienne należące do danej klasy, konstruktory klas pochodnych, a także konstruktory klas, które zawierają instancje naszej klasy w charakterze pól. Łącznie może być ich całkiem dużo i lepiej upewnić się, że przy okazji są wykonywane tylko te czynności, które są niezbędnie konieczne.

Pewne duże obiekty mogą oczywiście wymagać skomplikowanej inicjalizacji. Wówczas, zamiast pakować całą tę logikę do konstruktora, lepiej jest prawdopodobnie oddzielić inicjalizację od właściwego tworzenia obiektu. W tym celu można go zaopatrzyć w metodę w rodzaju Create czy Load, która dokonuje właściwego przygotowania obiektu do działania.
Może wydawać się to lekkim zawracaniem głowy, ale dla nietrywialnych obiektów ma sens. Pozbywamy się wad wymienionych powyżej, a jednocześnie zyskujemy dodatkowe możliwości (choćby dlatego, że wspomniana metoda może być wirtualna).

‘No i co tu jest źle?’ w wersji książkowej

Kiedy ma się dość pokaźną biblioteczkę książek, czasami natrafia się na pozycję, która nie wiadomo skąd się w niej wzięła. Pytanie takie staje się tym bardziej uzasadnione, gdy rzeczoną książkę otworzymy, przekartkujemy i pobieżnie przeglądniemy, by po krótkim czasie uznać, że najchętniej widzielibyśmy ją w… punkcie skupu makulatury :P
Coś takiego przytrafiło mi się zupełnie niedawno. Książką o której mam taką “pochlebną” opinię, jest dziełko opatrzone tytułem Jak NIE programować w C++. Jeszcze ciekawszy jest chyba podtytuł, który mówi, że wewnątrz znajdziemy dokładnie 111 programów z błędami oraz trzy działające. Statystyka jest imponująca, ale o co tak naprawdę tutaj chodzi?… Autor przedstawia nam mianowicie coś w rodzaju zbioru koderskich zagadek do samodzielnego rozwiązania, które polegają oczywiście na znalezieniu błędu w przedstawionym kawałku kodu.

Jak podejrzewam, celem tej książki w zamyśle autora było ustrzeżenie programistów C++ przez różnego rodzaju typowymi błędami, jakie mogą się zakraść do pisanego przez nich kodu. Cel to chwalebny, chociaż dość utopijny – w końcu nie wystarczy wiedzieć, na czym błąd polega, aby w magiczny sposób już nigdy więcej go nie popełnić. Trochę więcej wątpliwości mam natomiast co do obranej metody. Nie wiem, w jaki sposób obejrzenie ponad stu błędnych kodów ma sprawić, że będziemy częściej pisali poprawny kod. Spodziewałbym się raczej podświadomego nauczenia się prezentowanych tam złych przykładów i ich spontanicznego stosowania w rzeczywistych programach, co raczej nie ułatwiłoby nikomu pracy :)
Byłoby oczywiście świetnie, gdyby przykłady te były jedynymi niepoprawnymi kawałkami kodów, z którymi przychodzi nam się mierzyć. Ale przecież jest to odległe od prawdy o całe lata świetlne. Jako koderzy sami nieuchronnie produkujemy niepoprawny kod, który co rusz musimy korygować. Prawdopodobnie więc nie potrzebujemy dodatkowych łamigłówek tego rodzaju, bo wystarczą nam te, które w nieumyślny sposób tworzymy sami dla siebie. I niestety nie możemy w ich przypadku – w przeciwieństwie do kodów z książki – zajrzeć do części końcowej po wskazówki i odpowiedzi.
Jednak nawet wobec takich mankamentów, prezentowane w książce przykłady mogłyby mieć pewną wartość poznawczą. Rzecz w tym, że naprawdę interesujące zagadki można bez trudu policzyć na palcach obu rąk. Pozostałe są albo pomyłkami aż do bólu klasycznymi (na czele z pomyleniem operatora przypisania i równości w warunku logicznym), albo trywialnymi literówkami, albo świadectwami na – delikatnie mówiąc – niekompletną znajomość języka. (Moim faworytem jest deklaracja int n = 1,000,000;, w założeniu inicjująca zmienną wartością równą milion).

Aż chce się zapytać, czy są w tej książce jakieś cechy pozytywne. Odpowiadam prędko, że jak najbardziej, tyle że mają się one nijak do jej zasadniczej treści. Do każdej zagadki autor dołączył bowiem krótką, zabawną historyjkę “z życia wziętą” lub inny śmieszny tekst – wszystko oczywiście z dziedziny IT. Paradoksalnie więc ta “książka o C++” lepiej sprawdza się jako książka z dowcipami.
Jest też druga dobra strona. Przypomniałem sobie mianowicie, skąd u mnie wzięła się ta dziwna pozycja. Otóż zakupiłem ją podczas jakichś tragów wydawniczych, które akurat odbywały się na uczelni, zapłaciwszy za nią około dziesięć złotych. Nietrudno przeboleć taką niewielką sumę, nawet mimo tego, że nikomu nie poleciłbym wydania na tę książkę nawet jednej złotówki :)

Wypadki chodzą po laptopach

Kadr z materiału tvn24

Oglądając wczoraj jeden z programów informacyjnych, przeżyłem lekki szok. Oto w jednym z materiałów dziennikarze prezentowali dwa dość ponuro wyglądające laptopy. W jednym na przykład wierzchnia warstwa pokrywy częściowo nie trzymała się reszty obudowy; w drugim zaś przez ekran przebiegała urocza rysa (i to chyba nawet niejedna).
Nie był to bynajmniej reportaż pod tytułem “Dziwne przypadki utraty danych”, a rzeczone komputery nie zostały wcale zebrane z jezdni po bliskim spotkaniu z samochodem ani wyłowione z dna morza. Oba komputery pochodziły z Ministerstwa Sprawiedliwości, a więc miejsca dalekiego od takich ekstremalnych wypadków. A stąd już o krok od wniosku, że uszkodzenia te powstały od normalnego użytkowania komputerów.

I to jest straszne! Pomyślmy tylko, że wyciągamy laptop z torby i nagle zauważamy, że ni z tego, ni z owego, obudowa ekranu wygląda tak, jakby trzymała się tylko na słowo honoru. Albo budzimy się rano i widzimy, że matryca została nie wiadomo dlaczego podzielona na pół mało efektowną rysą. A wszystko to może zdarzyć się zupełnie spontanicznie i bez żadnych wyraźnych powodów! Bo skoro wydarzyło się w tak spokojnym i nudnym miejscu jak zwykłe ministerstwo, podczas całkowicie normalnego i zgodnego ze wszystkimi normami procesu użytkowania, to przecież może zdarzyć się każdemu z nas, prawda?…
Mam aczkolwiek wrażenie, że gdyby rzeczywiście coś takiego kiedyś przytrafiło się mnie albo dowolnemu innemu, przeciętnemu użytkownikowi, to nadal mógłby to być materiał do pokazania w TVN. Tyle że nie w Faktach, a raczej w Nie do wiary ;-)