Brian W. Kernighan B, Pike R - Lekcja programowania

Helion

E

Tytuł oryginału: The Practice of Programming Tłumaczenie: Łukasz Piwko Projekt okładki: Maciej Pasek ISBN:

978-83-246-3226-8

Authorized translation from the English language edition, entitled: The Practice of Programming, ISBN 020161586X, by Brian W. Kernighan and Rob Pike, published by Pearson Education, Inc, publishing as Addison Wesley. Copyright© 1999 by Lucent Technologies. Polish language edition published by Helion S.A. Copyright©

201 1 .

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education Inc. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki le, 44-100 GLIWICE tel.

32 231 22 19, 32 230 98 63

e-mail: [email protected] WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres

http://helion.pl/user/opinie ?prapro Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Pliki z przykładami omawianymi w książce można znaleźć pod adresem:

ftp:I/ftp.helion.pl/przyklady/prapro.zip Printed in Poland.

Spis treści

Wstęp

7

1. Styl 1.1. Nazwy 1 .2. Wyrażenia i instrukcje 1 .3. Spójność i idiomy 1 .4. Makra w roli funkcji 1.5. Liczby magiczne 1 .6. Komentarze 1 .7. Dlaczego warto dbać o styl?

11 13 16 20 28 29 33 38

2. Algorytmy i struktury danych 2.1. Przeszukiwanie 2.2. Sortowanie 2.3. Biblioteki 2.4. Sortowanie szybkie w Javie 2.5. Notacja O 2.6. Tablice rozszerzalne 2.7. Listy 2.8. Drzewa 2.9. Tablice mieszania 2.10. Podsumowanie

39 40 42

3. Projektowanie i implementacja 3.1. Algorytm łańcucha Markowa 3.2. Wybór struktury danych 3.3. Budowa struktury danych w języku C 3.4. Generowanie tekstu 3.5. Java 3.6. c++ 3.7. Awk i Perl 3.8. Wydajność 3.9. Wnioski

69 70 72 73 77 79 83 86 88 89

44

47 SO

51 54 59 64 68

4

SPIS TREŚCI

4. Inteńejsy 4.1. Wartości oddzielane przecinkami 4.2. Prototyp biblioteki 4.3. Biblioteka dla innych 4.4. Implementacja w języku C++ 4.5. Zasady projektowania interfejsów 4.6. Zarządzanie zasobami 4.7. Obsługa błędów 4.8. Interfejsy użytkownika

93 94 95 99 108 112 114 117 12 1

5. Usuwanie błędów 5.1. Programy diagnostyczne 5.2. Dobre pomysły, łatwe błędy 5.3. Brak pomysłów, trudne błędy 5.4. Ostatnia deska ratunku 5.5. Błędy niepowtarzalne 5.6. Narzędzia diagnostyczne 5. 7. Błędy popełnione przez innych 5.8. Podsumowanie

125 126 127 131 135 138 140 143 144

6. Testowanie 6.1. Testuj kod podczas jego pisania 6.2. Systematyczne testowanie 6.3. Automatyzacja testów 6.4. Ramy testowe 6.5. Testowanie przeciążeniowe 6.6. Porady dotyczące testowania 6.7. Kto zajmuje się testowaniem 6.8. Testowanie programu markov 6.9. Podsumowanie

147 148 153 157 1 59 163 1 66 167 168 170

7. Wydajność 7.1. Wąskie gardło 7.2. Mierzenie czasu wykonywania i profilowanie programu 7.3. Strategie przyspieszania 7.4. Regulowanie kodu 7.5. Oszczędzanie pamięci 7.6. Szacowanie 7.7. Podsumowanie

171 172 177 181 1 84 188 191 193

8. Przenośność 8.1. Język 8.2. Nagłówki i biblioteki 8.3. Organizacja programu 8.4. Izolacja 8.5. Wymiana danych 8.6. Kolejność bajtów 8.7. Przenośność a uaktualnianie 8.8. Internacjonalizacja 8.9. Podsumowanie

195 196 202 204 208 209 210 213 215 218

SPIS TREŚCI

9. Notacja 9. 1 . Formatowanie danych 9.2. Wyrażenia regularne 9.3. Programowalne narzędzia 9.4. Interpretery, kompilatory i maszyny wirtualne

9.5. Programy, które piszą programy 9.6. Generowanie kodu za pomocą makr 9.7. Kompilacja w locie

5 221 222 228 234 237 242 246 247

A Epilog

253

B Zebrane zasady

255

Skorowidz

259

6

SPIS TREŚCI

Wstęp

Czy zdarzyło Ci się kiedykolwiek .. . zmarnować dużo czasu na pisanie niewłaściwego algorytmu? użyć zbyt skomplikowanej struktury danych? pominąć oczywisty błąd w testowanym programie? spędzić cały dzień na szukaniu takiego błędu? przerabiać program, aby działał trzy razy szybciej i zużywał mniej pamięci? przenosić program ze stacji roboczej na komputer PC albo odwrotnie? próbować wprowadzić sensowne zmiany w programie napisanym przez kogoś innego? przepisać program od nowa, bo nie dało się go zrozumieć? Fajnie było? Podobne rzeczy zdarzają się programistom nieustannie, ale nie zawsze można sobie z nimi łatwo poradzić. Główną przyczyną tego problemu jest to, że takie zagadnienia, jak testowanie, diagnostyka, przenośność, wydajność, alternatywy projektowe i styl

-

praktyka

programowa­

nia - są często na zajęciach z informatyki i programowania traktowane po macoszemu. Więk­ szość programistów uczy się tego wszystkiego przypadkiem w miarę zdobywania doświadczenia, ale są też tacy, którym zagadnienia te są całkiem obce. W świecie rządzonym przez ogromne i skomplikowane interfejsy, ciągle zmieniające się narzędzia, języki i systemy, w którym wszyscy wciąż żądają więcej wszystkiego, można łatwo zapomnieć o podstawowych zasadach stanowiących kamień węgielny dobrego oprogramowania - prostocie, przejrzystości i ogólności. Nietrudno też nie docenić rozmaitych narzędzi i nota­ cji pozwalających zmechanizować proces powstawania oprogramowania, a więc i zaprzęgnąć komputery do programowania samych siebie. Centralnym tematem książki są te trzy wzajemnie ze sobą powiązane zasady, które mają za­ stosowanie we wszystkich przypadkach korzystania z komputera. Powtórzymy je zatem jeszcze raz. Zachowanie prostoty pozwala na uzyskanie krótkiego i łatwego w obsłudze kodu. Przej­ rzystość oznacza, że kod jest łatwy do zrozumienia zarówno dla ludzi, jak i maszyn. Kod ogólny to taki kod, który dobrze działa w różnych sytuacjach i szybko adaptuje się do nowych warun­ ków. Natomiast

automatyzacja to

sztuka zmuszania maszyny do wykonywania pracy za nas, co

pozwala nam uwolnić się od wielu żmudnych zadań. Analizując techniki programowania

8

WSTĘP

w różnych językach, od algorytmów i struktur danych, poprzez projektowanie, diagnostykę i testo­ wanie do optymalizacji wydajności, możemy wyodrębnić pewne uniwersalne koncepcje progra­ mistyczne, które są całkowicie niezależne od jakiegokolwiek języka, systemu operacyjnego czy paradygmatu programistycznego. Książka ta jest owocem wieloletniego doświadczenia w pisaniu i obsłudze licznych pro­ gramów, prowadzenia zajęć z programowania oraz współpracy z szerokim gronem programi­ stów. Chcemy podzielić się naszą praktyczną wiedzą, dać Ci możliwość skorzystania z naszego doświadczenia oraz wskazać zarówno bardziej, jak i mniej doświadczonym programistom, jak biegle opanować sztukę produktywnego pisania programów. Książka jest przeznaczona dla różnych grup czytelników. Dla studentów po kursach pro­ gramowania, chcących zwiększyć swoje umiejętności, ponieważ znajdą tu opis zagadnień, na które w szkole zabrakło czasu. Dla osób piszących programy w pracy, ale dla których nie jest to główne zajęcie, gdyż będą mogły zwiększyć efektywność swojej pracy. Dla zawodowych pro­ gramistów, którzy odczuwają braki w wiedzy na ten temat albo chcieliby odświeżyć wiadomości, a także dla kierowników projektów programistycznych chcących właściwie kierować swoimi zespołami. Mamy nadzieję, że zdobyte dzięki tej książce wiadomości pomogą Ci pisać lepsze progra­ my. Jedynym warunkiem wstępnym do jej przeczytania jest trochę doświadczenia programi­ stycznego, najlepiej w językach C, C+ + lub Java. Oczywiście im większe doświadczenie, tym łatwiej przyswoisz sobie tę wiedzę. Nie da się przejść od poziomu początkującego do profesjo­ nalisty w ciągu miesiąca. Niektóre z prezentowanych przykładów będą lepiej przemawiać do programistów pracujących w systemach Unix i Linux niż tych, którzy używają Windowsa lub systemu Mac OS, ale ogólnie rzecz biorąc, każdy powinien tu znaleźć coś dla siebie. Publikacja jest podzielona na dziewięć rozdziałów, z których każdy został poświęcony osob­ nemu aspektowi praktyki programowania. Rozdział 1. traktuje o stylu programowania. Zdecydowaliśmy się omówić ten temat już na samym początku, gdyż jest on niezwykle ważny. Dobrze napisany program jest zawsze lepszy od źle napisanego - ma mniej błędów i łatwiej się go modyfikuje i diagnozuje - dlatego od samego początku należy stosować dobry styl. Ponadto wprowadzamy pojęcie idiomów, które można znaleźć w praktycznie każdym języku. Algorytmy i struktury danych, które będą tematem rozdziału

2., to podstawowy przedmiot

w programie nauczania informatyki i jeden z najważniejszych w kursach programowania. Jako że wiedza ta nie jest obca większości czytelników, ograniczymy się tylko do krótkiego przypo­ mnienia kilku algorytmów i struktur danych, które można znaleźć w prawie każdym progra­ mie. Na ich bazie powstają później bardziej złożone algorytmy i struktury, dlatego opanowanie podstaw jest tak bardzo ważne. W rozdziale

3.

przedstawimy analizę projektu i implementacji niewielkiego programu, aby

pokazać zagadnienia związane z algorytmami i strukturami danych w realistycznym ujęciu. Program zaimplementujemy w pięciu językach, aby mieć możliwość porównania w nich pracy ze strukturami danych oraz zobaczenia, jak różnią się one między sobą pod względem ekspre­ sywności i wydajności. Fundamentalne znaczenie w programowaniu mają interfejsy łączące użytkowników, pro­ gramy i części programów, i dlatego właśnie sukces oprogramowania w dużej mierze zależy od ich jakości. W rozdziale

4.

pokażemy, jak rozwijała się niewielka biblioteka do przetwarzania

często używanego formatu danych. Przykład ten, mimo iż jest krótki, posłuży nam do zilu­ strowania wielu zagadnień związanych z projektowaniem interfejsów - abstrakcji, ukrywania informacji, zarządzania zasobami oraz obsługi błędów.

WSTĘP

9

Choć byśmy nie wiadomo jak się starali od samego początku, nie unikniemy błędów, a więc i konieczności przeprowadzenia diagnostyki kodu. W rozdziale 5. opisujemy techniki systema­ tycznego i skutecznego wykrywania błędów. M iędzy innymi poruszymy temat najczęściej wy­ stępuj ących błędów oraz omówimy metodykę polegającą na wykorzystaniu faktu, że w danych zwracanych przez narzędzia diagnostyczne można wyodrębnić pewne wzorce pomagające zna­ leźć przyczynę problemów. Testowanie to zestaw czynności maj ących na celu zapewnienie, na ile się da, że program działa poprawnie i będzie tak działał w toku rozwoj u. W rozdziale 6. kładziemy nacisk na ko­ nieczność systematycznego testowania oprogramowania zarówno własnoręcznie, jak i maszynowo. Testy wartości brzegowych pozwalaj ą wykryć słabe punkty programu. A utomatyzacj a i platformy testowe ułatwiają przeprowadzanie wyczerpuj ących testów przy względnie małym wysiłku. Te­ sty obciążeniowe umożliwiają natomiast przeprowadzenie diagnostyki w innym niż typowy zakresie oraz wykrycie całkiem innego rodzaju błędów. Dzięki szybkości dzisiej szych komputerów i wysokiej jakości kompilatorów większość pro­ gramów od razu po napisaniu działa na tyle szybko, że nie trzeba nic poprawiać . Zdarzają się też jednak takie, które mimo tego działaj ą za wolno lub zajmują zbyt dużo pamięci, albo j edno i drugie. W rozdziale 7. prezentujemy systematyczną metodę optymalizacji wykorzystania za­ sobów, pozwalaj ącą zachować poprawność i niezawodność kodu. W rozdziale 8. opisujemy zagadnienie przenośności programów. Dobre programy pozostaj ą w uŻytku na tyle długo, że może się zmienić środowisko ich uŻytkowania albo ktoś zechce je przenieść do nowego systemu, na nowy sprzęt albo dostosować do użytku w innej wersji języ­ kowej. Zapewnianie programom przenośności ma na celu redukcję liczby czynności, których wykonanie jest konieczne, aby dostosować je do działania w potencjalnych nowych warunkach. Liczba języków programowania jest bardzo duża. M ożna wśród nich znaleźć zarówno języ­ ki ogólnego przeznaczenia, przy użyciu których pisze się większość programów, j ak i j ęzyki specjalistyczne, których zastosowanie ogranicza się do wąskich dziedzin. W rozdziale 9. poka­ zujemy, jak ważna w programowaniu jest odpowiednia notacja. Jeśli jest dobrze dobrana, po­ zwala uprościć kodźródłowy, ułatwia implementację, a nawet może nam pomóc utworzyć pro­ gramy piszące inne programy. A by móc mówić o programowaniu, trzeba pokazać dużo przykładów kodu. Większość z nich została napisana specjalnie na potrzeby tej książki, ale jest też kilka takich, które przeję­ liśmy z innych źródeł. Dołożyliśmy wszelkich starań, aby ten kod był dobrze napisany i prze­ testowaliśmy go w kilku systemach bezpośrednio w postaci tekstu maszynowego. Większość programów napisano w j ęzyku C, kilka w C+ + i wJavie, a nieliczne także w ję­ zykach skryptowych. N a najniższym poziomie języki C i C++ prawie niczym się nie różnią, dzięki czemu wszystkie nasze programy w C można również skompilować w kompilatorze języ­ ka C+ +. C+ + iJava wywodzą się w prostej linii od języka C. M ają bardzo podobną do swoj e­ go przodka ekspresywną składnię i wydajność, ale są bogatsze w typy danych i biblioteki. Te trzy języki i wiele innych to dla nas chleb powszedni w codziennej pracy. Wybór języka programowania zależy od problemu, który chcemy rozwiązać, np. systemy operacyjne najlepiej pisać przy użyciu wydaj nych i nieograniczających języków, takich j ak C i C++. Do szybkiego tworzenia prototypów naj lepiej używać interpretera poleceń i j ęzyków skryptowych, takich jak A wk i Perl. Jeśli chodzi o interfejsy użytkownika, prym wiodą Visual Basic i Tcl/Tk, a także Java. Wybór języków do implementacji przykładów ma też podłoże pedagogiczne. Podobnie jak nie każdy problem da się rozwiązać równie dobrze przy użyciu każdego języka, tak nie każdy język jest idealny do naj lepszego przedstawienia każdego problemu. Języki wysokiego poziomu zdejmuj ą z programisty obowiązek podejmowania niektórych decyzji proj ektowych. Jeśli na­ tomiast użyj emy j ęzyka niskopoziomowego, musimy niekiedy wybrać jedną z kilku możliwości. Dzięki uwidocznieniu większej liczby szczegółów możemy j e lepiej omówić . Z doświadczenia

10

WSTĘP

wiemy, że nawet wówczas, gdy używamy wysokopoziomowych elementów języka, często po­ maga nam wiedza o tym, jak się one łączą z elementami niskopoziomowymi. Bez tej wiedzy można łatwo nabawić się problemów z wydajnością albo doprowadzić do pozornie dziwnego działania programu. Dlatego w wielu przypadkach, w których normalnie użylibyśmy jakiegoś innego języka, przykłady będziemy prezentować w językuC. M imo to większość materiału w tej książce nie jest związana z jakimkolwiek konkretnym językiem programowania. Strukturę danych wybiera się taką, na jaką pozwala używany język. W jednym języku programowania do wyboru może być wiele takich struktur, a w innym znacznie mniej, ale ogólne zasady dokonywania wyboru zawsze są takie same. Techniki testo­ wania i wykrywania błędów mogą być odmienne w różnych językach, ale strategia i taktyka ich stosowania pozostają bez zmian. Większość technik optymalizacji wydajności programu można zastosować w każdym języku programowania. Bez względu na to, jakiego języka programowania używasz, Twoim obowiązkiem jest wyko­ rzystać dostępne narzędzia najlepiej, jak się da. Dobry programista potrafi poradzić sobie z ograni­ czeniami słabego języka i nieprzyjaznym systemem operacyjnym, natomiast nawet najlepsze środowisko programistyczne nic nie pomoże, jeśli programista ma mierne umiejętności. M amy nadzieję, że książka ta pomoże Ci stać się lepszym programistą i czerpać więcej radości z pro­ gramowania, niezależnie od tego, jaki poziom umiejętności aktualnie prezentujesz. Jesteśmy bardzo wdzięczni naszym znajomym i kolegom z pracy, którzy przeczytali i sko­ mentowali pierwsze wersje maszynopisu. Jon Bentley, Russ Cox, John Lakos, John Linder­ man, Peter M emishian, I an Lance Taylor, Howard Trickey i Chris van Wyk zrobili to wiele razy, zawsze zachowując wyjątkową wnikliwość i skrupulatność . N astępujące osoby zasłużyły z kolei na naszą wdzięczność za cenne uwagi zgłaszane na różnych etapach powstawania tekstu: Tom Cargill, Chris Cleeland, Steve Dewhurst, Eric Grosse, A ndrew Herron, Gerard Holzmann, Doug M cllroy, Paul M cN amee, Peter N elson, Dennis Ritchie, Rich Stevens, Tom Szymanski, Kentaro Toyama, John Wait, Daniel C. Wang, Peter Weinberger, M argaret Wright oraz Cliff Young. Wreszcie A l A ho, Ken A rnold, Chuck Bigelow, Joshua Bl och, Bill Coughran, Bob F landrena, Renee F rench, M ark Kernighan, A ndy Koenig, Sape M ullender, Evi N emeth, M arty Rabinowitz, M ark V. Shaney, Bjarne Stroustrup, Ken Thompson oraz Phil Wadler wspomagali nas dobrymi radami i mądrymi sugestiami. DziękujemyWam wszystkim.

Brian W Kerniglzan RobPike

Styl

Od dawna wiadomo, że najlepsi pisarze często mają za nic zasady retoryki. Zawsze jednak dają czytelnikowi coś w zamian, coś, co wynagrodzi mu to barbarzyństwo. Kto nie ma pewności, że robi to równie dobrze, lepiej jeśli będzie trzymał się tych zasad.

William Strunk i E.B. White, The Elements of Style

Otofr agment kodu z pewnego bardzo starego programu:

(country (country

if

SING) POL) I I

(country = = BRN I ) I (country == ITALY) )

/* * Jeśli kraj to Singapur, Brunei lub Polska, * to aktualny czas jest czasem odpowiedzi, * a nie czasem połączenia. * Zresetuj czas odpowiedzi i ustaw dzie11 tygodnia. */

Kod ten został starannie napisany, sformatowany i opatrzony komentarzem, a program, z którego pochodzi , dzi ała bardzo dobrze. Programi ści, którzy go napi sali, są z niego bardzo dumni i mają do tego powody. A jednak ten fr agment dla przy padkowego czytelnika jest niejasny. Co mają ze sobą wspólnego taki e kraje, jak Singapur, Brunei, Pol ska i Włochy? Czemu w ko­ mentarzu nie ma nic na temat Włoch? Skoro i stnieje rozbi eżność między kodem a komenta­ rzem, któryś z nich musi zawierać błąd. Ni ewykluczone, że ma go jeden i drugi . Choci aż bar­ dzi ej prawdopodobne, że błąd znajduje się w komentarzu, poni eważ kod został przetestowany i dzi ała. N ajprawdopodobniej ktoś zapomniał po zmi enieni u kodu zaktuali zować komentarz. Ni e ma w nim wystarczających informacji na temat tego, co wiąże trzy wymieni one kraje. Gdybyśmy mieli zmodyfikować ten fragment, musielibyśmy uzyskać o nim dodatkowe i nfor­ macje. Tych kil ka wi erszy reprezentuje bardzo często spotykane zjawisko- całkiem dobrze napi ­ sany kod, który jednak można by było gdzieniegdzi e poprawić .

12

1 . STYL Tematem tej ksi ążki j est praktyka programowani a, czyli pi sani e programów do praktycz­

nego użytku. N aszym celem j est pi sani e programów dzi ałaj ących przynaj mni ej tak dobrze, j ak przedstawi ony w przykładzi e, ale pozbawi onych j ego wad i słabych punktów. Będzi emy uczyć si ę od samego początku pi sać j ak naj lepszy kodi doskonali ć go w trakci e j ego rozwoj u. Zaczni emy j ednak w dość ni ezwykły sposób, gdyż na początek omówi my zagadni eni e stylu. Zadani em stylu, który stanowi podstawę dobrego programowani a, j est zapewni eni e łatwości czytani a kodu nami i nnym. Zaj muj emy si ę ni m na samym początku, aby wtrakci e czytani a pozo­ stałej części ksi ążki Czytelni k był wyczulony na zwi ązane z ni m kwesti e. A by napi sać program , ni e wystarczy tylko zastosowani e poprawnej składni , poprawi eni e błędów i zoptymali zowani e szybkości dzi ałani a. Oprócz komputerów programy czytaj ą także programi ści . Jeśli kod źródłowy j est dobrze napi sany, to czyta si ę go i modyfi kuj e o wi ele ła­ twi ej ni ż kod napi sany źle. Dyscypli na przy pi sani u wysoki ej j akości kodu zwi ększa prawdo­ podobi eństwo uni kni ęci a błędów. N a szczęści e utrzymani e tej dyscypli ny j est ni etrudne. Zasady stylu programowani a są wyni ki em zdrowego rozsądku i praktycznych obserwacji , a ni e arbi tralni e przyj ętym zbi orem reguł i przepi sów. Kod źródłowy powi ni en być prosty i przej ­ rzysty, a wi ęc odznaczać si ę ni eskompli kowaną logi ką, naturalną ekspresj ą, konwencj onalnym sposobem użyci a elementów j ęzykowych, dobrze dobranymi nazwami , zgrabnym formatowa­ ni em i pomocnymi komentarzami , a przede wszystki m ni e powi nno w ni m być żadnych spryt­ nych sztuczek i ni etypowych konstrukcji . Ważną rolę odgrywa spój ność , poni eważ j eśli wszy­ scy będą stosować si ę do tych samych reguł, każdemu będzi e łatwi ej zrozumi eć kod napi sany przez kogoś i nnego. O pewnych szczegółach mogą decydować lokalne konwencj e, zarządzeni a ki erowni ctwa albo sam program, ale mi mo to zawsze warto trzymać si ę zbi oru szeroko przyj ę­ tych konwencji . Będzi emy stosować styl opi sany w ksi ążceJęzyk programowania

C z drobnymi

poprawkami dlaj ęzykówc+ + i Java. Często będzi emy pokazywać obok si ebi e przykład zarówno dobrego, j ak i złego stylu pro­ gramowani a, gdyż taki e kontrastowe zestawi eni a są bardzo pouczaj ące. Ni e będą to sztuczne twory, a fragmenty realnych programów napi sanych przez zwyczaj nych programi stów( czasami nas) pracuj ących w typowych warunkach stresowych, a wi ęc przy dużej i lości pracy i małej i lo­ ści czasu. Ni ektóre z ni ch ni eco okroi my dla zachowani a klarowności , ale to ni e oznacza, że będą błędni e zi nterpretowane. Wszystki e źle napi sane ury wki zostaną poprawi one. Poni eważ j ednak kod, o którym będzi e mowa, pochodzi z prawdzi wych proj ektów, może w ni m być wi ele wątpli wych elementów. Gdybyśmy chci eli odni eść si ę do ni ch wszystki ch, musi eli byśmy zbyt­ ni o odej ść od tematu, dlatego w ni ektórych przykładach określonych j ako dobre wci ąż mogą kryć si ęj aki eś ni eopi sane usterki. A by wyraźni e odróżni ć złe przykłady od dobrych, każdy wi ersz kodu budzącego wątpli wo­ ści poprzedzi li śmy znaki em zapytani a, j ak w poni ższym fragmenci e programu:

#defi ne ONE 1 #defi ne TEN 10 #defi ne TWENTY 20 Co j est ni e tak z tymi defini cj ami ? Wyobraź sobi e, co trzeba by zmi eni ć , gdybyśmy chci eli tabli cę o aktualnym rozmi arze dwudzi estu elementów (TWENTY) trochę powi ększyć . A by po­ prawi ć ten kod, powi nni śmy przynaj mni ej zmi eni ć nazwy wszystki ch wartości na nazwy odzwi er­ ci edlaj ącei ch rolę w programi e:

#defi ne I NPUT-MODE 1 #defi ne I NPUT-BUFS I Z E 10 #defi ne OUTPUT-BUFS I Z E 20

13

1.1. NAZWY

1.1. Nazwy Czym jest nazwa? N azwa fu nkcji lub zmiennej stanowi etykietę obiektu i przekazuje informa­ cję o jego przeznaczeniu. Powinna dobrze oddawać zastosowanie elementu, być zwięzła oraz dać się łatwo zapamiętać i wymówić , jeśli to możliwe. Wiele informacji można wywnioskować z kontekstu i zakresu dostępności. I m szerszy zakres dostępności zmiennej, tym więcej infor­ macji powinna przekazy wać jej nazwa.

Stosuj nazwy deskryptywne dla zmiennych globalnych i krótkie nazwy dla zmiennych lo­ kalnych. Zmienne globalne z defi nicji mogą występować w każdym miejscu programu, a więc ich nazwy powinny być na tyle długie i nasycone informacją, aby czytający kod mógł się zo­ rientować , do czego służą. Warto też przy deklaracjach takich zmiennych dodawać komentarze:

npend i ng

i nt

; O;

li Aktualna długość kolejki wejściowej

Także fu nkcje, klasy i struktury globalne powinny mieć nazwy deskryptywne, pozwalające odgadnąć ich rolę w programie. N atomiast w przypadku zmiennych lokalnych wystarczające są nazwy krótkie. Jeśli defi­ niujemy zmienną wewnątrz fu nkcji, to nazwa n może być wystarczająca,

npoi nts

jest w sam

raz, a n umberOf Poi nts to już przesada. N azwy konwencjonalnych zmiennych lokalnych mogą być bardzo krótkie. N a przykład nazwy i ij dla zmiennych pętlowych,

p iq

dla wskaźników oraz s i t dla łańcuchów stosuje się

tak często, iż zamiana ich na dłuższe nie dość , że nie przyniesie pożądanego ef ektu, to jeszcze może mieć wręcz odwrotny skutek. Porównajmy:

for ?

(theEl ementindex ; O ; theEl ement i ndex < numberOfEl ement s ; theEl ement i ndex++) el ementArray [theEl ement i ndex] ; theEl ement i ndex;

z

for ( i e l em [ i ]

O; i;

<

nel ems ;

i ++)

Programistów często zachęca się do stosowania długich nazw, bez względu na kontekst ich użycia. To jest błąd- przejrzystość często uzyskuje się poprzez zwięzłość . I stnieje wiele konwencji nazewniczych i lokalnych zwyczajów. M iędzy innymi wskaźni­ kom nadaje się nazwy zaczynające się od litery p lub się na nią kończące, np. zmiennych G l obal nych zaczyna się od wielkiej litery, a nazwy

STAŁYCH

nodep;

nazwy

pisze się w całości

wielkimi literami. N iektórzy stosują jeszcze bardziej wyszukane zasady nadawania nazw i ko­ dują w nich np. informacje o typie i sposobie użycia zmiennej. Wówczas nazwapch może ozna­ czać wskaźnik na znak, a nazwy strTo i strFrom - łańcuchy do zapisu i odczytu. Jeśli chodzi o zasady typografi czne, tj. czy pisać

npend i ng, n umPendi ng

czy num_pendi ng, to jest to sprawa

gustu. Ważne jest nie to, jaką konkretną konwencję zastosujemy, lecz to, aby wybrać jedną i stosować ją zawsze. Spójne konwencje nazewnicze pomagają w czytaniu nie tylko własnego kodu, lecz także kodu napisanego przez innych programistów. Ponadto ułatwiają wymyślanie nowych nazw w trakcie pisania kodu. I m program dłuższy, tym większe znaczenie ma systematyczny wybór dobrych i deskryptywnych nazw.

14

1 . STYL

w językach c++ i Java stosowanie klarownych i deskryptywnych nazw o odpowiedniej długości ułatwiają techniki zarządzania zakresem dostępności zmiennych w postaci pakietów Gava) i przestrzeni nazw(C+ +).

Bądź konsekwentny. Jeśli elementy są

ze sobą powiązane, nadaj im nazwy, które to powiąza­

nie odzwierciedl ają, a przy okazji zaznacz to, co je różni. Oprócz tego, że są zbyt długie, nazwy składowych w poniższej klasie wJavie są kompletnie niespójne:

?

cl ass UserQueue C i nt noOfiterns i nQ , frontOi TheQueue, queueCapaci ty ; publ i c i nt noOfUsers InQueue ( ) { . . . }

Słowo oznaczające kolejkę( ang.

queue) występuje w trzech postaciach: Q, Queue oraz queue.

Ponieważ jednak dostęp do kolejek można uzyskać wyłącznie przy użyciu zmiennej typu

UserQueue,

w nazwach składowych w ogóle nie trzeba używać żadnego oznaczenia kolejki, wy­

starczy sam kontekst, w związku z czym zapis

queue . queueCapaci ty jest zbędny. Lepsza jest taka wersja:

cl ass UserQueue { i nt ni terns , front , capaci ty ; publ i c i nt nusers ( ) { . . } .

T eraz można pisać instrukcje tego rodzaju:

queue. capaci ty++ ; n = queue.nusers ( ) ; N ie straciliśmy nic z kl arowności. A le to nie wszystko, co należy tu poprawić

-

i t ems

i u sers oznaczają to samo, a do oznaczania jednego pojęcia należy używać tylko jednej nazwy.

Do nazywania funkcji używaj czasowników. N azwyfu nkcji powinny tworzyć

czasowniki ozna­

czające aktywne czynności, po których mogą występować rzeczowniki:

now = date . getT i me ( } ; putchar( ' \n ' } ; N azwy fu nkcji zwracających wartości logiczne ( prawda lub fałsz) nie powinny pozostawiać wątpl iwości co do sposobu interpretacji wyniku. N a przykład instrukcja

i f (checkoctal (c) ) . . . nie wskazuje, która wartość jest prawdą, a którafałszem, natomiast

i f ( i soctal (c) ) . . .

15

1.1. NAZWY

jasno sygnalizuje, że fu nkcja zwraca prawdę, jeśli argument jest w formacie ósemkowym, lub fałsz w przeciwnym razie.

Dbaj o precyzję.

N azwa to nie tylko etykieta, lecz także przekaźnik informacji dla czytającego.

Jeśli nazwy są mylące, mogą prowadzić do powstawania trudnych do rozwikłania błędów. Jeden z nas napisał i przez wiele lat rozpowszechniał makro o nazwie i soc ta 1 o następującej niepoprawnej implementacji:

#defi ne

i soctal (c) ( (c )

>=

'O'

&&

(c)

<=

181)

Poprawnie jest:

#defi ne

i soctal (c) ( (c)

>=

' O' &&

(c)

<=

'7')

N azwa w tym przypadku była poprawna, ale gorzej było z implementacją. Łatwo zamasko­ wać dobrze dobraną nazwą błędy w implementacji. Oto przykład, w którym nazwa i kodźródłowy pozostają w wyraźnej sprzeczności:

publ i c boo l ean i nTab l e (Obj ect obj ) i nt j = thi s . getlndex(obj ) ; return (j == nTab l e) ;

F unkcja o nazwie getlndex zwraca wartość z przedziału od zera do n Tab 1 e - 1, jeśl i znajdzie obiekt, lub nTabl e w przeciwnym razie. Wobec tego wartość logiczna zwracana przez i

nTabl e

jest przeciwieństwem tego, na co wskazuje nazwa. W trakcie pisania kodu coś takiego raczej nie wywoła problemu, al e gdy później ktoś inny zechce zmodyfikować ten program, kłopoty są murowane.

Ćwiczenie I.I. Skomentuj dobór nazw i wartości w poniższym kodzie. ? ?

#defi ne TRUE O #defi ne FALSE 1

?

i f ( (eh = getcha r ( ) ) not_eof = FALSE;

EOF)

Ćwiczenie 1.2. Popraw t ęfu nkcję: i nt smal l er (char * s , char *t) i f (strcmp ( s , t) < 1) return l; el se return O ;

Ćwiczenie 1.3. Przeczytaj ten kod n a głos: i f ( (fal l oc (SMRHSHSCRTCH , S_FEXT I 0644 , MAXROOOHSH) ) < O)

16

1. STYL

1.2. Wyrażenia i instrukcje Podobnie jak nazwy należy dobierać w taki sposób, aby jak najbardziej ułatwiały zrozumienie kodu, wyrażenia i instrukcje trzeba pisać tak, by ich znaczenie było możliwie jak najbardziej przejrzyste. Pisz najprostszy kod, który wystarczy do wykonania określonego zadania. Wokół operatorów wstawiaj spacje, aby zaznaczyć grupowanie argumentów, a mówiąc bardziej ogólnie - stosuj czytelne formatowanie. M oże to jest oczywiste, ale bardzo pomaga. To tak jak utrzy­ mywanie porządku na biurku ułatwia znajdowanie na nim rzeczy. Jednak w odróżnieniu od przykładu z biurkiem, istnieje duże prawdopodobieństwo, że ktoś będzie analizował Twoje programy.

Stosuj wcięcia, aby uwidocznić strukturę kodu. N ajłatwiejszym sposobem na sprawienie,

aby

struktura kodu mówiła sama za siebie, jest zastosowanie wcięć . Poniżej widać przykład złego formatowania:

for (n++ ; n
for (n++ ; n < 100; fi el d [n++] = ' \O ' ) * i = ' \O ' ; return ( ' \n ' ) ; Jeszcze lepiej, gdybyśmy przypisanie umieścili w treści pętli i oddzielili inkrementację, dzięki czemu pętla przybrałaby bardziej typowąformę i była łatwiejsza do zrozumienia:

for (n++ ; n < 100; n++) fi el d [n] = ' \O ' ; *i = ' \O ' ; return ' \n ' ;

Naturalnie formatuj wyrażenia.

Pisz wyrażenia tak, aby dały się odczytać na głos. Do naj­

trudniejszych do zrozumienia zaliczają się wyrażenia zawierające negację:

i f ( ! (bl ock_i d < actbl ks) I I ! (bl ock_i d >= unbl ocks ) )

Oba testy są zapisane z negacją, chociaż żaden nie musi. Jeśli pozamieniamy relacje, to bę­ dziemy mogli zapisać wyrażenie bez negacji:

i f ( (bl ock_i d >= actbl ks) I I (bl ock_i d < unbl ocks ) )

Teraz kod czyta się naturalnie.

Stosuj nawiasy, aby uniknąć dwuznaczności. N awiasy służą do grupowania elementów i mo­ gą pomóc w wyklarowaniu wyrażeń nawet wówczas, gdy nie sąformalnie wymagane. W powyż­ szym wyrażeniu wewnętrzne nawiasy nie były konieczne, ale też i w niczym nie zaszkodziły.

17

1.2. WYRAŻENIA I INSTRUKCJE

Doświadczeni programiści mogliby je opuścić, bo wiedzą, że operatory relacji( <, <=, ==, >, >=) mają wyższy priorytet od operatorów logicznych( &&i11). Jeśli jednak w wyrażeniu używane są niepowiązane ze sobą operatory, warto zastosować nawiasy. W języku C i jemu podobnych występuj ą bardzo poważne problemy z określaniem kolejności wykonywania działań, przez co niezwykle łatwo popełnić błąd. Ponieważ operatory logiczne wykazują ściślejsze wiązanie niż operator przypisania, w większości wyrażeń, w któ­ rych są one stosowane razem, nawiasy są obowiązkowe:

whi l e ( ( c = getchar( ) ) ! = EOF)

Operatory bitowe & i

maj ą niższy priorytet od operatorów relacj i, takich jak==, a więc

wbrew pozorom wyrażenie

?

i f (x&MASK == BITS)

zostanie zinterpretowane jako

i f (x & {MASK==BITS) )

co z pewnością nie było zamierzeniem programisty. Ze względu na jednoczesną obecność operatorów bitowych i relacji wyrażenie należy uzbroić w nawiasy:

i f ( (x&MASK) == BITS)

N awiasy mogą pomóc w zrozumieniu wyrażenia nawet wówczas, gdy nie są formalnie wy­ magane. W poniższym kodzie nie musimy stosować nawiasów:

l eap_year

=

y % 4 == O && y % 100 ! = O I I y % 400 == O ;

alej eśli ich użyj emy, wyrażenie będzie o wiele bardziej klarowne:

l eap_year

=

( (y%4 == O) && (y%100 ! = O) ) I I {y%400 == O} ;

Usunęliśmy też niektóre spacj e - grupowanie argumentów operatorów o wyższym priory­ tecie również pomaga czytaj ącemu w rozpoznaniu struktury.

Dziel skomplikowane wyrażenia. Języki C, C+ +

i Java mają ekspresywną składnię i bogaty

zestaw operatorów, przez co łatwo jest dać się ponieść i upchać wszystko, co można, w jednej konstrukcji. Poniższe wyrażenie jest bardzo zwięzłe, ale upchano w nim zbyt wiele operacji:

*x += {*xp= (2*k < (n-m) ? c [k+l] : d [k--] } ) ; Łatwiej to zrozumieć po podzieleniu na kilka wierszy:

18

1. STYL

i f (2*k < (n-m) *xp = c [k+l ) ; el se *xp = d [k--] ; *x += *xp ;

Pisz klarownie.

Programiści mają niespożyte pokłady kreaty wnej energii, którą często wyko­

rzystują na pisanie jak najzwięźl ejszego kodu al bo znajdowanie sprytnych sztuczek pozwal ają­ cych osiągnąć żądany wynik. Czasami jednak źl e inwestują swoje tal enty, ponieważ cel em po­ winno być uzyskanie przejrzystego, a nie sprytnego kodu. Co robi poniższy misternie utkanyfr agment kodu?

subkey = subkey >> (bi toff - ( (b i toff >> 3) << 3 ) ) ; N ajgłębiej położone wyrażenie przesuwa wartość

b i to ff

o 3 bity w prawo. Wynik ten zo­

staje następnie przesunięty z powrotem w l ewo, co powoduje zastąpienie trzech przesuniętych bitów zerami. Ten wynik z kol ei zostaje odjęty od oryginal nej wartości, czego rezul tatem są 3 dol ne bity wartości bi

to ff. Bity te są użyte do przesunięcia wartości s ub key

w prawo.

Wyrażenie to jest równoważne z poniższym:

sub key = subkey >> (bi toff & Ox7 ) ; A by zrozumieć pierwszą wersję, trzeba się trochę pogłowić . Druga natomiast jest krótsza i kl arowniejsza. Doświadczeni programiści zapisują to jeszcze krócej, używając operatora przypisania:

subkey >>= bi toff & Ox7 ; N iektóre konstrukcje sprawiają wrażenie, jakby wręcz prosiły się o błędy. Zwłaszcza kod z operatorem ? : bywa zagadkowy:

chi l d= ( ! LC&& ! RC) ?O: ( ! LC?RC : LC) ; Bez prześl edzenia prawie wszystkich możl iwych ścieżek wykonania tego wyrażenia nie da się chyba rozszyfrować, co ono robi. Poniższa postać jest dłuższa, al e znacznie łatwiejsza do rozszyfr owania, ponieważ wyraźnie są w niej zaznaczone ścieżki wykony wania:

i f ( LC == O chi l d = el se i f (LC chi l d el se chi l d

&& RC == O) O; = = O) RC ; LC ;

Operator ? :

dobrze nadaje się do pisania krótkich wyrażeń, w których pozwal a jednym

wierszem zastąpić cztery wiersze instrukcji i f-el se:

max = ( a > b) ? a

:

b;

1.2.

19

WYRAŻENIA I INSTRUKCJE albo

pri ntf ( "Li sta zawi era %d el ement%s\n" , n , n==l ? " " : " 6w" ) ; N ie należy goj ednak traktować j ako tradycyj nego zastępnika instrukcj i warunkowych. Klarowność to nie to samo co zwięzłość. Czasami klarowniej szy kod j est krótszy, j ak było w przypadku przesuwania bitów, ale może też być dłuższy, j ak w przypadku wyrażenia warun­ kowego zapisanego za pomocą instrukcj i i f-el s e. N ależy się kierować tym, która z wersj i za­ pewnia większą czytelność kodu.

Uważaj na efekty uboczne. N iektóre operatory, takie j ak++ , powoduj ą powstawanie efektów ubocznych nie tylko zwracaj ą wartość, lecz także modyfikuj ą wartość zmiennej, względem -

której zostały użyte. Ef ekty uboczne w pewnych sytuacj ach są bardzo wygodne, ale mogą też wywoływać problemy, j eśli czynności pobierania wartości i aktualizowania zmiennej nie zosta­ ną wykonane j ednocześnie. W j ęzykach C i C++ kolej ność wykonywania ef ektów ubocznych niej est określona, przez co wielokrotnie użyta w poniższym przykładzie instrukcj a przy pisania może zwrócić nieprawidłowy wynik: '

s t r [ i ++] = str[i ++] = '

;

I ntencj ą autora było zapisanie spacj i w dwóch kolej nych elementach tablicy str. A le po­ nieważ nie wiadomo, kiedy wartość pominięta, przez co wartość

s t r [ i ++] str[i ++]

I I

i

i

zostanie zaktualizowana, j edna pozycj a w str może zostać

zwiększy się tylko o 1 . Lepiej podzielić to na dwie instrukcj e:

'• .

1 •

.

N awetj eślij est tylkoj edna inkrementacj a, przypisanie może zwracać różne wyniki:

?

array [ i ++] = i ; Gdyby zmiennai miała wartość początkową3, to element tablicy może mieć wartość

3

lub4.

N ie tylko inkrementacj a i dekrementacj a maj ą ef ekty uboczne. I nnym źródłem tego typu niespodzianek są operacj e wej ścia i wyj ścia. Poniższy kod stanowi próbę odczytania dwóch powiązanych ze sobą liczb z wej ścia standardowego:

·

scanf( "%d %d " , &yr, &profi t [yr] ) ; Problem polega na tym, że inna część wyrażenia modyfi kuj e zmienną yr, a inna j ej używa. W związku z tym wartość

profi t [yr]

może być poprawna tylko wówczas, gdy nowa wartość

yr

będzie równa starej . M oże się wydawać, że źródło problemu tkwi w kolej ności ewaluowania argumentów, ale tak naprawdę chodzi o to, iż wszystkie argumenty fu nkcj i scanf są ewalu­ owane przed j ej wywołaniem, a więc wartość

&profi t [yr]

będzie zawsze ewaluowana przy

użyciu starej wartości yr. Tego rodzaj u problem może poj awić się w prawie każdym j ęzyku programowania. Rozwiązaniemj estj ak zwykle podzielenie wyrażenia na prostsze części:

scanf ( " %d " , &yr) ; s canf ( " %d " , &profi t [yr] ) ;

20

1. STYL Zachowaj szczególną ostrożność przy każdym wyrażeni u z ef ektami ubocznymi .

Ćwiczenie

1.4. Popraw poni ższefr agmenty kodu:

'y ' 11 c

'y') )

i f ( ! (c return ;

==

l ength

( l ength < BUFSIZE)

fl ag

fl ag ? O

quote = (*l i ne ==

:

'"'

==

l ength

BUFS I Z E ;

1;

) ?

O·.

i f (val & 1 ) b i t = l; el se b i t = O;

Ćwiczenie 1.5. Znajdź błąd. i nt read ( i n t * i p) { s canf ( " %d " , i p) ; return * i p ; ? ?

i nsert (&graph [vert] , read(&val ) , read(&ch) ) ;

Ćwiczenie 1.6.

Wymi eń wszystki e możli we wyni ki tego kodu przy zastosowani u różnych ko­

lejności wykonywani a dzi ałań:

n = l; pri ntf ( "%d %d\n " , n++, n++) ; Wypróbuj go w jak najwi ększej li czbi e kompi latorów, aby zobaczyć , co będzi e si ę dzi ało w praktyce.

1.3. Spójność i idiomy Zachowani e spójności jest jednym z warunków napi sani a dobrego programu. Jeśli formatowa­ ni e zmi eni a si ę bez żadnej logi ki , pętle raz bi egną w górę poi ndeksach tabli cy, aby zaraz potem wracać w drugą stronę, do kopi owani a łańcuchów raz wykorzystuje si ę funkcję st repy, a gdzi e i ndzi ej znowu pętlę for, to wszystko bardzo utrudni a zrozumi eni e tego, co si ę dzi eje w kodzi e. Jeżeli natomi ast każda operacja jest zawsze wykonywana jednakowo, to jakakolwi ek zmi ana od razu podpowi ada, że wystąpi ła jakaśi stotna różni ca.

Spójnie stosuj wcięcia i nawiasy klamrowe. Wi adomo,

że wci ęci a pozwalają uwypukli ć struk­

turę kodu, ale jak najlepi ej je stosować ? Czy klamra otwi erająca powi nna znajdować si ę w tym samym wi erszu, co i nstrukcja i f, czy w następnym? Programi ści od dawna toczą zażarte dys­ kusje o układzi e kodu, ale tak naprawdę i stotny jest ni e tyle konkretny sposób stosowani a

21

1 .3. SPÓJNOŚĆ I IDIOMY

wcięć, ile trzymanie się przez cały czas jednego stylu. Wybierz jedną metodę, najlepiej naszą, stosuj ją zawsze i wszędzie i przestań marnować czas na jałowe dyskusje. Czy należy wstawiać klamry nawet wówczas, gdy nie są wymagane? Klamry, podobnie jak nawiasy, mogą pomóc rozwiązać różne niejasności i wyklarować kod. Wielu doświadczonych programistów chcąc zachować spójność formatowania kodu, zawsze umieszcza w klamrach treść pętli i instrukcji i f. Jeśli jednak treść ta składa się z jednej instrukcji, klamry nie są wymagane i czasami je pomijamy. Jeżeli również zdecydujesz się na ten krok, uważaj, żeby nie usunąć klamer w miejscu, w którym są potrzebne, jak w przedstawionym niżej przykładzie „ wiszą­ cegoel se":

i f (month == FEB) { i f (year%4 == O) if (day > 29) l egal FALSE ; el s e i f {day > 28) l egal = FALSE ; =

Wcięcia w tym przypadku s ą mylące, ponieważ instrukcja el s e należy do wiersza

i f (day

>

29)

i kod zawiera błąd. Dlatego jeśl i po instrukcji i f występuje od razu druga taka instrukcja, zawsze używaj klamer:

i f (month == FEB) { i f (year%4 == O) { i f (day > 29) lega 1 = FALS E ; el se { i f (day > 28) l egal = FALSE ;

Ryzyko wystąpienia tego rodzaju błędów składni można zmniejszyć poprzez wykorzystanie odpowiednich narzędzi do edycji kodu. Kod ten trudno jednak zrozumieć, nawet mimo poprawienia błędu. Będzie łatwiej, jeśli do przechowywania liczby dni w lutym użyjemy zmiennej:

i f (month == FEB) i nt nday ; nday = 28; i f (year%4 == O) nday = 29 ; i f (day > nday) l egal = FALSE ;

22

1. STYL Ten kod nadal jest błędny, ponieważ rok 2000 jest przestępny, natomiast 1900 i 2100

-

nie, ale taką strukturę znacznie łatwiej jest już doprowadzić do ostatecznego porządku. Przy okazji: jeśli pracujesz na nie swoim kodzie, zachowaj styl, który był w nim stosowany. Zmiany wprowadzaj przy użyciu zastosowanych w nim konwencji(a nie swoich), nawet jeśliCi się nie podobają. Spójność kodu źródłowego jest ważniejsza od Twojego komfortu, ponieważ ułatwia życie tym, którzy będą to czytać poTobie.

Używaj idiomów.

W językach programowania, podobnie jak w językach naturalnych, wystę­

pują idiomy, czyli typowe sposoby pisania określonych partii kodu, z których korzystają do­ świadczeni programiści. Kluczową rolę w nauce każdego języka odgrywa zaznajomienie się z występującymi w nim idiomami. Jednym z najczęściej spotykanych idiomów jest format pętli. Jako przykład niech posłuży nam kod napisany w języku C, C++ lub Java, nadający wartość n elementom tablicy. Ktoś mógłby napisać taką oto pętlę:

i = O; whi l e ( i < = n - 1 ) array [i ++] 1. O; albo taką:

for (i = O; i < n ; ) array [i ++] = 1 . 0 ; albo nawet taką:

for ( i = n; - - i >= O ; array [ i ] = 1 . 0 ; Wszystkie te pętle są poprawne, ale idiomatycznie zapisuje się to tak:

for (i = O ; i < n; i ++) array [ i ] = 1 . 0 ; Wybór ten nie jest arbitralny. Pętla ta odwiedza p o kolei każdy element tablicy n­ elementów indeksowanej od O don-1. Cały kod sterujący pętlą znajduje się w części for, pętla przechodzi od najmniejszego indeksu do największego, a do aktualizowania zmiennej pętlowej został użyty bardzo idiomatyczny operator++ . Zmienna indeksowa po zakończeniu działania pętli ma znaną wartość większą o jeden od rozmiaru tablicy. Doświadczeni użytkownicy języka rozpoznają ten idiom w mgnieniu oka i potrafią go zapisać bez zastanowienia.

w językuc+ +i wJavie często dodaje się jeszcze deklarację zmiennej pętlowej:

for ( i nt i = O ; i < n ; i ++) array [ i ] = 1 . 0 ; Oto standardowa pętla do przemierzania list w językuC:

for (p = l i st ; p ! = NULL; p = p->next)

1.3. SPÓJNOŚĆ I IDIOMY

23

T u ta kże sterowa nie pętlą mieści się w części f or . W roli nieskończonej pętli pref erujemy

for

(; ;)

a le pętla

whi l e ( l )

jest ró wnież popularna . Za wsze używa j jednej z tych wersji. Ta kże wcięcia powinny być stosowa ne idioma tycznie. P oniższy nietypowy pionowy za pis utrudnia zrozumienie kodu, a na wet ba rdziej przypomina trzy niezwiąza ne ze sobą instrukcje niż pętlę:

for ( ap = arr; ap < arr + 128 ; *ap++ = O

)

O wiele ła twiej jest odczyta ć zna czenie ze sta nda rdowego za pisu pętli:

for (ap *ap

= =

arr; ap < arr+l28; ap++) O;

P ona dto rozproszone formy za pisu często powodują podzielenie kodu na kilka stron l ub ekra nó w, co ró wnież osła bia czytelność. Kolejnym często spotyka nym idiomem jest wsta wia nie przypisa nia do wa runku pętli:

whi l e ( (c = getchar ( ) ) ! = EOF) putchar (c) ; I nstrukcji do-whi 1 e używa się zna cznie rza dziej niż whi 1 e i for, poniewa ż w niej test jest przeprowa dza ny na sa mym końcu, a więc jej kod za wsze zosta je wykona ny przyna jmniej ra z. W wielu przypa dka ch za stosowa nie tego rodza ju konstrukcji jest ró wnozna czne z proszeniem się o kłopoty, ta k ja k w poniższej wersji pętli zfu nkcjągetchar:

do c = getcha r ( ) ; putchar (c) ; whi l e (c ! = EOF) ; P oniewa ż test zosta je wykona ny po wywoła niu fu nkcji putchar, pętla ta za pisuje jeden nie­ potrzebny zna k wyjściowy. P ętli do-wh i 1 e na leży używa ć tylko wó wcza s, gdy instrukcje pętlowe muszą zosta ć wykona ne przyna jmniej ra z. Później zoba czymy kilka odpowiednich przykła dó w.

24

1. STYL

Jedną z zalet konsekwent nego t rzym ania się idiom ów j est t o, że od razu m ożna wizualnie wychwycić wszelkie niest andardowe pęt le, kt óre częst o oznaczaj ą kłopot y:

i nt i , *i Array , nmemb ; i Array = mal l oc (nmemb * si zeof ( i nt) ) ; for ( i = O ; i <= nmemb ; i ++) i Array [ i ] = i ; F unkcj a ma 1 1 oc alokuje m iej sce w pam ięci dla nmemb elem ent ów, od elem ent u i Array [OJ do i Array [nmemb - 1 ] , ale ponieważ w warunku pęt li zast osowano operat or relacji<=, pęt la wyj ­ dzie poza granicę t ablicy i zniszczy t o, co znaj duje się za nią w pam ięci. N iest et y, t ego t ypu błędów nie wykrywa się zwykle od razu, lecz dopiero wówczas, gdy wyrządzą dużo szkód. w językach c i c+ + są t eż idiom y dot yczące alokowania pam ięci dla łańcuchów i opero­ wania na niej. Kod, w kt órym się z nich nie korzyst a, częst o kryj e błędy:

char *p , buf [256] ; get s ( buf) ; p = mal l oc ( strl en (buf) ) ; strcpy ( p , buf) ; N igdy nie używaj fu nkcji gets, ponieważ uniem ożliwia ona określenie lim it u ilości wczy­ t ywanych danych. T o powoduj e probl em y z bezpieczeńst wem, do kt órych wrócim y jeszcze w rozdziale6.

-

pokażem yt am, że zawsze lepszą alt ernat ywąj est fu nkcja fgets. T o j ednak nie

j edyny problem . F unkcj a strl en nie liczy znaku ' \0 ' kończącego łańcuch, podczas gdyfu nkcj a

strcpy

go kopiuj e. Z t ego powodu zost anie alokowana zbyt m ała ilość pam ięci i fu nkcj a strcpy

zapisze dane za przydzielonym obszarem . I diom w t ym przypadku wygląda t ak:

p = mal l oc (strl en (buf) +l) ; strcpy ( p , buf) ; lub t ak w językuC + + .

p = new char [strl en (buf) +l] ; st rcpy ( p , buf) ; Jeśli nie widzisz inst rukcj i+ 1, podwój swoj ą czujność . WJavie t en problem nie wyst ępuje, ponieważ w niej łańcuchy nie są reprezent owane w po­ st aci t ablic zakończonych zerem . T akże indeksy t ablicy są sprawdzane, a więc nie da się wyj ść pozaj ej granice. w większości środowisk c i c+ + m ożna t ego problem u łat wo uniknąć dzięki zast osowaniu fu nkcj i bibliot ecznej

strdup,

kt óra t worzy kopię łańcucha przy użyciu fu nkcji ma 1 1

oc

i strcpy.

N iest et y, fu nkcja s trdup nie należy do st andardu ANSI C. Przy okazji zauważm y, że ani wersj a oryginalna, ani poprawiona nie sprawdzają wart ości zwracanej przez fu nkcję ma 1 1 oc . Pom inęl iśm y t en szczegół, aby skoncent rować się na naj waż­ niejszej kwest ii, ale w realnym świecie zawsze należy sprawdzać wynik zwracany przez fu nkcj e

ma 1 1 oc, rea 1 1

oc,

st rdup

i wszelkie inne alokujące pam ięć . .

25

1.3. SPÓJNOŚĆ I IDIOMY

Do podejmowania wielokierunkowych decyzji używaj instrukcji i f-el se. Decyzje wielo kie­ f . . . el se i f . . . el se:

r unko wei diom atycznie wyr aża si ę w po staci łańcuchai nstr ukcji i

i f (warunek,) instrukcja,

el se i f (warunek,) instrukcja,

el se i f (warunek.) instrukcja.

el se instrukcja-domyś lna

Warunki są spr awdzane o d gór y. Dla pierwszego, któr y zo stanie spełnio ny, wyko nywana jego instrukcja, a r eszta ko nstr ukcji zo staje pomi nięta. I nstr ukcja mo że być po jedyncza

jest lub

składać si ę z wi el u instr ukcji wydzielo nychm iędzy klamr ami. Ostatnia klauzul a el

se

o bsługuje sytuację „ dom yślną'', czyli jej instr ukcje są wyko nywane

wówczas, gdy żadna z po zo stałych o pcji nie zo stani e wybr ana. Jeśli nie pr zewiduje si ę takiej sytuacji, tę o statni ą instr ukcję mo żna o puści ć, al e war to ją po zo stawić z kom uni katem o błę­ dzi e na wypadek zdar zeni a, któr e „ ni emi ało pr awam ieć m iejsca" . Jeżeli cho dzi o str uktur ę ko du, l epiej wszystki e klauzule el

se

wyr ównać w pio ni e, ni ż sze­

r ego wać je w jednej li nii z instr ukcją i f. Taki e pio no we ustawieni e klauzul po dkr eśla sekwen­ cyjny spo sób pr zepro wadzania spr awdzeń or az zapo bi ega po wstawaniu zbyt długi ch wi er szy ko du. Często widząc skom pliko wane, wi elo po ziomo wo zagnieżdżo ne str uktur y i nstr ukcji

i f,

na­

l eży spo dziewać się pr zynajm niej ni ezgr abnego stylu pro gr amo wania, a w najgor szych pr zy­ padkach nawet po ważnych błędów.

?

? ? ?

i f (argc == 3 ) i f ( (fi n = fapen (argv [l ] , " r " ) ) ! = NU LL) if ( ( faut = fapen (argv [2] , "w" ) ) != NULL) whi l e ( (c = getc (fi n ) ) != EOF) putc ( c, faut) ; fcl ose (fi n) ; fcl ose (fout) ; el se pri ntf ( " N i e można otworzyE pl i ku wyj ści owego %s\n " , argv [2] ) ; el se pri ntf ( " N i e można otworzyE pl i ku wej ś c i owego %s\n" , argv [l ] ) ; el se pri ntf ( " Użyc i e : cp pl i kwej ści owy pl i kwyj ś c i owy\n " ) ; Ta zbi er anina instr ukcji

if

zm usza nas do pr zepro wadzeni a w m yślach sym ulacji ko lej­

nych testów, aby m óc o kr eśli ć, któr em u z nich o dpo wi adają po szczególne instr ukcje ( jeśli uda nam się to spami ętać). Po nieważ pr zynajm ni ej jedna czynno ść m usi zo stać wyko nana, pr zyda­ łaby nam się tu instr ukcja el

se-i f.

Ko d ten mo żem y wyklaro wać po pr zez zm ianę ko lejno ści

po dejm o wani a decyzji, a pr zy o kazji po zbędzi em y si ę dzięki tem u wycieku zaso bów, któr y kr ył si ę w pi er wo tnej wer sji:

i f (argc ! = 3 ) pri ntf ( " Użyc i e : cp pl i kwej ści owy pl i kwyj ś c i owy\ n " ) ; el se i f ( (fi n = fopen (argv [ l ] , " r" ) ) == NULL) pri ntf ( " N i e można otworzyE pl i ku wej ś c i owego %s\n " , argv [l ] ) ;

26

1.

STYL

el se i f ( (faut = fapen(argv [2] , "w" ) ) == NULL) { pri ntf("Ni e można otworzyć pl i ku wyj ści owego %s\n " , argv2] ) ; fcl ose(fi n ) ; el se { whi l e ( (c = getc (fi n ) ) ! = EOF) putc ( c , faut) ; fcl os e ( fi n) ; fcl ose (faut) ;

Cz yt amy po kolei instr ukcj e spr awdz aj ące, aż z naj dz iemy t aką, kt ór ej war unek j est speł­ niony, wykonuj emy odpowiadaj ące mu instr ukcj e i kont ynuuj emy wykonywani e pr ogr amu od miej sca z a ost at ni ą klauz ulą el se. Ogól na z asada j est t aka, aby instr ukcj e z naj dowały si ę j ak naj bliż ej decyzj i, z kt ór ą są z wi ąz ane. I nnymi słowy, z awsz e gdy prz epr owadz asz j akiś t est , wy­ konaj t eż j akieś cz ynności . Z agmat wany kod moż e powst awać t akż e w wyniku ni eudanych pr ób wi elokr ot nego wyko­ rz yst aniafr agment ów pr ogr amu:

swi tch (c) case ' - ' : case ' + ' : case ' . ' : defaul t :

{ s i gn = - 1 ; c = getchar ( ) ; break; if ( ! i sd i g i t (c ) ) return O ;

W t ym kodzi e w cel u unikni ęcia powt órz enia j ednego wi er sz a kodu z ast osowano bez po­ śr ednie prz ej ście z j ednej klauz uli case instr ukcj i wh i l e do nast ępnej ( ang. fall-through). Taki sposób pi sani a kodu t eż ni e j est i di omat ycz ny, poni eważ kl auz ul e case pr awi e z awsz e powi nny kończ yć się i nstr ukcj ą break. N ieli cz ne prz ypadki , w kt ór ych j ej pomi nięci e j est uz asadni one, nal eż y oz nacz ać st osownym koment arz em. Ot o bar dzi ej tr adycyj ny i ni eco dłuż sz y, ale z a t o bar dz iej prz ejrz yst y sposób z api sani at ego kodu:

swi tch (c) { case ' ' : s i gn = - 1 ; -

/*przejście bezpośrednie *I

?

case ' + ' : c = getchar() ; break; case ' ' · brea k ; defaul t : i f ( ! i sd i g i t (c ) ) return O ; break ;

Ni ewielki e z większ enie ilości kodu spowodowało ogr omną r óż nicę, j eśli ch odz i o j ego kla­ r owność . Jednak w prz ypadku t aki ch ni et ypowych str ukt ur naj lepiej pod wz ględem prz ejrz y­ st ości spr awdz aj ą si ę instr ukcj eel se- i f:

27

1.3. SPÓJNOŚĆ I IDIOMY i f ( C == I - I ) { s i gn = - 1 ; c = getchar () ; el se i f (c == ' + ' ) c = getchar () ; el se i f (c ! = ' . ' && ! i sdi gi t (c ) ) { return O ;

Kla mry ota cza jące jednowi ersz owe bloki uwypuklaj ą równoległą st rukt urę kodu. Prz ypa dek, w kt órym do prz yj ęcia j est opusz cz eni e i nst rukcj i bre a k w kla uz ula ch c a s e inst rukcj i

swi tch,

t o syt ua cja, gdy kilka t ych kla uz ul ma ta ki sa m kod. Sta nda rdowo za pisuje

si ęt ota k:

case case case

'O' : '1' : '2' : brea k ;

N iet rz eba doda wa ć ża dnego komenta rza .

Ćwiczenie 1.7. Na pi sz t efra gment y kodu w jęz ykuCIC+ +

w ba rdzi ej cz yt elny sposób:

i f ( i stty (stdi n ) ) el se i f (i stty( stdout ) ) ; el se i f ( i stty (stderr) ) el se return (O) ; i f (retval ! = SUCCESS) { return (retval ) ; /* Wszystko się udało! *I return SUCCESS ; for ( k = O ; k++ < 5 ; x += dx) scanf ( "%l f" , &dx) ;

Ćwiczenie 1.8.

Zna jdź błędy w t ym fra gmencie progra mu w j ęz ykuJa va i na pi sz go ponowni e

prz y użyciu i diomat ycz nej pęt li :

i nt count = O ; whi l e (count < total ) count++ ; i f (thi s . getName (count) return (true) ? ?

nametabl e . userName ( ) ) {

28

1. STYL

1.4. Makra w roli funkcji Starsi programiści języka C mają w zwyczaju dla krótkich i często wykonywanych obliczeń pisać makra zamiast funkcji. Powszechną aprobatą cieszą się operacje wejściowe typu get char i testy znaków w rodzaju i sdi g i t. Robi się to ze względu na wydajność, ponieważ makra są pozba­ wione typowego dla wywołania funkcji narzutu. Argument ten jednak był słaby już krótko po powstaniu języka C, czyli w czasach, gdy komputery były wolne i wywołanie funkcji stanowiło dla nich nie lada wysiłek. Obecnie to nie ma już żadnego znaczenia. Przy dzisiejszych kompu­ terach i kompilatorach wady stosowania makr przewyższają płynące z ich użycia korzyści.

Unikaj używania makr w roli funkcji. W języku C+ + makra można z powodzeniem zastąpić funkcjami rozwijanymi w linii wywołania. W Javie w ogóle ich nie ma. W języku C powodują więcej problemów, niż są warte. Jednym z największych problemów, jakie sprawiają makra funkcyjne, jest to, że każdy pa­ rametr, który występuje w definicji częściej niż raz, może zostać ewaluowany również częściej niż raz. Jeśli argument wywołania będzie zawierał wyrażenie powodujące efekty uboczne, wy­ stąpi trudny do wykrycia błąd. Poniższy kod stanowi próbę implementacji jednego z testów znakowych z biblioteki :

#defi ne i supper(c) ( (c) >= ' A ' && {c) <= ' Z ' ) Zauważmy, że parametr c występuje w treści makra dwa razy. Jeśli więc funkcja i s upper zostanie wywołana w następujący sposób:

whi l e (i supper (c = getchar() ) )

to za każdym razem, gdy zostanie wczytany znak większy od A lub równy A, nastąpi odrzu­ cenie wczytanego znaku i wczytanie kolejnego znaku w celu porównania go ze znakiem Z. Standard C został tak skonstruowany, że zezwala na pisanie funkcji jak i s upper jako makr, ale pod warunkiem, że każdy argument będzie ewaluowany tylko raz. Przedstawiona implementa­ cja tego warunku nie spełnia. Zawsze lepiej skorzystać z funkcji biblioteki ctype, niż implementować je własnoręcznie, a ponadto radzimy unikać zagnieżdżania procedur mających efekty uboczne, takich jak getchar. Jeśli przepiszemy kod przy użyciu dwóch wyrażeń zamiast jednego, to nie tylko zyska on na klarowności, lecz także my uzyskamy możliwość obsłużenia zdarzenia wystąpienia końca pliku:

whi l e ( (c = getch ar ( ) ) ! = EOF && i supper ( c ) )

Czasami wielokrotna ewaluacja parametru powoduje nie tyle konkretny błąd, ile obniżenie wydajności programu. Spójrzmy na poniższy przykład:

? #defi ne ROUND_TO_INT (x) ( ( i nt) ( (x)+ { { (x)>0) ?0 . 5 : -0 . 5 ) ) ) s i ze = ROUND_TO_I NT(sqrt (dx* dx + dy*dy) ) ;

29

1.5. LICZBY MAGICZNE

Ten kod będzie powtarzał czynności obliczania pierwiastka kwadratowego tyle razy, ile potrze­ ba. Nawet przy prostych argumentach złożone wyrażenie, takie jak treść makra ROUND_TO_ INT, przekłada się na wiele instrukcji, które powinny być umieszczone w jednej funkcji, możliwej do wywołania w razie potrzeby. Zastępowanie makra odpowiednim kodem przy każdym jego wystąpieniu powoduje rozdęcie programu po kompilacji (ten sam problem dotyczy funkcji rozwijanych w języku c+ + ) .

Treść i argumenty makr umieszczaj w nawiasach. Jeśli musisz używać makr, rób to z rozwagą. Działają one na zasadzie podmiany tekstu, tzn. parametry użyte w definicji są zastępowane przez argumenty wywołania, a następnie otrzymany kod jest wstawiany w postaci tekstu w miejsce oryginalnego wywołania. To właśnie ta problematyczna cecha odróżnia je od funkcji. Wyrażenie

1 / square(x) zadziała poprawnie, jeśli square będzie funkcją, ale jeśli będzie makrem takim jak poniżej

#de fi ne square (x) (x) * (x) zostanie rozwinięte do błędnej postaci

1 / (x) * (x) Należałoby je napisać tak:

#defi ne square (x)

( (x) * (x) )

Wszystkie użyte nawiasy są tu niezbędne, ale nawet ich prawidłowe zastosowanie nie chro­ ni nas przed problemem wielokrotnej ewaluacji. Jeśli w programie występuje jakaś pochłania­ jąca dużo zasobów lub często używana operacja, najlepiej jest ją zdefiniować w postaci funkcji. W języku C+ + makra można zastąpić funkcjami rozwijanymi, które pod względem wydaj­ ności oferują te same korzyści co makra, a są pozbawione ich wad składniowych. Dobrze nadają się do definiowania niewielkich operacji ustawiających lub pobierających pojedynczą wartość.

Ćwiczenie 1.9. Znajdź problemy w poniższej definicji makra. #defi ne ISDIGIT(c) ( (c >= ' D ' ) && (ce <= ' 9 ' ) ) ? 1

:

D

1.5. Liczby magiczne Liczby magiczne to wszelkie stałe, rozmiary tablic, pozycje znaków, współczynniki konwersji i inne wartości liczbowe występujące w kodzie w postaci literałów.

Nadawaj nazwy liczbom magicznym. Ogólnie można przyjąć, że każda liczba różna od O i 1 może być magiczna i powinna mieć swoją nazwę. Jeśli w kodzie programu występują gołe licz­ by, to nie wiadomo, skąd się wzięły ani co oznaczają, przez co trudno taki program zrozumieć i modyfikować. Poniższy fragment kodu źródłowego programu drukującego histogram często­ ści występowania liter w obsługiwanym za pomocą kursora terminalu o wymiarach 24 x 80 mógłby być znacznie klarowniejszy, gdyby nie cała masa użytych w nim magicznych liczb:

30

I.

fac = l i m / 2 0 ; i f (fac < 1 ) fac = l ;

STYL

I* Ustawienie współczynnika skalowania *I

I* Tworzenie histogramu *I

for

< 2 7 ; i ++ , j++) { ( i = O , col = O ; col += 3 ; k = 21 - ( l et [i ] / fac) ; I* star = ( l et [ i ] == O) ? ' ' for (j = k; j < 2 2 ; j ++) draw(j , col , star) ; I •

'

?

} draw (23 , 2 , ' ' ) ; l* Oznaczenie osi X */ for ( i = ' A ' ; i <= ' Z ' ; i ++) pri ntf( "%c i); • ,

W powyższym kodzie znajdziemy m. in. takie liczby: 20, 21, 22, 23 i 27. N a pewno są ze so­ bą jakoś powiązane. . . chyba. W istocie w tym programie kluczowe znaczenie mają tylko trzy liczby: 24 - liczba wierszy na ekranie, 80 - liczba kolumn na ekranie, oraz 26 - liczba liter w alfa becie. Ż adna z nich nie występuje jednak w podanym fr agmen� ie, co czyni te, które w nim są, jeszcze bardziej tajemniczymi. N adając najważniejszym liczbom w kodzie nazwy, sprawiamy, że jest on znacznie łatwiej­ szy do zrozumienia. Odkryliśmy np., że liczba 3 to wynik działania (80-1)/26, a tablica l et po­ winna mieć

26

elementów zamiast 27 ( pomyłka o jeden jest spowodowana najprawdopodobniej

przez to, że współrzędne ekranu są indeksowane od 1). Po wprowadzeniu kilku dodatkowych ulepszeń kod wygląda tak:

enum { MINROW MI NCOL MAXROW MAXCOL LABELROW NLET HEIGHT WIDTH };

= 1 1 = 24 = 80 = 1 = 26 = MAXROW - 4 , = (MAXCOL- 1 ) /NLET =

I* Górna krawędź *I I* Lewa la·awędź *I I* Dolna krawędź (<=) *I I* Prawa krawędź (<=) *I I* Położenie etykiet *I I* Liczba liter w alfabecie *I I* Wysokość słupków *I I* Szerokość słupków *I

fac = (1 i m + H E I GHT-1) / HEIGHT; /* Ustawienie współczynnika skalowania *I i f (fac < 1 ) fac = 1 ; /* Tworzenie histogramu *I for ( i = O ; i < NLET; i ++) { i f ( l et [i ] == O) conti nue; for (j = HEIGHT - l et [i ] /fac ; j < H EIGHT; j++) draw (j+l + LABELROW, ( i +l) *W I DTH , ' * ' ) ; } draw (MAXROW- 1 , MI NCOL+l , ' ' ) ; /* Oznaczenie osi X *I for ( i = ' A ' ; i <= ' Z ' ; i ++) pri ntf( "%c i); • ,

Teraz treść pętli głównej nie ma przed nami żadnych tajemnic. Została zapisana w postaci idiomatycznej, a jej zmienna sterująca iteruje od O do N LET, co wskazuje na to, że przetwarza elementy tablicy. Również wywołaniafu nkcji draw są jaśniejsze, ponieważ słowaMAXROW iMINCOL

1.5. LICZBY MAGICZNE

31

przypominają nam kolejność argumentów. Co najważniejsze, program w tej postaci można ła­ two dostosować do ekranu o innym rozmiarze lub innego zestawu danych. Liczby zostały od­ czarowane i program od razu stał się klarowniejszy.

Definiuj liczby jako stałe, a nie makra. Programiści C mają w zwyczaju definiować liczby magiczne przy użyciu dyrektywy #defi ne. Ponieważ jednak preprocesor języka C to potężne, ale tępe narzędzie, używanie makr w tej roli nie jest najlepszym rozwiązaniem, gdyż zmieniają one strukturę leksykalną programu. Wykorzystajmy możliwości, jakie oferuje nam język. W języ­ kach C i C + + stałe całkowitoliczbowe można definiować przy użyciu instrukcji en urn, co wi­ dzieliśmy w poprzednim przykładzie. Ponadto w języku C+ + można definiować stałe dowolnego typu przy użyciu słowa kluczowego con st:

const i nt MAXROW = 24, MAXCOL = 80 ; W Javie podobną rolę odgrywa słowo kluczowe fi na l :

stati c fi nal i nt MAXROW = 24, MAXCOL = 80 ; W języku C też występuje słowo kluczowe con st, ale zdefiniowanych przy jego użyciu war­ tości nie można używać do oznaczania granicy tablic, w związku z czym w tym języku pozo­ staje nam enum.

Używaj stałych znakowych zamiast całkowitoliczbowych. Funkcje w bibliotece i ich odpowiedniki służą do sprawdzania właściwości znaków. Jeśli napiszemy taki test:

i f (c >= 65 && c <= 90)

to całkowicie uzależnimy się od konkretnej reprezentacji znaków. Dlatego lepiej jest napi­ sać to tak:

i f (c >= ' A ' && c <= ' Z ' )

Wadą tej metody jest to, że jeśli w danym zestawie znaków litery nie są ustawione w sposób ciągły albo alfabet zawiera jakieś nieprzewidziane przez nas litery, mamy problem. Najlepiej skorzystać z funkcji bibliotecznej :

i f ( i supper (c) )

Powyższy kod dotyczy języków C i C+ + . Odpowiednik dla Javy jest następujący:

i f (Character . i sUpperCase (c) )

Podobny problem dotyczy liczby O, która często występuje w programach w rozmaitych kontekstach. Kompilator przekonwertuje ją sobie na odpowiedni typ, ale gdybyśmy go okre­ ślali jawnie, to czytający kod miałby znacznie ułatwione zadanie. Na przykład w języku C do

32

1. STYL

reprezentacji wskaźnika zerowego używajmy zapisu (voi d*) O lub NULL, a bajt zerowy na końcu łańcucha znaków oznaczajmy notacją ' \O ' zamiast po prostu O. Innymi słowy, zamiast pisać

str = O ; narne [ i ] = O ; X = O; piszmy

str = NULL; narne [ i ] = ' \O ' ; X = O.O; Wolimy używać innych wyraźnie określonych stałych, a O zarezerwować do reprezentowa­ nia literalnej wartości zero, ponieważ ten sposób użycia stałych stanowi jakby fragment doku­ mentacji. Jednak w języku C + + przyjęte jest, że do oznaczania zerowych wskaźników używa się O, a nie słowa NULL. Najlepiej ten problem rozwiązano w Javie - zdefiniowano słowo klu­ czowe nul 1 służące do tworzenia referencji obiektowych, które do niczego się nie odnoszą.

Rozmiary obiektów określaj za pomocą konstrukcji językowych. Nie określaj bezpośrednio rozmiaru żadnego typu danych, a więc zamiast pisać np. 2 lub 4, pisz s i zeof ( i n t ) . Analogicz­ nie lepszym rozwiązaniem może być zapis s i zeof (array[O] ) niż s i zeof ( i n t ) , ponieważ jeśli typ tablicy się zmieni, będziemy mieli o jedną rzecz do zmodyfikowania mniej.

Operator s i zeof pozwala czasami uniknąć wymyślania nazw dla liczb określających roz­ miary tablic. Jeśli np. napiszemy

char buf [1024] ; fgets ( buf, s i zeof {buf) , stdi n ) ; rozmiar bufora pozostaje liczbą magiczną, ale występuje tylko raz, w deklaracji. Wymyśla­ nie nazwy dla rozmiaru lokalnej tablicy może nie być warte zachodu, lecz bez wątpienia warto pisać kod w taki sposób, aby nie trzeba było w nim nic poprawiać, gdy zmieni się typ lub rozmiar. Tablice w Javie mają pole 1 ength określające liczbę elementów:

char buf[] = new char[1024] ; for ( i nt i = O; i < buf. l engt h ; i ++)

w c i c + + nie ma odpowiednika konstrukcji 1 ength, ale liczbę elementów tablicy (nie wskaźnika), której deklaracja jest widoczna, można obliczyć za pomocą poniższego makra: .

#defi ne N ELEMS (array) ( s i zeof (array) / s i z eof(array [O] ) ) doubl e dbuf [lOO] ; for ( i = O ; i < NELEMS {dbuf) ; i ++)

33

1.6. KOMENTARZE

Rozmiar tablicy został ustawiony tylko w jednym miejscu. Jeśli s i ę zmieni, reszta kodu i tak pozostanie bez zmian. W przypadku tego makra nie występuje problem z wielokrotną ewaluacją, ponieważ nie mogą wystąpić żadne efekty uboczne, a obliczenia są w istocie wyko­ nywane w czasie kompilacji programu. Jest to dobry przykład zastosowania makra, gdyż robi coś, czego nie da się zrobić za pomocą funkcji - oblicza rozmiar tablicy z jej deklaracji.

Ćwiczenie 1.10. Przepisz poniższe definicje tak, aby zminimalizować ryzyko wystąpienia błędów. #defi ne #defi ne #defi ne #defi ne #defi ne

FT2METER 0 . 3048 METER2FT 3 . 28084 MI2FT 5280 . 0 MI2KM 1 . 609344 SQMI2SQKM 2 . 589988

1 .6. Komentarze Komentarze mają za zadanie pomagać w zrozumieniu kodu programu. To nie znaczy jednak, że należy w nich pisać to, co w sposób oczywisty wynika z kodu, ani też zaprzeczać temu, co widać, tudzież rozpraszać czytającego poprzez stosowanie wyrafinowanych zabiegów typogra­ ficznych. Idealny komentarz pomaga w zrozumieniu kodu, wyłuszczając najbardziej istotne szczegóły lub w szerszej perspektywie ukazując proces wykonywania.

Nie wypisuj oczywistych rzeczy. Komentarzy nie należy używać do informowania o rzeczach oczywistych, np. że instrukcja i ++ zwiększyła wartość i . Oto kilka naszych ulubionych bezwar­ tościowych komentarzy:

?

/* * default */

defau l t : break ; /* zwraca SUCCESS */

return SUCCESS ; zerocount++ ; /* Zwiększa licznik zer */ I* lnicjalizuje fota! wartością number_received */

node->total

=

node->number_recei ved ;

Wszystkie te komentarze należałoby usunąć, bo tylko zaśmiecają kod. Komentarz powinien zawiadamiać o czymś, czego nie widać od razu po kodzie, albo gro­ madzić w jednym miejscu informacje, które są rozproszone w większym obszarze kodu. Ko­ mentarze mogą być pomocne do objaśniania pewnych subtelnych zjawisk, ale jeśli opisują coś oczywistego, to ich stosowanie jest bezcelowe:

whi l e ( (c = getchar ( ) ) ! = EOF && i sspace (c) ) EOF) i f (c type = endoffi l e ;

/*pomiń białe znaki */ /* koniec plilm */

34

1. STYL

el se i f (c ' (') type = l eftpare n ; el se i f ( c = ' ) ' ) type = ri ghtpare n ; el se i f ( c = ' ; ' ) type = semi col o n ; el se i f ( i s_op (c) ) type = operator; el se if ( i s d i g i t (c ) ) ==

I* otwarcie nawiasu *I I* zamknięcie nawiasu *I I* średnik *I I* operator *I I* liczba *I

Te komentarze również są niepotrzebne, ponieważ wszystko wyjaśniają dobrze dobrane nazwy.

Komentuj funkcje i dane globalne. Oczywiście komentarze mogą być przydatne. Stosujmy je do funkcji, zmiennych globalnych, definicji stałych, pól struktur i klas oraz ogólnie zawsze wtedy, gdy krótkie streszczenie może być pomocne. Zmienne globalne lubią pojawiać się gdzieniegdzie w każdym programie. Opatrzenie ich komentarzem przypomina, do czego służą. Poniżej znajduje się przykład kodu zaczerpnięty z rozdziału 3 . : st ruct State { I *przedrostek i lista przyrostków *I char *pref[NPREF] ; I* przedrostki *I Su ff i x *suf; I* lista przyrostków *I State *n ext ; I* następny element w tablicy mieszającej *I }; Komentarz znajdujący się przed funkcją powinien stanowić krótkie wprowadzenie do jej kodu źródłowego. Jeśli kod ten nie jest bardzo długi ani skomplikowany, wystarczy jedna li­ nijka komentarza: li random: zwraca liczbę całkowitą z przedziału [O.. r-1]

i nt random ( i nt r) { return ( i nt) (Mat h . fl oor (Math . random ( ) *r) ) ;

Czasami gdy w kodzie zostaną użyte jakieś skomplikowane algorytmy albo struktury da­ nych, bywa on naprawdę trudny do zrozumienia. Wówczas pomocny może być komentarz odsyłający do właściwego źródła wiedzy. Często też warto objaśnić motywy podjęcia określo­ nych decyzji. Poniższy komentarz stanowi wprowadzenie do niezwykle wydajnej implementa­ cji algorytmu odwrotnego dyskretnego przekształcenia kosinusowego (ang. discrete cosine trans­ form DCT) zastosowanego w dekoderze obrazów JPEG. -

I* * idei: implementacja dwuwymiarowego 8 x8 * algorytmu odwrotnego dyskretnego przekształcenia kosinusowego * Chen-Wanga (IEEE ASSP-32, s. 803 - 816, sierpień 1984) * * 32-bitowa arytmetyka całkowitoliczbowa (współczynniki 8-bitowe) * 11 mnoże1i, 29 operacji dodawania wjednym przekształceniu DCT *

35

1.6. KOMENTARZE * Współczynniki rozszerzone do 12 bitów w celu uzyskania * zgodności z IEEE 1180-1990 *I

stat i c {

void

i dct ( i nt

b [8*8] )

W tym bardzo pomocnym komentarzu zawarto informację o materiale referencyjnym, krótko opisano użyte dane, poinformowano o wydajności algorytmu oraz wskazano, jak i dla­ czego oryginalny algorytm został zmodyfikowany.

Nie komentuj źle napisanego kodu, lecz go poprawiaj. Komentuj wszystko, co może być niejasne lub mylące, ale jeśli długość komentarza przewyższy długość kodu, jest to znak, że coś z tym kodem jest nie tak. W tym przykładzie mamy długi zagmatwany komentarz i warunkowo kompilowaną instrukcję drukowania przeznaczoną do wykrywania błędów. To wszystko służy do objaśnienia jednej instrukcji: I * Wartość O zmiennej result oznacza znalezienie identycznych elementów, zostanie więc zwrócona prawda (wartość różna od zera). Wpozostałych przypadkach wartość resultjest różna od zera, więc zostanie zwrócony fałsz (zero). */

#i fdef DEBUG pri ntf("*** i sword zwraca ! resul t ffl ush (stdout) ; #end i f

%d\n " , ! resul t ) ;

=

return ( ! resul t ) ; Negacje są zawsze trudne do zrozumienia i najlepiej ich unikać, kiedy tylko się da. Czę­ ściowo do problemu dokłada się nic niemówiąca nazwa zmiennej res ul t. Gdyby zastosowano bardziej deskryptywną nazwę typu matchfound, komentarz stałby się całkowicie zbędny, a i in­ strukcja drukująca byłaby bardziej przejrzysta.

# i fdef DEBUG pri ntf ( "*** i sword zwraca matchfound ffl ush (stdout ) ; #end i f

=

%d\ n " , matchfound) ;

return matchfound;

Dbaj o spójność komentarzy z kodem. Większość komentarzy w czasie powstawania jest zgodna z kodem, do którego się one odnoszą. Ale często zdarza się tak, że program ewoluuje, do ko­ du są wprowadzane poprawki i usuwane z niego usterki, a komentarze pozostają bez zmian. To mogłoby być powodem niespójności, którą zaobserwowaliśmy w pierwszym przykładzie w tym rozdziale. Bez względu na to, jaka była przyczyna powstania rozbieżności między kodem a komentarzami, komentarze, które nie odzwierciedlają tego, co jest w kodzie, zawsze wprowadzają w błąd i już niejednego zmusiły do przeprowadzenia niepotrzebnej sesji wykrywania błędów. Pamiętaj, aby przy każdej zmianie kodu źródłowego sprawdzić, czy komentarze nadal są poprawne.

36

1. STYL

Komentarze powinny nie tylko zgadzać się z kodem, lecz także go wspierać. Komentarz w poniższym przykładzie jest poprawny - objaśnia znaczenie dwóch następnych wierszy kodu - ale wydaje się, że nie odpowiada temu, co rzeczywiście robi kod. Jest w nim mowa o znaku nowego wiersza, a w kodzie - o spacji:

t i me (&now) ; strcpy (date , ctime (&now) ) ;

? /* usuwa końco1'11)1 znak nowego wiersza skopiowany z 1'\l)lniku funkcji ctime */ ? i =O ; ? whi l e (date [i] > = ' ' ) i ++ ; ? date [ i ] = O ; Jedną z możliwości poprawienia tego jest ponowne napisanie kodu w bardziej idiomatyczny sposób:

?

t i me (&now) ; strcpy (date, c t i me (&now) ) ; /* usuwa ko1ico1'11)1 znak nowego wiersza skopiowany z wyniku funkcji ctime */

for ( i = O ; date [ i ] ! = ' \n ' ; i ++)

dat e [ i ] = ' \O ' ; Teraz komentarz zgadza się z kodem, ale jeden i drugi można poprawić, stosując bardziej bezpośrednie wyrażenie. Rozwiązywanym tu problemem jest usunięcie znaku nowego wiersza, który funkcja et i me umieszcza na końcu zwracanego przez siebie łańcucha. Zarówno komentarz, jak i kod powinny to jasno komunikować:

t i me (&now) ; strcpy (date, ctime(&now) ) ; /* Funkcja ctimeO umieszcza na ko1icu łańcucha znak nowego wiersza. Usuwamy go. */

date [strl en (date) - 1 ] = ' \O ' ;

Ostatnie wyrażenie w tym kodzie to idiomatyczny sposób usuwania ostatniego znaku z łań­ cucha w języku C. W tej postaci kod jest krótki, idiomatyczny i klarowny, a komentarz dobrze go wspiera, objaśniając jego rolę.

Objaśniaj, zamiast zaciemniać. Zadaniem komentarzy jest pomóc czytającemu przebrnąć przez trudniejsze partie kodu, a nie stwarzać dodatkowe problemy. W poniższym przykładzie zastosowano nasze wskazówki dotyczące komentowania funkcji i objaśniania nietypowych fragmentów. Jednakże mowa tu o funkcji strcmp i te nietypowe elementy mają drugorzędne znaczenie dla wykonywanego zadania, którym jest implementacja standardowego i powszech­ nie znanego interfejsu: ? i nt strcmp (char *s l , char *s2) ? /* Procedura porównująca ła1icuchy, zwracająca wartość -1,jeśli si jest nad */ ? /* s2 w liście posortowanej rosnąco, O, jeśli s I i s2 są równe, */ /* oraz I, jeśli si jest poniżej s2. */

{

?

whi l e (*sl ==*s2) { i f (*sl == ' \O ' ) return (O) ; s l++ ; s2++ ;

1 .6.

KOMENTARZE

37

i f (*sl >*s2) return ( l } ; return ( - 1 ) ;

Jeśli do opisania działania kodu potrzeba więcej niż kilku słów, to najczęściej taki kod na­ daje się do ponownego napisania. W tym przypadku kod z pewnością można by poprawić, ale większy problem sprawia zbyt długi i niejasny komentarz (co dokładnie oznacza „nad"?). Nie można powiedzieć, że ten kod trudno zrozumieć, ale skoro jest to implementacja funkcji stan­ dardowej, to jej komentarz mógłby zawierać opis działania i odsyłacz do definicji. Niczego więcej nie potrzeba: I* strcmp: wartość zwrotna < O, jeśli s/ O, jeśli sl>s2; O, jeśli sl =s2 *I I* ANSJ C, podrozdział 4. 11.4.2 *I

i nt strcmp (const char *s l , const char *s2}

Studentom mówi się, że należy wszystko komentować. Także zawodowym programistom często nakazuje się komentować cały pisany przez nich kod. Trzeba jednak pamiętać, że ślepe trzymanie się reguł może całkowicie zatrzeć prawdziwe przeznaczenie komentarzy. Komenta­ rze mają na celu pomóc czytającemu kod w zrozumieniu tych partii kodu, których znaczenie nie jest oczywiste. Staraj się pisać kod jak najprostszy, wówczas będziesz potrzebować mniej komentarzy. Dobry kod wymaga mniej komentarzy niż słaby.

Ćwiczenie 1.11. Wypowiedz się na temat poniższych komentarzy. voi d d i ct : : i nsert (stri ng& w)

li Zwraca 1, jeśli wjest w słowniku, w przeciwnym razie zwraca O

i f (n

>

MAX 1 1 n % 2 > O} li Sprawdza, czy liczbajestparzysta

li Drukuje komunikat li Zwiększa licznik wierszy po wydrukowaniu każdego wiersza

vo i d wri te-message () {

li Zwiększa licznik wierszy

l i ne number = l i ne number + l ; fpri ntf(fout , "%d %s\n%d %s\n%d %s\n" , l i ne_number , HEADER, l i ne number + l, BODY , l i ne=number + 2 , TRAI LER} ;

li Zwiększa licznik wierszy

l i ne number = l i ne_number + 2 ;

38

I.

STYL

1 .7. Dlaczego warto dbać o styl? W rozdziale tym omówiliśmy najważniejsze kwestie dotyczące stylu programowania : stosowa­ nie nazw deskryptywnych, klarowność wyrażeń, proste sterowanie wykonywaniem instrukcji, czytelność kodu i komentarzy oraz konieczność spójnego stosowania konwencji i idiomów, aby osiągnąć te cele. Trudno się nie zgodzić z wszystkimi przedstawionymi stwierdzeniami. Ale po co w ogóle dbać o styl? Kogo obchodzi wygląd programu, który dobrze działa? Czy upiększanie kodu nie zajmuje za dużo czasu, a poza tym - czy te wszystkie zasady nie są ustalone arbitralnie? Prawda jest taka, że dobrze napisany kod łatwiej się czyta i lepiej rozumie, prawie zawsze ma mniej błędów i często jest krótszy od niedbale skleconych instrukcji, którym nie poświęco­ no ani chwili na wyszlifowanie. Kiedy pracujemy pod presją czasu, bardzo łatwo jest odsunąć kwestie stylu na bok, aby tylko zdążyć skończyć pracę w wyznaczonym terminie. Decyzja, aby zająć się stylem później, może nas jednak dużo kosztować. Co może pójść nie tak, jeśli nie za­ dbamy wystarczająco o styl, widzieliśmy w niektórych przedstawionych w tym rozdziale przy­ kładach. Niechlujny kod to zły kod - i to nie tylko trudny do odczytania, lecz także często po prostu najeżony usterkami. Kluczowe znaczenie ma to, aby wyrobić sobie nawyk pisania w dobrym stylu. Można to osiągnąć poprzez stosowanie się do wymienionych zasad od samego początku pisania każdego programu i przeglądanie tego, co się napisało, w celu naniesienia poprawek. Gdy już dobry styl wejdzie Ci w krew, wiele szczegółów będziesz podświadomie wykonywać automatycznie, dzięki czemu nawet pod presją będziesz pisać lepszy jakościowo kod.

Lektura uzupełniająca Jak wspomnieliśmy na początku rozdziału, pisanie dobrego kodu ma wiele wspólnego z pisa­ niem w dobrym stylu po angielsku. Niezmiennie najlepszą krótką pozycją na temat dobrego stylu pisania w tym języku jest książka The Elements of Style Strunka i White' a (Allyn & Bacon). W rozdziale tym zostały wykorzystane wiadomości z książki The Elements of Programming Style Briana Kernighana i P.J. Plaugera (McGraw-Hill, 1 978). Znakomitym źródłem porad na temat programowania jest książka Writing Solid Code Steve'a Maguire'a (Microsoft Press, 1 993). Także w książkach Kod doskonały Steve'a McConnella (Helion, 201 0) i Expert C Pro­ gramming. Deep C Secrets (Prentice Hall, 1994) Petera van der Lindena można znaleźć warto­ ściowe wypowiedzi na temat stylu programowania.

2 Algorytmy i struktury danych

Ostatecznie problem można poprawnie rozwiązać tyll
Raymond Fielding, The Technique of Special Effects Cinematography

Nauka o algorytmach i strukturach danych stanowi jeden z filarów informatyki. Jest to dzie­ dzina nasycona pięknymi technikami i wyrafinowanymi matematycznymi wywodami. Co wię­ cej, nie jest to tylko pole do popisu i zabawy dla teoretyków - dzięki zastosowaniu dobrego algorytmu lub odpowiedniej struktury danych problem, którego rozwiązanie mogłoby zająć lata, można rozwiązać w kilka sekund. W takich specjalistycznych dziedzinach, jak obróbka grafiki, bazy danych, analiza skła­ dniowa i przeprowadzanie symulacji zastosowanie najbardziej kunsztownych algorytmów jest warunkiem w ogóle wykonalności niektórych zadań. Jeśli pracujesz nad programem w nowej dla siebie dziedzinie, koniecznie zapoznaj się z aktualnym stanem wiedzy w branży albo zmarnu­ jesz mnóstwo czasu na wypracowanie marnego rozwiązania problemu, który ktoś już rozwiązał bardzo dobrze. W każdym programie używa się algorytmów i struktur danych, ale bardzo rzadko koniecz­ ne jest opracowywanie czegoś całkiem nowego. Nawet w takich skomplikowanych aplikacjach, jak kompilatory i przeglądarki internetowe przeważającą część wszystkich uŻytych struktur danych stanowią tablice, listy, drzewa i tablice mieszające. Jeśli w programie występuje coś bardziej złożonego, najczęściej jest to zbudowane na bazie wymienionych podstawowych struktur. Zatem większość programistów powinna przede wszystkim poznać dostępne algorytmy i struk­ tury danych i nauczyć się wybierania ich do właściwych celów. Nie rozwodząc się zbytecznie, można powiedzieć, że istnieje zbiór kilku podstawowych al­ gorytmów, które są używane w prawie każdym programie - są to przede wszystkim algorytmy przeszukiwania i sortowania - i nawet z tych wiele można znaleźć w bibliotekach. Analogicz­ nie prawie wszystkie struktury danych są utworzone na bazie kilku podstawowych struktur. Dlatego materiał przedstawiony w tym rozdziale będzie wyglądał znajomo prawie wszystkim programistom. Aby nie pisać o nierealnych rzeczach, napisaliśmy działające wersje omawia­ nych przez nas algorytmów i struktur. Można je w całości skopiować i wykorzystać, jeśli zaj­ dzie taka potrzeba, ale zanim to zrobisz, zapoznaj się z ofertą biblioteki języka programowania, którego używasz.

40

2. ALGORYTMY I

STRUKTURY DANYCH

2. 1 . Przeszukiwanie Tablice są najlepsze do przechowywania danych statycznych nadających się do zapisania w ta­ beli. Dzięki inicjalizacji w czasie kompilacji tworzenie tablic to mało wymagający i prosty pro­ ces (w Javie tablice są inicjalizowane w czasie działania programu, ale ten szczegół implemen­ tacyjny zaczyna mieć znaczenie dopiero wówczas, gdy tablice są bardzo duże). W programie do wykrywania słów, których nie należy raczej używać w pięknym języku literackim, moglibyśmy znaleźć następującą tablicę:

char *fl ab[] = { 11 wi ęc" , 11 bo 11 , " s łabi z na " , " c i en i ut ko " , NULL }; Procedura przeszukująca musi wiedzieć, ile tablica zawiera elementów. Informację tę można jej przekazać w postaci argumentu albo (jak poniżej) umieszczając wartość NULL na końcu struk­ tury danych: /* lookup: sekwencyjne wyszukiwanie słów w tablicy */

i nt l ookup (char *word , char *array [] )

i nt i ; for (i O ; array [ i ] ! = NULL; i ++) i f (strcmp (word , array [i ] ) == O ) return i ; return - 1 ; =

w językach c i c + + parametry będące tablicami łańcuchów można deklarować jako zmienne typu char *array [] lub char **array. Obie formy są równoważne, ale pierwsza wy­ raźniej wskazuje planowany sposób użycia parametru. Ten algorytm jest nazywany wyszukiwaniem sekwencyjnym, ponieważ szuka określonego elementu, sprawdzając po kolei wszystkie elementy struktury danych. Przy małej ilości danych algorytm ten działa wystarczająco szybko. Istnieją jego standardowe implementacje służące do przeszukiwania niektórych typów danych, np. funkcje strchr i strstr wyszukują pierwsze wystąpienie danego znaku lub podłańcucha w łańcuchach C i C+ + , klasa Stri ng w Javie ma me­ todę o nazwie i nd exOf, a ogólnych algorytmów fi nd języka C+ + można używać na prawie wszystkich typach danych. Jeśli dla typu danych, który Cię interesuje, istnieje odpowiednia funkcja, użyj jej. Algorytm przeszukiwania sekwencyjnego można łatwo zaimplementować, ale ilość pracy, którą on wykonuje, jest wprost proporcjonalna do ilości danych, które trzeba przeszukać. Jeśli szukany element nie istnieje w strukturze danych, to podwojenie jej rozmiaru spowoduje po­ dwojenie czasu przeszukiwania. Ponieważ występuje tu zależność liniowa (czas wykonywania jest funkcją liniową rozmiaru zbioru danych), ta metoda nazywana jest również przeszukiwa­

niem liniowym. Oto fragment tablicy o bardziej realistycznym rozmiarze z programu wykonującego analizę składniową kodu HTML. Zdefiniowano w niej nazwy dla ponad stu znaków:

2.1.

PRZESZUKIWANIE

41

typedef struct Nameval Nameval ; struct Nameval { char *name ; i nt val ue; }; /* Znaki HTML, np. AE!igjest ligaturą złożoną z liter A i E. */ /* Wartości są kodowane zgodnie ze standardem Unicode/ISOJ0646. */

Nameval html chars D = { "AEl i g " , Ox00-6 , "Aacute " , Ox00-1 , "Aci rc " , Ox00-2 , /* ... */

"zeta " , Ox03b6 ,

}; Do przeszukiwania większych tablic, jak ta, lepiej użyć algorytmu przeszukiwania binar­ nego. Zasada jego działania jest podobna do tego, jak szukamy słów w słowniku. Zaczynamy od sprawdzenia elementu znajdującego się w środku. Jeśli wartość środkowa jest większa od szukanej, przeszukujemy pierwszą połowę struktury danych, jeśli jest mniejsza - drugą. Czynności te powtarzamy aż do znalezienia szukanego elementu albo stwierdzenia, że nie wy­ stępuje on w tym zbiorze danych. Aby możliwe było przeprowadzenie przeszukiwania binarnego, tablica musi być posorto­ wana, tak jak w przykładzie (zrobienie tego i tak należy do dobrego stylu, a poza tym ludzie też lepiej sobie radzą z przeszukiwaniem posortowanych zbiorów danych), i musi być znana jej długość. W tym przypadku może nam pomóc makro N ELEMS z rozdziału 1 . :

pri ntf ( " Li czba s łów w tabl i cy HTML: %d \ n " , NELEMS (htmlchars) ) ; Implementacja w postaci funkcji algorytmu przeszukiwania binarnego dla tej tablicy mo­ głaby wyglądać tak: /* lookup: binarne wyszukiwanie nazw w tablicy; zwraca indeks */

i nt l ookup (char *name , Nameval tab [] , i nt ntab) { i nt l ow , h i g h , mi d , cmp; l ow O ; h i gh = ntab - 1 ; whi l e ( l ow <= h i gh) { mi d (l ow + h i gh) / 2 ; cmp strcmp (name , tab [mi d] . name) ; i f (cmp < O) h i gh = mi d - 1 ; el se i f ( cmp > O) l ow = mi d + 1 ; e ls e /* znaleziono szukany element */ return mi d ; =

=

=

return - 1 ;

/* brak szukanego elementu */

42

2. ALGORYTMY I STRUKTURY DANYCH

Tablicę html cha rs możemy teraz przeszukać następująco:

hal f = l ookup ( " frac12 " , html chars , NELEMS (html chars ) ) ; W ten sposób znajdziemy indeks symbolu Vi. Algorytm przeszukiwania binarnego w każdej iteracji eliminuje połowę danych. Zatem liczba kroków jest proporcjonalna do tego, ile razy możemy podzielić n przez 2, zanim zostanie nam tylko jeden element. Pomijając kwestię zaokrąglania, wartość ta wynosi log,n. Gdybyśmy więc mieli do przeszukania tysiąc elementów, algorytm liniowy mógłby wykonać do tysiąca kroków, natomiast binarny - około dziecięciu. Gdyby wartość tę zwiększyć do miliona, algo­ rytm liniowy mógłby wykonać do miliona kroków, a binarny - najwyżej dwadzieścia. Im wię­ cej elementów, tym korzyści z używania algorytmu przeszukiwania binarnego są większe. Po przekroczeniu pewnego progu (zależnego od implementacji) przeszukiwanie binarne staje się szybsze od liniowego.

2.2. Sortowanie Algorytm wyszukiwania binarnego można stosować tylko na posortowanych zbiorach danych. Jeśli przewidujesz, że jakiś zbiór danych będzie przeszukiwany wielokrotnie, warto go posor­ tować od razu, aby móc później przeszukiwać go za pomocą algorytmu przeszukiwania binar­ nego. Jeśli zbiór danych jest z góry znany, można go posortować już podczas pisania programu i zainicjalizować w czasie kompilacji. W przeciwnym razie sortowanie trzeba wykonać już pod­ czas działania programu. Jednym z najlepszych wszechstronnych algorytmów sortowania jest tzw. sortowanie szyb­ kie (ang. quicksort) wynalezione w 1 960 roku przez C.A.R. Hoare'a. Algorytm ten stanowi zna­ komity przykład tego, jak można uniknąć wykonywania niepotrzebnych obliczeń. Dzieli on elementy tablicy na dwie grupy - małe i duże: Wybierz jeden element z tablicy (oś). Pozostałe elementy podziel na dwie grupy: „elementy małe" - mniejsze od elementu osi i „elementy duże" - większe od elementu osi lub mu równe. Posortuj rekurencyjnie każdą z grup. Po zakończeniu tego procesu tablica będzie posortowana. Tajemnicą szybkości algorytmu jest to, że dzięki naszej wiedzy, iż dany element jest mniejszy od elementu centralnego, nie musimy go porównywać z żadnym elementem z grupy dużych elementów. Ta sama zasada obowiązuje przy porównywaniu dużych elementów z małymi. Ten algorytm jest znacznie szyb­ szy niż takie metody sortowania, jak sortowanie przez wstawianie i bąbelkowe, które każdy element porównują z wszystkimi pozostałymi. Algorytm sortowania szybkiego jest praktyczny i wydajny. Dzięki temu, że poświęcono mu mnóstwo opracowań, powstało wiele rozmaitych jego wersji. Poniżej przedstawiamy jedną z najprostszych implementacji, ale bez wątpienia nienależącą do najszybszych. Poniższa funkcja qui cksort sortuje tablicę liczb całkowitych: /* quicksort: sortuje elementy v[O}„ v[n-1} w porządku rosnącym */

voi d qui c ksort ( i nt v [] , i nt n ) { i nt i , l as t ;

43

2.2. SORTOWANIE

i f (n <= 1 ) /* Nie ma nic do roboty *I return ; swap ( v , O, rand ( ) % n) ; /* Przesunięcie osi do v[O] */ l ast = O ; for ( i = 1 ; i < n ; i ++) l* Podziałna grupy */ i f ( v [i ] < v [O] ) swap ( v , ++l ast, i ) ; swap ( v , O , l ast) ; /* Przywrócenie osi */ qui c ksort ( v , l as t ) ; /* Sortowanie rekurencyjne */ qui c ksort (v+l ast+l , n - 1 ast - 1 ) ; /* każdej z części */

Ponieważ operacja swap zamieniająca miejscami dwa elementy została użyta trzy razy, naj­ lepiej będzie, jeśli ją zdefiniujemy w postaci funkcji: /* swap: zamienia miejscami elementy v[i] i vlj] *I

voi d swap ( i nt v [] , i nt i , i nt j ) { i nt temp ; temp = v [i ] ; v [i ] v [j ] ; v [j ] = temp ;

W procesie podziału zbioru na dwie części losowo zostaje wybrany element pełniący funk­ cję osi, który zostaje tymczasowo przeniesiony na początek. Następnie elementy mniejsze od osi (małe elementy) są przenoszone przed niego (do lokalizacji l ast), a większe - za niego (do lokalizacji i ). Na początku procesu, zaraz po przeniesieniu osi na początek, l ast=O, a elementy tablicy o indeksach od 1 do n - 1 są jeszcze niezbadane: Elementy niebadane

p

t t

t

l ast

n-1

W początkowych iteracjach pętli for elementy od 1 do l as t są mniejsze od osi, elementy od l as t+ 1 do i - 1 są od niej większe lub jej równe, zaś elementy od i do n - 1 nie zostały jeszcze sprawdzone. Dopóki element v [ i ] nie jest większy ani równy v [O] , algorytm może zastępować element v [ i ] nim samym. To powoduje pewną stratę czasu, ale na tyle niewielką, że nie ma się czym przejmować. p

< p

t t o

1

El ementy niebadane

>= p

t

l ast

t

t

n-1

P o podzieleniu wszystkich elementów element O zostaje zamieniony miejscami z elemen­ tem l a st, aby element osi znalazł się w ostatecznym położeniu. W ten sposób uzyskiwana jest prawidłowa kolejność. Teraz tablica wygląda tak:

44

2. ALGORYTMY I STRUKTURY DANYCH

<

t o

p

p

t

l ast

>= p

t

n-1

T e same działania s ą wykonywane n a lewej i prawej części tablicy. P o ich zakończeniu cała tablica jest posortowana. Jak szybki jest algorytm sortowania szybkiego? W najbardziej optymistycznym przypadku •

w pierwszym przebiegu zbiór n elementów zostaje podzielony na dwie części po n/2 ele­ mentów;

•

następnie z tych dwóch części tworzone są cztery części, każda po około n/4 elementów;

•

później te cztery części, każda po n/4 elementów, zostają podzielone na osiem części, każda po około n/8 elementów;

•

itd.

Proces ten jest powtarzany log,n razy, a więc w najbardziej optymistycznym przypadku liczba kroków wykonywania algorytmu odpowiada n + 2xn/2 + 4xn/4 + 8xn/8„ . (wyrazy log,n), co jest równe nlog,n. Ś rednia wartość jest tylko nieznacznie wyższa. Zwyczajowo używa się lo­ garytmów o podstawie 2, dlatego mówi się, że poziom złożoności algorytmu sortowania szyb­ kiego wynosi nlogn. Mimo iż przedstawiona implementacja algorytmu bardzo dobrze nadaje się do prezentacji ze względu na swoją prostotę, ma ona swoje wady. Jeśli oś za każdym razem dzieli zbiór danych na dwie prawie równe części, to wszystko jest w porządku. Jeśli jednak podział byłby zbyt czę­ sto nierówny, to poziom złożoności algorytmu mógłby zbliżyć się do n2• Wybierając element osi losowo w naszej implementacji, zmniejszyliśmy ryzyko trafienia na nietypowe wartości, które spowodują nierówny podział danych. Ale gdyby wszystkie wartości były takie same, to nasza implementacja dokonywałaby podziału po jednym elemencie za każdym razem i czas wykonywania wyniósłby n2• Działanie wielu algorytmów w znacznym stopniu zależy od danych wejściowych. Dlatego niektóre algorytmy po otrzymaniu niefortunnego zbioru danych mogą działać bardzo wolno albo zużywać zbyt dużo pamięci. Bardziej finezyjne implementacje algorytmu sortowania szybkiego mogą prawie całkowicie wyeliminować ryzyko takich niepożądanych zachowań.

2.3. Biblioteki W bibliotekach języków C i C+ + znajdują się funkcje sortujące, które są odporne na nieko­ rzystne dane wejściowe i zoptymalizowane pod kątem szybkości działania. Procedury biblioteczne są zaprojektowane do operowania na wszystkich typach danych, za co ceną jest konieczność dostosowania się do ich nieco bardziej, niż widzieliśmy wcześniej, skomplikowanych interfejsów. W języku C mamy do dyspozycji funkcję o nazwie qsort. Do porównywania wartości wykorzystuje ona wskazaną przez użytkownika funkcję porównującą. Ponieważ wartości mogą być dowolnego typu, funkcja porównująca pobiera dwa wskaźniki typu voi d* na elementy, które mają być porównywane. Sama przekonwertuje je sobie na odpowiedni typ, wydobędzie wartości, porówna je i zwróci wynik (ujemny, zerowy lub dodatni, w zależno­ ści od tego, czy pierwsza wartość jest mniejsza od drugiej, równa jej czy od niej większa).

45

2.3. BIBLIOTEKI

Poni że j znaj duje si ę i mple me nta cja częst o s pot yka ne j fu nkcji do s ort owa nia ta bli c łań cuchów. F unkcja

s cmp

wykonuje rzut owa nie s woi ch a rg ume nt ów i wywołuje fu nkcję s trcmp w ce lu wy­

kona nia porównywa nia .

I* scmp: porównywanie łańcuchów *pl i *p2 *I

i nt scmp (const voi d *pl , const v o i d { char *vl , *v2 ;

*p2)

vl ; * (char **) pl ; v2 ; * (char **) p 2 ; return strcmp ( v l , v2) ;

F unkcję t ę mogli byśmy za pisa ć w je dnym wie rs zu, a le posta nowi li śmy doda ć t ymczas owe zmie nne, a by ułat wi ć czyta nie kodu. Nie może my użyć fu nkcji

strcmp

be zpośre dni o do porównywa nia, ponie wa ż fu nkcja

prze ka zuje a dres ye le me nt ów ta bli cy &str[ i ] (t ypu c har**) za miast i ch wa rt ości

char*),

s t r [i ]

qsort (t ypu

ja k wi da ć na rys unku poni że j:

Tablica n wskaźników: str[ O J st r [ l ] str [ 2 J

str[ N - 1 ]

--+--- ł a ńcuchów

A by pos ort owa ć ele me nt y od s t r [O] do s t r [N - 1] ta bli cy łań cuchów, musi my w wywoła­ ni u fu nkcji

q sort

prze ka za ć t ęta bli cę, je j dług ość, rozmia r s ort owa nych e le me nt ów ora z fu nk­

cję porównującą:

char *str [N] ; qsort (str, N , s i zeof (str [O] ) , scmp) ; A ot o podobna fu nkcja do porównywa nia li czb ca łkowit ych o na zwie

I* icmp: porównuje liczby całkowite *pl i *p2 *I

i nt i cmp ( const voi d *pl , const voi d *p2) { i nt v l , v 2 ; v l ; * ( i nt * ) p l ; v2 ; * ( i nt * ) p2 ;

i cmp:

46

2. ALGORYTMY I STRUKTURY DANYCH

i f { v l < v2) return - 1 ; el se i f ( v l v2) return O; el se return l ; = =

Moglibyśmy napisać

return v l - v 2 ; ale gdyby zmienna v 1 miała dużą wartość dodatnią, a v2 dużą wartość ujemną, lub od­ wrotnie, mogłoby wystąpić przepełnienie i uzyskalibyśmy nieprawidłowy wynik. Bezpośrednie porównywanie może trwa dłużej, ale jest bezpieczniejsze. W tym przypadku również w wywołaniu funkcji qsort należy przekazać tablicę i jej długość, rozmiar elementów, które mają zostać posortowane, oraz funkcję porównującą: -

i nt arr [N] ; qsort (arr, N , s i zeof (arr [O] ) , i cmp) ;

W języku ANSI C dostępna jest też procedura przeszukiwania binarnego o nazwie bsearch. Podobnie jak qsort wymaga ona wskaźnika na funkcję porównującą (często może to być ta sa­ ma funkcja, której użyto z funkcją qsort). Zwraca ona wskaźnik na znaleziony element albo NU LL, jeśli nic nie znajdzie. Oto nasza procedura przeszukująca kod HTML dostosowana do funkcji bsearc h : /* lookup: używa funkcji bsearch do znajdowania nazw w tablicy, zwraca indeks */

i nt {

l ookup (char *name , Nameval tab [] , i nt ntab)

Nameval key, * n p ; key . name = name; key. va 1 ue = O; /* Nieużywane, może być cokolwiek */ np = (Nameval *) bsearch (&key, tab , ntab , s i zeof (tab [O] ) , nvcmp) ; i f {np == NULL) return - 1 ; e l se return np-tab ;

Podobnie jak w przypadku funkcji qsort procedura porównująca pobiera adresy elemen­ tów, które mają zostać porównane, a więc key musi mieć określony typ. W tym przykładzie musieliśmy utworzyć fikcyjny element Nameva l , który przekazujemy do procedury porównują­ cej. Procedura ta jest funkcją o nazwie nvcmp, porównującą dwa elementy Nameval za pomocą · wywołania funkcji st rcmp na ich składnikach łańcuchowych, przy ignorowaniu ich wartości: /* nvcmp: porównuje dwie naziry Nameval */

i nt nvcmp (const voi d *va , const v o i d *vb) {

2.4. SORTOWANIE SZYBKIE W JAVIE

47

const Nameval * a , * b ; a = (Nameval *) v a ; b = (Nameval *) v b ; return strcmp(a->name, b->name) ;

Funkcja nvcmp jest podobna do funkcji scmp, ale różni się od niej tym, że porównywane łańcuchy są przechowywane jako składowe struktury. Problem z dostarczaniem klucza powoduje, że funkcja bsearch jest mniej wszechstronna od qs ort. Kod dobrej procedury sortującej ogólnego przeznaczenia zajmuje przynajmniej stro­ nę lub dwie, natomiast kod algorytmu przeszukiwania binarnego jest tylko nieznacznie dłuż­ szy od kodu potrzebnego do połączenia się z funkcją bsearch. Niemniej jednak i tak lepiej jest korzystać z funkcji bsearch, zamiast pisać własną. Lata doświadczeń podpowiadają, że po­ prawna implementacja przeszukiwania binarnego jest trudniejsza, niż może się wydawać. W bibliotece standardowej języka C+ + znajduje się ogólny algorytm o nazwie sort o gwa­ rantowanym czasie wykonywania rzędu O(nlogn) . Korzystanie z niego jest łatwiejsze, ponieważ nie ma potrzeby wykonywania rzutowania elementów ani określania ich rozmiaru oraz nie trzeba bezpośrednio określać funkcji porównującej, jeśli porównywane są typy będące w relacji porządku.

i nt arr [N] ; sort (arr, arr+N) ; Biblioteka języka C+ + zawiera także ogólne procedury przeszukiwania binarnego o po­ dobnych zaletach.

Ćwiczenie 2.1. Najbardziej naturalnym sposobem wyrażenia algorytmu sortowania szybkiego jest zastosowanie rekurencji. Zaimplementuj go przy użyciu iteracji i porównaj obie wersje (Hoare opisuje, jak trudno mu było zaimplementować ten algorytm przy użyciu iteracji i jak ładnie wszystko poszło, gdy zastosował rekurencję).

2.4. Sortowanie szybkie w Javie W Javie sytuacja wygląda inaczej. W kilku pierwszych wersjach języka nie było standardowej funkcji sortującej, a więc za każdym razem trzeba było pisać własną. W nowszych wersjach jest już funkcja o nazwie sort, która działa na klasach implementujących interfejs Comparab l e. Ponieważ jednak techniki implementacji algorytmu sortowania szybkiego w Javie mogą być przydatne także w innych sytuacjach, postanowiliśmy pokazać, jak się to robi. Napisanie algorytmu sortowania szybkiego dla dowolnie wybranego typu danych, które chcemy posortować, jest nietrudne, ale o wiele więcej się nauczymy, gdy napiszemy ogólny al­ gorytm sortowania, odpowiedni do zastosowania dla każdego rodzaju obiektów - coś w ro­ dzaju interfejsu qsort. Jedną z największych różnic między językami C i C + + a Javą jest to, że w Javie nie można w wywołaniu funkcji przekazać funkcji porównującej. W tym języku nie ma wskaźników na funkcje. Zamiast tego tworzy się interfejs, którego jedyną zawartość stanowi funkcja porów­ nująca dwa obiekty typu Obj ect. Następnie dla każdego typu danych, który chcemy posortować,

48

2. ALGORYTMY I STRUKTURY DANYCH

tworzymy klasę z funkcją składową implementującą interfejs dla tego typu danych. Egzem­ plarz tej klasy przekazujemy funkcji sortującej, która z kolei porównuje elementy przy użyciu pochodzącej z tej klasy funkcji służącej do porównywania. Zaczniemy od zdefiniowania interfejsu o nazwie Cmp z jedną składową - funkcją cmp do porównywania dwóch obiektów typu Obj ect:

i nterface Cmp { i nt cmp (Obj ect x , Object y) ;

Teraz możemy napisać funkcje porównujące, które implementują ten interfejs. Poniższa przykładowa klasa zawiera definicję funkcji porównującej obiekty typu Integer:

li/cmp: Porównywanie obiektów typu lnteger

c l as s I cmp i mpl ements Cmp { publ i c i nt cmp (Obj ect o l , Obj ect o2) { i nt i l ; ( ( I nteger) o l ) . i ntVal ue() ; i nt i 2 ; ( ( Integer) o2) . i ntVal ue ( ) ; i f (i l < i2) return - 1 ; el se i f ( i l ;; i 2) return O ; else return 1 ;

a ta porównuje obiekty typu Stri ng:

li Scmp: Porównywanie łańcuchów

c l ass Scmp i mpl ements Cmp { publ i c i nt cmp (Obj ect o l , Object o2) { Stri ng s l ; (String) o l ; Stri ng s 2 ; (Stri ng) o2 ; return s l . compareTo (s2) ;

W ten sposób można sortować tylko obiekty typów pochodnych typu Obj ect, a więc wy­ kluczone są typy podstawowe, takie jak i nt czy do ub 1 e. Dlatego właśnie sortowaliśmy obiekty typu I nteger, a nie wartości typu i nt. Teraz możemy przekonwertować naszą funkcję sortowania szybkiego w języku C na Javę i zmusić ją do wywoływania funkcji porównującej z obiektu Cmp przekazanego jako argument. Najważniejsza zmiana dotyczy użycia indeksów 1 eft i r i ght i została wymuszona przez fakt, że w Javie nie ma wskaźników na elementy tablic. li Quicksort.sort: sortowanie szybkie v[left}.. v[right]

stati c voi d sort {Obj ect [] v , i nt l eft , i nt ri ght , Cmp cmp) { i nt i , l as t ; i f (1 eft > ; ri ght) li nie m a nic do roboty

2.4. SORTOWANIE SZYBKIE W JAVIE

49

return ; swap ( v , l eft , rand (l eft , right ) ) ; liprzesunięcie osi // do v[left} l ast = l eft; for ( i = l eft+l ; i <= r i g h t ; i ++) //podział i f ( cmp . cmp ( v [i ] , v [l eft] ) < O) swap ( v , ++l ast , i ) ; liprzywraca oś swap ( v , l eft , l ast) ; li sortowanie rekurencyjne sort ( v , l eft , l ast-1 , cmp) ; li każdej części sort { v , l ast+l , right, cmp) ;

Metoda Qui cksort . sort porównuje pary obiektów przy użyciu funkcji cmp oraz wywołuje funkcję swap, jak poprzednio, w celu zamienienia tych obiektów miejscami.

li Quicksort.swap: zamienia miejscami obiekty v[i} i v[j} stat i c voi d swap (Obj ect [] v , i nt i , i nt j ) { Obj ect temp; temp = v [i ] ; v [i ] v [j ] ; v [j ] = temp ;

Liczby losowe są generowane przez funkcję losującą wartości z zamkniętego przedziału

l eft-ri ght: stat i c Random rgen = new Random { ) ;

li Quicksort.rand: zwraca losową liczbę całkowitą z przedziału [left, right} stat i c i nt rand ( i nt l eft , i nt ri ght) { return l eft + Math . abs (rge n . nextint ( ) ) %(ri ght-l eft+l ) ;

Za pomocą metody Math . abs obliczamy wartość bezwzględną, której następnie używamy, ponieważ generator liczb losowych Javy może zwracać zarówno ujemne, jak i dodatnie wartości. Funkcje sort, swap i rand oraz obiekt generatora rgen są składowymi klasy Qui cksort. Aby posortować tablicę obiektów typu Stri ng za pomocą metody Qui c ksort . sort, powin­ niśmy napisać

Stri ng [] sarr = new Stri ng [n] ;

li zapisuje n elementów z tablicy sarr„. Qui c ksort . sort (sarr, O, sarr . l ength - 1 , new Scmp ( ) ) ; Wywołujemy metodę sort, przekazując jej jako argument obiekt porównywania łańcuchów utworzony specjalnie na tę okazję.

Ćwiczenie 2.2. Nasz algorytm wykonuje bardzo dużo konwersji, ponieważ musi rzutować ele­ menty z ich oryginalnego typu (np. I nteger) na Obj ect i z powrotem. Zoptymalizuj metodę Qui c ksort . sort pod kątem różnych typów danych, aby oszacować, jak duże straty wydajności powodują te konwersje.

50

2. ALGORYTMY I STRUKTURY DANYCH

2.5. Notacja O I lość pracy, jaką musi wykonać algoryt m, wyrażaliśmy w odniesieniu do liczby n elementó w wejściowych. P rzeszukiwanie nieposort owanego zbioru n elementó w może zająć ilość czasu proporcjonalną do n. Czas działania algoryt mu przeszukiwania binarnego na posort owanym zbiorze danych jest proporcjonalny dologn. Czas sort owania może być proporcjonalny do liczby

n2 lubnlogn.

P ot rzebny jest nam jakiś bardziej precyzyjny sposó b wyrażania t ych informacji, któ ry przy okazji pozwoli wyeliminować z rozw ażań t akie czynniki, jak prędkość procesora czy sprawność kompilat ora ( i programist y). I nt eresuje nas poró wny wanie czasu działania i kwest ia wymagań pa­ mięciowych algorytmó w bez względu na język programowania, kompilat or, archit ekt urę sprzęt ową, szybkość procesora, obciąż enie syst emu i inne czyn niki zaciemniające rzeczy wist y obraz. Do t ego celu służy st andardowa not acja zwana notacją

O ( ang. 0-notation). Jej podst awo­ n, oznaczająca rozmiar problemu, a złożoność obliczeniową, czyli czas działania algoryt mu, wyraża się jakofu nkcję liczby n. Wielkie O w nazwie t ej not acji

wym paramet rem jest wart ość

oznacza rząd wielkości- jeśli np. złożoność obliczeniowa przeszukiwania binarnego wynosi

O(logn), znaczy t o, że do przeszukania t ablicy zawierającej n elementó w pot rzebnych jest logn krokó w. Zapis O(j(n)) oznacza, iż przy dużych wart ościach n . czas działania algoryt mu będzie 2 najwyżej ró wnyf(n), np. O(n ) lub O(nlogn) . Takie asympt ot yczne szacunki są bardzo pomocne wt eoret ycznej analizie algoryt mó w i bardzo pomagają poró wnywać wiele ró żnych algoryt mó w, ale w prakt yce duże znaczenie mogą mieć pewne szczegó lne przypadki. N a przykład algoryt m

2) może działać szybciej niż algoryt m o wysokim poziomie O(nlogn) przy małych wart ościach n, ale po przekroczeniu pewnego progu t ej wart ości szybszy o niskim poziomie złożoności O(n

może st ać się algoryt m o wolniejszym przyroście poziomu złożoności. M usimy t akże rozró żnić pesymistyczną złożoność

algorytmu

od jego oczekiwanej złożo­

ności. N ie da się jednoznacznie określić, czym jest oczekiwana złożoność algoryt mu, ponieważ ma na nią wpływ rozważany rodzaj danych wejściowych. Zwykle da się nat omiast precyzyjnie zdefi niować złożoność pesymist yczną, chociaż może t o być czasami mylące. Złożoność pesymi­ st yczna algoryt mu szybkiego sort owania wynosiO(n

2), ale spodziewany czas jego wykonywania

określa się na poziomie O(nlogn). St arannie dobierając oś za każdym razem, możemy zmniej­ szyć prawdopodobieńst wo wyst ąpienia przypadku złożoności kwadrat owej,

O(n 2), w ist ocie do

zera. W prakt yce ty powy dobrze napisany algoryt m sort owania szybkiego ma złożoność obli­ czeniową rzędu O(nlogn) . P oniższat abela przedst awia wykaz najważniejszych rodzajó w złożoności obliczeniowej: Przykład

Notacja

Nazwa

0(1)

stała

indeks tablicy

O(logn)

logarytmiczna

przeszukiwanie binarne

O(n)

liniowa

porównywanie łańcuchów

O(nlog11)

11/ogn

sortowanie szybkie

O(n2)

kwadratowa

proste algorytmy sortowania

O(n3)

sześcienna

mnożenie macierzy

0(2")

wykładnicza

dzielenie zbiorów

2.6. TABLICE ROZSZERZALNE

51

Czas dostępu do elementów w tablicach to wielkość stała wyrażana jako 0(1). Algorytm, który w każdym przebiegu eliminuje połowę danych wejściowych, np. przeszukiwanie binarne, zwykle ma złożoność obliczeniową rzędu O(logn) . Porównanie dwóch łańcuchów po n znaków za pomocą funkcji strcmp zajmuje O(n) czasu. Typowy algorytm mnożenia macierzy ma zło­ żoność obliczeniową O(n 3), ponieważ każdy element wynikowy stanowi sumę iloczynów n par liczb, a w każdej macierzy jest n 2 elementów. Wykładnicza złożoność obliczeniowa algorytmów najczęściej bierze się z ewaluacji wszystkich możliwości - w zbiorze n elementów jest 2° podzbiorów, a więc algorytm, który musi przej­ rzeć wszystkie podzbiory, będzie miał złożoność obliczeniową rzędu 0(2°). Algorytmy o złożono­ ści wykładniczej zwykle nie nadają się do praktycznych zastosowań, z wyjątkiem przypadków, gdy wartość n jest bardzo mała, ponieważ dodanie jednego elementu powoduje podwojenie cza­ su wykonywania. Niestety, algorytmów o złożoności wykładniczej jest wiele, np. algorytm roz­ wiązujący słynny problem komiwojażera. W takich przypadkach najczęściej zadowalamy się algorytmami, które potrafią znaleźć tylko przybliżenie szukanej wartości.

Ćwiczenie 2.3. Wymień kilka zbiorów danych, które spowodowałyby pesymistyczną złożoność obliczeniową algorytmu sortowania szybkiego. Spróbuj znaleźć takie zbiory, które zmusiłyby do powolnego działania wersję algorytmu z biblioteki używanego przez Ciebie języka. Zauto­ matyzuj cały proces, aby móc łatwo i szybko wykonywać dużą liczbę testów.

Ćwiczenie 2.4. Zaprojektuj i zaimplementuj algorytm sortujący tablicę n liczb całkowitych najwolniej, jak to możliwe. Nie oszukuj, tzn. algorytm musi cały czas robić postępy i w końcu posortować dane. Nie można stosować sztuczek w rodzaju jałowych pętli. Jaka jest złożoność obliczeniowa Twojego algorytmu wyrażona jako funkcja n?

2.6. Tablice rozszerzalne Użyte we wcześniejszych podrozdziałach tablice były statyczne pod tym względem, że ich rozmiar i zawartość były ustalane już na etapie kompilacji programu. Gdybyśmy przewidywali zmiany w tablicach niepożądanych słów albo znaków HTML, lepszym rozwiązaniem byłoby użycie do ich przechowywania tablic mieszających. Złożoność obliczeniowa operacji powięk­ szania posortowanej tablicy o n elementów jednocześnie wynosi O(n2), a więc należy tego uni­ kać przy dużych wartościach n . Ponieważ często musimy mieć możliwość przechowywania zmiennych, ale niewielkich zbiorów danych, tablice mogą być dla nas bardzo dobrym rozwiązaniem. W celu zminimalizo­ wania kosztów alokacji rozmiar tablicy należy zmieniać po kawałku, a dla zachowania porząd­ ku samą tablicę najlepiej jest trzymać z informacjami potrzebnymi do zarządzania nią. W języ­ kach c+ + i Java użylibyśmy do tego klas z bibliotek standardowych. w języku c podobny efekt można uzyskać przy użyciu struktur. Poniżej znajduje się definicja rozszerzalnej tablicy elementów typu Nameva l , w której nowe elementy dodawane są na końcu. Czas dostępu do każdego elementu jest stały i dostęp odbywa się za pomocą indeksu. Jest to struktura podobna do klas wektorów w bibliotekach języków Java i c+ + .

typedef struct Nameval Nameval ; struct Nameval { *name ; char val ue; i nt

52

2. ALGORYTMY I STRUKTURY DANYCH

};

struct NVtab { i nt nval ; max ; i nt Nameval tnameval ; nvtab ;

I* aktualna liczba wartości */ /* liczba alokowanych wartości */ I* tablica par nazwa-wartość */

enum { NV I N I T = 1 , NVGROW = 2 } ; /* addname: dodaje nową nazwę i wartość do nvtab *I

i nt addname (Nameval newname) { Nameval *nvp; if (nvtab . nameval == NULL) { /*pierwszy raz */ nvtab . nameval (Nameval *) mal l oc (NV I N I T * s i zeof(Nameval ) ) ; i f (nvtab . nameval == NULL) return 1 ; nvtab . max = NVINI T ; nvtab . nval = O ; e l s e i f (nvtab . nval > = nvtab . max) { /*powiększenie */ nvp = (Nameval *) real l oc (nvtab . nameval , (NVGROW*nvtab .max) * s i zeof(Nameval ) ) ; i f (nvp == NULL) return - 1 ; nvtab . max * = NVGROW; nvtab . nameval nvp; -

=

nvtab . nameval [nvtab . nv a l ] return nvtab . nval ++ ;

newname;

Funkcja addname zwraca indeks ostatnio dodanego elementu lub -1, jeśli wystąpi jakiś błąd. Funkcja rea 1 1 oc rozszerza tablicę, zachowując jej dotychczasowe elementy, i zwraca wskaźnik na tę tablicę lub wartość NULL, jeśli jest za mało pamięci. Dzięki podwajaniu roz­ miaru w każdym wywołaniu funkcji rea 1 1 oc utrzymuje się spodziewany koszt kopiowania każdego elementu na stałym poziomie. Gdyby rozmiar był w każdym wywołaniu tej funkcji zwiększany tylko o jeden element, złożoność obliczeniowa wyniosłaby O(n2) . Ponieważ adres tablicy po realokacji może się zmienić, w pozostałej części programu musimy odwoływać się do jej elementów za pomocą indeksów, a nie wskaźników. Zwróćmy uwagę, że nie mamy nigdzie takiego kodu:

nvtab . nameval = (Nameval *) real l oc (nvtab . nameval , (NVGROW*nvtab . max) * si zeof(Nameval ) ) ; Przy takim zapisie, gdyby realokacja nie powiodła się, oryginalna tablica zostałaby utracona. Wartość początkową tablicy ustawiamy na bardzo niskim poziomie (NV I N I T = 1). W ten sposób zmuszamy program do zwiększania tablic od samego początku, a więc mamy pewność, że ta jego część zostanie od razu sprawdzona. Po przeznaczeniu programu do praktycznego użytkowania wartość tę można będzie zwiększyć, aczkolwiek koszt rozpoczynania od bardzo małego rozmiaru jest zaniedbywalnie niski.

2.6. TABLICE ROZSZERZALNE

53

Wartości zwrotnej funkcji rea 1 1 o c nie trzeba rzutować na typ ostateczny, ponieważ w ję­ zyku C promocja typu v o i d* odbywa się automatycznie. Nie robi tego jednak język C+ + , w którym t o rzutowanie jest konieczne. Można się sprzeczać, czy lepiej rzutować (czystość, uczciwość), czy nie rzutować (rzutowanie może ukrywać jakieś błędy). Zdecydowaliśmy się na rzutowanie dlatego, że dzięki niemu program jest poprawny zarówno według standardu języka C, jak i C+ + . Ceną za to jest zmniejszona czujność kompilatora języka C, ale nadrabiamy to do­ datkową możliwością przeprowadzenia testów przy użyciu dwóch kompilatorów. Problemy może sprawiać usuwanie nazw, ponieważ musimy coś zrobić z powstałą po nich luką w tablicy. Jeśli porządek elementów jest nieważny, lukę można wypełnić ostatnim ele­ mentem tablicy. W przeciwnym razie konieczne jest przeniesienie wszystkich elementów znaj­ dujących się za elementem usuniętym o jedną pozycję: I* delname: usuwa pie1wszy znaleziony element nameval z tablicy nvtab *I

i nt del narne (char *narne) { i nt i ; for ( i = O ; i < nvtab . nval ; i ++) i f (strcrnp ( nvtab . n arneval [i] . narne, narne) == O ) { rnernrnove (nvtab . narneval +i , nvtab . narneval +i+l , (nvtab . nval - ( i+l ) ) * s i zeof (Narneval ) ) ; nvtab . nval - - ; return 1 ; return O ;

Funkcja memmove zmniejsza tablicę, przesuwając jej elementy o jedną pozycję. Jest to stan­ dardowa funkcja do kopiowania bloków pamięci o dowolnym rozmiarze. W standardzie ANSI C można znaleźć definicje dwóch funkcji tego typu: memcopy, która jest szybka, ale może nadpisać pamięć, jeśli źródło i cel na siebie nachodzą, i memmove, która może działać wolniej, ale zawsze bezbłędnie. Programista nigdy nie powinien być stawiany przed dylematem wyboru między szybkością a poprawnością działania kodu. Powinna być tylko jedna funkcja. Dlatego udawajmy, że tak jest, i zawsze używajmy funkcji memmove. Wywołanie funkcji memmove można zastąpić poniższą pętlą:

i nt j ; for (j i ; j < nvtab . nval - 1 ; j ++) nvtab . narneval [j] = nvtab . narneval [j+l] ; Preferujemy jednak funkcję memmove, ponieważ chroni nas przed łatwym do popełnienia błędem skopiowania elementów w niewłaściwej kolejności. Gdybyśmy wstawiali elementy, a nie je usuwali, to w pętli musielibyśmy odliczać w dół zamiast w górę, aby uniknąć nadpisania ele­ mentów. Używając funkcji memmove, nie musimy się nad tym ciągle zastanawiać. Alternatywnym rozwiązaniem do przesuwania elementów jest oznaczanie usuniętych ele­ mentów jako nieużywanych. Wówczas przy dodawaniu nowego elementu najpierw szukaliby­ śmy nieużywanego miejsca i dopiero gdybyśmy takiego nie znaleźli, zwiększalibyśmy wektor. Nieużywany element można by było oznaczyć poprzez przypisanie mu wartości NULL. Tablice są najprostszą s trukturą danych. Nie jest dziełem przypadku to, że w większości ję­ zyków programowania są wydajne i wygodne w użyciu indeksowane tablice, ani to, że czasami łańcuchy reprezentuje się jako tablice znaków. Tablice są łatwe w użyciu, oferują czas dostępu rzędu 0(1) do każdego elementu, dobrze współpracują z algorytmami przeszukiwania binarne-

54

2 . ALGORYTMY I STRUKTURY DANYCH

go i sortowania szybkiego oraz zużywają niewiele pamięci. W przechowywaniu zbiorów danych o stałym rozmiarze, które można utworzyć już na etapie kompilacji i małych kolekcji danych, tablice są wręcz nie do pobicia. Gorzej sprawa wygląda w przypadku zbiorów danych o zmien­ nym rozmiarze. Dlatego do przechowywania nieprzewidywalnych i potencjalnie dużych zbio­ rów danych lepiej używać innych struktur.

Ćwiczenie 2.5. W powyższym kodzie funkcja del name nie wywołuje funkcji rea 1 1 oc w celu zwrócenia pamięci zwolnionej w wyniku usunięcia elementu. Czy warto się tym przejmować? Na jakiej podstawie należy podjąć decyzję, czy to ma znaczenie?

Ćwiczenie 2.6. Zmodyfikuj funkcje addname i del n ame, aby zamiast usuwać elementy, ozna­ czały je jako nieużywane. Jak bardzo reszta programu jest niezależna od tych zmian?

2.7. Listy Drugą po tablicach pod względem popularności w typowych programach strukturą danych są listy. W wielu językach można znaleźć standardowe implementacje tych struktur, a niektóre np. LISP - całkowicie się na nich opierają. To nie zmienia faktu, że jeśli w języku C chcemy użyć listy, musimy ją sobie zbudować sami. w c + + i Javie listy są dostępne w bibliotekach, ale też musimy nauczyć się z nich korzystać. W tej części rozdziału skoncentrujemy się na bu­ dowie list w języku C, ale zawarte tu wskazówki mają dalece szerszy sens.

Listy jednokierunkowe to zbiory elementów, z których każdy zawiera jakieś dane i wskaźnik na następny element. Przed pierwszym elementem listy znajduje się element zwany głową (ang. head). Zawiera on wskaźnik na pierwszy element. Natomiast na końcu listy znajduje się element, który obejmuje wskaźnik pusty. Poniższy rysunek przedstawia listę złożoną z czte­ rech elementów: G owa

-

NULL Element 1

Element 2

Element 3

Element 4

Tablice i listy różnią się między sobą w kilku kluczowych kwestiach. Po pierwsze tablice mają stały rozmiar, natomiast lista zawsze ma taki rozmiar, jaki jest potrzebny do pomieszcze­ nia wymaganych elementów, powiększony o miejsce do przechowywania wskaźników. Po dru­ gie elementy w liście można przemieszać, zmieniając tylko kilka wskaźników, co wymaga znacznie mniej pracy niż przenoszenie bloków pamięci w tablicach. W końcu dodawanie do listy elementów i usuwanie ich z niej nie wymaga przesuwania pozostałych elementów. Jeśli wskaźniki na elementy zostaną zapisane w osobnej strukturze danych, to żadne zmiany w liście nie będą mogły spowodować ich uszkodzenia. Te różnice wskazują, że do przechowywania zmiennych, a zwłaszcza nieprzewidywalnych zbiorów danych lepiej nadają się listy. Tablice są natomiast lepsze do przechowywania danych statycznych. Istnieje zbiór podstawowych operacji, które można wykonać na każdej liście - dodawanie elementu na początku i końcu, wyszukiwanie określonego elementu, dodawanie i usuwanie elementu znajdującego się przed lub za określonym elementem oraz usuwanie wybranego ele­ mentu. Listy są jednak na tyle prostymi strukturami, że ich zestaw operacji można w razie po­ trzeby bez trudu rozszerzyć.

2.7. LISTY

55

W języku C, aby skorzystać z listy, nie pisze się bezpośredniej definicji typu L i st, lecz po prostu definiuje się typ elementów, jak np. typ Nameval , o którym już była mowa, i wzbogaca się go o wskaźnik na następny element:

typedef struct Nameval Nameval ; struct Nameval { char *name ; i nt val u e ; Nameva l *n ext ; /* następny element listy */

};

Ponieważ trudno jest zainicjalizować pustą listę w czasie kompilacji, listy w przeciwień­ stwie do tablic są tworzone dynamicznie. Najpierw musimy znaleźć sposób na tworzenie ele­ mentów. Najprościej będzie zastosować alokację przy użyciu odpowiedniej funkcji, którą na­ zwiemy newi tern: I* newitem: tworzy nowy element z naZłl'.)' i wartości *I

Nameval *newi tem ( char *name, i nt val ue) { Nameval *newp ; newp ; (Nameval *) emal l oc (s i zeof(Nameval ) ) ; newp->name ; name ; newp->val ue ; val ue; newp->next ; NULL; return newp;

Procedury ema 1 1 oc będziemy używać jeszcze wiele razy, więc warto się z nią bliżej zapo­ znać. Wywołuje ona funkcję ma 1 1 oc i jeśli alokacja się nie powiedzie, zgłasza błąd, po czym zamyka program. Jej kod zobaczymy w rozdziale 4. Na razie wystarczy nam wiedza, że będzie­ my ją traktować jako alokator pamięci, który nigdy nie zwraca informacji o niepowodzeniu. Najprostszym i najszybszym sposobem tworzenia listy jest dodawanie nowych elementów na początku: /* addfront: dodaje newp na początku listp */

Nameval *addfront(Nameval *l i st p , Nameval *newp) { newp->next ; l i st p ; return newp ;

Jeśli lista zostanie zmodyfikowana, jej pierwszy element może zostać zmieniony - tak się dzieje, gdy wywołamy jej funkcję addfront. Dlatego funkcje zmieniające listę muszą zwracać wskaźnik na jej nowy pierwszy element, który jest zapisywany w zmiennej oznaczającej listę. Funkcja addfront i podobne do niej zwracają ten wskaźnik jako swoją wartość zwrotną. Oto typowy sposób użycia tej funkcji:

nv l i st ; addfront ( nv 1 i st, new i tem ( 11 smi l ey 11 , Ox263A) ) ; Tak zaprojektowanej funkcji można używać nawet wówczas, gdy lista jest pusta, a ponadto nie sprawia ona problemów przy łączeniu z innymi funkcjami w wyrażeniach. To podejście wydaje się bardziej naturalne niż przekazywanie wskaźnika na wskaźnik głowy listy.

56

2. ALGORYTMY I STRUKTURY DANYCH

Złożoność obliczeniowa operacji dodawania elementu na końcu listy wynosi O(n), ponie­ waż aby znaleźć koniec, musimy przejrzeć wszystkie elementy listy: I* addend: dodaje newp na ko1icu listy listp */

Nameval *addend (Nameval *l i stp, Nameval *newp) { Nameval *p; if ( l i stp NULL) return newp ; for (p = l i stp ; p->next ! = NULL ; p = p->next) ==

p->next newp ; return l i stp ; =

Gdybyśmy chcieli obniżyć złożoność obliczeniową funkcji addend do 0(1), moglibyśmy osobno zapisać wskaźnik na ostatni element listy. Wadą tej metody, pomijając kłopoty z utrzymaniem wskaźnika na ostatni element, jest to, że nasza lista nie byłaby już reprezentowana tylko przez jedną zmienną wskaźnikową. Dlatego pozostaniemy przy uproszczonej wersji. Aby znaleźć element o określonej nazwie, listę należy przeglądać przy użyciu wskaźnika

next : /* lookup: sekwencyjne wyszukiwanie nazw w listp */

Nameval *l ookup(Nameval *l i st p , char *name) { for ( ; l i stp ! = NULL; l i stp = l i stp->next) i f (strcmp (name, l i stp->name) == O) return l i stp ; return NULL; /* nie znaleziono */

Ta operacja ma złożoność obliczeniową rzędu O(n) i w zasadzie nie da się tego wyniku po­ prawić. Nawet gdyby lista była posortowana, i tak musielibyśmy ją przejrzeć liniowo, aby do­ trzeć do określonego elementu. W listach nie da się zastosować przeszukiwania binarnego. Drukowanie elementów listy można zaimplementować w postaci funkcji odwiedzającej i dru­ kującej po kolei wszystkie elementy. Długość listy można obliczyć za pomocą funkcji przechodzą­ cej kolejno od elementu do elementu i za każdym razem zwiększającej licznik. Alternatywnie można napisać jedną funkcję, np. o nazwie appl y, która będzie przeglądać listę i dla każdego jej elementu wywoływać jakąś inną funkcję. Funkcja ta będzie jeszcze bardziej przydatna, jeśli umożliwimy przekazanie w niej argumentu funkcji, którą ma wywoływać. Zatem nasza funkcja app l y będzie miała trzy argumenty - lista, funkcja do wywołania na rzecz każdego elementu oraz argument dla tej funkcji: /* apply: wykonujefn dla każdego elementu listp */

voi d app l y (Nameval *l i stp , v o i d {*fn) (Nameval * , voi d*) , v o i d *arg) for ( ; l i stp ! = NULL; l i stp = l i stp->next) {*fn) { l i st p , arg) ; /* wywolaniefankcji */

57

2.7. LISTY

Drugim argumentem funkcji app l y jest wskaźnik na funkcję, która pobiera dwa argumenty i nie zwraca wyniku. Standardowy, choć mało elegancki zapis

voi d (*fn) (Nameval * , voi d*) jest deklaracją fn jako wskaźnika na funkcję voi d, tzn. fn jest zmienną przechowującą ad­ res funkcji, która nie zwraca wyniku. Pobiera ona dwa argumenty: Nameva 1 * (element listy) i voi d * (ogólny wskaźnik na argument tej funkcji). Aby za pomocą funkcji app 1 y np. wydrukować elementy listy, możemy napisać prostą funkcję pobierającą jako argument łańcuch formatujący: /*printnv: drukuje nazwy i wartości przy użyciuformatu zapisanego w arg */

v o i d pri ntnv (Nameval *p, voi d *arg) { char *fmt ; fmt = (char *} arg ; pri ntf ( fmt , p->name, p->val ue) ;

Oto sposób jej wywołania:

appl y (nvl i st , pri ntnv, "%s : %x\n " ) ; Do liczenia elementów zdefiniujemy funkcję przyjmującą jako argument wskaźnik na liczbę całkowitą, którą będziemy odpowiednio zwiększać: /* inccozmter: zwiększa licznik *arg */

voi d i nccounter (Nameva 1 *p , voi d *arg) i nt * i p ; /* pjest nieużywany */

i p = ( i nt *) arg ; (*i p ) ++ ;

Sposób wywołania:

i nt n ; n = O; appl y ( nvl i st , i nccounter, &n) ; pri ntf ( " Li czba el ement6w w l i lc i e nvl i st : %d \n " , n ) ; Ten sposób nie jest najlepszy do wykonywania wszystkich operacji listowych. Przykładowo przy usuwaniu listy powinniśmy zachować większą ostrożność: /* ji-eeall: zwalnia wszystkie elementy listp */

v o i d freeal 1 (Nameval * 1 i stp) { Nameval *next ; for ( ; l i stp ! = NULL; l i stp next = l i stp->next ;

next) {

58

2. ALGORYTMY I STRUKTURY DANYCH

/* założenie, że name usunięto gdzieś indziej *I

free ( 1 i stp) ;

Ponieważ po zwolnieniu pamięci nie można jej używać, przed zwolnieniem elementu wskazy­ wanego przez wskaźnik l i stp musimy l i stp->next zapisać w zmiennej lokalnej o nazwie next. Gdyby pętla została napisana tak jak inne

for ( ; l i stp ! = NULL ; l i stp = l i stp->next) free ( l i stp} ; wartość l i stp->next mogłaby zostać nadpisana przez free i wystąpiłby błąd. Zauważmy, że funkcja freea 1 1 nie zwalnia pamięci pola l i s tp->narne. Przyjęliśmy w niej założenie, że pole narne każdego elementu Narneva l zostanie zwolnione gdzieś indziej albo że nigdy nie zostało alokowane. Zapewnienie spójnej alokacji i zwalniania elementów wymaga zsynchronizowania działania funkcji new i tern i freea 1 1 . Trzeba zdecydować, czy wolimy gwa­ rancję, że pamięć zostanie zwolniona, czy że nie zostanie zwolnione nic, co nie powinno zostać zwolnione. Jeśli popełnimy tu błąd, będziemy mieli wiele problemów. W innych językach, takich jak Java, problem ten rozwiązuje za nas system usuwający nie­ użytki. Do tern.atu zarządzania zasobami wrócimy jeszcze w rozdziale 4. Usunięcie elementu z listy wymaga więcej pracy niż dodanie go: /* de/item: usuwa pie1wszą nazwę z listy listp */

Nameval *del i tem(Nameval *l i st p , char *name) { Nameval *p , *prev; prev = NULL; for (p = l i st p ; p ! = NULL; p = p->next) i f (strcmp (name , p->name) == O) { i f (prev == NULL) l i stp = p->next; el se prev->next = p->nex t ; free (p} ; return l i stp ; prev = p ; epri ntf ( " del i tem : % s n i e ma w l i §c i e " , name} ; return NULL; /* nie można się tu dostać */

Podobnie jak freea 1 1 funkcja del i tern nie zwalnia pola narne. Funkcja epri ntf wyświetla komunikat o błędzie i zamyka program, a więc nie działa zbyt zgrabnie. Eleganckie wychodzenie z sytuacji awaryjnych to trudna sztuka, której trzeba po­ święcić nieco więcej uwagi. Odkładamy to do rozdziału 4., w którym zobaczymy też implemen­ tację funkcji epri ntf. Te podstawowe struktury i operacje listowe wystarczą do większości zastosowań w typo­ wych programach. Nie oznacza to jednak, że poza nimi nie ma już nic więcej. W niektórych bibliotekach, takich jak biblioteka STL języka C + + , można znaleźć listy dwukierunkowe,

59

2.8. DRZEWA

a więc takie, w których każdy element ma dwa wskaźniki - n a element poprzedni i następny. Mimo iż listy takie zajmują trochę więcej pamięci, znaj dowanie w nich ostatniego elementu i usuwanie bieżącego to operacje o złożoności obliczeniowej rzędu 0(1). W niektórych przy­ padkach wskaźniki na elementy są alokowane osobno - nie z danymi, które łączą. Listy takie są nieco trudniejsze w użyciu, ale za to pozwalają na występowanie elementów w kilku listach jednocześnie. Oprócz wielkich zalet w sytuacjach, gdy trzeba dodawać i usuwać elementy w środku struk­ tury, listy doskonale nadają się do przechowywania elementów o zmiennym rozmiarze, zwłasz­ cza jeśli dostęp do nich uzyskuje się głównie według zasady LIFO (ang. last-in-first-out „ostatni przyszedł, pierwszy wyjdzie"), czyli tak jak w stosach. Jeżeli w programie użyto kilku stosów, które niezależnie od siebie są powiększane i zmniejszane, taki sposób wykorzystania pamięci jest bardziej efekcywny, niż gdyby do tego celu użyto tablic. Dodatkowym atutem tych list jest to, że doskonale sprawdzają się w przechowywaniu informacji jakoś wewnętrznie upo­ rządkowanych, ale o nieznanym z góry rozmiarze - takie cechy mają dane w postaci słów z dokumentów tekstowych. Jeśli jednak planujesz częste aktualizacje i potrzebujesz swobodnego dostępu do elementów, lepiej użyć nieliniowej struktury danych, np. drzewa lub tablicy mieszającej.

Ćwiczenie 2.7. Zaimplementuj kilka innych operacji listowych, np. kopiowanie, scalanie, dzielenie na dwie części oraz wstawianie elementu za i przed wybranym elementem. Czy obie operacje wstawiania są tak samo trudne w implementacji? W jakim stopniu możesz wykorzy­ stać napisane do tej pory procedury, a ile musisz napisać samodzielnie?

Ćwiczenie 2.8. Napisz funkcję reverse, która odwraca kolejność elementów listy, w wersji re­ kurencyjnej i iteracyjnej. Nie twórz nowych elementów listy, lecz wykorzystaj istniejące.

Ćwiczenie 2.9. Napisz ogólny typ Li st w języku C. Najprościej będzie to zrobić poprzez zapisanie w każdym elemencie listy wskaźnika typu voi d* wskazującego na dane. To samo zrób w języku C+ + przy użyciu szablonów i w Javie przez zdefiniowanie klasy przechowującej listy typu Obj ect. Jakie są słabe i mocne strony każdego z tych języków, jeśli chodzi o realizację tego zadania? Ćwiczenie 2.10. Zaprojektuj i zaimplementuj zestaw testów do weryfikacji swoich operacji listowych. Techniki testowania są opisane w rozdziale 6.

2.8. Drzewa Drzewo to hierarchiczna struktura danych, w której każdy element ma jakąś wartość, może wskazywać zero lub więcej innych elementów i jest wskazywany przez dokładnie jeden inny element. Wyjątkiem jest element zwany korzeniem drzewa, na który nie wskazuje żaden inny węzeł. Istnieje wiele rozmaitych rodzajów drzew odzwierciedlających nawet skomplikowane struktury, takie jak drzewa powstałe w wyniku analizy składni zdań albo programów czy też drzewa ro­ dzinne ukazujące relacje między ludźmi. Budowę drzew prześledzimy na przykładzie binarnego drzewa poszukiwań, czyli takiego, w którym każdy węzeł ma dwa połączenia z innymi węzła­ mi. Jest to najłatwiejszy typ drzew do implementacji, a przy okazji pozwalają zademonstrować podstawowe cechy tego rodzaju struktur danych. Każdy węzeł binarnego drzewa poszukiwań ma wartość i dwa wskaźniki l eft i ri ght na jego dzieci. Jeśli węzeł ma mniej niż dwoje dzieci, to wskaźnik brakującego potomka jest pusty. Cechą charakterystyczną binarnych drzew -

-

60

2. ALGORYTMY I STRUKTURY DANYCH

poszukiwań jest to, że potomkowie znajdujący się po lewej stronie każdego węzła mają od niego mniejsze wartości, a znajdujące się po prawej stronie - większe. Dzięki temu drzewa takie można szybko przeszukiwać w celu znalezienia określonego elementu albo stwierdzenia, że dany element nie istnieje. Struktura Nameva l w postaci drzewa jest bardzo prosta:

typedef struct Nameval Nameval ; struct Nameval { char *name ; i nt val ue; Nameva 1 *1 eft ; I* mniejszy *I Nameva 1 *ri ght ; /* większy *I }; Komentarze mni ej szy i wi ększy odnoszą się do właściwości łączy - dzieci po lewej stronie przechowują wartości mniejsze, a po prawej - większe od rodzica. Spójrzmy na konkretny przykład. Na poniższym rysunku widzimy fragment tablicy nazw znaków przedstawionej w postaci binarnego drzewa poszukiwań elementów Nameva l , posorto­ wanych według wartości przyporządkowanych im w standardzie ASCII: " smi l ey " Ox263A

/ °""-

/

�

" zeta "

"Aacut e "

Ox03b6

OxOOcl

/

/

"AEl i g " Ox00c6

°""-

�

" Ac i re " Ox00c2

Dzięki dodatkowym wskaźnikom na inne elementy w każdym węźle drzewa wiele operacji, które w listach i tablicach miały złożoność obliczeniową rzędu O(n), w drzewie ma złożoność tylko O(logn). Wskaźniki te pozwalają zmniejszyć złożoność czasową operacji poprzez zmniej­ szenie liczby węzłów, które trzeba sprawdzić, aby znaleźć szukany element. Binarne drzewo poszukiwań (które od tej pory będziemy dla uproszczenia nazywać po pro­ stu drzewem) tworzy się poprzez rekurencyjne dodawanie potomków węzłów, przechodząc od­ powiednio do lewej lub prawej gałęzi, aż do znalezienia odpowiedniego miejsca do zapisu ele­ mentu, który musi być poprawnie zainicjalizowanym obiektem typu Nameval - nazwa, wartość i dwa wskaźniki puste. Nowy węzeł jest dodawany jako liść, tzn. nie ma jeszcze żadnych potomków.

61

2.8. DRZEWA

/* insert: wstawia newp do treep i zwraca treep */

Nameval *i nsert (Nameval *treep , Nameval *newp) { i nt cmp ; i f (treep NULL) return newp ; cmp = strcmp ( newp->name, treep->name) ; i f (cmp O) wepri ntf ( " i nsert : el ement %s j uż występuj e newp->name) ; el se i f (cmp < O) t reep->l eft i nsert (treep->l eft , newp) ; el se treep->ri ght i nsert (treep->ri ght , newp) ; return t reep ; ==

==

został z i gnorowany " ,

=

=

Do tej pory nie wspomnieliśmy jeszcze o dublowaniu się elementów. Ta wersja funkcji i nsert nie pozwala na dodanie do drzewa dwóch takich samych elementów (cmp == O). Analogiczna procedura listowa nie zgłaszała w takim przypadku problemu, gdyż wymagałoby to przeszuka­ nia całej listy, co wydłuży czas wstawiania z 0(1) do O(n) . W drzewach takie sprawdzenie do­ stajemy za darmo w promocji, a poza tym nie ma jasności, jak miałaby wyglądać ta struktura, gdyby dopuścić w niej duplikaty. W niektórych przypadkach jednak dopuszczenie duplikatów może być konieczne lub najlepszym rozwiązaniem będzie ich ignorowanie. Procedura wepri ntf jest zmodyfikowaną wersją funkcji epri ntf. Drukuje komunikat o błędzie poprzedzony słowem warni ng, ale w przeciwieństwie do pierwowzoru nie zamyka programu. Drzewo, w którym długość drogi od korzenia do dowolnego liścia jest mniej więcej taka sama, nazywa się drzewem zrównoważonym (ang. balanced tree). Zaletą drzew zrównoważo­ nych jest to, że wyszukiwanie w nich dowolnego elementu ma złożoność obliczeniową rzędu O(logn), ponieważ w każdym kroku liczba możliwości zmniejsza się o połowę - tak jak w prze­ szukiwaniu binarnym. Jeśli elementy są dodawane do drzewa na bieżąco wprost z wejścia, może powstać drzewo niezrównoważone, a w najgorszych przypadkach może nawet przybrać wyjątkowo niefortunny kształt. Jeżeli np. dodawane elementy są już posortowane, program dla każdego kolejnego ele­ mentu będzie tworzył nową niższą gałąź. W ten sposób powstanie lista złożona po linii dowią­ zań prawostronnych, która będzie miała wszystkie wady zwykłej listy. Jeśli jednak elementy na wejściu będą się pojawiały w kolejności losowej, ryzyko wystąpienia takiej sytuacji jest bardzo mało prawdopodobne i najczęściej wówczas powstaje drzewo, lepiej lub gorzej zrównoważone. Implementacja drzewa gwarantującego zrównoważenie jest skomplikowana i właśnie z tego powodu istnieje tak dużo różnych rodzajów drzew. My w celach edukacyjnych pominiemy ten problem i przyjmiemy założenie, że dane są wystarczająco dobrze pomieszane, aby mogło po­ wstać drzewo zrównoważone. Kod funkcji l oo kup, przeszukującej drzewo, jest podobny do funkcji i n sert: I* lookup: szuka nazwy w drzewie treep */

Nameval *l ookup (Nameval *treep , char *name) { i nt cmp ; i f (treep == NULL) return NULL ; cmp = strcmp (name , treep->name) ; i f (cmp == O)

62

2. ALGORYTMY I STRUKTURY DANYCH

return treep ; el se i f (cmp < O) return l oo kup {treep->l eft , name) ; el se return l oo kup {treep->right, name) ;

W tym miejscu należy poczynić kilka uwag na temat funkcji l oo kup i i n sert. Po pierwsze wyglądają łudząco podobnie do prezentowanego już na początku rozdziału algorytmu przeszu­ kiwania binarnego. Nie jest to przypadkowe podobieństwo, gdyż algorytmy te działają według tej samej zasady „dziel i rządź", która ma logarytmiczną złożoność obliczeniową. Po drugie obie procedury są rekurencyjne. Gdybyśmy je napisali przy użyciu iteracji, były­ by jeszcze podobniejsze do przeszukiwania binarnego. W istocie iteracyjną wersję funkcji l o­ o kup można zrealizować, przerabiając jej wersję rekurencyjną. Jeśli nie znajdzie szukanego elementu, ostatnią czynnością funkcji l ookup jest zwrot wyniku swojego własnego wywołania - jest to tzw. rekurencja ogonowa (ang. taił recursion). Funkcję tę można łatwo przekształcić w iteracyjną, uzupełniając argumenty i wywołując ją ponownie. Najprościej byłoby użyć in­ strukcji goto, ale pętla wh i l e jest znacznie bardziej przejrzysta: I* nrlookup: nierekurencyjne wyszukiwanie nazwy name w drzewie treep *I

Nameval *nrl ookup {Nameval *treep , char *name) { i nt cmp ; whi l e (treep ! NULL) { cmp ; strcmp (name , treep->name) ; i f ( cmp O) return treep ; el se i f (cmp < O) treep treep->l eft ; el se treep treep->ri ght; ;

;;

return NULL;

Gdy już będziemy mogli poruszać się po drzewie, zaprogramowanie pozostałych operacji to już nic trudnego. Możemy wykorzystać niektóre techniki zastosowane w listach, np. napisanie ogólnej funkcji przeglądającej drzewo i wywołującej wybraną funkcję dla każdego węzła. Tym razem musimy jednak dokonać pewnych wyborów: kiedy będziemy wykonywać operacje na elementach i kiedy będziemy przetwarzać resztę drzewa? Odpowiedź na te dwa pytania zależy od tego, co reprezentuje drzewo. Jeśli służy do przechowywania danych w określonym porządku, jak binarne drzewo poszukiwań, najpierw przeglądamy lewą stronę, a potem prawą. Czasami jednak struktura drzewa odzwierciedla specyficzny porządek danych, tak jak w drzewie gene­ alogicznym. Wówczas kolejność odwiedzania liści zależy od rodzaju relacji reprezentowanych przez drzewo. Przy przeglądaniu poprzecznym drzewa (ang. in-order traversal) operacja jest wykonywana po przejrzeniu lewego poddrzewa, ale jeszcze przed przejrzeniem prawej części: I* applyinorder: wywołanie.fimkcjifi1 na węzłach drzewa treep przy zastosowaniu metodyprzeglądania poprzecznego *I

voi d app l yi norder (Nameval *treep , void {*fn ) (Nameval * , voi d*) , voi d *arg)

63

2.8. DRZEWA

i f (treep NULL) return ; appl yi norder(treep->l eft , fn , arg) ; {*fn) ( treep , arg ) ; appl yi norder(treep->ri ght , fn , arg) ; ==

T ę metodę przeglądania drzew stosuje się wówczas, gdy węzły trzeba odwiedzać w określo­ nym porządku, aby je np. po kolei wydrukować:

appl yi norder(treep, pri ntnv , "%s : %x\n " ) ; Na tej podstawie można też opracować dobrą technikę sortowania - wstaw elementy do drzewa, alokuj tablicę o odpowiednim rozmiarze, a następnie zastosuj technikę przeglądania poprzecznego w celu zapisania ich w tablicy w odpowiedniej kolejności.

Przeglądanie wsteczne (ang. post-order traversal) polega na wykonaniu działań na węźle dopie­ ro po odwiedzeniu jego obu potomków: /* applypostorder: wywołaniefankcjifi1 na węzłach drzewa treep przy zastosowaniu metody przeglądania wstecznego */

void appl ypostorder (Nameval *treep , voi d (*fn) (Nameval * , voi d*) , voi d *arg) i f (treep NULL) return ; appl ypostorder(treep->l eft , fn , arg) ; appl ypostorder (treep->ri ght , fn , arg) ; (*fn ) (treep , arg) ; ==

Przeglądanie wsteczne stosuje się wówczas, gdy operacja na węźle jest zależna od jego pod­ drzew. Przykładem jest tu np. obliczanie wysokości drzewa (weź większą z wysokości dwóch poddrzew i dodaj do niej jeden), rozmieszczanie drzewa w pakiecie graficznym (przydziel miej­ sce na stronie dla każdego poddrzewa, a następnie połącz je w celu wyznaczenia miejsca dla całego węzła) oraz obliczanie ogólnej ilości wymaganej pamięci. Trzecia możliwość to przeglądanie wzdłużne (ang. pre-order traversal), które rzadko się sto­ suje, a więc je pominiemy. Binarne drzewa poszukiwań są używane nieczęsto, ale tzw. B-drzewa, charakteryzujące się silnym rozgałęzieniem, są wykorzystywane do przechowywania informacji w pamięci drugiego stopnia. W codziennym programowaniu drzewa często wykorzystuje się do reprezentacji struk­ tury instrukcji i wyrażeń. Na przykład instrukcję

mi d

=

( l ow + hi gh) / 2 ;

można zaprezentować w postaci drzewa analizy składniowej widocznego na poniższym ry­ sunku. Aby obliczyć jej wartość, należy zastosować przeglądanie wsteczne z wykonaniem od­ powiedniej operacji w każdym węźle.

64

2. ALGORYTMY I STRUKTURY DANYCH

/ �

mi d

+

I

/ �

2

/ �

l ow

h i gh

Drzewom analizy składniowej dokładniej przyjrzymy się w rozdziale 9.

Ćwiczenie 2.11. Porównaj działanie funkcji 1 ookup i nrl ookup. Jak rekurencja wypada w po­ równaniu z iteracją pod względem wydajności? Ćwiczenie 2.12. Napisz procedurę sortującą przy użyciu przeglądania poprzecznego. Jaką zło­ żoność czasową ma ten algorytm? W jakich warunkach działałby najgorzej? Jak wypada pod względem wydajności w porównaniu z naszym algorytmem szybkiego sortowania i wersją bi­ blioteczną? Ćwiczenie 2.13. Zaprojektuj i zaimplementuj zestaw testów do sprawdzenia poprawności swoich trzech procedur.

2.9. Tablice mieszania Tablice mieszania to jedno z najwspanialszych osiągnięć informatyki. Łączą w sobie zalety zwykłych tablic i list, do których zastosowano pewne koncepcje matematyczne. To wszystko sprawia, że są doskonałym narzędziem do przechowywania i wyszukiwania informacji, które mogą się zmieniać. Typową realizacją tablicy mieszania jest tablica symboli, która umożliwia powiązanie wartości (dane) z dowolnym elementem zmieniającego się zbioru łańcuchów (klu­ czy). Twój ulubiony kompilator prawie na pewno używa takiej tablicy do przechowywania in­ formacji o wszystkich zmiennych w Twoich programach. Przeglądarki internetowe w tablicach symboli mogą zapisywać informacje o niedawno odwiedzanych stronach, a gdy łączysz się z Internetem, to zapewne w takiej tablicy zapisujesz nazwy ostatnio odwiedzanych domen i ich adresy IP. Idea jest taka, aby przepuścić klucze przez specjalną funkcję mieszającą w celu wygenerowania z nich wartości funkcji mieszania równomiernie rozprowadzonych w niewielkim zbiorze liczb całkowitych. Wartości funkcji mieszania są używane jako indeksy podczas zapisywania danych w tablicy. W języku Java dostępny jest standardowy interfejs do tablic rozproszonych, natomiast w C i C+ + najczęściej z każdą wartością funkcji mieszania (tzw. kubełkiem - ang. bucket) wiąże się listę elementów, dla których wartość ta jest wspólna, jak widać na rysunku przedstawionym na następnej stronie. W praktyce często funkcja mieszania jest od początku dostępna, a tablica odpowiedniego rozmiaru jest alokowana na etapie kompilacji. Każdy element tej tablicy tworzy listę powiąza­ nych elementów, które mają tę samą wartość funkcji mieszającej. Innymi słowy, tablica mie­ szania n elementów to tablica list, których średnia długość wynosi n/(rozmiar tablicy). Pobiera­ nie elementów to operacja o złożoności rzędu 0(1), ale pod warunkiem, że zostanie użyta dobra funkcja mieszająca i listy nie będą zbyt długie.

65

2.9. TABLICE MIESZANIA

symtab[NHASH] :

Łańcuchy elementów w kubełkach: -

NULL

NULL

name l

name 2

NULL

va l u e 1

value 2

NU LL -

NULL

NULL

name 3

NULL

value 3

Dzięki temu, że tablica mieszania to w istocie tablica list, jej elementy mają taki sam typ, jak elementy listy:

typedef struct Nameval Nameval ; struct Nameval { char *name ; i nt val u e ; I* Następny w lmicuchu */ Nameval *nex t ; }; Nameva1 *symtab [NHASH] ; /* Tablica symboli */ Do zarządzania poszczególnymi łańcuchami elementów można wykorzystać techniki listowe opisane w części 2.7. Jeśli mamy dobrą funkcję mieszającą, to praca pójdzie nam jak po maśle - wybieramy tylko kubełek i przechodzimy wzdłuż listy, aby znaleźć idealne dopasowanie. Poniżej prezentujemy kod procedury przeszukującej tablicę mieszania i wstawiającej do niej wartości. Jeśli określony element zostanie znaleziony, funkcja go zwróci. Jeżeli element nie zo­ stanie znaleziony, a sygnalizator create będzie włączony, funkcja doda go do tablicy. Ta funk­ cja również nie tworzy kopii nazwy, gdyż przyjęte zostało, że wywołujący sam wykonał jej ko­ pię zapasową. /* loo/...--i1p: znajduje nazwę w symtab lub opcjonalnie ją tworzy */

Nameval * l ookup {char *name , i nt create , i nt val ue) { i nt h ; Nameval *sym; h hash (name) ; for (sym symtab [h] ; sym ! = NULL; sym = sym->next) i f (strcmp (name , sym->name) O) return sym; i f ( create) { sym = (Nameval *) emal l oc {s i zeof (Nameval } ) ; sym->name = name; /* Zakładamy, że ma przydzieloną pamięć gdzieś indziej */ sym->val ue val ue; sym->next symtab [h] ; symtab [h] sym; =

=

==

=

=

return sym;

66

2. ALGORYTMY I STRUKTURY DANYCH

Takie połączenia procedur przeszukiwania i wstawiania elementów są spotykane bardzo często. Bez tego konieczne byłoby wykonywanie tej samej pracy dwa razy, ponieważ musieliby­ śmy pisać instrukcje tego rodzaju:

i f ( l ookup ( " name " ) == NULL) addi tem(newi tem ( "name" , val ue) ) ; przez co wartość funkcji mieszającej byłaby obliczana dwukrotnie. Jaki rozmiar powinna mieć tablica? Ogólnie przyjmuje się, że powinna mieć rozmiar wy­ starczający do tego, aby w każdym łańcuchu znajdowało się przynajmniej kilka elementów, dzięki czemu złożoność obliczeniowa operacji znajdowania elementów wyniesie 0(1) . Na przy­ kład kompilator może mieć rozmiar tablicy ustawiony na kilka tysięcy, ponieważ duży plik źró­ dłowy może się składać z kilku tysięcy wierszy kodu, przy czym nie przewiduje się, aby iden­ tyfikatorów było więcej niż wierszy kodu. Teraz trzeba zdecydować, co nasza funkcja mieszająca h a s h będzie obliczać. Jej wynik musi być określony, powinna być szybka i równomiernie rozmieszczać dane w tablicy. Jeden z naj­ częściej stosowanych algorytmów obliczania wartości mieszania dla łańcuchów dodaje każdy bajt łańcucha do wielokrotności dotychczas uzyskanej wartości mieszania. Mnożenie rozpro­ wadza bity nowego bajta w już obliczonej wartości. Gdy pętla zakończy działanie, powinniśmy otrzymać wartość powstałą z wymieszania bajtów wprowadzonych na wejściu. W wyniku doświad­ czeń stwierdzono, że dla łańcuchów znaków ASCII najlepszymi mnożnikami są liczby 3 1 i 37.

enum { MULT I PLIER

=

31} ;

/* hash: oblicza wartościfunkcji mieszającej dla łmicuchów */

unsi gned i nt hash (char *str) { unsi gned i nt h ; unsi gned char * p ; h = O; for ( p (unsi gned char *} str; * p ! = ' \O ' ; p++) h MULT I PL I ER * h + *p ; return h % NHASH ; =

=

W obliczeniach wykorzystywane są zmienne typu unsi gned char, ponieważ w językach C i C + + nie jest określone, czy zmienna typu char ma mieć znak, czy nie, a my chcemy, aby wartość funkcji mieszającej była dodatnia. Wynikiem funkcji mieszającej jest obliczona wartość podzielona modulo przez rozmiar ta­ blicy. Jeśli funkcja mieszająca rozprowadza wartości kluczy równomiernie, to dokładny roz­ miar tablicy nie ma znaczenia. Nigdy jednak nie można mieć pewności, że funkcja mieszająca będzie działać idealnie. Istnieją takie zestawy danych wejściowych, przy których może zawieść nawet najlepsza funkcja. Dlatego warto rozmiar tablicy określić liczbą pierwszą, co da nam gwarancję, że rozmiar tablicy, mnożnik i spodziewane wartości nie będą przynajmniej miały wspólnego dzielnika. Doświadczenie pokazuje, że dla zróżnicowanych zbiorów łańcuchów trudno jest napisać lep­ szą funkcję mieszającą od powyższej, ale za to z łatwością można stworzyć taką działającą od niej gorzej. We wczesnych wersjach Javy była dostępna funkcja mieszająca, która lepiej się sprawdzała, gdy używano jej do długich łańcuchów znaków. Jeśli łańcuch składał się z więcej niż 16 znaków, oszczędzano czas, sprawdzając w regularnych odstępach czasu tylko jego 8 lub 9 pierwszych znaków. Niestety, słabe właściwości statystyczne funkcji wszystkie te oszczędności obracały wniwecz. Pomijanie części znaków powodowało, że niektórych łańcuchów nie dało się

2.9. TABLICE MIESZANIA

67

rozróżnić. Tak było np. z nazwami plików, które często na początku mają identyczny długi ciąg znaków określający katalog, a różnią się tylko kilkoma znakami na końcu, np . .java i .class. Większość adresów URL zaczyna się od ciągu http://, a kończy ciągiem .html, a więc różnice występują głównie w ich części środkowej. Opisywana funkcja mieszająca często sprawdzała tylko tę wspólną część nazwy, co powodowało powstawanie bardzo długich łańcuchów elemen­ tów, które utrudniały przeszukiwanie tablicy. Aby rozwiązać problem, pierwotną funkcję mie­ szającą zastąpiono inną, podobną do tej, którą przedstawiliśmy powyżej (z mnożnikiem 37), sprawdzającą każdy znak w łańcuchu. Funkcja mieszająca, która dobrze działa na danych jednego rodzaju (np. krótkich nazwach zmiennych), nie musi wcale dobrze się sprawdzać, gdy poda się jej dane innego typu, takie jak np. adresy URL. Dlatego przed użyciem funkcję taką należy zawsze dokładnie przetestować. Czy dobrze miesza krótkie łańcuchy? Jak radzi sobie z długimi? A jak się sprawdza w przypad­ ku łańcuchów o tej samej długości, które tylko nieznacznie się różnią? Działaniu funkcji mieszających można poddawać nie tylko łańcuchy. Jeśli np. przeprowa­ dzamy symulacje fizyczne, w tablicach mieszania możemy przechowywać trójwymiarowe współrzędne cząsteczek. To pozwala zaoszczędzić pamięć, gdyż zamiast tablicy trójwymiarowej o złożoności pamięciowej O(wartośćx x wartośćy x wartośćz) użylibyśmy tablicy jednowymiaro­ wej o złożoności O(liczba cząsteczek). Doskonały przykład wykorzystania tablic mieszania można znaleźć w programie Supertra­ ce Gerarda Holzmanna służącym do analizy protokołów i systemów współbieżnych. Program ten zbiera informacje o wszystkich możliwych stanach badanego systemu, następnie przepusz­ cza je przez funkcję mieszającą, aby wygenerować adres pojedynczego bitu w pamięci. Jeśli bit ma wartość 1, oznacza to, że był już wcześniej widziany. W przeciwnym razie stan ten jeszcze nie występował. Mimo iż program Supertrace korzysta z tablicy o rozmiarze wielu bajtów, to w każdym kubełku przechowuje tylko po jednym bicie. W związku z tym w strukturze tej nie ma łańcuchów elementów. Jeżeli wystąpi kolizja spowodowana tym, że dla dwóch stanów funkcja mieszająca zwróci tę samą wartość, program tego nie spostrzeże. Autorzy liczą na to, że prawdopodobieństwo wystąpienia kolizji jest bardzo niskie (nie musi być zerowe, gdyż pro­ gram Supertrace i tak daje tylko przybliżone wyniki). Dlatego funkcję mieszającą zaprojekto­ wano niezwykle skrupulatnie. Zastosowano w niej cykliczną kontrolę nadmiarową (ang. cyclic redundancy check), czyli funkcję, która dokładnie miesza dane. Tablice mieszania doskonale sprawdzają się jako tablice symboli, gdyż oczekiwany czas do­ stępu do któregokolwiek elementu wynosi w nich 0(1). Nie oznacza to jednak, że są idealne. Jeśli zastosuje się niskiej jakości funkcję mieszającą albo ustawi zbyt mały rozmiar tablicy, to mogą powstać za długie listy. Ponieważ listy te są nieposortowane, czas dostępu do elementów może wynosić O(n). Do elementów listy nieposortowanej nie można uzyskać bezpośredniego dostępu. Można jednak łatwo je policzyć, alokować tablicę, wypełnić ją wskaźnikami na te elementy i posortować. Jeżeli z tablicy mieszania korzysta się we właściwy sposób, oferowany przez nią stały czas dostępu do elementów, a także czas ich usuwania i wstawiania są nieosią­ galne dla innych struktur danych.

Ćwiczenie 2.14. Nasza funkcja mieszająca doskonale działa na łańcuchach znaków. Niemniej jednak można zmusić ją do gorszego działania, podając jej pewne specyficzne dane. Opracuj taki zestaw danych, który sprawi, że funkcja ta będzie działać źle. Czy łatwiej jest znaleźć złe dane dla różnych wartości stałej NHASH?

Ćwiczenie 2.15. Napisz funkcję umożliwiającą dostęp do kolejnych elementów nieposortowa­ nej tablicy mieszania. Ćwiczenie 2.16. Zmodyfikuj funkcję l oo kup w taki sposób, aby gdy średnia długość listy prze­ kroczy wartość x, tablica była automatycznie powiększanay razy i tworzona od nowa.

68

2. ALGORYTMY I STRUKTURY DANYCH

Ćwiczenie 2.17. Zaprojektuj funkcję mieszającą do przechowywania dwuwymiarowych współ­ rzędnych punktów. Czy łatwo jest ją dostosować do użytku ze współrzędnymi innego typu, np. zastąpić wartości całkowite zmiennoprzecinkowymi albo zamiast współrzędnych kartezjań­ skich użyć współrzędnych biegunowych czy też zwiększyć liczbę wymiarów?

2. 1 O. Podsumowanie Wyboru algorytmu należy dokonywać w kilku krokach. Po pierwsze należy sprawdzić poten­ cjalnie dostępne algorytmy i struktury danych. Następnie trzeba oszacować, jaką ilość danych program będzie prawdopodobnie przetwarzał. Jeśli nie jest ich dużo, najlepiej wybrać rozwią­ zanie, które nie będzie zbyt skomplikowane. Jeżeli zbiór danych może się powiększać, to już na wstępie odrzuć struktury o stałym rozmiarze. Później skorzystaj, jeśli to możliwe, z biblioteki używanego języka programowania. W przeciwnym wypadku napisz prostą i łatwą do zrozu­ mienia własną implementację albo pożycz ją od kogoś innego. W następnej kolejności przete­ stuj swój program. Dopiero gdy okaże się, że działa on za wolno, należy poszukać bardziej za­ awansowanych rozwiązań. Mimo dostępności wielu struktur danych, z których część jest zoptymalizowana do pew­ nych specyficznych użyć, w większości programów zastosowanie znajdują przede wszystkim tablice, listy, drzewa i tablice mieszania. Wszystkie one oferują podstawowy zestaw operacji, tzn. dodawanie, wyszukiwanie i usuwanie elementów. Każda operacja ma oszacowaną spodziewaną złożoność obliczeniową, dzięki czemu można stwierdzić, czy dana struktura (lub jej wersja implementacyjna) nadaje się do użycia w kon­ kretnym przypadku. Zaletą tablic jest stały czas dostępu do elementów, ale problematyczne jest ich powiększanie i zmniejszanie. Listy dobrze poddają się operacjom zwiększania i zmniejsza­ nia, ale za to czas dostępu do losowo wybranych elementów jest w nich rzędu O(n) . Drzewa i tablice mieszania łączą w sobie zalety obu poprzednich struktur, ale tylko wówczas, jeśli będzie przestrzegany warunek zrównoważenia. Istnieją jeszcze inne struktury danych, zoptymalizowane pod kątem rozwiązywania specy­ ficznych problemów, ale większość oprogramowania powstaje przy użyciu tych kilku struktur opisanych w niniejszym rozdziale.

Lektura uzupełniająca Przystępny opis wielu przydatnych algorytmów można znaleźć w cyklu książek Boba Sedge­ wicka pt. Algorithms (Addison-Wesley). Obszerne omówienie funkcji mieszających i algoryt­ mów zmiany rozmiaru tablic można znaleźć w wydanej w 1998 roku książce Algorithms in C + + tego samego autora. Wyczerpujące i rygorystyczne analizy wielu algorytmów zamieścił w swojej książce Sztuka programowania (WNT, 2002) Donald Knuth. W tomie trzecim zostały omówione algorytmy sortowania. Opis programu Supertrace znajduje się w książce Design and Validation of Computer Proto­ cols Gerarda Holzmanna wydanej przez wydawnictwo Prentice Hall w 1991 roku. Jon Bentley i Doug Mcllroy w artykule Engineering a Sort Function, opublikowanym w cza­ sopiśmie „Software - Practice and Experience" 1993, R. 23, nr 1 1, na s. 1249 - 1 265 opisali technikę tworzenia szybkiej i niezawodnej implementacji algorytmu szybkiego sortowania.

3

Projektowanie i implementacja

Jeśli pokażesz mi swoje schematy blokowe, a ukryjesz tablice, to i tak wszystko będzie dla mnie tajemnicą; jeśli natomiast pokażesz mi swoje tablice, to nie będę już potrzebował schematów blokowych. Wszystko stanie się jasne.

Frederick P. Brooks jr, Mityczny osobomiesiąc (przeł. A. Ehrlich)

Powyższy cytat z klasycznej książki Brooksa sugeruje, że przy tworzeniu nowego programu najważniejszy jest wybór odpowiednich struktur danych. Dzięki wyborowi właściwych struktur danych ułatwione jest pisanie algorytmów, a wtedy praca nad całym programem staje się rów­ nież prostsza. Przedstawiony pogląd jest znacznie uproszczony, ale zgodny z rzeczywistością. W poprzed­ nim rozdziale zrobiliśmy przegląd podstawowych struktur danych, które wchodzą w skład prawie każdego programu. W tym rozdziale wykorzystamy je do zaprojektowania średniej wielkości programu. Pokażemy, jak wybór struktur danych jest zależny od rodzaju problemu do rozwią­ zania, oraz wykażemy, że kod źródłowy każdego programu o wiele łatwiej zrozumieć, gdy zna się budowę użytych w nim struktur danych. Co ważne, przy takim podejściu do sprawy na ostateczny kształt projektu niewielki wpływ ma wybór języka programowania. Najpierw opracujemy abstrakcyjny model aplikacji, a na­ stępnie zaimplementujemy go w językach C, Java, C + + , Awk i Perl. Porównując te różne im­ plementacje, dowiemy się, jak specyficzne właściwości języków programowania mogą pomagać programiście lub utrudniać mu pracę oraz kiedy język nie ma żadnego znaczenia. Projekt programu może w niewielkim stopniu odzwierciedlać struktury specyficzne dla języka programowania, który zostanie użyty do jego implementacji, ale nie powinien jednak być przez niego zdomi­ nowany. Problem, którego rozwiązanie przedstawimy, jest nietypowy, ale ma pewne cechy właściwe wszystkim programom - jakieś dane przyjmuje, coś zwraca, a napisanie algorytmów przetwa­ rzających te dane wymaga nieco pomysłowości. Napiszemy program, który generuje dający się czytać tekst w języku angielskim. Gdybyśmy postawili na generowanie losowych liter lub wyrazów, to otrzymany wynik byłby bezsensowny. Na przykład program wybierający losowe litery i spacje mógłby zwrócić następujący wynik:

xptmxgn xusaj a afqnzgxl lhi d l wcd rj dj uvpydrl wnjy

70

3. PROJEKTOWANIE I IMPLEMENTACJA

Nie ma czym się chwalić. Gdybyśmy wybierali litery według częstości ich występowania w angielskich tekstach, otrzymalibyśmy coś w tym rodzaju:

i dtefoae tcs trder j c i i ofdsl nqetacp t ol a Też niewiele lepiej. Dobór losowych słów ze słownika również nie da zadowalającego efektu:

pol ydactyl equatorial spl ashi l y j owl verandah ci rcumscri be Aby uzyskać lepsze wyniki, jest nam potrzebny dobry model statystyczny o określonej struk­ turze, np. informacje o częstości występowania w języku całych wyrażeń. Gdzie można coś takiego znaleźć? Moglibyśmy np. sporządzić duży korpus tekstów w języku angielskim i szczegółowo go przeanalizować, ale znamy lepszy i przyjemniejszy sposób. Warto sobie uświadomić, że na pod­ stawie dowolnego tekstu można zbudować model statystyczny, który będzie pokazywał sposób użycia języka w tym tekście. Następnie na podstawie tego modelu można generować losowe teksty o charakterystyce podobnej do oryginału.

3. 1 . Algorytm łańcucha Markowa Eleganckim sposobem realizacji tego zadania jest technika nazywana algorytmem łańcucha Markowa (ang. Markov chain algorithm). Jeśli przyjmiemy założenie, że na wejściu będą poja­ wiać się ciągi nachodzących na siebie wyrażeń, to algoryun każde z nich podzieli na dwie części:

przedrostek złożony z kilku słów i przyrostek złożony z jednego słowa. Algorytm łańcucha Markowa tworzy wyrażenia poprzez losowy dobór przyrostków, które dołącza do przedrostków, zgodnie ze strukturą statystyczną tekstu, w naszym przypadku oryginalnego. Metoda dobrze sprawdza się dla wyrażeń trójwyrazowych, a więc złożonych przy użyciu przedrostków skła­ dających się z dwóch wyrazów:

w zmi ennych � i � zap i s z dwa pi erwsze s łowa z tekstu wydrukuj w, i w, pęt l a : wybi erz l os owo z tekstu następni k w, przedrostka w, w, wydrukuj w, w, i w, zami eń na w, i w, powtórz pętl ę W ramach przykładu załóżmy, że chcemy wygenerować tekst na podstawie dwóch zdań z oryginalnej wersji motta tego rozdziału:

Show your fl owcharts and conceal your tab l es and I wi l l be mys t i fi ed . Show your tab l es and your fl owcharts wi l l be obvi ous . (kon i ec) Oto kilka przykładowych par wyrazów wejściowych i wyrazów, które występują po nich:

3.1.

71

ALGORYTM ŁAŃCUCHA MARKOWA

Przedrostki

Przyrostki

Show your

fl owcharts tabl es

your f1 owcharts

and wi 1 1

f1 owcharts and

concea l

f1 owcharts wi 1 1

be

your tabl es

and and

wi 1 1 be

mysti fi ed . obv i ous .

be mysti fi ed .

show

be obvi ous

( koni ec)

Algorytm Markowa najpierw wydrukuje przedrostek S how your, a następnie losowo wybie­ rze wyraz fl owcharts lub tabl es. W pierwszym przypadku przedrostkiem stanie się wyrażenie your fl owc harts, a kolejnym wybranym słowem będzie and lub wi 1 1 . Gdyby jednak na po­ czątku wybrał wyraz tabl es, następnym byłoby słowo and. Działania te będą kontynuowane, aż na wyjściu zostanie wygenerowana odpowiednia ilość danych lub algorytm napotka znacz­ nik końca. Nasz program będzie wczytywał fragment tekstu po angielsku, a następnie przy użyciu al­ gorytmu Markowa będzie generował nowy tekst, biorąc pod uwagę częstość występowania wy­ rażeń o stałej długości. Liczba wyrazów, z których będzie się składał przedrostek, to parametr (w naszym przypadku dwa). Gdybyśmy skrócili przedrostek, otrzymalibyśmy mało zrozumiały tekst, a gdybyśmy go przedłużyli, program powielałby bez zmian duże części oryginalnego tek­ stu. W przypadku języka angielskiego wybór dwóch słów i uzupełnienie ich trzecim to bardzo dobra decyzja. W ten sposób powstanie coś w rodzaju udziwnionej wersji pierwotnego tekstu. Czym jest słowo? Odpowiedź zdaje się oczywista: słowo to ciąg znaków alfabetu. Wydaje się też, że warto pozostawić znaki przestankowe, które powodują, że words i words . to dwa różne słowa. Jeśli dobór słów uzależnimy częściowo od występowania tych znaków, a więc po­ średnio od pewnych zasad gramatycznych, to wygenerujemy tekst o większych walorach este­ tycznych. Wówczas musimy jednak liczyć się z tym, że w tekście mogą wystąpić nawiasy i cu­ dzysłowy nie do pary. Zatem podsumowując te rozważania - słowo zdefiniujemy jako ciąg znaków umieszczony między dwiema spacjami. Ta decyzja pozwala na użycie tekstu wejścio­ wego w dowolnym języku oraz pozostawienie znaków przestankowych dołączonych do słów. Ponadto będziemy mieli ułatwioną pracę nad programem, ponieważ w większości języków programowania dostępne są narzędzia do dzielenia tekstu na słowa według spacji. Przy tej technice każde słowo i każde wyrażenie dwu- i trzywyrazowe zwracane na wyjściu musi znajdować się też w tekście wejściowym. Ale powinny się też pojawiać dłuższe wyrażenia, powstałe z tych krótszych składników. Oto kilka zdań wygenerowanych przez program, nad którym będziemy pracować w tym rozdziale. Powstały one na podstawie fragmentu oryginalnej wersji rozdziału 7. powieści pt. Słońce też wschodzi Ernesta Hemingwaya: As I started up the undershirt anto his chest black, and big stornach muscles bulging under the light. „You see them?" Below the line where his ribs stopped were two raised white welts. „See on the forehead." „Oh, Bren, I love you." „Let's not talk. Talking's all bilge. I'm going away tomorrow." „Tomorrow?" „Yes. Didn't I say so? I am." „Let's have a drink, then." Mieliśmy sporo szczęścia, że znaki przestankowe się nie pomieszały. Nie zawsze jest tak dobrze.

72

3. PROJEKTOWANIE I IMPLEMENTACJA

3.2. Wybór struktury danych Jaką ilość danych będzie przetwarzać nasz program? Jak szybki musi on być? Wydaje się, że program powinien być w stanie wczytywać nawet całe książki, a więc powinien być przygoto­ wany na zbiory danych wejściowych o rozmiarze n = 100 tysięcy słów i więcej. Na wyjściu bę­ dzie zwracał setki, a nawet tysiące słów i czas na wykonanie zadania powinien być liczony ra­ czej w sekundach niż w minutach. Przy 1 00 tysiącach słów n ma bardzo dużą wartość, więc jeśli zależy nam na wydajności, nie możemy zastosować uproszczonych algorytmów, lecz musimy poszukać bardziej zaawansowanych rozwiązań. Aby algorytm Markowa rozpoczął generowanie tekstu, musi wpierw otrzymać do dyspozycji cały tekst wejściowy, który musimy w jakiś sposób dla niego zapisać. Jednym z możliwych rozwiązań jest wczytanie i zapisanie całego tekstu w postaci długiego łańcucha znaków, ale przecież zależy nam na tym, aby podzielić go na słowa oddzielane spacjami. Jeśli użyjemy ta­ blicy wskaźników na poszczególne słowa, to generowanie wyniku będzie ułatwione: przed wy­ drukowaniem każdego kolejnego słowa przeglądamy tekst wejściowy, aby sprawdzić, jakie słowa mogą wystąpić za ostatnio wygenerowanym przedrostkiem i losowo wybieramy jedno z nich. To jednak oznacza, że za każdym razem musimy przejrzeć wszystkie 1 00 tysięcy słów. Zatem wygenerowanie tysiąca słów oznaczałoby konieczność wykonania setek milionów porównań łańcuchów, co nie byłoby szybkie. Inną możliwością jest zapisanie tylko po jednym egzemplarzu każdego wyrazu i sporządze­ nie listy określającej miejsce występowania każdego z nich. To przyspieszyłoby proces wyszuki­ wania kolejnych słów. Moglibyśmy również użyć tablicy mieszania, jak opisana w rozdziale 2., ale ta konkretna implementacja nie najlepiej spełnia wymagania algorytmu Markowa, który musi szybko znajdować wszystkie przyrostki danego przedrostka. Potrzebna jest nam struktura danych, która będzie lepiej reprezentować przedrostki i zwią­ zane z nimi przyrostki. Program będzie działał dwuprzebiegowo. W pierwszym przebiegu bę­ dzie pobierał dane wejściowe i budował strukturę danych reprezentującą wyrażenia, a w drugim - wykorzystywał tę strukturę do generowania losowego tekstu. W obu przypadkach musimy szybko znajdować przedrostki. W pierwszym przebiegu w celu zaktualizowania listy możli­ wych przyrostków, a w drugim w celu wybrania losowego przyrostka spośród dostępnych. Do realizacji tego planu nadaje się tablica mieszania, której klucze będą reprezentować przedrostki, a wartości będą zbiorami odpowiadających im przyrostków. Na potrzeby przykładu przyjmiemy założenie, że przedrostki składają się z dwóch wyra­ zów, a więc każde słowo na wyjściu będzie zależało od pary poprzedzających je słów. Liczba słów w przedrostku nie ma wpływu na strukturę programu i powinno być możliwe używanie przedrostków dowolnej długości, ale objaśnienia będą łatwiejsze do zrozumienia, jeśli posłu­ żymy się konkretnymi liczbami. Zgodnie ze standardową terminologią przyjętą w odniesieniu do algorytmów Markowa przedrostek wraz ze zbiorem wszystkich jego przyrostków będziemy nazywać stanem. Dla każdego przedrostka musimy zapisać zbiór wszystkich jego przyrostków, aby móc ich później użyć. Przyrostki są dodawane pojedynczo w sposób nieuporządkowany. Ponieważ nie wiadomo, ile ich będzie, musimy użyć struktury danych, której rozmiar można łatwo i szybko zwiększać, takiej jak np. lista lub tablica dynamiczna. Przy generowaniu tekstu wyjściowego dla każdego przedrostka musimy losowo wybrać jeden przyrostek ze zbioru. Niczego nie bę­ dziemy usuwać. Co zrobimy, gdy jakieś wyrażenie będzie występować częściej niż raz? Przykładowo wyra­ żenie „might appear twice" może wystąpić dwa razy, a wyrażenie „might appear once" - tylko raz. Taką sytuację możemy zaprezentować poprzez umieszczenie wyrazu „twice" na liście przy­ rostków przedrostka „might appear" dwa razy albo tylko jeden raz i dołączyć do niego licznik z wartością 2. Wypróbowaliśmy obie możliwości. Wersja bez licznika jest łatwiejsza, gdyż przy

3.3. BUDOWA STRUKTURY DANYCH W JĘZYKU C

73

dodawaniu przyrostka nie trzeba sprawdzać, czy już znajduje się na liście. Poza tym doświad­ czenia wykazały, że różnica w wydajności tych dwóch podejść jest zaniedbywalnie mała. Podsumujmy. Każdy stan składa się z przedrostka i listy przyrostków. Wszystkie informa­ cje są przechowywane w tablicy mieszania, w której kluczami są przedrostki. Wszystkie przed­ rostki są złożone z takiej samej stałej liczby słów. Jeśli określony dla danego przedrostka przy­ rostek występuje częściej niż raz, każde jego wystąpienie zostanie zapisane w liście z osobna. Kolejna decyzja, którą musimy podjąć, dotyczy sposobu reprezentacji samych słów. Najła­ twiej byłoby przechowywać je w postaci pojedynczych łańcuchów. Ze względu na to, że więk­ szość tekstów składa się z pewnego zbioru wielokrotnie powtarzających się słów, moglibyśmy zaoszczędzić pamięć, tworząc drugą tablicę mieszania, w której zapisalibyśmy po jednym eg­ zemplarzu każdego słowa. Wpłynęłoby to też korzystnie na szybkość pracy z tablicą mieszania, ponieważ zamiast poszczególnych znaków moglibyśmy porównywać tylko wskaźniki na nie każde słowo miałoby niepowtarzalny adres. Implementację tej techniki pozostawiamy Czytelni­ kowi jako ćwiczenie, a w naszym programie każdy łańcuch będziemy przechowywać osobno.

3.3. Budowa struktury danych w języku C Zaczniemy od implementacji w języku C, a mówiąc konkretnie, od zdefiniowania kilku stałych.

enum { NPREF = 2 , /* Liczba słów w przedrostku */ NHASH 409 3 , /* Rozmiar tablicy mieszania przechowującej stany */ MAXGEN = 10000 /* Maksymalna liczba słów, jaka może zostać wygenerowana *I }; =

W powyższej deklaracji określiliśmy liczbę składników przedrostka (NPREF), rozmiar tabli­ cy mieszania (NHASH) oraz limit liczby słów, jaka może zostać wygenerowana (MAXGEN). Dzięki temu, że NPREF jest stałą o wartości znanej już na etapie kompilacji, łatwiej będzie nam zarzą­ dzać pamięcią. Domyślny rozmiar tablicy został ustawiony na dość dużą wartość, ponieważ spodziewamy się na wejściu dużych zbiorów danych, nawet całych książek. Wybraliśmy war­ tość 4 093 z tego względu, że nawet jeśli dane wejściowe będą składać się z 10 tysięcy różnych przedrostków (par słów), to na jeden łańcuch średnio przypadną jedynie dwa lub trzy przed­ rostki. Im większy początkowy rozmiar tablicy, tym krótsze łańcuchy i szybsze przeszukiwanie struktury. Ten program piszemy tylko dla zabawy, a więc wydajność nie jest dla nas kluczowa. Jeśli jednak ustawimy zbyt mały rozmiar tablicy, przetwarzanie spodziewanego zbioru danych może trwać bardzo długo. Natomiast z drugiej strony, jeśli przesadzimy z tym rozmiarem, struktura może nam się nie zmieścić w dostępnej pamięci. Przedrostki można przechowywać w tablicy słów. Elementy tablicy mieszania reprezento­ wane jako typ danych o nazwie State będą łączyć listy przyrostków typu Suffi x z odpowied­ nimi przedrostkami:

typedef struct State State; typedef struct Suffi x Suffi x ; struct State { /*przedrostek + lista przyrostków *I char *pref [NPREF] ; /* Słowa przedrostka */ /* Lista przyrostków */ Suffi x *suf; State *nex t ; /* Następny w tablicy *I }; struct Suffi x { /* lista przyrostków */

74

};

3. PROJEKTOWANIE I IMPLEMENTACJA char *word ; Suffi x *next ;

/* Przyrostek */ /* Następny na liście przyrostków */

State *statetab [NHASH] ; /* Tablica mieszania do przechowywania stanów */ Na poniższym rysunku widać graficzną reprezentację przedstawionych struktur. Ta b l ica

statetab :

Egze mp larz struktury

State :

" Show"

pref [ O J

"you r "

pref[ l ] suf n ext

Egze m p l a rz struktu ry

Suffi x : word

I n ny egzemplarz struktury

" fl oweha rts "

n ext

State : ���� pre f [ O J pre f [ l ] suf next

I n ny egze m p l a rz struktury

Suffi x : word

" tabl e s "

next

Dla naszych przedrostków przechowywanych w postaci tablicy słów potrzebujemy funkcji mieszającej. Bez trudu możemy zmodyfikować funkcję mieszającą dla łańcuchów z rozdziału 2., tak aby przemierzała za pomocą pętli łańcuchy w tablicy i zwracała wartości powstałe ze zmieszania połączeń łańcuchów. /* hash: oblicza wartość mieszania dla tablicy NPREF łmicuchów */

unsi gned i nt hash (char *s [NPREF] ) { unsi gned i nt h ; unsi gned char *p; i nt i ; h ; O; for ( i ; O ; i < NPREF; i ++) for (p ; (unsi gned char *) s [i ] ; *p ! ; ' \O ' ; p++) h ; MULT I PL I ER * h + *p ; return h % NHASH ;

Podobna modyfikacja procedury przeszukującej kończy implementację naszej tablicy mie­ szania:

3.3. BUDOWA STRUKTURY DANYCH W JĘZYKU C

75

/* lookup: szuka przedrostka i w razie potrzeby go tworzy */ /* Zwraca wskaźnik na znaleziony lub utworzony przedrostek albo NULL w pozosta61ch przypadkach. *I /* Przy tworzeniu przedrostków nie jest 1'\l)'WOQJWana funkcja strdup, co oznacza, że łańcuchów nie wolno później zmieniać. */

State* l ookup (char *prefi x [NPREF] , i nt create) {

i nt i , h ; State *sp; h = hash (prefi x) ; for (sp = statetab [h] ; sp ! = NULL; sp = sp->next) for (i = O ; i < NPREF; i ++) if ( strcmp {prefi x [ i ] , sp->bpref[i ] ) != O) break ; i f ( i = = NPREF) /* Znaleziono */ return s p ; i f (create) { sp = (State *) emal l oc ( s i zeof(State) ) ; for ( i = O ; i < NPREF; i ++) sp->pref [ i ] = prefi x [i ] ; sp->suf = NULL; sp->next = statetab [h] ; statetab [h] = s p ; return s p ;

Zauważmy, ż e funkcja l oo kup przy tworzeniu nowego stanu nie wykonuje kopii przycho­ dzących łańcuchów, tylko zapisuje wskaźniki za pomocą instrukcji sp->pre f [] . Zadaniem programisty wywołującego tę funkcję jest zagwarantowanie nienaruszalności tych danych w przy­ szłości. Jeśli np. łańcuchy są przechowywane w buforze strumienia wejścia-wyjścia, to przed wywołaniem funkcji l ookup należy wykonać ich kopię. Gdyby tego nie zrobiono, następna porcja danych wejściowych zniszczyłaby dane wskazywane przez elementy naszej tablicy mie­ szania. Często do rozstrzygnięcia pozostaje kwestia, czyją własnością są wspólne zasoby do­ stępne poprzez interfejs. Zagadnienie to szczegółowo omówimy w następnym rozdziale. Czas na napisanie funkcji tworzącej tablicę mieszania z danych pobieranych z pliku: I* build: wczyluje dane i tworzy tablicę przedrostków *I

voi d bui l d (char *prefi x [NPREF] , FILE *f) {

char buf[lOO] , fmt [lO] ;

/* Tworzy lmicuchformatowania; 'Yas może 1'1'.J'Wołać przepełnienie bufora */

spri ntf(fmt , "%%%ds " , si zeof{buf) - 1 ) ; whi l e (fscan f ( f , fmt , buf) ! = EOF) add ( prefi x , estrdup (buf) ) ;

Wywołanie funkcji spri ntf pozwala obejść potencjalny problem z wywołaniem funkcji scanf, która poza tym doskonale nadaje się do tego celu. Funkcja f s c a n f wywołana z forma­ tem %s wczytuje z pliku wejściowego do bufora kolejne słowo, nie zwracając przy tym uwagi na liczbę znaków. Istnieje zatem ryzyko poważnych kłopotów, gdyby długość łańcucha przekro­ czyła rozmiar bufora wejściowego. Jeśli bufor miałby rozmiar 100 bajtów (znacznie więcej niż rozmiar jakiegokolwiek wyrazu w normalnym tekście), moglibyśmy zastosować format %99s

76

3. PROJEKTOWANIE I IMPLEMENTACJA

(jeden bajt pozostawiając dla zera oznaczającego koniec łańcucha) nakazujący funkcji wczytać maksymalnie 99 bajtów danych. Przy takim podejściu bardzo długie słowa zostaną podzielone na części, ale lepsze to niż ryzykowanie kłopotów. Moglibyśmy zapisać następujące deklaracje:

enum char

BUFS I Z E = 100) ; fmt [] = "%99s " ; /* BUFSIZE-1 */

ale w takim przypadku będziemy zmuszeni do określenia rozmiaru bufora, zdefiniowania dwóch stałych i jeszcze dodatkowo zadbania o odpowiednie ich powiązanie. Problem ten można rozwiązać przez tworzenie łańcucha formatu dynamicznie za pomocą funkcji spri n t f i właśnie to podejście zastosowaliśmy w naszym programie. Funkcja bui 1 d przyjmuje dwa argumenty: tablicę prefi x przechowującą NPREF poprzed­ nich słów i wskaźnik na plik FI LE. Następnie przekazuje przedrostek i kopię słowa wejściowego funkcji add, która dodaje nowy wpis do tablicy mieszania i przesuwa przedrostki: /* add: dodaje słowo do listy przyrostków i aktualizuje tablicę przedrostków */

voi d add (char *prefi x [NPREF] , char *suffi x) {

State *sp; sp = l ookup (prefi x , 1) ; /* Utwórz, jeśli nie znajdziesz */ addsuffi x ( s p , suffi x) ; /* Przesunięcie słów w tablicy przedrostków */

memmov e ( prefi x , prefi x+l , (NPREF- l } *si zeof (prefi x [O] ) ) ; prefi x [NPREF-1] su ffi x ; =

Wywołanie funkcji memmove to idiomatyczny sposób usunięcia elementu z tablicy. Funkcja ta przesuwa elementy z pozycji 1-NPREF- 1 tablicy przedrostków na pozycję O-NPREF-2, przy okazji usuwając pierwsze słowo przedrostka i tworząc na końcu miejsce na nowe słowo. Natomiast procedura addsuffi x dodaje nowy przyrostek: /* addsuffix: dodaje do stanu. Przyrostek nie może się później zmienić */

voi d {

addsuffi x (State *sp, char *suffi x) Suffi x *suf; suf = (Suffi x *} emal l oc ( s i zeof(Suffi x) ) ; suf->word = suffi x ; suf->next = sp->suf; sp->suf = suf;

Czynność aktualizacji wykonujemy w dwóch funkcjach: add i addsuffi x. Funkcja add jest bardziej ogólna i jej zadaniem jest dodawanie przyrostka do przedrostka, z kolei funkcja addsuffi x wykonuje specyficzną dla programu czynność dodawania słowa do listy przyrost­ ków. Pierwsza z tych funkcji jest wykorzystywana przez funkcję b u i 1 d, natomiast funkcji addsuffi x używa tylko na swoje wewnętrzne potrzeby funkcja add. Mimo iż jest ona wywoły­ wana tylko w jednym miejscu, tego rodzaju szczegóły implementacyjne zawsze lepiej wyodręb­ niać w postaci osobnych funkcji, gdyż nie wiadomo, czy się nie zmienią.

3.4. GENEROWANIE TEKSTU

77

3.4. Generowanie tekstu Mamy już projekt struktury danych, a więc możemy przejść do generowania tekstu wyjściowego. Główna idea pozostaje bez zmian: weź przedrostek, wybierz losowo jeden przyrostek, wydru­ kuj, przesuń elementy w tablicy przedrostków. Jest to stały punkt naszego programu. Nie wie­ my jednak jeszcze, jak rozpoczynać i kończyć działanie algorytmu. Początek będzie łatwy, jeśli tylko zapamiętamy słowa tworzące pierwszy przedrostek i od nich zaczniemy. Zakończenie również nie jest trudne - wystarczy zdefiniować specjalne słowo, po którego napotkaniu algo­ rytm będzie kończył działanie. W tym celu na końcu danych wejściowych możemy umieścić takie słowo, które na pewno nie pojawi się w żadnym normalnym tekście:

bui l d (prefi x , stdi n) ; add (prefi x , NONWORD) ; Stałej NONWORD należy przypisać taką wartość, która z pewnością nie pojawi się w żadnym normalnym zbiorze danych wejściowych. Ponieważ słowa na wejściu są oddzielane spacjami lub innymi znakami białymi, do naszych celów idealnie nada się słowo utworzone z takiego właśnie znaku, np. znaku nowego wiersza:

char NONWORD []

=

11 \n11 ; /* Nie może wystąpićjako zwykle słowo */

Pozostał jeszcze jeden problem do rozwiązania: co program zrobi, gdy danych będzie za mało, aby uruchomić algorytm? Są dwie możliwości: albo zamykamy program, albo przyjmu­ jemy założenie, że każda porcja danych jest wystarczająca i w ogóle nie sprawdzamy jej rozmiaru. W tym programie zastosowaliśmy to drugie podejście. Proces tworzenia struktury danych i generowania tekstu możemy uruchamiać przy użyciu specjalnie spreparowanego przedrostka. W ten sposób zagwarantujemy, że program zawsze otrzyma minimalną ilość potrzebnych danych wejściowych. W celu rozruszania pętli programu zainicjalizujemy tablicę przedrostków zawierającą same słowa NONWORD. Dodatkową korzyścią z tego jest to, iż pierwsze słowo pliku wejściowego będzie pierwszym przyrostkiem sztucznego przedrostka, dzięki czemu pętla generująca będzie musiała wydrukować tylko przyrostki, które wytworzy. Aby ilość danych wyjściowych nie okazała się zbyt duża jak na nasze możliwości, możemy działanie algorytmu kończyć po wygenerowaniu określonej liczby słów lub po napotkaniu słowa NONWORD użytego jako przyrostka, zależnie od tego, co będzie pierwsze. Dodanie kilku słów NONWORD na końcach danych znacznie upraszcza kod głównych pętli przetwarzania. Jest to przykład zastosowania techniki polegającej na oznaczeniu końców da­ nych za pomocą tzw. wartowników (ang. sentinel). Jedną z zasad programowania jest to, aby w programie obsłużyć wszystkie nieregularności, wyjątki i specyficzne rodzaje danych. Pisanie kodu można sobie nieco ułatwić, jeśli zadba się o jak najprostszy i regularny przepływ sterowania. Funkcja generate stanowi realizację algorytmu opisanego przez nas wcześniej. Wytwarza po jednym słowie na wiersz danych wyjściowych, które można następnie połączyć w dłuższe linie przy użyciu procesora tekstu. W rozdziale 9. omawiamy prosty program o nazwie fmt, który można wykorzystać do tego celu. Dzięki użyciu słów NONWORD na początku i na końcu danych funkcja generate rozpoczyna i kończy działanie zgodnie z oczekiwaniami:

78

3. PROJEKTOWANIE I IMPLEMENTACJA

I* generale: tworzy dane wyjściowe, po jednym słowie na wiersz */

voi d generate ( i nt nwords) { State * s p ; Suffi x *suf; char *prefi x [NPREF] , *w ; i nt i , nmatch ; for (i = O ; i < NPREF; i ++) /* Wyzerowanie początkowego prefiksu *I prefi x [ i ] = NONWORD ; for (i = O; i < nwords ; i ++) sp = l ookup (prefi x , O) ; nmatch = O ; for (suf = sp->suf; s u f ! = NULL; s u f = suf->next) i f (rand ( ) % ++match == O) /* Prawdopodobieństwo = l/nmatch *I w = suf->word ; i f (strcmp (w , NONWORD) == O) break ; pri ntf ( "%s\ n " , w) ; memmove (prefi x , pre fi x+ 1 , (NPREF- 1 ) *si zeof (pre fi x [Ol) ) ; prefi x [NPREF-1] = w ;

Jeśli nie znamy liczby elementów, algorytm pobiera losowo jeden z nich. Podczas przeglą­ dania listy liczba elementów jest zapisywana w zmiennej nmatch. Wyrażenie

rand() % ++nmatch == O zwiększa zmienną nmatch i zwraca wartość „prawda" z prawdopodobieństwem 1/nmat ch. Zatem pierwszy element zostaje wybrany z prawdopodobieństwem 1, drugi zastąpi go z praw­ dopodobieństwem 1/2, trzeci zastąpi poprzedni z prawdopodobieństwem l/3 itd. W dowolnym momencie każdy z k użytych dotychczas elementów został wybrany z prawdopodobieństwem 1/k. Na początku elementom tablicy pre fi x nadaliśmy wartości początkowe, które na pewno znajdą się w tablicy mieszania. Pierwszymi słowami w zmiennej typu Suffi x będą pierwsze słowa dokumentu, ponieważ są one gwarantowanymi następnikami pierwszego przedrostka. Później przyrostki będą wybierane losowo. Pętla for wywołuje funkcję l ookup w celu znalezie­ nia w tablicy mieszania bieżącego przedrostka, następnie wybiera losowy przyrostek, drukuje go i przesuwa elementy tablicy przedrostków. Jeśli wybrany przyrostek jest słowem NONWORD, to kończymy działanie pętli, ponieważ oznacza ono koniec danych wejściowych. W pozostałych przypadkach drukujemy wybrane słowo, ka­ sujemy pierwsze słowo przedrostka za pomocą wywołania funkcji memmove, przesuwamy przy­ rostek na miejsce drugiego wyrazu przedrostka i powtarzamy pętlę. Teraz wszystkie napisane procedury możemy zebrać w funkcji ma i n, która wczytuje dane ze standardowego strumienia wejściowego i generuje nie więcej niż określoną liczbę słów: /* main: generuje losowe łańcuchy Markowa "'!

i nt mai n (vo i d ) { i nt i , nwords = MAXGEN; char *prefi x [NPREF] ;

/* Bieżący przedrostek wejściowy */

79

3.5. JAVA

for (i O ; i < NPREF ; i ++) prefi x [i ] NONWORD ; bui l d (prefi x , stdi n) ; add (prefi x , NONWORD} ; generate(nwords} ; return O ;

/* Początkowy przedrostek */

=

=

Oto cała implementacja w języku C. Na końcu rozdziału dokonamy jeszcze porównania implementacji programu napisanych w różnych językach programowania. Największą zaletą języka C jest to, że programista z niego korzystający ma pełną kontrolę nad tym, co pisze, i programy napisane w tym języku zwykle działają bardzo szybko. Ceną za te korzyści jest jed­ nak zwiększona ilość pracy, ponieważ trzeba samodzielnie przydzielać i zwalniać pamięć, two­ rzyć tablice mieszania oraz listy powiązane itd. Język C jest jak żyletka, za pomocą której można utworzyć elegancki i wydajny program albo się pokaleczyć.

Ćwiczenie 3.1. Do działania algorytmu wybierającego losowo elementy z listy o nieznanej dłu­ gości potrzebny jest dobry generator liczb losowych. Zaprojektuj go i przeprowadź kilka ekspe­ rymentów, aby sprawdzić, jak ten algorytm działa w praktyce.

Ćwiczenie 3.2. Gdyby słowa wejściowe przechowywano w drugiej tablicy mieszania, cały tekst byłby przechowywany tylko w jednym miejscu, co powinno umożliwić zaoszczędzenie pamię­ ci. Sprawdź na kilku dokumentach, jakiego rzędu to oszczędność. Stosując taką organizację, przy wybieraniu przedrostków z tablicy mieszania porównywalibyśmy wskaźniki, a nie rze­ czywiste słowa, co powinno przyspieszyć działanie programu. Zaimplementuj tę wersję pro­ gramu i sprawdź, jak różni się od poprzedniej wersji pod względem szybkości działania i zuży­ cia pamięci.

Ćwiczenie 3.3.

Zmodyfikuj funkcję

czyła działanie bez słów

NONWORD

generate

w taki sposób, aby poprawnie rozpoczynała i koń­

w roli wartowników. Pamiętaj, że program musi prawidłowo

działać także wówczas, gdy na wejściu otrzyma zero słów, bądź dwa, trzy lub cztery słowa. Po­ równaj tę wersję z wersją z wartownikami.

3 . 5 . Java Drugą implementację algorytmu łańcucha Markowa napiszemy w Javie.

W

językach obiekto­

wych, takich jak Java, szczególną uwagę należy poświęcić interfejsom między komponentami programu, które stanowią hermetycznie zamknięte odrębne jednostki nazywane obiektami lub klasami, wyposażone w specjalne funkcje zwane metodami. Java ma obszerniejszą bibliotekę niż język C. Można w niej znaleźć m.in.

nerowych

Vector,

szerzalnego kontenera jest klasa o nazwie

Obj ect.

zbiór klas konte­

służących do grupowania obiektów na rozmaite sposoby. Jednym przykładem roz­

Innym jest klasa

H a s h t a b l e,

służąca do przechowywania obiektów typu

która służy do przechowywania wartości jednego typu

i pobierania ich za pomocą kluczy w postaci obiektów innego typu. Jeśli chodzi o naszą aplikację, to do przechowywania przedrostków i przyrostków idealnie nadają się wektory (obiekty klasy

Vector)

łańcuchów. Możemy użyć obiektu klasy

Has hmap,

której klucze będą stanowiły wektory przedrostków, a wartości - wektory przyrostków. Zgodnie z tradycyjną nomenklaturą taką strukturę danych nazywamy rowującym przedrostki na przyrostki.

W

słownikiem

(ang.

Javie nie musimy tworzyć typu

map) odwzo­

S tate,

ponieważ

80

3. PROJEKTOWANIE I IMPLEMENTACJA

struktura Has htabl e automatycznie wiąże przedrostki z przyrostkami. Zatem projekt w tym języku będzie się różnił od projektu w języku C, w którym musieliśmy utworzyć struktury State do przechowywania stanów składających się z przedrostków i odpowiadających im przy­ rostków oraz zapisywaliśmy je w tablicy mieszania według przedrostków, aby uzyskać pełne stany. Klasa Has htab l e udostępnia metodę put, służącą do zapisywania par klucz-wartość, i me­ todę get do pobierania wartości odpowiadającej podanemu kluczowi:

Hashtabl e h = new Hashtabl e ( ) ; h . put ( key , val ue) ; Sometype v = ( Sometype) h . get ( key) ;

W naszym programie utworzymy trzy klasy. Pierwszą z nich nazwiemy Prefi x i posłuży nam ona do przechowywania słów tworzących przedrostki: c l ass Prefi x { publ i c Vector pref;

li NPREF kolejnych słów ze strumienia wejściowego

Druga klasa, o nazwie Cha i n, będzie wczytywała dane, tworzyła tablicę mieszania i genero­ wała dane wyjściowe. Oto definicja jej zmiennych:

cl ass Cha i n { stat i c fi nal i nt NPREF = 2 ; llRozmiarprzedrostka stat i c f i n a l String NONWORO = " \n " ; li ,. Słowo ", które nie może pojawić się w danych wejściowych

Hashtabl e statetab = new Hashtabl e ( ) ; li klucz = przedrostek, wartość = wektor przyrostków

Prefi x pref i x = new Prefi x ( N PREF, NONWORD) ; li Przedrostek początkowy

Random rand = new Random ( ) ;

Trzecia klasa będzie interfejsem publicznym. Odgrywa ona dwie role: zawiera funkcję ma i n i tworzy egzemplarz klasy Cha i n :

c l ass Markov { stat i c fi nal i nt MAXGEN 10000; li Limit liczby wygenerowanych słów publ i c stati c voi d mai n (Stri n g [] args) throws IOExcept i on { Cha i n cha i n = new Chai n () ; i nt nwords MAXGEN ; =

=

cha i n . bu i l d ( System . i n) ; chai n . generate (nwords ) ;

Gdy utworzymy egzemplarz klasy Cha i n, obiekt ten utworzy tablicę mieszania i ustawi po­ czątkowy przedrostek złożony z NPREF słów NONWORD. Do podziału danych wejściowych na po­ jedyncze słowa według rozdzielających je białych znaków służy funkcja biblioteczna o nazwie StreamTo keni zer. Trzy wywołania znajdujące się przed pętlą przestawiają algorytm dzielenia tekstu na tryb rozpoznawania słów zgodnie z naszą definicją.

81

3.5. JAVA

li Metoda build z klasy Chain: tworzy tablicę stanów z danych pobieranych na wejściu voi d bui l d ( I nputStream i n) throws IOExcepti on {

StreamToken i zer st = new StreamTokeni zer ( i n) ; s t . resetSyntax () ; li Usuwa domyślne reguły s t . wordChars ( O , Character . MAX VALUE) ; li Włącza wszystkie znaki s t . whi tespaceChars ( O , ' ' ) ; li oprócz spacji whi l e ( s t . nextToken () ! = s t . TT_EOF) add (st . sval ) ; add (NONWORD) ; -

Funkcja add pobiera z tablicy mieszania wektor przyrostków odpowiadających bieżącemu przedrostkowi. Jeśli go nie ma, tworzy nowy wektor i prefiks, które zapisuje w tablicy. W każ­ dym przypadku funkcja add dodaje nowe słowo do wektora przyrostków i aktualizuje przedro­ stek, usuwając jego pierwsze słowo i dodając nowe słowo na jego końcu.

li Metoda add z klasy Chain: dodaje słowo do listy przyrostków i aktualizuje przedrostek v o i d add (Stri ng word) { Vector suf = (Vector) stateta b . get (prefi x) ; i f (suf == nul l ) { suf = new Vector () ; statetab . put(new Pref i x ( prefi x) , suf) ; } s u f . addEl ement (word ) ; prefi x . pref. removeEl ementAt (O) ; pref i x . pref. addEl ement(word) ;

Zauważmy, że jeśli wektor s u f jest pusty, funkcja add wstawia do tablicy mieszania nowy obiekt klasy Pre fi x, a nie wektor pre fi x. Jest to konieczne z tego względu, iż w klasie Hashtabl e zapisywane są tylko referencje do elementów, a więc jeśli nie sporządzimy kopii wektora, to w przyszłości moglibyśmy utracić dane z tablicy. Z takim samym problemem mieliśmy do czynienia w trakcie pisania programu w języku C. Funkcja generująca jest w Javie podobna do odpowiednika w języku C. Będzie tylko nieco krótsza, ponieważ może odwoływać się do dowolnego elementu wektora bezpośrednio za po­ mocą indeksów, zamiast używać pętli do przeglądania listy.

li Metoda generale z klasy Chain: generuje tekst wyjściowy voi d generate ( i nt nwords) { prefi x = new Prefi x (NPREF, NONWORD) ; for ( i nt i = O ; i < nword s ; i ++) Vector s (Vector) statetab . get (prefi x) ; i nt r = Math . abs (rand . next i n t ( ) ) % s . si z e ( ) ; Stri ng suf = (Stri ng) s . el ementAt ( r) ; i f (suf. equal s (NONWORD) ) brea k ; System . out . pri ntl n (suf) ; prefi x . pref. removeEl ementAt (O) ; prefi x . pref . addEl ement (suf) ; =

82

3. PROJEKTOWANIE I IMPLEMENTACJA

W klasie Prefi x zdefiniowaliśmy dwa konstruktory tworzące egzemplarze tej klasy z do­ starczonych danych. Pierwszy kopiuje istniejący obiekt Pre fi x, a drugi tworzy przedrostek z n kopii łańcucha. Służy nam on przy inicjalizacji tablicy do utworzenia NPREF kopii słowa NONWORD:

li Konstruktor klasy Prejix: kopiuje istniejący przedrostek Prefi x ( Prefi x p) {

pref = (Vector) p . pref . c l one ( ) ;

liKonstrnktor klasy Prefix: tworzy n kopii ła11cucha str Prefi x ( i nt n , Stri ng str) { pref = new Vecto r ( ) ; for ( i n t i = O; i < n ; i ++) pref. addEl ement (str) ;

Klasa Prefi x ma również dwie metody, o nazwach h a s hCode i equal s . Są one niejawnie wykorzystywane przez obiekt klasy Hashtab l e do indeksowania. i przeszukiwania tablicy mie­ szania. Konieczność posiadania tych dwóch metod, z których korzysta klasa Hashtab l e, wy­ musiła na nas zdefiniowanie klasy Pre fi x dla przedrostków. Gdyby nie to, moglibyśmy użyć zwykłego wektora, tak jak w przypadku przyrostków. Metoda hashCode oblicza wartości mieszania dla wszystkich elementów wektora, a następ­ nie łączy je w jedną wartość dla całego przedrostka:

stati c fi nal i nt MULT I P L I ER = 3 1 ;

li Mnożnik dla metody hashCodeO

li Metoda hashCode z klasy Prejix: genernje wartość mieszania z wszystkich słów tworzących przedrostek publ i c i nt hashCod e ( ) { i nt h = O ; for ( i n t i = O ; i < pref . s i ze { ) ; i ++) h = MULTI PLIER * h + pref . e l ementAt ( i ) . hashCode ( ) ; return h ;

Natomiast metoda equal s porównuje elementy przedrostków, aby sprawdzić, czy zawierają takie same słowa:

li Metoda equals z klasy Prejix: sprawdza, czy w porównywanych prefiksach znajdują się takie same słowa publ i c bool ean equal s (Obj ect o) { Prefi x p ( Prefi x) o ; for ( i nt i = O ; i < pref . s i z e ( ) ; i ++) i f ( ! pref . el ementAt (i ) . equal s ( p . pref . el ementAt ( i ) ) ) return fal se; return true;

3.6. c++

83

Program w Javie jest znacznie krótszy od odpowiednika w C, a przy tym zadbano w nim o więcej szczegółów. W znacznym stopniu umożliwiły nam to klasy Vector i Hashtab l e. Ogólnie rzecz biorąc, w Javie łatwiej jest zarządzać pamięcią, ponieważ wektor automatycznie zmienia rozmiar, jeśli zajdzie taka potrzeba, a system usuwania nieużytków uwalnia nas od konieczno­ ści pamiętania o zwalnianiu nieużywanych fragmentów pamięci. Nie wszystko jednak robi za nas język programowania, gdyż klasie Hashtab l e do działania potrzebne są metody h a s hCode i equa l s, które musieliśmy napisać samodzielnie. Jeśli porównamy sposób reprezentacji struktur danych i operowania na nich w obu języ­ kach, to spostrzeżemy, że w Javie lepiej rozdzieliliśmy poszczególne zadania. Na przykład za­ miana wektorów na tablice nie sprawiłaby nam żadnego problemu. Jednak w języku C każda część programu wie, co robią pozostałe części - tablica mieszania operuje na rozmieszczonych w różnych miejscach tablicach, funkcja l oo kup zna budowę struktur State i Suffi x, a rozmiar tablicy przedrostków jest znany każdej funkcji.

% j ava Markov
Ćwiczenie 3.4. Zmień program napisany w Javie tak, aby w klasie State do przechowywania przedrostków zamiast wektora używana była tablica.

3.6. c + + Trzecią wersję programu zaimplementujemy w języku C+ + . Ze względu na podobieństwo między językami c i c + + kod w języku c + + często można traktować jako kod w c zawiera­ jący kilka usprawnień notacyjnych. Także pierwsza wersja programu napisana w języku C jest poprawnym programem w języku C + + . Lepiej byśmy jednak zrobili, gdybyśmy do budowy programu w języku C + + użyli klas i obiektów, podobnie jak w Javie. To pozwoliłoby nam ukryć szczegóły implementacyjne. My poszliśmy nawet jeszcze o krok dalej i użyliśmy stan­ dardowej biblioteki wzorców, czyli tzw. biblioteki STL (ang. Standard Template Library), która zawiera wiele potrzebnych nam narzędzi. W standardzie ISO biblioteka STL stanowi część definicji języka C + + . W bibliotece STL można znaleźć różne kontenery, takie jak wektory, listy i zbiory, oraz ze­ staw podstawowych algorytmów do przeszukiwania, sortowania, usuwania i dodawania ele­ mentów. Dzięki temu, że biblioteka STL powstała w oparciu o szablony języka C + + , jej algo­ rytmy współpracują z różnymi kontenerami, wliczając w to zarówno te zdefiniowane przez użytkownika, jak i kolekcje typów wbudowanych, takich jak i nt. Kontenery te mają postać ogólnych szablonów, które można dostosowywać na potrzeby przechowywania obiektów do­ wolnego typu. Istnieje przykładowo klasa o nazwie vector, na bazie której można utworzyć kontenery do przechowywania m.in. liczb całkowitych (vector) i łańcuchów znaków (vector). W tych konkretnych wersjach dostępne są wszystkie standardowe operacje klasy v ector, włącznie z algorytmami sortowania.

84

3. PROJEKTOWANIE I IMPLEMENTACJA

Oprócz klasy vector, która jest podobna do kontenera Vector w Javie, biblioteka STL za­ wiera dodatkowo kontener o nazwie deque (należy wymawiać: dek). Jest to kolejka dwukie­ runkowa, świetnie nadająca się do tego, co robimy z przedrostkami: pozwala przechowywać dowolną liczbę elementów oraz udostępnia operacje pobierania elementu z początku i wsta­ wiania elementu na końcu o stałej złożoności czasowej. Klasa deque dostępna w bibliotece STL jest nawet bardziej ogólna, niż nam potrzeba, gdyż umożliwia zdejmowanie i wkładanie elementów z obu stron, ale gwarantowana przez nią wydajność sprawia, że nie ma co się zasta­ nawiać nad jej wyborem. W bibliotece STL dostępny jest też słownik w postaci klasy o nazwie map. Jest to struktura danych działająca na zasadzie drzew zrównoważonych, która pozwala przechowywać pary klucz-wartość i oferuje czas dostępu do wartości skojarzonych z kluczami na poziomie O(logn). Słowniki może nie dorównują wydajnością tablicom mieszania, które oferują stały czas dostępu do elementów, ale i tak przyjemnie jest pomyśleć, że nie trzeba nic pisać, aby móc z nich ko­ rzystać (w niektórych niestandardowych implementacjach języka c + + znajdują się klasy hash i hash_map mogące oferować nawet jeszcze lepszą wydajność). Do porównywania składników przedrostków użyjemy wbudowanej funkcji porównywania. Z tymi narzędziami pod ręką bez problemu napiszemy kod programu. Oto pierwsze dekla­ racje:

typedef deque Prefi x ; map > stateta b ; liprzedrostek -> przyrostki

W bibliotece STL znajduje się szablon klasy deque, który można wyspecjalizować do prze­ chowywania łańcuchów, stosując zapis deque. Ponieważ struktury tej używamy w progra­ mie wielokrotnie, nadaliśmy jej nazwę Prefi x za pomocą instrukcji typedef. Natomiast słowniko­ wi, w którym będziemy przechowywać przedrostki i przyrostki, nie nadawaliśmy żadnej nowej nazwy, gdyż zostanie on użyty tylko w jednym miejscu. Zdefiniowaliśmy z kolei zmienną statetab reprezentującą słownik kojarzący przedrostki z wektorami łańcuchów. Ta metoda jest wygod­ niejsza niż techniki, które zastosowaliśmy zarówno w C, jak i w Javie, gdyż zwalnia nas z obo­ wiązku dostarczania funkcji mieszającej lub metody equa 1 s. Funkcja ma i n inicjalizuje przedrostek, wczytuje dane wejściowe ( z wejścia standardowego, które w bibliotece i ostream języka c + + nazywa się c i n), dołącza ogon i generuje dane wyj­ ściowe, dokładnie tak jak poprzednie wersje programu: li main: funkcja generiifąca tekstprzy użyciu algorytmu la1icucha Markowa

i nt mai n (voi d) { i nt nwords MAXGEN ; Prefi x prefi x ; =

li Bieżący przedrostek wejściowy

for ( i nt i = O ; i < NPREF; i ++) llPoczątkowyprzedrostek add (pref i x , NONWORD) ; bui l d (prefi x , ci n) ; add (prefi x , NONWORD) ; generate (nwords) ; return O ;

Funkcja bui 1 d wczytuje z wejścia p o jednym słowie, wykorzystując do tego celu narzędzia z biblioteki i ostream:

85

3.6. c + +

li build: pobiera slowa z wejścia i tworzy tablicę stanów

voi d bui l d ( Prefi x& prefi x , i stream& i n ) { stri ng buf; whi l e ( i n >> buf) add ( prefi x , buf} ;

Długość słów na wejściu jest nieograniczona, gdyż zmienna łańcuchowa b u f może się w razie potrzeby powiększać. Na przykładzie użycia funkcji add można spostrzec wiele zalet używania biblioteki STL: li add: dodaje slowo do listy przyrostków, aktualizuje przedrostek

voi d add ( Prefi x& pref i x , const stri ng& s) { i f (prefi x . s i ze ( ) ;; N PREF) { statetab [prefi x] . push-bac k ( s ) ; prefi x . pop_front (} ; ) prefi x . push_bac k ( s ) ;

Te pozornie proste instrukcje kryją sporo tajemnic. W klasie map operator indeksowa­ nia [] jest przeciążony w taki sposób, że zachowuje się jak operacje wyszukiwania. Wyrażenie statetab [pre fi x] przeszukuje słownik statetab przy użyciu klucza pre fi x i zwraca referen­ cję do znalezionego elementu. Jeśli dany wektor nie istnieje, to zostaje utworzony. Funkcja push_back, która wchodzi w skład zarówno klasy vector, jak i deque, dołącza nowy łańcuch na końcu struktury danych. Natomiast funkcja pop_front zdejmuje pierwszy element z listy deque. Algorytm tworzenia tekstu wyjściowego jest podobny do tego z poprzednich wersji: li generale: tworzy dane wyjściowe, pojednym słowie na wiersz

voi d generate ( i nt nwords) { Pref i x prefi x ; i nt i ; for ( i ; O ; i < NPREF; i ++) llPoczątkowyprzedrostek add (prefi x , NONWORD) ; for (i O ; i < nword s ; i ++} vector& suf ; statetab[prefi x] ; const stri ng& w ; suf [rand ( ) % suf . s i ze ( } ] ; i f (w NONWORD) break ; cout << w << " \n " ; prefi x . pop front ( } ; li Przesunięcie prefi x . pu sh_back (w} ; ;

;;

86

3. PROJEKTOWANIE I IMPLEMENTACJA

Ogólnie rzecz biorąc, ta wersja programu jest wyjątkowo elegancka i przejrzysta - zwięzły kod, widoczna struktura danych oraz jasny algorytm. Niestety, ma to swoją cenę, ponieważ ten program działa znacznie wolniej od wersji w języku C, ale i tak nie jest najwolniejszy ze wszyst­ kich. Do pomiarów wydajności niedługo wrócimy.

Ćwiczenie 3.5. Największą zaletą biblioteki STL jest to, że umożliwia eksperymentowanie z róż­ nymi strukturami danych. Zmień w przedstawionym wyżej programie struktury danych użyte do reprezentowania przedrostków, przyrostków i tablicy stanów na dowolne inne, aby spraw­ dzić, jak zmieni się wydajność programu.

Ćwiczenie 3.6. Napisz program w języku C + + przy użyciu tylko klas i typu danych stri ng. Nie korzystaj z żadnych dodatkowych zaawansowanych narzędzi bibliotecznych. Porównaj swój program z wersją STL pod względem stylu i szybkości działania.

3.7. Awk i Perl Na zakończenie przedstawiamy jeszcze wersje programu napisane w dwóch popularnych języ­ kach skryptowych: Awku i Perlu. Języki te udostępniają wszystko, czego nam potrzeba, czyli tablice asocjacyjne i mechanizmy przetwarzania łańcuchów.

Tablica asocjacyjna (ang. associative array) to w istocie tablica mieszania w poręcznym opako­ waniu. Na pierwszy rzut oka przypomina zwykłą tablicę, ale indeksami tablicy asocjacyjnej mogą być dowolne ciągi znaków i liczby, a także ich listy oddzielane przecinkami. Są one ro­ dzajem słowników odwzorowujących jeden typ danych w inny. W języku Awk dostępne są tyl­ ko tablice asocjacyjne, podczas gdy w Perlu można korzystać zarówno z konwencjonalnych ta­ blic indeksowanych liczbami całkowitymi, jak i tablic asocjacyjnych, tu nazywanych tablicami mieszania ze względu na to, jak są zaimplementowane. Programy w Awku i Perlu zoptymalizujemy tylko pod kątem przedrostków złożonych z dwóch słów. # markov.awk: alg01ytm lmicucha Markowa dla przedrostków dwuwyrazowych

BEGIN { MAXGEN = 10000 ; NONWORD "\n" ; wl = w2 = NONWORD } { for (i = 1 ; i <= N F; i ++) { # Wczytanie wszystkich słów statetab [wl , w2 , ++nsuffi x [wl ,w2] ] = $ i wl w2 w2 $ i =

= =

END { statetab [wl , w2 , ++ns uffi x [w l , w2] ] = NONWORD # Dodanie ogona wl = w2 = NONWORD for (i O; i < MAXGEN ; i ++) { # Generowanie r i nt (ran d ( ) *nsuffi x [w l , w2] ) + 1 # nsujfix >= 1 p = statetab [wl , w2 , r] i f (p == NONWORD) exi t pri nt p # Aktualizacja lmicucha wl w2 w2 = p =

=

=

87

3.7. AWK I PERL

Program w języku Awk to sekwencja instrukcji zdefiniowanych dla określonych wzorców, tzn. program wczytuje dane po jednym wierszu, każdy wiersz porównuje ze zdefiniowanymi wzorcami i dla każdego wiersza odpowiadającego wzorcowi wykonuje odpowiednie działania. Istnieją też dwa wzorce specjalne: BEG I N i END. Zgodność z pierwszym z nich uzyskuje się przed pierwszym wierszem danych wejściowych, a z drugim - po ostatnim wierszu. Czynność definiuje się jako blok instrukcji w nawiasach klamrowych. W naszym progra­ mie blok BEG I N inicjalizuje kilka zmiennych, w tym także zmienną przechowującą przedrostek. Ponieważ następny blok nie ma żadnego wzorca, zostanie on domyślnie wykonany dla każ­ dego wiersza danych wejściowych. Język Awk automatycznie rozbija każdy wiersz na tzw. pola (słowa oddzielane spacjami) o nazwach od $ 1 do $ N F. Zmienna N F określa liczbę pól. Instrukcja

statetab [wl , w2 ,++nsuffi x [w l , w2] ]

=

$i

buduje słownik odwzorowujący przedrostek na przyrostki. Tablica nsuffi x służy do liczenia przyrostków, a element tablicy ns uffi x [wl , w2] zawiera liczbę przyrostków skojarzonych z danym przedrostkiem. Przyrostki są przechowywane w elementach tablicowych statetab [wl , w2 , 1] , statetab [wl ,w2 , 2] itd. Wykonanie bloku END oznacza, że nastąpił koniec danych wejściowych. W tym momencie dla każdego przedrostka istnieje element tablicy n s uffi x zawierający licznik przyrostków od­ powiadających temu przedrostkowi oraz tyle elementów tablicy statetab z przyrostkami, ile wskazuje ten licznik. Wersja programu w Perlu jest bardzo podobna do poprzedniej, z tą różnicą, że zamiast trzeciego indeksu do liczenia przyrostków została użyta anonimowa tablica. Ponadto aktualiza­ cja przedrostka jest wykonywana przy użyciu instrukcji wielokrotnego przypisania. W języku Perl do oznaczania typów zmiennych używa się różnych specjalnych znaków, tak więc $ ozna­ cza wartości skalarne, @ tablice indeksowane liczbami, do których elementów można się odwoływać za pomocą nawiasów kwadratowych [] , a klamry { } służą do indeksowania tablic mieszania. -

# markov.pl: alg01ytm łańcucha Markowa dla przedrostków dwuwyrazowych

$MAXGEN = 10000 ; $NONWORD = " \n " ; $wl = $w2 = $NONWORD; # Stan początkowy whi l e (<>) { # Wczytywanie wszystkich wierszy danych wejściowych foreach (spl i t) { push ( @ { $statetab { $wl } { $w2 } } , $ ) ; ($wl , $w2) = ($w2 , $_) ; # Wielokrotne przypisanie } pus h ( @ { $statetab { $wl } { $w2 } } , $NONWORD) ;

# Dodanie ogona

$wl $w2 = $NONWORD ; O; $ i < $MAXGEN ; $ i ++) for ( $ i $suf = $statetab { $wl } { $w2 } ; # Odwalanie do tablicy $r = i nt ( rand @$s uf) ; # @$suf oznacza liczbę elementów exi t i f ( ($t = $suf->[$r] ) eq $NONWORD) ; pri nt "$t\n" ; ($wl , $w2) = ($w2 , $t) ; # Aktualizacja laiicucha =

=

Tak jak w poprzednich programach słownik zapisaliśmy przy użyciu zmienńej statetab. Sercem programu jest poniższy wiersz:

88

3. PROJEKTOWANIE I IMPLEMENTACJA

push (@{ $ statetab { $wl } { $w2 } } , $_) ; Umieszcza on nowy przyrostek na końcu anonimowej tablicy zapisanej w elemencie

statetab { $w1 } { $w2 } . Podczas generowania danych wyjściowych instrukcja statetab { $wl } '-+ { $w2 } jest odwołaniem do tablicy przyrostków, natomiast $ s u f - > [ $ r] wskazuje przyrostek o numerze r. Kod źródłowy programów w Perlu i Awku jest bardziej zwięzły niż w pozostałych prezen­ towanych językach, ale za to trudniej jest go przystosować do działania z przedrostkami skła­ dającymi się z innej liczby słów niż dwa. Główna część (funkcje add i generate) programu napisa­ nego przy użyciu biblioteki STL języka C+ + ma podobną długość, a przy tym jest bardziej przejrzysta. Niemniej jednak języki skryptowe często doskonale nadają się do eksperymento­ wania, tworzenia prototypów, a nawet pisania programów użytkowych, w których szybkość działania nie jest najważniejszym czynnikiem.

Ćwiczenie 3.7. Dostosuj programy napisane w Awku i Perlu, aby obsługiwały przedrostki do­ wolnej długości. Sprawdź, jak te zmiany wpłynęły na wydajność programu.

3.8. Wydajność Mamy do porównania kilka implementacji tego samego programu. Do mierzenia ich szybko­ ści działania wykorzystaliśmy Księgę Psalmów z angielskiej wersji Biblii króla Jakuba, która zawiera 42 685 słów (5 238 słów niepowtarzających się i 22 482 przedrostki). W tekście wystę­ puje na tyle dużo powtarzających się fraz, np. „Blessed is the . . . ", że jedna z list przyrostków zawierała aż ponad 400 elementów. Oprócz tego było kilkaset list zawierających po kilka­ dziesiąt przyrostków. Można zatem stwierdzić, że wybraliśmy dobry zestaw danych testowych.

Bl essed i s the man of the net . Turn thee unto me , and rai se me u p , that I may tel l al l my fears . They l ooked unto h i m , he heard . My pra i s e shal l be bl essed . Weal th and ri ches shal l be saved . Thou hast deal t wel l wi th thy hi d treasure: they are cast i nto a stand i ng water, the fl i nt i nto a stand i ng water, and dry ground i nto waterspri ngs . W poniższej tabeli przedstawione są wyniki pomiarów czasu potrzebnego do wygenerowa­ nia 1 0 tysięcy słów przez każdy z programów na dwóch komputerach. Pierwszy z nich miał procesor MIPS R lOOOO 250 MHz i system operacyjny Irix 6.4, a drugi: procesor Pentium II 400 MHz, 128 MB pamięci RAM oraz system operacyjny Windows NT. Czas wykonywania programu prawie całkowicie zależy od rozmiaru danych wejściowych, gdyż proces generowania wyniku jest bardzo szybki. W tabeli uwzględniono również przybliżoną liczbę wierszy kodu źródłowego, z jakiej składa się każdy program. 250 MHz

c

Java C+ +/STL/deque C+ +/STL/list Awk Perl

400 MHz

RIO OOO

Pentium II

Liczba wierszy kodu

0,36 s 4,9 2,6 1,7 2,2

0,30 s 9,2 1 1,2 1,5 2,1

150 105 70 70 20

1,8

1,0

18

3.9. WNIOSKI

89

D o kompilacji programów w językach C i C+ + użyto kompilatorów optymalizujących, na­ tomiast program w Javie był uruchomiony przy włączonej kompilacji na czas. W przypadku programów w C i C + + uruchomionych w systemie Irix wybrano najlepsze czasy uzyskane z trzech różnych kompilatorów. Podobne wyniki zostały uzyskane także w maszynach Sun SPARC i DEC Alpha. Program napisany w języku C zdeklasował wszystkie pozostałe pod względem szybkości działania. Na drugim miejscu jest implementacja w Perlu. Należy jednak zaznaczyć, że wyniki przedstawione w tabeli pokazują tylko doświadczenia zebrane przez nas przy korzystaniu z określonego zestawu bibliotek i kompilatorów. Gdyby ktoś inny przepro­ wadził te same testy, mógłby otrzymać zupełnie inne wyniki. W systemie Windows jest coś nie tak z implementacją kolekcji deque z biblioteki STL języka C+ + . Z naszych analiz wynikało, że operacje związane z tą kolekcją, która jest wykorzystywa­ na do reprezentacji przedrostków, dominowały w ogólnym czasie wykonywania programu, a przecież nie zawiera ona nigdy więcej niż dwa elementy. Należałoby się spodziewać, że dominująca będzie główna struktura danych, czyli słownik. Zamiana na listę dwukierunkową z STL poprawiła wynik wielokrotnie. Natomiast zmiana słownika na niestandardową tablicę mieszania w systemie Irix nie przyniosła żadnego rezultatu. W naszym systemie Windows nie mieliśmy dostępu do tablic mieszania. To że do zamiany jednej kolekcji na inną wystarczyło tylko zamienić słowo 1 i st na deque, hash albo map w tylko dwóch miejscach, jest ogromną za­ letą biblioteki STL. Na podstawie doświadczeń stwierdzamy, że biblioteka STL, która stanowi nowość w języku C+ +, jest jeszcze nie w pełni dopracowana. Nie da się przewidzieć zmian wydajności programu, jeśli użyje się innej implementacji, a nawet gdy zastosuje się różne struktury danych. To samo dotyczy Javy, w której również występują duże różnice między im­ plementacjami. Testowanie programów służących do wytwarzania dużej ilości losowych danych to nie lada wyzwanie. Skąd wiadomo, że program w ogóle działa? Skąd wiadomo, czy program pracuje przez cały czas? W rozdziale 6„ poświęconym testowaniu, przedstawiamy kilka propozycji oraz opisujemy, jak testowaliśmy programy Markowa.

3.9. Wnioski Program Markowa ma długą historię. Jego pierwszą wersję napisał Don P. Mitchell, a później w latach 80. Bruce Ellis zaadaptował ją do użytku w zabawach dekonstrukcyjnych. Potem o programie zapomniano na dłuższy czas, aż wygrzebaliśmy go w celu wykorzystania na zaję­ ciach uniwersyteckich do zademonstrowania etapów projektowania programu. Nie użyliśmy jednak oryginału, lecz na jego podstawie napisaliśmy całkiem nową wersję w języku C, aby przypomnieć sobie, jakie problemy trzeba rozwiązać podczas implementacji tego algorytmu. Następnie opracowaliśmy jeszcze kilka dodatkowych wersji w różnych innych językach pro­ gramowania, za każdym razem używając specyficznych idiomów charakterystycznych dla da­ nego języka. Po serii wykładów przerabialiśmy programy wielokrotnie, aby poprawić przejrzy­ stość ich kodu źródłowego. Jednak przez cały ten czas podstawowy projekt pozostawał niezmieniony. Rozwiązania za­ stosowane przez nas zostały użyte także w pierwotnej wersji programu, aczkolwiek w nim po­ jawiła się jeszcze dodatkowa tablica mieszania do reprezentowania poszczególnych słów. Gdy­ byśmy mieli go napisać jeszcze raz, to zapewne wprowadzilibyśmy niewiele poprawek. Cały projekt programu opiera się na strukturze przetwarzanych danych. Struktury danych nie defi­ niują wszystkich szczegółów, ale wpływają na ogólny kształt programu. Wybór niektórych struktur danych, np. list zamiast rozszerzalnych tablic, ma niewielkie znaczenie. Pewne implementacje są bardziej ogólne od innych, np. programy w językach Awk i Perl

90

3. PROJEKTOWANIE I IMPLEMENTACJA

można by z łatwością przerobić, aby obsługiwały przedrostki jedno- lub trójwyrazowe, ale za­ programowanie eleganckiej implementacji takiego rozwiązania przy użyciu parametrów byłoby już trudniejsze. Jak przystało na obiektowe języki programowania, takie jak Java i c+ + , wprowadzając kilka drobnych zmian, można b y dostosować struktury danych do obsługi obiektów innego typu niż tekst w języku angielskim, np. programów (w których znaczenie miałyby białe znaki), nut, a nawet kliknięć myszą czy wyborów z menu. Podczas gdy struktury danych używane w programach różnią się między sobą w niewiel­ kim stopniu, to jeśli chodzi o wygląd ogólny, ilość kodu i wydajność, różnice między nimi są duże. Ogólnie rzecz biorąc, programy napisane przy użyciu języków wysokiego poziomu są wolniejsze od napisanych przy użyciu języków niskiego poziomu, ale nie należy z tego wycią­ gać zbyt daleko idących wniosków. Dostęp do takich narzędzi jak biblioteka STL w języku C+ + czy tablice asocjacyjne i mechanizmy przetwarzania tekstu w językach skryptowych po­ zwala uzyskać bardziej zwięzły kod i skrócić czas pracy nad programem. I chociaż nie ma nic za darmo, straty wydajności w takich programach jak implementacja algorytmu Markowa, które działają tylko przez kilka sekund, mogą mieć niewielkie znaczenie. Trudniej natomiast zdecydować, jak traktować utratę kontroli nad programem, gdy system, w którym działa, dostarcza takich ilości kodu, że w zasadzie nie wiadomo, co tak naprawdę się tam dzieje. Właśnie ten problem dotyczy biblioteki STL. Jej wydajność jest zawsze wielką niewiadomą i nie ma dobrego sposobu, aby ją jakoś oszacować. Jedna z implementacji bibliote­ ki STL wymagała poprawek, zanim w ogóle mogliśmy jej użyć do uruchomienia naszego pro­ gramu. Niewielu programistów ma możliwości i siły do znajdowania i poprawiania takich nie­ dociągnięć. Problem ten cały czas narasta i trzeba się z nim borykać coraz częściej : im biblioteki, in­ terfejsy i inne narzędzia stają się bardziej skomplikowane, tym trudniej je ogarnąć i nad nimi zapanować. Gdy wszystko idzie dobrze, to rozbudowane środowiska programistyczne stanowią ogromną pomoc dla programisty, ale jeśli tylko wystąpi jakaś trudność, nie ma gdzie szukać pomocy. Jeżeli w programie wystąpią trudne do wykrycia usterki związane z wydajnością lub logiką, to możemy sobie przez długi czas nie zdawać sprawy z ich istnienia. Na podstawie projektu i implementacji przedstawionego w tym rozdziale programu można wyciągnąć kilka ogólnych wniosków, które dotyczą także większych aplikacji. Po pierwsze zawsze należy wybierać jak najprostsze struktury danych, wystarczające do rozwiązania zada­ nego problemu w rozsądnym czasie. Jeśli ktoś już wcześniej coś takiego robił i zamieścił w bi­ bliotece odpowiednie rozwiązania, to jeszcze lepiej. Skorzystaliśmy z takiej pomocy podczas programowania implementacji w języku c+ + . Kierując się radą Brooksa: naszym zdaniem projektowanie programu najlepiej jest zacząć od szczegółowego opracowania struktury danych, biorąc jednocześnie pod uwagę to, jakie algo­ rytmy będą z nią najlepiej współpracować. Gdy dysponuje się ułożonymi strukturami danych, pisanie programu jest o wiele łatwiejsze. Trudno od razu stworzyć idealny projekt programu i potem wcielić go w życie. Zazwyczaj praca nad programem odbywa się na zasadzie serii prób i błędów. W trakcie pisania kodu zmu­ szani jesteśmy do szczegółowego objaśnienia tych zagadnień, nad którymi wcześniej nie zasta­ nawialiśmy się zbyt wiele. Tak też przebiegała praca nad programami przedstawionymi w tym rozdziale. Wielokrotnie zmienialiśmy w nich rozmaite szczegóły. Jeśli to możliwe, zawsze za­ czynaj pracę od czegoś prostego, aby następnie poszerzając swoją wiedzę, stopniowo dodawać kolejne elementy. Gdybyśmy algorytm Markowa chcieli zaprogramować wyłącznie na własne potrzeby, to prawie na pewno użylibyśmy do tego celu języka Awk lub Perl, aczkolwiek nie po­ święcilibyśmy tak dużo uwagi szczegółom. Jednak napisanie programu, który będzie rozpowszechniany wśród użytkowników, to znacznie trudniejsze zadanie niż utworzenie prototypu. Gdybyśmy programy przedstawione w tym roz­ dziale chcieli traktować jako nadające się do powszechnego użytku (bo je przetestowaliśmy

LEKTURA UZUPEŁNIAJĄCA

91

i dopracowaliśmy), to stwierdzilibyśmy, że napisanie takiego programu może wymagać nawet o dwa rzędy wielkości więcej wysiłku niż napisanie go na własny użytek.

Ćwiczenie 3.8. Zetknęliśmy się z implementacjami programu Markowa w wielu językach pro­ gramowania, takich jak Scheme, Tel, Prolog, Python, ogólna Java, ML i Haskell. Każdy z nich miał swoje zalety i przedstawiał specyficzne trudności, z którymi trzeba było sobie poradzić. Napisz ten program w swoim ulubionym języku i porównaj jego wydajność i ogólne cechy z imple­ mentacjami przedstawionymi w tej książce.

Lektura uzupełniająca Opis biblioteki STL można znaleźć w wielu książkach, między innymi w książce pt. Generic Programming and the STL Matthew Austerna (Addison-Wesley, 1 998). Wyczerpującym źró­ dłem wiedzy o języku C+ + jest książka Bjarne'a Stroustrupa pt. Język C + + (WNT, 2002). Po informacje o Javie warto sięgnąć do książki Java TM Kena Arnolda i Jamesa Goslinga (WNT, 1 999). Najlepszy opis języka Perl znajduje się w książce Programming Perl Larry'ego Walla, Toma Christiansena i Randala Schwartza (O'Reilly, 1 996). Idea wzorców projektowych (ang. design pattems) opiera się na spostrzeżeniu, że w więk­ szości programów używanych jest tylko kilka podstawowych konstrukcji, podobnie jak jest tylko kilka bazowych struktur danych. Wzorce projektowe można luźno porównać do idiomów kodu, które zostały opisane w rozdziale 1. Klasycznym podręcznikiem na ten temat jest książ­ ka pt. Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku Ericha Gammy, Richarda Helma, Ralpha Johnsona i Johna M. Vlissidesa (Helion, 20 1 0). Barwne dzieje niesfornego programu markov, który pierwotnie miał nazwę shaney, zostały opisane w artykule pt. Computing Recreations w czerwcowym numerze czasopisma „Scientific American" z 1989 roku. Artykuł ten opublikowano ponownie w książce pt. The Magie Machine A.K. Dewdneya (W.H. Freeman, 1990).

92

3. PROJEKTOWANIE I IMPLEMENTACJA

Interfejsy

Zanim mur wybuduję, powinienem wiedzieć, Od czego się odgradzam, co zamurowuję I komu czynię afront przez stawianie muru. Istnieje siła murom granicznym przeciwna, Która pragnie je zburzyć.

Robert Frost, Naprawianie muru (przeł. L. Elektorowicz, Wiersze, Warszawa, PIW 1 972)

Istotą projektowania jest znalezienie równowagi między celami a ograniczeniami. Przy pisaniu niewielkiego samowystarczalnego systemu programista może sobie pozwolić na pewne ustęp­ stwa, ponieważ konsekwencje podejmowanych przez niego decyzji są widoczne tylko w tym systemie i dotyczą wyłącznie jego samego. Jeśli jednak z programu będzie korzystać szersze grono odbiorców, skutki podjętych decyzji mogą być dalece bardziej doniosłe. Przystępując do pracy nad projektem, należy zawsze rozważyć następujące kwestie: •

Interfejsy: jakie usługi planujemy oferować i jak będzie można uzyskać do nich dostęp? Istotną cechą interfejsu jest to, że stanowi on rodzaj umowy wiążącej dostawcę i odbiorcę. Należy dążyć do tego, aby oferowane usługi były spójne i wygodne w użyciu, a także funkcjonalne, lecz nie nazbyt rozbudowane, aby nie sprawiały kłopotów użytkownikowi.

•

Ukrywanie informacji: jakie informacje ukryjemy, a jakie pozostawimy widoczne? Kon­ strukcja interfejsu powinna pozwalać na bezproblemowy dostęp do jego składników i jed­ nocześnie ukrywać ich szczegóły implementacyjne, tak aby można było je modyfikować bez wiedzy użytkownika.

•

Zarządzanie zasobami: kto zarządza pamięcią i innymi ograniczonymi zasobami? Naj­ ważniejsze problemy w tym przypadku to: przydzielanie i zwalnianie pamięci oraz obsłu­ ga wspólnych kopii informacji.

•

Obsługa błędów: kto wykrywa błędy, a kto je zgłasza i w jaki sposób to robi? Jakie środki zaradcze są stosowane na wypadek pojawienia się błędu?

94

4. INTERFEJSY

W rozdziale 2. zajmowaliśmy się poszczególnymi składnikami budowy systemu, czyli strukturami danych. W rozdziale 3. z połączenia tych struktur utworzyliśmy niewielki pro­ gram. Teraz natomiast zajmiemy się sposobami łączenia komponentów programowych mogą­ cych pochodzić z różnych źródeł. Budowę interfejsu przedstawimy na przykładzie projektu biblioteki funkcji i struktur danych pomocnych w wykonywaniu pewnego typowego zadania. Przy okazji zdefiniujemy kilka podstawowych zasad projektowania. W przeciętnym projekcie do podjęcia są setki decyzji, ale tylko niewielka część z nich jest dokonywana świadomie. In­ terfejsy tworzone z pominięciem omawianych tu zasad są często dosyć chaotyczne, o czym wie każdy programista, który miał nieprzyjemność zmagać się z nimi w swojej pracy.

4. 1 . Wartości oddzielane przecinkami Format CSV, czyli wartości oddzielane przecinkami (ang. comma-separated values), to powszechnie stosowany standardowy format do prezentacji danych tabelarycznych. Wiersze tabeli są repre­ zentowane jako linie tekstu, a poszczególne pola oddzielają przecinki. Początek tabeli z końca poprzedniego rozdziału w formacie CSV można by przedstawić następująco: , "250 MHz " , " 400 MHz " , " Li czba wi erszy " , "Rl OOOO " , " Penti um I I " , " kodu" C , 0 . 36 s , 0 . 30 s , 150 Java , 4 . 9 , 9 . 2 , 105 Formatu tego używają do prezentacji i pobierania danych rozmaite programy, np. arkusze kalkulacyjne. Nie jest też dziełem przypadku to, że w tym formacie pojawiają się różne usługi na stronach internetowych, np. informacje o cenach akcji. Na pewnej popularnej stronie inter­ netowej zawierającej kursy akcji można znaleźć taką tabelę: Symbol

Last Trade

Exchange

Volume

LU

2 : 19 PM

86-1/4

+4-1/16

+4,94%

5 804 8 0 0

T

2:19 PM

60-l l/16

-1-3/16

-1,92%

2 468 ooo

MSFT

2:24 PM

106-9/16

+ 1-3/8

+ 1,31 %

1 1 474 900

Download Spreadsheet Format

Pobieranie takich danych za pomocą przeglądarki internetowej jest możliwe, ale czaso­ chłonne. Trzeba uruchomić aplikację, poczekać, obejrzeć serię reklam, wpisać listę akcji, cze­ kać, czekać, czekać, obejrzeć kolejną serię reklam i w końcu można otrzymać dane. Strasznie żmudne zajęcie. Aby dalej przetworzyć te liczby, należy wykonać jeszcze kilka dodatkowych czynności. Klikając odnośnik Download Spreadsheet Format (Pobierz plik arkusza kalkulacyjnego) albo podobny, pobierzemy na dysk komputera plik w formacie CSV zawierający dane ułożone w mniej więcej następujący sposób (układ danych został trochę zmodyfikowany, aby zmieścił się na stronie): " LU " , 86 . 25 , " 1 1/4/1998" , " 2 : 19PM" , +4 . 0625 , 83 . 9375 , 86 . 87 5 , 83 . 625 , 5804800 "T" , 60 . 6875 , " l l/4/1998" , "2 : 19 PM" , - 1 . 1875 , 62 . 375 , 62 . 625 , 60 . 43 7 5 , 2468000 "MSFT " , 106 . 562 5 , " 1 1/4/1998" , " 2 : 24PM" , + 1 . 375 , 105 . 8125 , 107 . 3 1 2 5 , 105 . 5625 , 1 1474900

95

4.2. PROTOTYP BIBLIOTEKI

W tym przykładzie w oczy rzuca się złamanie zasady, zgodnie z którą tego rodzaju prace powinno się zlecać do wykonania komputerowi. Wprawdzie przeglądarki pozwalają uzyskać dostęp do danych umieszczonych na serwerze, ale wygodniej byłoby pobierać informacje au­ tomatycznie. Za kliknięciami tych wszystkich przycisków kryją się w istocie czysto tekstowe procedury: przeglądarka wczytuje kod HTML, użytkownik wpisuje na stronie tekst, przeglą­ darka przekazuje go do serwera i w zamian znowu otrzymuje kod HTML. Tego rodzaju infor­ macje można z łatwością pobierać automatycznie, jeśli tylko dysponuje się odpowiednimi narzę­ dziami i zna właściwy język programowania. Poniżej przedstawiamy program napisany w języku Tel łączący się z opisywanym serwisem internetowym w celu pobrania informacji o kursach akcji w formacie CSV z kilkoma nagłówkami na początku: # getquotes.tcl: ceny akcji form Lucent, A T&T i Microsoft

set so [soc ket quot e . yahoo . com 80] ; # Połączenie z serwerem set q "/d/quotes . csv?s= LU+T+MSFT&f=sl ldltlclohg v " p u t s $so "GET $q HTTP/1 . 0\n\n " fl ush $so puts [read $so]

; # Wysianie żądania ; # Pobranie i wydrukowanie odpowiedzi

Zagadkowy łańcuch zaczynający się od znaków f= to nieudokumentowany łańcuch sterujący, analogiczny do pierwszego argumentu funkcji p r i ntf, określający wartości, które mają zostać pobrane. Metodą prób i błędów ustaliliśmy, że s oznacza symbol akcji, 1 1 ostatnią cenę, c 1 zmianę w stosunku do poprzedniego dnia itd. Nie o szczegóły nam tu jednak chodzi, które i tak mogą się zmieniać, lecz o samą możliwość zautomatyzowania tego procesu. Pobranie i prze­ konwertowanie na odpowiedni format potrzebnych informacji można wykonać całkowicie bez angażowania człowieka. Wszystko zrobi za nas maszyna. Program getquotes uwinie się z pracą w ułamku sekundy, podczas gdy nam zajęłoby to znacznie więcej czasu. Dane po pobraniu można poddać dalszemu procesowi przetwarzania te w formatach takich jak CSV najłatwiej przetwarzać, gdy ma się pod ręką specjalne biblioteki służące do ich pobierania i generowania, najlepiej połączone jeszcze z narzędziami do ich ob­ róbki, np. konwersji liczb. Ponieważ nie znamy ani jednej ogólnodostępnej biblioteki przezna­ czonej do przetwarzania danych w formacie CSV, napiszemy ją samodzielnie. W kilku następnych podrozdziałach przedstawimy trzy wersje biblioteki do wczytywania danych w formacie CSV i ich przekształcania na format wewnętrzny programu. Przy okazji omówimy różne problemy, jakie może napotkać programista projektujący oprogramowanie, które musi współpracować z innym oprogramowaniem. Nie istnieje np. oficjalna specyfikacja formatu CSV, przez co w swojej pracy nie możemy oprzeć się na żadnych ścisłych regułach. Tego typu kwestie często pojawiają się podczas projektowania interfejsów.

4.2. Prototyp biblioteki Istnieje niewielkie prawdopodobieństwo, że już za pierwszym razem uda nam się napisać do­ skonały projekt biblioteki lub interfejsu. Jak napisał kiedyś Fred Brooks, „zaplanuj, że odrzu­ cisz jeden projekt, bo na pewno będziesz musiał". Brooks pisał o dużych systemach, ale jego spostrzeżenia można odnieść do każdego większego programu. Nierzadko jest tak, że różne kwestie można zrozumieć na tyle dobrze, aby poprawnie zaprojektować system, dopiero po utworzeniu i używaniu przez jakiś czas jego pierwszej wersji.

96

4. INTERFEJSY

W związku z tym konstrukcję naszej biblioteki do przetwarzania danych w formacie CSV rozpoczniemy od utworzenia prototypu, który później odrzucimy. W pierwszej wersji projektu pominiemy wiele zagadnień, którymi zajęlibyśmy się, gdybyśmy do zadania podchodzili bar­ dziej starannie. Mimo to biblioteka będzie nadawała się do użytku, co pozwoli nam dokładniej zapoznać się z problemem. Pracę zaczniemy od napisania funkcji o nazwie es vget l i ne - będzie ona pobierała z pliku po jednym wierszu danych CSV do bufora wejściowego, dzieliła je na pola, które zapisze w ta­ blicy, usuwała cudzysłowy i zwracała wartość określającą liczbę pól. W naszej praktyce mieliśmy okazję pisać podobny program w prawie wszystkich językach programowania, jakie znamy, więc nie jest to dla nas nowość. Oto prototypowa wersja biblioteki napisana w języku C. Doda­ liśmy znaki zapytania, aby zaznaczyć, że to tylko wersja próbna: char buf [200] ; char *fi el d [20] ;

/* Bufor danych wejściowych */ /* Pola */

I* csvgetline: wczytuje i przetwarza wiersze danych. zwraca licznik pól */ I* Przykładowa porcja danych wejściowych: "LU",86.25, "111411998", "2:19PM", +4. 0625 *I

i nt csvget l i ne (F I L E *fi n) {

i nt nfi el d ; char *p , *q ; i f ( fgets (buf, s i zeof(buf) , fi n ) == NULL) return - 1 ; nfi el d = O ; for {q = buf; {p=strto k { q , " , \n\r" ) ) ! = NULL; q fi el d [nfi el d++] = unquote {p) ; return nfi el d ;

NULL)

W początkowej części programu znajduje się komentarz zawierający przykładową porcję danych wejściowych dla tego programu. Takie komentarze ułatwiają programistom zrozumie­ nie działania programów pobierających dane w skomplikowanych formatach. Ponieważ format CSV jest zbyt skomplikowany, aby zapisane w nim dane wygodnie pobie­ rać za pomocą funkcji scanf, posłużyliśmy się standardową funkcją języka C o nazwie s trtok. Wywołanie funkcji st rto k ( p, s) zwraca wskaźnik na pierwszy leksem występujący w argu­ mencie p, w którym nie ma znaków występujących w argumencie s . W celu oznaczenia końca leksemu funkcja strtok zamienia następny znak oryginalnego łańcucha na pusty bajt. W pierw­ szym wywołaniu pierwszy argument funkcji strtok wskazuje łańcuch, który ma zostać prze­ analizowany. W kolejnych wywołaniach analizowanie jest wznawiane od oznaczonego symbo­ lem NULL miejsca, w którym zostało uprzednio przerwane. Jest to bardzo niskiej jakości interfejs. Między poszczególnymi wywołaniami funkcji strtok przechowywana jest sekretna zmienna, dlatego w jednym czasie może być aktywna tylko jedna sekwencja wywołań. Niepo­ wiązane naprzemienne wywołania funkcji będą ze sobą kolidować. Funkcja unquote usuwa cudzysłowy z początku i końca przykładowego łańcucha danych. Ponieważ jednak nie radzi sobie z cudzysłowami w środku danych, nie nadaje się do ogólnych zastosowań, aczkolwiek w prototypie jest wystarczająca. /* unquote: usuwa cudzysłowy z początku i kaika danych */

char *unquote {char *p) { i f {p [O] == ) { ""

97

4.2. PROTOTYP BIBLIOTEKI

i f ( p [strl en (p) -1] == ' " ' ) p [strl en (p) - 1] = ' \O ' ; p++ ; return p ;

D o sprawdzenia, czy funkcja csvgetl i ne działa, posłuży nam prosty program testowy: /* Funkcja main programu csvtest: testujefunkcję csvgetline */

i nt rnai n (voi d) { i nt i , nf; whi l e ( (nf = csvgetl i ne (std i n ) ) != - 1 ) for ( i = O ; i < nf; i ++) pri ntf ( " fi el d [%d] '%s ' \n " , i , fi el d [i ] ) ; return O ; =

Funkcja p r i n t f drukuje pola w pojedynczych cudzysłowach, które stanowią ograniczniki, a przy okazji pozwalają wykryć błędy obsługi spacji. Możemy teraz uruchomić ten program na danych zwróconych przez program getquotes.tcl: % getquotes . tc l I csvtest fi el d [O] fi el d [l] fi el d [2] fi el d [3] fi el d [4] fi el d [5] fi el d [6] fi e l d [7] fi e l d [8] fi el d [O] fi el d [l]

' LU ' ' 86 . 37 5 ' ' 1 1/5/1998 ' ' l : Ol PM ' ' -0 . 125 ' ' 86 ' ' 86 . 375 ' ' 85 . 0625 ' ' 2888600 ' 'T' ' 6 1 . 0625 '

(Usunęliśmy nagłówki HTTP). Wygląda na to, że nasz prototyp prawidłowo przetwarza dane takiego typu, jak powyższe. Dla pewności warto jednak przetestować go jeszcze na jakichś innych danych, zwłaszcza jeśli mamy zamiar udostępnić nasz program do użytku komuś innemu. Znaleźliśmy kolejny serwis internetowy zawierający informacje o kursach akcji, lecz prezentujący je w nieco zmienionej formie. Zamiast znaku nowego wiersza do oddzielania rekordów użyto w nim znaku powrotu karetki (\ r) przy czym koniec pliku nie jest oznaczany tym znakiem. Poniższe dane przereda­ gowaliśmy, aby zmieściły się na stronie książki: ,

"Ti cker" , " Pri ce " , " Change" , " Open " , " Prev Cl ose " , " Day Hi gh" , " Day Low" , "52 Week H i gh " , "52 Week Low" , "D i v i dend " , " Y i e l d " , " Vol urne " , "Average Vol urne " , " P/ E " " LU " , 86 . 3 1 3 , -0 . 188 , 86 . 00 0 , 86 . 500 , 86 . 43 8 , 85 . 063 , 108 . 50 , 36 . 18 , 0 . 16 , 0 . 1 , 2946700 , 9675000 , N/A "T" , 61 . 125 , 0 . 938 , 60 . 37 5 , 60 . 188 , 61 . 12 5 , 60 . 000 , 68 . 50 ,

98

"

4. INTERFEJSY

46 . 50 , 1 . 32 , 2 . 1 , 3061000, 4777000 , 17 . 0 MSFT 107 . OOO , 1 . 500 , 105 . 3 1 3 , 105 . 500 , 107 . 188 , 105 . 250, 1 19 . 62 , 59 . 0 0 , N/A , N/A , 7977300 , 16965000 , 51 . 0 " ,

Na tych danych wejściowych nasz prototyp poległ. Popełniliśmy zasadniczy błąd polegający na tym, że do tworzenia prototypu przystąpiliśmy od razu po przeanalizowaniu danych z tylko jednego źródła i początkowo przetestowaliśmy go tylko na danych z tego samego źródła. Nie należy się zatem dziwić, że przy pierwszym spotka­ niu z danymi pobranymi z innego miejsca ponieśliśmy sromotną klęskę. Naszemu programowi poważnych trudności nastręczają długie wiersze danych wejściowych, duże ilości pól oraz nie­ przewidziane znaki oddzielające bądź ich całkowity brak. Tego wrażliwego na przeciwności losu prototypu można używać tylko na własne potrzeby albo posługiwać się nim jako dowodem na to, że zadanie jest wykonalne, ale to wszystko. Zanim przystąpimy do pisania nowej imple­ mentacji, powinniśmy jeszcze raz przemyśleć nasz projekt. Projektując prototyp, dokonaliśmy wielu wyborów. Pewne z nich były świadome, a inne zupełnie nieświadome. Oto niektóre z decyzji, które podjęliśmy. Nie wszystkie należy naśla­ dować przy projektowaniu biblioteki ogólnego przeznaczenia. Każda z tych decyzji sygnalizuje jakiś problem, którym trzeba się bliżej zająć. •

Prototyp nie obsługuje długich wierszy wejściowych i dużych ilości pól. Wyniki zwracane przez program mogą być nieprawidłowe, ponieważ nie ma w nim mechanizmu zabezpieczają­ cego przed przepełnieniami, a nawet procedury zapewniającej sensowne wartości zwrotne w przypadku wystąpienia błędów.

•

Na wejściu program oczekuje danych w postaci wierszy znaków oddzielanych znakami nowego wiersza.

•

Pola, które są ujmowane w pojedyncze cudzysłowy, rozdzielane są przecinkami. Nie przewidziano możliwości wystąpienia cudzysłowów ani przecinków wewnątrz samych danych.

•

Po pobraniu wiersz danych wejściowych nie jest przechowywany, lecz kasowany przez procedurę tworzenia pól.

•

Między jednym wierszem danych wejściowych a kolejnym nie są zapamiętywane żadne informacje. Jeśli trzeba coś zapamiętać, konieczne jest wykonanie kopii tego czegoś.

•

Tablicę, służącą do przechowywania pól, reprezentuje zmienna globalna o nazwie f i e l d, do której mają wspólny dostęp funkcja csvgetl i ne i funkcje ją wywołujące. Dostęp do treści pól i wskaźników nie jest w żaden sposób kontrolowany. Nie ma też zabezpieczenia przed sięganiem poza ostatnie pole.

•

Zmienne globalne uniemożliwiają równoległe wykonywanie wątków programu, a nawet przeplatanie wykonywania dwóch sekwencji wywołań.

•

Funkcja cs vgetl i ne pobiera dane tylko z otwartych plików, co oznacza, że użytkownik musi je jawnie otwierać.

•

Operacje pobierania danych i dzielenia ich na pola są nierozerwalnie połączone. W każdym wywołaniu wiersz danych zostaje wczytany i podzielony na pola, bez względu na to, czy jest to aplikacji potrzebne, czy nie.

•

Wartością zwrotną jest liczba pól w wierszu. Aby obliczyć tę wartość, trzeba podzielić każdy wiersz. Ponadto nie istnieje sposób na odróżnienie błędów spowodowanych napo­ tkaniem końca pliku. Żadnej z powyższych cech programu nie da się zmienić bez modyfikacji kodu.

•

4.3. BIBLIOTEKA DLA INNYCH

99

W przedstawionych wyżej punktach wypisaliśmy niektóre z licznych trudności projekto­ wych, z jakimi przyjdzie nam się zmierzyć. Każda decyzja, którą podjęliśmy, ma swoje bezpo­ średnie odbicie w kodzie. Takie podejście można stosować w prostych zadaniach, takich jak np. przekształcanie z jednego formatu na inny, niezmienny format, danych pochodzących ze znanego źródła. Co się jednak stanie, jeżeli format się zmieni, między cudzysłowami pojawi się przecinek albo serwer przekaże wyjątkowo długi wiersz, tzn. nietypowo dużą liczbę pól? Wydaje się, że nie są to problemy trudne do rozwiązania, zwłaszcza iż biblioteka jest nie­ wielka, a poza tym to i tak tylko prototyp. Wyobraź sobie jednak, że po miesiącach lub latach nieużywania program wraca do łask i zostaje wcielony do większego programu, którego specy­ fikacja zmienia się, zanim zostanie on ukończony. Jak funkcja scvgetl i ne zareaguje na te zmiany? Jeśli program, o którym mowa, byłby używany przez innych ludzi, podejmowanie w pośpiechu decyzji przy jego budowie może się nam odbić czkawką dopiero po latach. Tego rodzaju pro­ blemy spotykał już w przeszłości niejeden źle napisany interfejs. Przykro to mówić, ale na­ prędce sklecony i pełen usterek kod często trafia do powszechnie używanego oprogramowania, gdzie pozostaje niezmieniony przez wiele lat i ciągnie się jak kula u nogi.

4.3. Biblioteka dla innych Korzystając z doświadczenia zebranego przy budowie prototypu, spróbujemy napisać bibliote­ kę nadającą się do użytku ogólnego. Najbardziej oczywistą rzeczą jest to, że musimy poprawić funkcję cs vget l i ne tak, aby obsługiwała długie wiersze składające się z dużej liczby pól. Także procedura analizy pól wymaga ulepszenia. Jeśli chcemy, aby nasz interfejs nadawał się do użytku przez innych ludzi, przy tworzeniu jego projektu musimy przemyśleć zagadnienia wymienione na początku rozdziału: interfejsy, ukrywanie informacji, zarządzanie zasobami i obsługę błędów. Współpraca tych wszystkich elementów ma bardzo duży wpływ na ostateczny kształt programu. Przedstawiony podział jest jednak nieco sztuczny, gdyż wszystkie wymienione kwestie są ze sobą wzajemnie powiązane.

Interfejs. Zdecydowaliśmy się udostępniać trzy podstawowe operacje: char *csvgetl i n e ( FI LE *) : wczytuje nowy wiersz danych w formacie CSV, char *csvfi el d ( i nt n) : zwraca n-te pole bieżącego wiersza, i nt csvnfi el d ( voi d) : zwraca licznik pól znajdujących się w bieżącym wierszu. Jaką wartość powinna zwracać funkcja csvgetl i n e ? Najlepiej, gdyby zwracała jak najwięcej potrzebnych informacji, co przywodzi na myśl liczbę pól, którą zwracała także wersja prototy­ powa. Wówczas jednak pola byłyby liczone nawet wtedy, gdyby nie były używane. Inną moż­ liwością jest zwracanie długości wiersza wejściowego, która zależy od tego, czy znajdujący się na końcu znak nowego wiersza zostanie uwzględniony, czy nie. Po kilku eksperymentach zde­ cydowaliśmy, że funkcja csvgetl i ne będzie zwracała wskaźnik na oryginalny wiersz wejściowy albo wartość NULL, jeśli napotka koniec pliku. Znak nowego wiersza z końca wiersza zwracanego przez funkcję usuniemy, ponieważ w ra­ zie potrzeby można go łatwo przywrócić. Z definicją pola będą problemy. Staraliśmy się opracować definicję, która odpowiadałaby takim danym, jakie można znaleźć w arkuszach kalkulacyjnych i innych programach. Pole to ciąg dowolnej liczby znaków (włącznie z zerem). Do oddzielania pól służą przecinki. Białe znaki przed i za polem pozostają zachowane. Jeśli pole jest ujęte w podwójne cudzysłowy, wów­ czas może zawierać przecinki, a także cudzysłowy, ale te drugie tylko pod warunkiem, że do

1 00

4. INTERFEJSY

ich reprezentacji zostaną użyte dwa sąsiadujące ze sobą znaki cudzysłowu. W związku z tym pole CSV " x " " y " definiuje łańcuch znaków x"y. Pola mogą być puste - puste pole 11 11 jest równoważne z polem między dwoma sąsiadującymi przecinkami. Numeracja pól zaczyna się od zera. Co będzie, jeśli użytkownik poprosi o nieistniejące pole, np. za pomocą wywołania cs vfi e 1 d ( - 1 ) albo csvfi el d ( 100000) ? W odpowiedzi na takie zapy­ tanie moglibyśmy zwracać puste pole " 11 , które można wydrukować i użyć w operacji porów­ nywania. Programy przetwarzające różne ilości pól nie musiałyby stosować żadnych specjalnych zabezpieczeń przed nieistniejącymi polami. Ale wykorzystując to podejście, uniemożliwiamy rozróżnienie braku pola od pola pustego. Innym rozwiązaniem może być wydrukowanie ko­ munikatu o błędzie albo nawet przerwanie pracy programu. Wkrótce wyjaśnimy, dlaczego to rozwiązanie nie jest pożądane. Zdecydowaliśmy się na zwracanie wartości NULL, która standar­ dowo służy w języku C do zaznaczania braku łańcuchów.

Ukrywanie informacji. Długość wiersza i liczba pól będą w naszej bibliotece nieograniczone. Aby to było możliwe, ktoś musi dostarczyć odpowiedniej ilości pamięci: wywołujący lub wy­ woływany (biblioteka). Funkcji fgets z biblioteki języka C przekazujemy tablicę i liczbę okre­ ślającą jej maksymalny rozmiar. Jeśli na wejściu pojawi się wiersz przekraczający rozmiar bufora, to zostanie on podzielony na części. W interfejsie CSV taki sposó.b działania nie jest pożądany, dlatego w razie potrzeby biblioteka będzie przydzielała dodatkową pamięć. Zatem wszystkie operacje związane z zarządzaniem pamięcią zostaną ukryte w funkcji csv­ getl i ne. Nic na ten temat nie wydostaje się na zewnątrz. Najlepszym sposobem n a zapewnie­ nie takiej izolacji jest użycie interfejsu składającego się z trzech funkcji. Funkcja cs vgetl i ne wczytuje po kolei wiersze danych, nie zważając na ich rozmiar. Funkcja csvfi el d ( n ) zwraca wskaźnik na bajty n-tego pola bieżącego wiersza, a funkcja csvnfi e 1 d - licznik pól w bieżą­ cym wierszu. Gdy na wejściu pojawią się dłuższe wiersze lub większe ilości pól, będziemy zmuszeni przy­ dzielać dodatkowe zasoby pamięci. Sposób zaprogramowania tego rozwiązania będzie ukryty w trzech wymienionych funkcjach csv. W żadnej innej części programu nie będzie wiadomo, czy biblioteka początkowo wykorzystuje małe tablice, które następnie powiększa, czy przeciw­ nie - używa od razu bardzo dużych tablic albo stosuje jakieś jeszcze inne rozwiązanie. Także moment zwalniania pamięci nie jest przez interfejs ujawniany. Gdy wywołana zostanie tylko funkcja cs vget 1 i ne, nie trzeba dzielić wiersza wejściowego na pola. Podziału na pola można dokonywać na żądanie. Kolejnym ukrytym szczegółem im­ plementacyjnym jest to, czy dzielenie wiersza na pola jest wykonywane ochoczo (natychmiast po wczytaniu wiersza danych), leniwie (tylko gdy potrzebujemy pól lub ich liczby), czy wręcz bardzo leniwie (wydzielenie tylko jednego wybranego pola).

Zarządzanie zasobami. Musimy zdecydować, kto będzie zarządzał wspólnymi informacjami. Czy funkcja csvgetl i ne powinna zwracać oryginalne dane, czy kopię danych? Postanowili­ śmy, że funkcja csvgetl i ne będzie zwracać wskaźnik na oryginalne dane, które zostaną skaso­ wane z chwilą wczytania nowego wiersza. Pola będą wydobywane z kopii wiersza wejściowego, a funkcja es vget 1 i ne zwróci wskaźnik na pole wewnątrz tego wiersza. Przy takim sposobie działania funkcji użytkownik chcąc zapisać lub zmienić wybrany wiersz lub pole, będzie musiał wykonać jego kolejną kopię, a ponadto do jego obowiązków należy zwolnienie później pamięci, której już nie będzie używał. Kto będzie otwierał i zamykał plik z danymi? Ktokolwiek to będzie, musi również zadbać o jego zamknięcie w odpowiednim czasie - czynności uzupełniające się należy wykonywać na tym samym poziomie lub w tym samym miejscu. Założymy, że funkcja c s vgetl i ne będzie wywoływana przy użyciu wskaźnika FI LE na otwarty plik oraz że zamknięcie pliku będzie na­ leżało do wywołującego po zakończeniu pracy.

101

4.3. BIBLIOTEKA DLA INNYCH

Zawsze trudno jest zarządzać zasobami wspólnymi lub przekazywanymi między biblioteką a mechanizmami, które z niej korzystają. Często istnieje kilka wykluczających się rozwiązań i każde z nich ma dobre uzasadnienie. Problemy i nieporozumienia związane z zasadami wspól­ nego korzystania z zasobów są częstym źródłem błędów.

Obsługa błędów. Ponieważ funkcja csvgetl i ne zwraca wartość NULL, nie da się w prosty spo­ sób odróżnić końca pliku od błędów typu wyczerpanie pamięci. Podobnie próba użycia nieist­ niejącego pola kończy się błędem. Moglibyśmy do naszego interfejsu dodać funkcję o nazwie csvgeterror, która - tak jak funkcja ferror - zwracałaby informacje o ostatnim błędzie, ale nie zrobimy tego, by nie komplikować kodu. Zgodnie z ogólnymi zasadami funkcje biblioteczne nie powinny w razie wystąpienia błędu ograniczać się do przerwania działania, lecz muszą przekazywać wywołującemu odpowiednie informacje, niezbędne do podjęcia przez niego właściwych dalszych czynności. Nie powinny też wyświetlać komunikatów ani żadnych wyskakujących okienek, gdyż w niektórych środowi­ skach takie zachowanie może być szkodliwe. Obsługa błędów to temat zasługujący na szersze potraktowanie, dlatego dyskusję tę wznowimy nieco dalej w tym rozdziale.

Specyfikacja. Wszystkie podjęte decyzje należy zebrać w jednym miejscu w celu sporządzenia dokumentacji działania funkcji cs vget l i ne i świadczonych przez nią usług. W przypadku du­ żych projektów specyfikację pisze się wcześniej, niż opracowuje implementację programu, gdyż pisaniem specyfikacji i pisaniem kodu zwykle zajmują się całkiem inne osoby, czasami nawet z różnych organizacji. Często jednak w praktyce jest tak, że specyfikacja i kod są rozwijane równocześnie, a nawet zdarza się, iż specyfikację pisze się po zakończeniu pracy nad kodem, aby udokumentować z grubsza, co on robi. Najlepiej sporządzanie specyfikacji rozpocząć na wczesnym etapie prac i ciągle ją udosko­ nalać w miarę postępu pracy nad projektem i poszerzania swojej wiedzy praktycznej. Im bar­ dziej precyzyjna i lepiej dopracowana będzie specyfikacja, tym większą mamy szansę, że napi­ szemy dobrze działający program. Nawet jeśli tworzymy tylko na własne potrzeby, warto opracować w miarę dokładną specyfikację, gdyż będzie to stanowić dla nas bodziec do rozwa­ żenia różnych alternatywnych rozwi;izań oraz umożliwi wgląd w podejmowane wcześniej decyzje. W specyfikacji sporządzonej na nasze potrzeby zamieścimy prototypy funkcji oraz szczegółowe opisy ich zachowań, zakresu odpowiedzialności i założeń przyjętych podczas ich pisania: Pola są oddzielane przecinkami. Pole może być ujęte w podwójny cudzysłów:

11• " . . .

Pole ujęte w podwójny cudzysłów może zawierać przecinki, ale nie znaki nowego wiersza. Pole ujęte w podwójny cudzysłów może zawierać znaki podwójnego cudzysłowu reprezentowane przez dwa znaki takiego cudzysłowu: 11 11 •

Pola mogą być puste: zarówno pole

11 11

,

jak i pusty łańcuch to reprezentacje pustego pola.

Białe znaki na początku i końcu pozostają zachowane.

char *csvget l i ne ( Fl LE *f) ; Wczytuje jeden wiersz danych z otwartego pliku f; do oznaczenia końca wiersza powinien być użyty jeden z następujących znaków: \r, \n, \r\n lub EOF. Zwraca wskaźnik na wiersz, po uprzednim usunięciu znaku końcowego lub NULL w przypadku napotkania końca pliku.

1 02

4. INTERFEJSY

Długość wiersza jest nieograniczona. W przypadku wyczerpania pamięci zwracana jest wartość NULL. Wiersze należy traktować jako pamięć tylko do odczytu; jeśli wywołujący chce zachować lub zmienić treść wiersza, musi wykonać jego kopię.

char *csvfi el d ( i nt n) ; Numeracja pól zaczyna się od O. Funkcja zwraca n-te pole ostatniego wiersza wczytanego przez funkcję csvgetl i ne; zwraca NULL, jeśli n jest mniejsze od zera lub ma wartość przekraczającą liczbę pól. Pola są oddzielane przecinkami. Pola mogą być ujęte w cudzysłowy " . . . ", które zostaną usunięte; 11 ciągi 11 11 są zamieniane na znak 11 , a przecinki nie są traktowane między znakami 11 jako znaki oddzielające. • • •

W polach nieujętych w cudzysłów znaki cudzysłowu są traktowane jak zwykłe znaki. Liczba i długość pól są nieograniczone; w przypadku wyczerpania pamięci funkcja zwraca wartość NULL. Pola należy traktować jako pamięć tylko do odczytu; aby dokonać zmian lub je zapisać, wywołujący musi wykonać kopię treści pola. Zachowanie funkcji w przypadku wywołania jej przed funkcją csvgetl i ne jest niezdefiniowane.

i nt csvnfi el d (voi d ) ; Zwraca liczbę pól w ostatnim wierszu wczytanym przez funkcję csvgetl i ne. Zachowanie funkcji w przypadku wywołania jej przed funkcją csvgetl i ne jest niezdefiniowane. Ta specyfikacja nie zawiera odpowiedzi na wszystkie pytania. Na przykład nie wiadomo, jakie wartości powinny zwracać funkcje csvfi el d i csvnfi el d, jeśli zostaną wywołane po na­ potkaniu przez funkcję csvget l i ne końca pliku. Jak powinny być obsługiwane nieprawidłowo zbudowane pola? Rozwiązanie wszystkich tego typu kwestii może nastręczać wielu problemów nawet w małym programie, nie mówiąc już o większych projektach, ale koniecznie trzeba spróbować. Wiele niedociągnięć i zaniedbań można wykryć dopiero podczas pracy nad imple­ mentacją. W dalszej części tego rozdziału przedstawiamy nową implementację, która będzie zgodna z napisaną specyfikacją. Bibliotekę podzieliliśmy na dwa pliki: nagłówek o nazwie csv.h zawie­ rający deklaracje funkcji stanowiących interfejs publiczny i plik csv.c z właściwym kodem im­ plementacji. Użytkownicy dołączają plik csv.h do swojego kodu źródłowego, a następnie kom­ pilują i konsolidują własne pliki z plikiem csv.c. Plik źródłowy nie musi być widoczny. Oto zawartość pliku nagłówkowego: I* csv.h: inteifejs biblioteki csv *I

extern char *csvgetl i ne ( F I LE *f) ; extern char *csvfi el d ( i nt n) ; extern i nt csvnfi el d (voi d) ;

I* Wczytuje następny wiersz */ /* Zwraca pole n */ /* Zwraca licznik pól */

1 03

4.3. BIBLIOTEKA DLA INNYCH

Zmienne wewnętrzne służące do przechowywania tekstu i funkcje takie jak spl i t są wi­ doczne tylko w obrębie pliku, w którym zostały zadeklarowane przy użyciu słowa kluczowego stat i c. Jest to najprostszy sposób ukrywania informacji w języku C.

enum { NOMEM = -2 } ; stat i c stati c stati c stat i c stat i c stat i c

char char i nt char i nt i nt

*l i ne *sl i ne maxl i ne **fi el d maxfi el d nfi el d =

/* Sygnał braku pamięci */

NULL; /* Znaki wejściowe */ NULL; /* Kopia wiersza używana przezfunkcję split */ /* Rozmiar tablic line[] i sline[} *I O; NULL; /* Wskaźniki na pola *I /* Rozmiar tablicy field[} */ O; /* Liczba pól w tablicyfield[] *I O;

stat i c char fi el dsep [] =

"

, ; l* Znald oddzieldjącepola *I "

Zmienne są również inicjalizowane statycznie. Wartości początkowe służą do sprawdzenia, czy utworzyć lub powiększyć tablice. Powyższe deklaracje stanowią definicję prostej struktury danych. W tablicy l i ne przecho­ wywany jest pobrany z wejścia wiersz. Tablica s l i ne powstaje przez skopiowanie znaków z tablicy l i ne i wstawienie znaku oznaczającego koniec każdego z pól. Tablica array zawiera wskaźniki na elementy tablicy s l i ne. Na poniższym rysunku widać stan tych trzech tablic po zakończeniu przetwarzania wiersza ab , 11 cd 11 , 11 e 11 11 f11 „ 11 9 , h 11 • Pozycje zaciemnione w tablicy s l i ne nie są częścią żadnego pola.

l i ne

s l i ne

fi e l d

b \O "

o

d \O \O "

1

h \O

2

3

Oto kod źródłowy funkcji csvgetl i ne: I* csvgetline: pobiera jeden wiersz, zwiększa tablicę w razie potrzeby */ I* Przykładowe dane wejściowe: "LU",86.25, "1 11411998", "2: 19PM", +4. 0625 */

char *csvget l i n e ( FI LE *fin) { i nt i , c ; char *newl , *news ; i f ( l i ne == NULL) { /* Alokacja przy pierwszym wywołaniu */ maxl i ne = maxfi el d = l ; l i ne = (char *) mal l oc (maxl i ne) ; sl i ne = { char *) mal l oc (maxl i ne) ; fi el d = (char **} mal l oc (maxfi e l d*si zeof ( fi el d [O] ) } ; i f ( l i ne == NULL 1 1 s l i ne == NULL 1 1 fi el d == NULL) { reset ( ) ; /* Wyczerpanie pamięci */ return NULL ;

4

1 04

4 . INTERFEJSY

for ( i =O ; (c=getc (fi n ) ) ! =EOF && ! endofl i ne ( fi n , c) ; i ++) { i f ( i >= maxl i ne-1) { /* Powiększenie wiersza */ maxl i ne *= 2 ; /* Podwojenie aktualnego rozmiaru */ newl = (char *) real l oc ( l i ne , maxl i ne) ; news = (char *) real l oc (s l i ne , maxl i ne) ; i f (newl == NULL I I news ==NULL) { reset () ; return NULL; /* Wyczerpanie pamięci */ 1 i ne = newl ; s l i ne = news ; } l i ne [i ] = c ;

l i ne [i ] = ' \O ' ; i f {spl i t () == NOMEM) reset () ; return NULL; } return (c == EOF &&

I* Wyczerpanie pamięci */

O)

NULL : l i ne ;

Wiersze przychodzące są gromadzone w tablicy l i ne, której rozmiar w razie potrzeby zostaje podwojony za pomocą funkcji rea 1 1 oc, tak jak robiliśmy w podrozdziale 2.6. Rozmiar tablicy sl i ne jest zawsze taki sam jak tablicy l i ne. Funkcja csvget l i ne wywołuje funkcję spl i t w celu utworzenia wskaźników na pola zapisywane w osobnej tablicy o nazwie fi el d, której rozmiar również w razie potrzeby może być powiększany. Zgodnie z naszym zwyczajem tablicom nadajemy niewielkie rozmiary początkowe i zwięk­ szamy je, gdy zajdzie taka potrzeba, co pozwala nam sprawdzić, czy kod zwiększający rozmiar w ogóle działa. Jeśli alokacja nie powiedzie się, przywracamy zmienne globalne do stanu po­ czątkowego za pomocą funkcji reset. Dzięki temu kolejne wywołanie funkcji csvgetl i ne ma szanse powodzenia : /* reset: przywraca wartości początkowe zmiennym */

stati c voi d reset (vo i d ) { free (1 i ne) ; /* Wywolaniefree(NULL)jest dozwolone w standardzie ANSI C */ free {sl i ne) ; free (fi el d) ; l i ne = NULL; s l i ne = NULL; fi el d = NULL; maxl i ne = maxfi el d nfi el d O;

Funkcja endofl i ne obsługuje różne rodzaje zakończeń wiersza wejściowego: znak powrotu karetki, znak nowego wiersza, obydwa te znaki lub nawet znak końca pliku: I* endojline: sprawdza i usuwa znaki \r, \n, \r\n oraz EOF */

stati c i nt endofl i ne ( FILE *fi n , i nt c) { i nt eol ;

4.3. BIBLIOTEKA DLA INNYCH

1 05

eol ( c== ' \r ' 1 1 c== ' \n ' ) ; i f ( c == ' \r ' ) { c = getc (fi n ) ; i f (c ! = ' \n ' && c ! = EOF) ungetc ( c, fi n) ; /* Wczytano za dużo, cofii ięcie c *I =

return eol ;

Utworzenie osobnej funkcji było konieczne, gdyż standardowe funkcje wejściowe nie ob­ sługują wszystkich możliwych formatów danych wejściowych. · W prototypie do znajdowania kolejnego leksemu używaliśmy funkcji strtok, która szukała przecinka jako znaku oddzielającego. Ten sposób działania uniemożliwiał nam jednak obsługę przecinków w cudzysłowach. Funkcja sp l i t wymaga dużych zmian w implementacji, aczkolwiek sam jej interfejs pozostanie nienaruszony. Rozważmy poniższe wiersze danych wejściowych:

Każdy wiersz składa się z trzech pustych pól. Aby zapewnić poprawne przetwarzanie tego rodzaju nietypowych informacji, trzeba znacznie skomplikować kod źródłowy. Jest to przykład sytuacji, w której obsługa kilku specjalnych i brzegowych przypadków może stać się dominują­ cą częścią kodu źródłowego programu. /* split: dzieli wiersze na pola */

stati c i nt spl i t (voi d) { char *p, **newf; char *sepp ; /* Wskaźnik na tymczasowy znak oddzielający */ i nt sepc ; /* Tymczasowy znak oddzielający *I n fi el d = O ; i f (l i ne [OJ == ' \O ' ) return O ; s trcpy ( s l i ne , l i ne) ; p = s l i ne ; do { i f (nfi el d >= maxfi eld) { max f i el d *= 2 ; /*Podwojenie aktualnego rozmiaru */ newf = (char **) real l oc ( f i el d , maxfi el d * s i zeof(fi el d [OJ ) ) ; i f (newf == NULL) return NOMEM; fi el d = newf; } i f ( *p == "" ) se pp advquoted ( ++p) ; /* Pominięcie pie1wszego cudzysłowu *I el se sepp p + strcspn ( p , fi el dsep) ; sepc = se pp [OJ ; sepp [OJ = ' \O ' ; /* Zako1iczenie pola *I fi e l d [nfi el d++J p;

1 06

4. INTERFEJSY

p = sepp + l ; whi l e (sepc == ' , ' ) ; return n fi el d ;

Oto co robi pętla: zwiększa w razie potrzeby tablicę wskaźników na pola, a następnie wy­ wołuje jedną funkcję lub dwie w celu zlokalizowania i przetworzenia kolejnego pola. Jeśli po­ brane pole zaczyna się od znaku cudzysłowu, funkcja advquoted znajduje to pole i zwraca wskaźnik na znak oddzielający oznaczający jego koniec. W przeciwnym razie szukamy następ­ nego przecinka przy użyciu funkcji z biblioteki standardowej o nazwie strcspn ( p , s ) , która przeszukuje łańcuch przekazany w argumencie p w celu znalezienia kolejnego wystąpienia ja­ kiegokolwiek znaku w argumencie s. Jej wartością zwrotną jest liczba pominiętych znaków. Ponieważ znaki cudzysłowu wewnątrz pól są reprezentowane przez dwa sąsiadujące znaki cudzysłowu, funkcja advquoted usuwa jeden z nich i dodatkowo usuwa też cudzysłowy z po­ czątku i końca pola. Funkcję komplikuje mechanizm obsługi pozornie poprawnych danych, które jednak nie spełniają wymogów specyfikacji, np. " abc"def. Takie problemy rozwiązujemy, za­ liczając do pola wszystko, co znajduje się między drugim cudzys_łowem i następnym znakiem oddzielającym. W programie Microsoft Excel chyba zastosowano podobny algorytm. /* advquoted: pole w cudzysłowie; zwraca wskaźnik na następny znak oddzielający *I

stat i c char *advquoted ( char *p) { i nt i , j ; for ( i = j = O ; p [j] ! = ' \O ' ; i ++ , j++) { i f ( p [j] == 1 11 1 && p [++j] ! = 1 11 1 ) { I* Kopiuje do napotkania następnego znaku oddzielającego lub znaku \O *I

i nt k = strcspn (p+j , fi el dsep) ; me111Tio ve (p+i , p+j , k) ; i += k ; j += k; brea k ; } p [i ] = p [j] ;

} p [i ] = ' \O ' ; return p + j ;

Gdy podzieliliśmy wiersz danych na pola, napisanie funkcji cs v fi e l d i c s vnf i e l d jest już łatwe: /* csvfield: zwraca wskaźnik na n-tepole */

char *csvfi el d ( i nt n) { i f (n < O I I n >= nfi el d) return NULL; return fi el d [n] ;

I* csvnfield: zwraca licznik pól */

i nt csvnfi el d (vo i d )

1 07

4.3. BIBLIOTEKA DLA INNYCH

return nfi el d ;

Teraz możemy zmodyfikować program testowy, aby sprawdzić nową wersję biblioteki. Po­ nieważ w przeciwieństwie do prototypu ta wersja przechowuje kopię wiersza wejściowego, można wydrukować oryginalny wiersz, zanim wydrukuje się pola: /* main: testuje bibliotekę CSV */

i nt mai n (vo i d) { i nt i ; char *l i ne ; whi l e ( ( l i ne = csvgetl i ne (stdi n ) ) ! = NULL) pri ntf ( " l i ne = "%s ' \n " , l i ne) ; for (i = O ; i < csvnfi el d () ; i ++) pri ntf ( " fi el d [%d] "%s ' \n " , i , csvfi el d ( i ) ) ; =

return O ;

N a tym zakończyliśmy pracę nad implementacją w języku C . Program obsługuje dowolnie dużą ilość danych wejściowych i nawet nieźle sobie radzi z nietypowymi formatami. Ceną za te udoskonalenia jest zwiększenie długości kodu ponad czterokrotnie w stosunku do prototypu i pojawienie się kilku zawiłych fragmentów kodu. Takie zwiększenie rozmiaru i poziomu zło­ żoności ostatecznej wersji programu jest typowym zjawiskiem.

Ćwiczenie 4.1. Operacja dzielenia wierszy na pola dobrze nadaje się do realizacji różnych ro­ dzajów przetwarzania leniwego. Przykładowo po odebraniu żądania jednego pola można po­ dzielić od razu cały wiersz, wydzielić tylko jedno wybrane pole albo wyodrębnić żądane pole i wszystkie znajdujące się przed nim. Sporządź listę możliwych metod implementacji tej funk­ cji, oszacuj potencjalne trudności i zalety każdej z nich, a następnie je zrealizuj i zmierz pręd­ kość ich działania.

Ćwiczenie 4.2. Dodaj do programu mechanizm pozwalający jako znaki oddzielające pola zasto­ sować (a) znaki dowolnego rodzaju; (b) różne znaki dla różnych pól; (c) wyrażenia regularne (zobacz rozdział 9.). Jak powinien wyglądać interfejs?

Ćwiczenie 4.3. Podstawowym mechanizmem wyboru sposobu działania naszego programu uczyniliśmy statyczną inicjalizację zmiennych: jeśli wskaźnik jest na początku pusty, to go ini­ cjalizujemy. Można też zlecić użytkownikowi obowiązek wywołania funkcji inicjalizującej, która ustawiałaby zalecane początkowe rozmiary tablic. Zaimplementuj rozwiązanie będące połączeniem zalet obu przedstawionych rozwiązań. Jaką rolę będzie odgrywać w Twojej im­ plementacji funkcja reset?

Ćwiczenie 4.4. Zaprojektuj i zaimplementuj bibliotekę do tworzenia danych w formacie CSV. W najprostszym wydaniu program może pobierać łańcuchy z tablicy i drukować je z dodanymi cudzysłowami i przecinkami. Bardziej zaawansowana wersja może używać łańcucha formatu podobnego do używanego przez funkcję pri nt f. Jeśli potrzebujesz podpowiedzi na temat nota­ cji, zajrzyj do rozdziału 9.

1 08

4. INTERFEJSY

4.4. Implementacja w języku C + + csv w języku c+ + , którego uży­ cie pozwoli nam rozwiązać niektóre problemy wynikające z ograniczeń języka C. W związku z tym będziemy musieli wprowadzić kilka zmian w specyfikacji programu. Najważniejsza bę­ dzie dotyczyła tego, że zamiast tablic znaków będziemy używać łańcuchów znaków C+ +. Ta zmiana automatycznie rozwiąże niektóre z naszych problemów związanych z zarządzaniem pamięcią, gdyż funkcje biblioteki standardowej języka c+ + zwolnią nas z obowiązku wyko­ nywania pewnych czynności. Procedury obsługujące pola będą zwracały łańcuchy znaków, które funkcje wywołujące są w stanie bez przeszkód przetwarzać. To znaczny postęp, jeśli cho­ dzi o elastyczność w stosunku do poprzedniej wersji programu. Interfejs publiczny zdefiniujemy w klasie Csv, w której zgrabnie ukryjemy zmienne i funk­ cje należące do implementacji. Ponieważ pojedynczy obiekt tej klasy zawiera cały stan, bę­ dziemy mogli tworzyć dowolną liczbę zmiennych typu Csv. Jako że każdy obiekt stanowi nie­ zależną jednostkę, będzie można operować na kilku strumieniach wejściowych jednocześnie. w tym podrozdziale zajmiemy się implementacją biblioteki

li Wczytuje wartości oddzielane przecinkami i analizuje ich składnię li Przykładowe dane wejściowe: "LU",86.25, "111411998", "2:19PM", +4. 0625

cl ass Csv {

publ i c : Csv ( i stream& fi n = ci n , stri ng sep fi n ( fi n) , fi el dsep ( sep) { }

" , ")

i nt getl i ne(stri ng&) ; stri ng getfi el d ( i nt n) ; i nt getnfi el d () con st { return n fi el d ; } pri vate : i stream& fi n ; stri ng l i ne ; vector fi el d ; i nt nfi el d ; stri ng fi el dsep ; i nt i nt i nt i nt

li Wskaźnik na plik wejściowy li Wiersz wejściowy li Łańcuchy reprezentujące pola li Liczba pól li Znaki oddzielające

spl i t ( ) ; endofl i ne (char) ; advp l a i n (const stri ng& l i ne , stri ng& fl d , i nt) ; advquoted (const stri ng& l i ne , stri ng& fl d , i nt) ;

}; Ponieważ zdefiniowaliśmy domyślne parametry konstruktora, domyślny obiekt klasy Csv będzie wczytywał dane z e standardowego strumienia wejściowego przy użyciu normalnego znaku oddzielającego pola. Oba argumenty można zastąpić jawnymi wartościami. Do zarządzania łańcuchami znaków w klasie wykorzystywane są standardowy typ stri ng języka C+ + i klasa vector (zrezygnowaliśmy z łańcuchów w stylu języka C). W typie stri ng nie istnieje coś takiego jak brak stanu: pusty łańcuch to tylko łańcuch o zerowej długości; nie ma też odpowiednika wartości N U L L, a więc nie można jej użyć do oznaczania końca pliku. W związku z tym argument funkcji Csv : : get l i ne wykorzystaliśmy do przesłania referencji do wiersza danych wejściowych w postaci łańcucha, a sama wartość zwrotna posłuży nam do przekazywania informacji o końcu pliku i błędach.

4.4. IMPLEMENTACJA W JĘZYKU C+ +

1 09

li getline: pobierajeden wiersz, zwiększa rozmiar w razie potrzeby

i nt Csv : : getl i n e (stri ng& str) {

char c ; for ( l i ne = " " ; fi n . get(c) && ! endofl i ne (c) ; ) l i ne += c ; spl i t ( ) ; str = l i ne ; return ! fi n . eo f ( ) ;

Operator += występuje tu w wersji przeciążonej dołączającej znak na końcu łańcucha. Kod funkcji endofl i ne wymaga tylko drobnych poprawek. Tu również musimy wczytywać dane wejściowe po jednym znaku, ponieważ żadna standardowa funkcja nie potrafi obsłużyć całej różnorodności wszystkich możliwych formatów. li endojline: sprawdza i usuwa znaki \r, \n, \r\n oraz EOF

i nt Csv : : endofl i ne (char c) { i nt eol ; eol = (c== ' \r ' I I c== ' \n ' ) ; i f ( c == ' \r ' ) { fi n . get(c) ; i f ( ! fi n . eof() && c ! = ' \n ' ) fi n . putback ( c) ; li Wczytano za dużo return eol ;

Oto nowa wersja funkcji spl i t : li split: dzieli wiersze na pola

i nt Csv : : spl i t ( ) {

stri ng fl d ; i nt i , j ; nfi el d = O ; i f ( l i ne . l ength ( ) == O) return O ; i = O; do i f (i < l i ne . l ength ( ) && l i ne [i] == "" ) j advquoted ( l i ne , fl d , ++i ) ; llPomija cudzysłów el se j = advpl ai n (l i ne , fl d , i ) ; i f (nfi el d >= fi el d . si z e ( ) ) fi el d . push_bac k ( fl d) ; el se fi el d [nfi el d] = fl d ; nfi el d++; =

1 10

4. INTERFEJSY

i = j + l; whi l e (j < l i ne . l ength ( ) ) ; return nfi el d ;

Ponieważ funkcja strcspn nie obsługuje łańcuchów języka C + +, jesteśmy zmuszeni zmo­ dyfikować zarówno funkcję spl i t, jak i advquoted. W nowej wersji tej drugiej z wymienionych funkcji użyjemy standardowej funkcji języka c+ + o nazwie fi nd _fi rst_o f, która posłuży nam do znajdowania kolejnego wystąpienia znaku oddzielającego. Wywołanie s . fi nd_fi rst_ '+of ( fi el dsep , j ) przeszukuje łańcuch s w celu znalezienia pierwszego wystąpienia którego­ kolwiek ze znaków znajdujących się w argumencie fi e l dsep na pozycji j lub za nią. Jeśli nic nie znajdzie, to zwraca indeks o numerze spoza łańcucha, a więc musimy się cofnąć. Znajdują­ ca się dalej pętla wewnętrzna for dołącza do łańcucha f1 d wszystkie znaki, które mieściły się przed szukanym znakiem oddzielającym.

li advquoted: pole w cudzysłowie; zwraca indeks kolejnego znaku oddzielającego i nt Csv : : advquoted (const stri ng& s , stri ng& fl d , i nt i ) { i nt j ; fl d = " " ; for (j = i ; j < s . l ength ( ) ; j ++) { i f ( S [j ] ) && S [++ j] ! = i nt k = s . fi nd fi rst of(fi el dsep, j ) ; i f ( k > s . l ength () ) li Nie znaleziono żadnego znaku oddzielającego k = s . l ength ( ) ; for (k -= j ; k-- > O ; fl d += s [j ++] ; break; ::

I U I

° '1 1

fl d += s [j] ; return j ;

Funkcji fi nd_fi rst_of używamy także w nowej funkcji o nazwie advp l a i n służącej do przeglądania zwykłych pól nieujętych w cudzysłowy. Ta zamiana również została wymuszona przez to, że funkcje działające na łańcuchach w stylu języka C (np. strcspn) nie działają na łańcuchach języka c+ +, ponieważ są to całkiem różne typy danych.

li advplain: pole nieujęte w cudzysłów; zwraca indeks następnego znaku oddzielającego i nt Csv : : advpl ai n (const stri ng& s , stri ng& fl d , i nt i ) { i nt j ; j = s . fi nd fi rst of (fi el dsep, i ) ; li Szuka znaku oddzielającego if (j > s . length() ) li Nie znaleziono j = s . l ength ( ) ; fl d = stri ng ( s , i , j - i ) ; return j ;

111

4.4. IMPLEMENTACJA W JĘZYKU C+ +

Tak jak poprzednio napisanie funkcji Csv : : getfi el d to banalnie proste zadanie, a imple­ mentacja funkcji Csv : : getnfi el d jest tak krótka, że umieściliśmy ją w definicji klasy. li getjield: zwraca n-te pole

string Csv : : getfi el d ( i nt n) { i f (n < O 1 1 n > = nfi el d) return " " ; e l se return fi el d [n] ;

Program testowy również przypomina poprzednią wersję: li main: testuje klasę Csv

i nt mai n (voi d) { stri ng l i ne ; Csv csv;

whi l e (csv . getl i ne ( l i ne) ! = O) { cout << " l i ne << l i ne <<11 1 \n " ; for ( i nt i = O ; i < csv . getnfi el d () ; i ++) cout << " fi e l d [ " << i << ] = · n « csv . getfi el d ( i ) « " ' \n " ; =

· n

"

return O ;

Sposób użycia tego programu niewiele różni się o d wersji w języku C. Przy dużym pliku wejściowym zawierającym 30 tysięcy wierszy po około 25 pól każdy wersja napisana w języku C+ + działa o około 40% do czterech razy wolniej od wersji w języku C, w zależności od użyte­ go kompilatora. Jak zauważyliśmy w czasie porównywania różnych wersji programu markov, różnice te wynikają z niedoskonałości biblioteki. Program w języku C + + jest o około 20% krótszy.

Ćwiczenie 4.5. Rozszerz implementację w języku C+ + o przeciążenie operatora [] , aby dostęp do pól można było uzyskiwać za pomocą notacji csv [i ] . Ćwiczenie 4.6. Zaimplementuj bibliotekę CSV w Javie, a następnie porównaj wszystkie trzy wersje pod względem klarowności kodu, niezawodności i szybkości działania. Ćwiczenie 4.7. Napisz nową wersję biblioteki CSV w języku C+ + przy użyciu iteratorów z biblio­ teki STL.

Ćwiczenie 4.8. w wersji programu napisanej w języku c + + możliwe jest działanie wielu nie­ zależnych egzemplarzy klasy Csv jednocześnie. Jest tak dzięki zamknięciu całego opisu stanu w jednym obiekcie, który może występować w wielu egzemplarzach. Zmodyfikuj wersję w ję­ zyku C tak, aby uzyskać w nim ten sam efekt. W tym celu zamień globalne struktury danych na struktury alokowane i inicjalizowane za pomocą jawnego wywołania funkcji csvnew.

1 12

4. INTERFEJSY

4.5 . Zasady projektowania interfejsów We wcześniejszych podrozdziałach pracowaliśmy nad interfejsem, który stanowi granicę mię­ dzy kodem świadczącym usługi a kodem, który z tych usług korzysta. Interfejs określa, co pewna część programu robi dla użytkowników, jak składające się nań funkcje i czasami dane mogą zostać uŻyte w pozostałej części programu. Interfejs CSV, który zaprojektowaliśmy, za­ wiera trzy funkcje - wczytującą wiersz danych, wyodrębniającą pola i zwracającą licznik pól. Są to jedyne możliwe do wykonania operacje. Interfejs powinien być właściwie dostosowany do zadania, które ma wykonywać - powi­ nien być prosty, ogólny, regularny, przewidywalny i niezawodny - oraz musi elegancko przy­ stosowywać się do zmian w wymaganiach użytkowników i implementacji. Dobre interfejsy tworzy się według pewnych zasad. Nie są one wzajemnie zależne ani nawet spójne, ale pomagają opisać, co się dzieje na styku dwóch części oprogramowania.

Ukrywanie szczegółów implementacji. Wewnętrzne mechanizmy implementacji interfejsu powinny być ukryte przed resztą programu, aby można było je w razie potrzeby zmienić bez konieczności modyfikowania czegokolwiek innego. Zasada ta ma wiele nazw, np. ukrywanie informacji, hermetyzacja, abstrakcja, modularyzacja itp. Każda z nich oznacza mniej więcej to sarno. Wszystkie szczegóły implementacji interfejsu, które nie są potrzebne jego użytkowni­ kom, powinny być ukryte. Niewidoczne szczegóły implementacji interfejsu można zmieniać w sposób niezauważalny dla klientów (użytkowników), co pozwala np. na jego bezproblemowe rozszerzanie, optymalizowanie czy wręcz na całkowitą wymianę wszystkich wewnętrznych me­ chanizmów. Przykłady stosowania zasady ukrywania informacji można znaleźć w podstawowych biblio­ tekach większości języków programowania. Nie zawsze są one jednak idealnie zrealizowane. Do najszerzej znanych należy biblioteka wejścia i wyjścia języka C, która zawiera kilkadziesiąt funkcji służących do otwierania, zamykania, odczytywania, zapisywania i przetwarzania plików na jeszcze wiele innych sposobów. Implementacja mechanizmów wejścia i wyjścia plików jest ukryta w typie danych FI LE*. Wiele jej szczegółów można znaleźć w nagłówku , ale nie należy tej wiedzy wykorzystywać. Jeśli w pliku nagłówkowym nie ma rzeczywistej deklaracji struktury, lecz jest wyłącznie jej nazwa, to strukturę taką nazywa się typem nieprzezroczystym, ponieważ jej właściwości są niewidoczne, a wszelkie związane z nią operacje wykonuje się za pośrednictwem wskaźnika na realny obiekt tej struktury. Staraj się jak najmniej używać zmiennych globalnych. Zawsze lepiej jest, jeśli to możliwe, wykorzystywać argumenty funkcji do przekazywania referencji do danych. Jesteśmy zdecydowanie przeciwni publicznemu udostępnianiu jakichkolwiek informacji. Zachowanie spójności danych jest o wiele trudniejsze, jeśli użytkownicy mogą zmieniać warto­ ści zmiennych wedle własnego upodobania. Egzekwowanie przestrzegania zasad dostępu uła­ twia stosowanie interfejsów funkcji, ale ta zasada bywa często łamana. Standardowe strumienie wejścia i wyjścia, takie jak stdi n i stdout, są prawie zawsze definiowane jako elementy globalnej tablicy struktur typu FI LE:

extern FILE i ob [-NFI LE] ; #defi ne stdi n- (& i ob [O] ) #defi ne stdout (g;:- i ob [l] ) #defi ne stderr ( &:=:i ob [2] )

1 13

4.5. ZASADY PROJEKTOWANIA INTERFEJSÓW

Przez to implementacja jest całkowicie widoczna. Co więcej, mimo iż stdi n, stdout i stderr wyglądają jak zmienne, nie można ich użyć w instrukcji przypisania. Dziwnie wyglądająca na­ zwa _i ob (na początku są dwa znaki podkreślenia) to konwencjonalny w standardzie ASCII C sposób zapisu prywatnych nazw, które muszą być widoczne. Dzięki temu zmniejsza się ryzyko wystąpienia konfliktu z innymi nazwami używanymi w programie. W językach C+ + i Java istnieje lepszy sposób ukrywania informacji - ukrywanie pod po­ stacią klas. W istocie klasy stanowią podstawę poprawnego korzystania z tych języków. O krok dalej posunięto się przy projektowaniu klas kontenerowych w bibliotece STL języka C+ + (którą opisaliśmy w rozdziale 3.). Oprócz pewnych gwarancji dotyczących wydajności brak ja­ kichkolwiek informacji na temat implementacji, a więc twórcy bibliotek mogą używać dowol­ nych mechanizmów.

Wybierz niewielki ortogonalny zbiór podstawowych operacji. Dobrze jest, gdy interfejs udo­ stępnia dokładnie tyle funkcji, ile potrzeba, przy czym zakresy ich działania nie powinny się w zbyt dużym stopniu pokrywać. Im więcej funkcji w bibliotece, tym łatwiej się z niej korzysta, ponieważ wszystko, czego trzeba, jest pod ręką. Ale duży interfejs trudno jest napisać i trudno nim zarządzać, a poza tym sam rozmiar może utrudniać jego poznawanie. Niektóre interfejsy programistyczne (ang. application programming interface tzw. API) są wręcz tak rozbudowane, że żaden śmiertelnik nie jest w stanie opanować ich w całości. Pewne interfejsy dla samej tylko wygody umożliwiają wykonywanie niektórych czynności na wiele sposobów. Należy wystrzegać się takiego podejścia do ich projektowania. W standar­ dowej bibliotece wejścia i wyjścia języka C można znaleźć co najmniej cztery różne funkcje służące do wysyłania na wyjście pojedynczych znaków: -

char c ; putc ( c , fp) ; fputc ( c , fp) ; fpri ntf{fp , "%c " , c) ; fwri t e (&c , s i zeof (char) , 1 , fp) ; Jeśli dane mają pójść do strumienia stdout, możliwości ich wysłania jest jeszcze więcej. To wygodne dla programisty, ale niepotrzebne. Z zasady preferowane są zwięzłe interfejsy, których nie należy rozszerzać, jeśli nie ma się do tego bardzo dobrych powodów. Skup się na jednym i zrób to dobrze. Nie dodawaj nic do interfejsu tylko dlatego, że się da, i nie poprawiaj go, jeśli problemy sprawia nie on, lecz im­ plementacja. Na przykład zamiast szybkiej funkcji memcpy i bezpiecznej funkcji memmove lepiej utworzyć jedną funkcję, która jest bezpieczna i w miarę możliwości jak najszybsza.

Nie działaj w tajemnicy przed użytkownikiem. Funkcje biblioteczne nie powinny w tajemni­ cy tworzyć plików i zmiennych ani modyfikować danych globalnych. Także ze zmienianiem danych u wywołującego należy być powściągliwym. Niektóre z tych zasad łamie funkcja str­ tok. Jest czymś zaskakującym, że wstawia ona puste bajty do środka łańcucha, który otrzymuje na wejściu. Pusty wskaźnik używany przez nią do oznaczania miejsca, w którym zakończyła się poprzednia operacja, to sekretna informacja wstawiana do danych między kolejnymi wywoła­ niami funkcji. Jest to potencjalne źródło błędów, dodatkowo uniemożliwiające równoległe wy­ konywanie funkcji (zobacz ćwiczenie 4.8). Możliwość użycia jednego interfejsu nie powinna być uzależniona od dostępności innego tylko dlatego, że tak było wygodniej programiście, który go tworzył. Spraw, aby tworzony przez Ciebie interfejs był samowystarczalny, a jeśli to niemożliwe, wyraźnie napisz, jakie

1 14

4. INTERFEJSY

zewnętrzne pomoce są potrzebne. Jeżeli tego nie zrobisz, utrudnisz klientowi utrzymanie oprogra­ mowania. Doskonałym przykładem pogwałcenia tych zasad jest zmuszanie programistów języków c i c+ + do wpisywania koszmarnie długich list plików nagłówkowych w plikach źródłowych programów. Nagłówki mogą zawierać po kilka tysięcy wierszy kodu i dołączać dziesiątki innych nagłówków.

Tę samą czynność wykonuj zawsze tak samo. Bardzo ważna jest spójność i regularność dzia­ łań. Do osiągnięcia zbliżonych celów należy zawsze używać podobnych środków. Z funkcji łańcuchowych z biblioteki języka C korzysta się bardzo łatwo nawet bez dokumentacji, ponie­ waż wszystkie działają podobnie: kierunek przepływu danych jest taki sam jak w instrukcjach przypisania, czyli od lewej do prawej strony, oraz wszystkie te funkcje zwracają łańcuchy, które wytworzyły w czasie działania. Trudno natomiast w standardowej bibliotece wejścia i wyjścia języka C przewidzieć kolejność argumentów w funkcjach. W niektórych argument FI LE* wy­ stępuje jako pierwszy, a w innych jako ostatni. W pewnych funkcjach rozmiar i liczba elemen­ tów są pomieszane. Interfejs algorytmów w bibliotece STL jest bardzo spójny, dzięki czemu łatwo domyślić się, jaki jest sposób użycia nawet nieznanych funkcji. Nie mniej wartym zachodu celem jest zadbanie o tzw. spójność zewnętrzną, czyli o to, aby różne niepowiązane ze sobą funkcje działały podobnie. Na przykład w języku C funkcje do za­ rządzania pamięcią zaprojektowano później niż funkcje operujące na łańcuchach, ale pożyczo­ no od nich styl. Ze standardowych funkcji wejścia-wyjścia fread i fwri te korzystałoby się znacznie łatwiej, gdyby były one podobne do swoich pierwowzorów read i wri te. W wierszu poleceń systemu Unix przed opcjami stawia się znak minus, ale ta sama litera w różnych, nawet powiązanych ze sobą programach może oznaczać coś całkiem innego. Jeśli symbole wieloznaczne, takie jak np. * w wyrażeniu * . exe, są rozwijane przez interpre­ ter poleceń, to jest to robione zawsze tak samo. Jeżeli jednak robią to poszczególne programy, wówczas każdy z nich może to wykonywać w inny sposób. Aby skorzystać z odnośnika w prze­ glądarce internetowej, należy go kliknąć jeden raz. Natomiast aby uruchomić program lub przejść w jakieś miejsce, trzeba kliknąć dwa razy. Z tego powodu wielu użytkowników kompu­ tera klika dwukrotnie i tu, i tu. W jednych środowiskach powyższe zasady są łatwiejsze do przestrzegania niż w innych, ale one obowiązują wszędzie. Przykładowo w języku C trudno jest ukryć szczegóły implementa­ cyjne, ale dobry programista nie będzie tego wykorzystywał, gdyż stanowiłoby to pogwałcenie zasady ukrywania informacji. Kiedy nie można zmusić użyrkowników do właściwego zacho­ wania, często stosuje się różne środki zachęcające, takie jak komentarze w plikach nagłówkowych czy specjalne nazwy typu i ob. Mimo wszelkich starań nasze możliwości w zakresie doskonalenia interfejsu są ograniczone. Nawet najlepsze dzisiejsze interfejsy mogą w przyszłości zacząć sprawiać problemy, ale jeśli je dobrze zaprojektujemy, to możemy ten moment w przyszłości nieco oddalić.

4.6. Zarządzanie zasobami Jednym z największych problemów, jakie trzeba rozwiązać przy projektowaniu interfejsu dla biblioteki (albo klasy lub pakietu), jest zarządzanie zasobami będącymi własnością tej bibliote­ ki lub należącymi do biblioteki i programów z niej korzystających. Takim zasobem, który od razu przychodzi na myśl, jest pamięć - kto powinien ją przydzielać i zwalniać? Przykłady in­ nych wspólnych zasobów to otwarte pliki i stany zmiennych, których wartości są wspólnie wy­ korzystywane. Rozważane problemy można podzielić na takie kategorie, jak: inicjalizacja, utrzymywanie stanu, współdzielenie i kopiowanie oraz usuwanie.

4.6. ZARZĄDZANIE ZASOBAMI

1 15

W prototypie naszej biblioteki CSV do ustawiania wartości początkowych (wskaźników, liczników itp.) zastosowaliśmy inicjalizację statyczną. Decyzja ta spowodowała jednak pewne ograniczenia, gdyż uniemożliwia przywrócenie procedur do pierwotnego stanu, jeśli któraś z funkcji została wywołana. Alternatywnym rozwiązaniem może być utworzenie funkcji ini­ cjalizującej wszystkie wartości wewnętrzne odpowiednimi wartościami początkowymi. To po­ zwala ponownie uruchamiać procedury, ale trzeba liczyć na to, że użytkownik sam taką funkcję wywoła. W drugiej wersji programu można by wykorzystać do tego celu funkcję reset, zmie­ niając jej definicję na publiczną. w językach c+ + i Java do inicjalizacji składowych elementów danych klas używa się kon­ struktorów. Dobrze zaprojektowany konstruktor zapewnia inicjalizację wszystkich niezbędnych zmiennych składowych oraz uniemożliwia utworzenie niezainicjalizowanego obiektu. Jest możliwe tworzenie różnych konstruktorów spełniających nieco inne zadania, np. w klasie Csv można by utworzyć dwa konstruktory: pobierający na wejściu nazwę pliku i strumień wejściowy. Co z kopiami informacji zarządzanych przez bibliotekę, takimi jak wiersze i pola wejścio­ we? W programie csvgetl i ne, który napisaliśmy w języku C, umożliwiliśmy bezpośredni do­ stęp do łańcuchów wejściowych (wierszy i pól), zwracając wskaźniki na nie. Taki nieograni­ czony dostęp ma kilka wad. Użytkownik może zmienić zawartość pamięci i uszkodzić w ten sposób inne dane. Przykładowo wykonanie wyrażenia:

strcpy (csvfi el d ( l } , csvfi e l d ( 2) ) ; może się nie powieść z wielu powodów, np. jeśli pole nr 2 będzie dłuższe od pola nr l , to początek pola nr 2 może zostać skasowany. Użyrkownik biblioteki chcąc kolejny raz wywołać funkcję csvgetl i ne, musi wpierw przygotować kopię wszystkich informacji, które chce za­ chować. Po wykonaniu poniższej sekwencji instrukcji możemy otrzymać niepoprawny wskaź­ nik, jeżeli drugie wywołanie funkcji csvget l i ne spowoduje realokację bufora wiersza:

char * p ; csvgetl i ne ( fi n} ; p = csvf i el d ( l } ; csvget l i n e ( fi n } ; /* W tym miejscu wskaźnik p może być niepoprawny */

Wersja napisana w języku C + + jest bezpieczniejsza, gdyż pracuje na kopiach łańcuchów, które można modyfikować do woli. W Javie do obiektów, czyli wszystkiego, co nie jest typem podstawowym, takim jak i nt, można odwoływać się za pomocą referencji. To podejście jest bardziej wydajne niż tworzenie kopii, ale można ulec złudzeniu, że referencja jest kopią obiektu. Taki błąd przydarzył się nam w czasie pisania pierwszej wersji programu markov w Javie. Jest to nieustające źródło błędów związanych z obsługą łańcuchów w stylu języka C. W razie potrzeby można wykonać kopię łańcucha za pomocą jednej z metod klonujących. Uzupełnieniem inicjalizacji, czyli konstrukcji obiektów, jest ich finalizowanie, a więc usu­ wanie. Polega to na wykonaniu operacji porządkujących i odzyskaniu zasobów, które były używane przez niepotrzebną już jednostkę. Szczególne znaczenie ma to w przypadku pamięci. Jeśli program nie będzie jej odzyskiwał po usuniętych obiektach, to w końcu mu jej zabraknie. Z zażenowaniem obserwujemy, w jak wielu nowoczesnych programach występują tego typu niedociągnięcia. Podobne problemy dotyczą zamykania otwartych plików: jeżeli zapisujemy dane w buforze, to bufor ten kiedyś trzeba będzie opróżnić (a zajmowaną przez niego pamięć odzyskać). Standardowe funkcje języka C automatycznie opróżniają bufory, jeśli program

1 16

4. INTERFEJSY

zostanie zamknięty normalnie. W pozostałych przypadkach trzeba to zaprogramować samo­ dzielnie. Funkcja a tex i t języków C i C+ + pozwala przejąć sterowanie wykonywaniem pro­ gramu tuż przed jego zamknięciem. Programiści interfejsów mogą ją zastosować do wykonania w odpowiednim momencie procedur porządkowych.

Zwalniaj zasoby w tej samej warstwie, w której zostały alokowane. Jednym ze sposobów sprawowania kontroli nad alokacją i odzyskiwaniem zasobów jest zlecenie wykonywania obu tych czynności tej samej bibliotece, pakietowi lub interfejsowi. Innymi słowy, stan alokacji zasobu nie powinien się zmieniać w obrębie interfejsu. Nasze biblioteki CSV pobierają dane z otwar­ tych plików, a więc po zakończeniu pracy pliki te również pozostawiają otwarte. Ich zamknięcie to zadanie dla programu wywołującego bibliotekę. W języku C + + przestrzeganie tych zasad ułatwiają konstruktory i destruktory. Gdy eg­ zemplarz klasy staje się bezużyteczny albo zostaje jawnie usunięty, następuje wywołanie jego destruktora. Destruktor może opróżnić bufory, odzyskać pamięć, przywrócić początkowy stan zmiennych i wykonać wszystkie inne tego rodzaju czynności. W Javie nie ma takiego mechani­ zmu. Wprawdzie w klasie można zdefiniować metodę finalizującą, ale nie ma gwarancji, że zo­ stanie ona wykonana, nie mówiąc już o możliwości precyzyjnego wyboru momentu jej wyko­ nania. Nie można zatem mieć pewności, iż procedury porządkowe zostaną wywołane, aczkolwiek w wielu przypadkach można zakładać, że tak się stanie: Język Java bardzo ułatwia zarządzanie pamięcią poprzez swój algorytm usuwania nieużyt­ ków (ang. garbage collection). Działający program alokuje w pamięci obiekty. Mimo iż nie da się ich usunąć jawnie, system wykonawczy sprawdza, które z nich są jeszcze w użyciu, a które nie, i co jakiś czas przywraca nieużywaną pamięć do puli dostępnej pamięci. Algorytm usuwania nieużytków bywa realizowany na wiele sposobów. W niektórych im­ plementacjach rejestruje się liczbę użyć każdego obiektu, jest to tzw. licznik odniesień (ang. reference count), i jeśli liczba ta dla danego obiektu spadnie do zera, obiekt ten zostaje usunięty. Techniki tej można jawnie używać w językach C i C+ + do zarządzania wspólnymi obiektami. Inne algorytmy co pewien czas śledzą przydziały z ogólnej puli pamięci do wszystkich obiek­ tów, do których występują odniesienia. Obiekty znalezione w ten sposób są cały czas używane. Natomiast te, do których nie odwołuje się żaden inny obiekt, są nieużywane i można je usunąć. Samo istnienie automatycznego systemu usuwania nieużytków nie oznacza jednak całko­ witego wyeliminowania problemów z zarządzaniem pamięcią. Nadal konieczne jest sprawdza­ nie, czy interfejsy zwracają referencje do wspólnych obiektów, czy do ich kopii, i dotyczy to całego programu. Oprócz tego system usuwania nieużytków nie jest darmowy. Nie dość, że utrzymywanie informacji i przywracanie nieużywanej pamięci generuje dodatkowe koszty, to jeszcze nie można przewidzieć, kiedy system zostanie uruchomiony. Wszystkie te problemy są jeszcze spotęgowane w systemach wielowątkowych, takich jak wielowątkowe programy w Javie. Rozwiązaniem w tym przypadku jest pisanie programów wielowejściowych (ang. reentrant), a więc takich, które działają bez względu na liczbę równocześnie wykonywanych wątków wy­ konawczych. W kodzie wielowejściowym należy unikać zmiennych globalnych, statycznych zmiennych lokalnych i wszystkich innych rodzajów zmiennych, które mogą zostać zmodyfi­ kowane przez jeden wątek, podczas gdy są używane przez inny. Kluczem do sukcesu przy pro­ jektowaniu programu wielowątkowego jest precyzyjne odgraniczenie jego poszczególnych komponentów, tak aby ich część wspólna była realizowana wyłącznie przez dobrze zdefiniowa­ ny interfejs. Biblioteki, które wbrew zamierzeniom udostępniają zmienne do użytku, rujnują ten model (w programie wielowątkowym funkcje typu strtok byłyby katastrofą, podobnie jak wszystkie pozostałe funkcje z biblioteki języka C, przechowujące wartości w wewnętrznej sta­ tycznej pamięci). Aby zmienna mogła być używana wspólnie, musi być chroniona specjalną blokadą umożliwiającą dostęp do niej tylko jednemu wątkowi naraz. Bardzo pomocne są tu

1 17

4.7. OBSŁUGA BŁĘDÓW

klasy, gdyż stanowią one podstawę rozważań na temat modeli współużytkowania i blokowania danych. Synchroniczne metody w Javie pozwalają zablokować przez wątek całą klasę lub eg­ zemplarz klasy w celu ochronienia ich przed modyfikacją przez inny wątek. Synchronizacja bloków to technika pozwalająca ograniczyć liczbę wątków wykonujących określoną sekcję kodu do jednego. Programowanie wielowątkowe to bardzo skomplikowane zagadnienie, które jest zbyt ob­ szerne, aby je szczegółowo omówić w tej książce.

4.7. Obsługa błędów W poprzednich rozdziałach do obsługi błędów używaliśmy takich funkcji, jak epri ntf i estrdup, które przed zamknięciem programu wyświetlały stosowne komunikaty. Na przykład funkcja epri n t f zachowuje się jak wywołanie fpri ntf ( stderr, . . . ) , ale przed zamknięciem programu informuje użytkownika o zaistniałej sytuacji. Funkcja ta wykorzystuje nagłówek i funkcję biblioteczną vfpri ntf d o drukowania argumentów reprezentowanych w prototypie przez wielokropek. Przed rozpoczęciem korzystania z biblioteki stdarg trzeba ją zainicjalizo­ wać za pomocą wywołania funkcji v a_start, a po zakończeniu jej używania należy wywołać funkcję va_ end. Interfejsu tego będziemy jeszcze używać w rozdziale 9.

#i ncl ude #i ncl ude #i ncl ude I* eprintf: drukuje komunikat o błędzie i zamyka program *I

voi d epri ntf (char *fmt , . . . ) { va_l i st args ; ffl ush (stdout) ; i f (progname { ) ! = NU LL) fpri ntf(stderr. "%s : "

progname ( ) ) ;

va start (args , fmt) ; vfpri ntf(stderr, fmt , args) ; va_en d ( args) ; i f ( fmt [O] ! ' \O ' && fmt [strl en (fmt ) - 1] ' : ') fpri ntf(stderr, "%s " , strerror(errno) ) ; fpri ntf(stderr, " \ n " ) ; exi t (2 ) ; I* Standardowa wartość oznaczająca błąd wykonywania *I =

==

Jeśli zakończenie argumentu jest oznaczone dwukropkiem, funkcja endpri ntf wywołuje standardową funkcję języka C o nazwie strerror, zwracającą łańcuch zawierający wszystkie dostępne informacje systemowe o błędzie. Dodatkowo napisaliśmy jeszcze funkcję wepri ntf, która działa podobnie do epri nt f, ale nie zamyka programu po wyświetleniu komunikatu o błędzie. Interfejs udostępniający funkcje zbliżone do pri n t f ułatwia tworzenie łańcuchów możliwych do wydrukowania albo wyświetlenia w oknie dialogowym.

1 18

4. INTERFEJSY

Analogicznie funkcja es trdup próbuje utworzyć kopię łańcucha i jeśli nie zdoła tego zrobić z powodu braku pamięci, zamyka program i zgłasza (za pomocą funkcji epri n t f) komunikat o błędzie: /* estrdup: kopiuje la1icuch i informuje o ewentualnych błędach */

char *estrdup (char *s) { char * t ; t = (char *) mal l oc ( strl en ( s ) +l) ; i f (t == NULL) epri ntf( "Wykonan i e funkcj i ( \ " % . 20s\ " ) n i e powi od1o s i ę : " , s) ; strcpy ( t , s) ; · return t ;

Funkcja ema 1 1 oc zachowuje się podobnie do wywołań funkcji m a 1 1 oc: /* emalloc: alokuje pamięć i zgłasza ewentualny błąd */

voi d *emal l oc ( s i ze-t n) {

void *p; p = mal l oc (n) ; i f (p == NULL) epri ntf( "Al o kacj a %u bajtów funkcj ą mal l oc n i e powi od1a s i ę : " , n) ; return p ;

W pliku nagłówkowym eprintf.h znajdują się deklaracje następujących funkcji: /* eprintfh: funkcje opakowujące obsługi błędów */

extern extern extern extern extern extern extern

void voi d char void void char voi d

epri ntf (char * , . . . ) ; wepr i n t f ( char * , . . . ) ; *estrdup (char *) ; *emal l oc (s i ze t) ; *ereal l oc (voi d *, s i z e_t) ; *progname (voi d) ; setprogname (char *) ;

Ten nagłówek należy dołączyć do wszystkich plików, w których używane są funkcje obsłu­ gi błędów. Każdy komunikat o błędzie zawiera także nazwę programu, jeśli została ona usta­ wiona przez wywołującego. Do ustawiania nazwy służą proste w użyciu funkcje setprogname i progname, których deklaracje znajdują się w pliku nagłówkowym, a definicje w tym samym pliku źródłowym, co definicja funkcji epri ntf:

stat i c char *name

=

NULL ; /* Nazwa programu do użycia w komunikatach o błędach */

/* setprogname: ustawia zapisywaną nazwę programu */

voi d setprogname (char *str) { name = estrdup (str) ;

4.7. OBSŁUGA BŁĘDÓW

1 19

I* progname: zwraca zapisaną nazwę programu *I

char *progname (vo i d ) { return name;

Typowy sposób użycia tych funkcji:

i nt mai n ( i nt arg c , char *argv [] ) { setprogname ( "markov " ) ; f fopen ( argv [ i ] , " r " ) ; i f (f NULL) epri ntf ( " N i e można otworzye pl i ku %s : " , argv [i ] ) ; =

==

Przykładowy wynik:

markov : n i e można otworzyE pl i ku psa l m . txt : brak pl i ku l ub katal ogu Funkcje te bardzo ułatwiają nam programowanie. Nie dość że pozwalają ujednolicić obsługę błędów, to jeszcze sama dostępność tych funkcji sprawia, iż chętniej przechwytujemy błędy, zamiast je ignorować. Sam nasz projekt nie jest jednak w żadnej mierze wyjątkowy i w innych programach można zastosować odmienne podejście. Wyobraźmy sobie, że funkcje piszemy nie na własny użytek, lecz tworzymy bibliotekę do użytku przez innych programistów. Jak funkcja z takiej biblioteki powinna się zachowywać w przypadku wystąpienia błędu, którego nie da się naprawić? Napisane wcześniej przez nas funkcje po prostu wyświetlają stosowną informację i zamykają program. Takie zachowanie jest dopuszczalne w wielu programach, zwłaszcza niewielkich samodzielnych narzędziach i aplika­ cjach. W wielu przypadkach jednak zamykanie programu jest złym podejściem, gdyż unie­ możliwia innym częściom programu podjęcie prób wyjścia z trudnej sytuacji. Na przykład edy­ tor tekstu musi radzić sobie z błędami, aby móc zapisać aktualnie przetwarzany dokument. W niektórych sytuacjach procedury biblioteczne nie powinny nawet wyświetlać żadnych ko­ munikatów, ponieważ program może działać w środowisku, w którym taka wiadomość mogła­ by ingerować w wyświetlane dane albo zniknąć bez śladu. Dobrym rozwiązaniem awaryjnym w podobnych sytuacjach jest zapisywanie danych diagnostycznych w osobnym dzienniku, by można je było tam spokojnie przeanalizować.

Wykrywaj błędy na niskim, a obsługuj je na wysokim poziomie. Jest to podstawowa zasada obsługi błędów: należy je wykrywać na jak najniższym poziomie, a obsługiwać - na poziomie wysokim. W większości przypadków o sposobie obsługi błędów powinien decydować program wywołujący, a nie wywoływany. Pomocne w tym mogą być funkcje biblioteczne, jeśli będą ele­ gancko zachowywać się w momencie wystąpienia błędu. To rozumowanie doprowadziło nas do decyzji, aby zwracać wartość NULL, gdy nie ma pola, zamiast zamykać program. Podobnie funk­ cja csvgetl i ne zwraca wartość NULL bez względu na to, ile razy zostanie wywołana po napo­ tkaniu pierwszego końca pliku. Nie zawsze jest oczywiste, jaka wartość powinna być zwracana, o czym przekonaliśmy się wcześniej, rozważając, co powinna zwracać funkcja csvgetl i ne. Należy zwracać tak dużo poży­ tecznych informacji, jak to możliwe, ale w formie, w której łatwo je wykorzystać w pozostałych

1 20

4. INTERFEJSY

częściach programu. W językach C, C+ + i Java oznacza to zwracanie czegoś jako wartości funkcji oraz innych wartości poprzez argumenty referencyjne (wskaźnikowe). Działanie wielu funkcji bibliotecznych jest uzależnione od możliwości odróżniania normalnych wartości od błędów. Funkcje wejściowe, takie jak getchar, zwracają znak po otrzymaniu poprawnych da­ nych albo - w pozostałych przypadkach - jakąś wartość innego typu niż char, np. EOF dla końca pliku. Mechanizm ten nie działa, jeśli funkcja w wyniku poprawnego działania może zwracać wszystkie możliwe wartości. Przykładowo funkcja matematyczna l og może zwrócić każdą licz­ bę zmiennoprzecinkową. W standardzie IEEE opisującym liczby zmiennoprzecinkowe istnieje specjalna wartość o nazwie NaN (ang. not a number - nieliczba), która oznacza błąd i której można używać do sygnalizowania błędów. W niektórych językach programowania, takich jak Perl i Tel, dowolną liczbę wartości można zgrupować w tzw. krotce (ang. tupie). Dzięki temu „taniemu" mechanizmowi jest moż­ liwe zwracanie wartości funkcji i informacji o błędach w jednym pakiecie. W bibliotece STL języka C+ + istnieje typ danych o nazwie pai r, którego można używać w podobny sposób. Różne wyjątkowe wartości, np. koniec pliku i stan błędu, najlepiej jest w jakiś sposób roz­ dzielić, zamiast używać do ich prezentacji jednej wartości. Jeśli nie da się łatwo dokonać takie­ go rozdziału, to można zastosować rozwiązanie polegające na zwracaniu jednej wartości „wy­ jątkowej" i dodaniu funkcji dostarczającej szczegółowych informacji o ostatnim błędzie. Takie podejście zastosowano w systemie Unix i bibliotece standardowej języka C, w któ­ rych wiele wywołań systemowych i funkcji bibliotecznych zwraca wartość -1, lecz jednocześnie koduje w specjalnej zmiennej globalnej o nazwie errno informację o błędzie, który wystąpił. Funkcja strerror zwraca łańcuch odpowiadający numerowi wykrytego błędu. W naszym sys­ temie poniższy program:

#i ncl ude #i ncl ude #i ncl ude #i ncl ude



I* main: testuje zmienną errno *I

i nt mai n (vo i d ) {

doub l e f ; errno O ; I * Kasuje stan błędu *I f = l og { - 1 . 23) ; pri ntf( "%f %d %s\ n " , f , errn o , strerror(errno) ) ; return O ; =

drukuje

nanOxlOOOOOOO 33 Domai n error Najpierw trzeba skasować zawartość zmiennej errno. Jeśli później wystąpi jakiś błąd, w zmiennej tej zostanie zapisana nowa wartość różna od zera.

Używaj wyjątków tylko w szczególnych sytuacjach. W niektórych językach istnieje mecha­ nizm wyjątków (ang. exception) służący do wykrywania nietypowych sytuacji i reagowania na nie. Wyjątki pozwalają zmienić ścieżkę wykonywania programu, gdy wydarzy się coś niepożądanego.

4.8. INTERFEJSY UŻYTKOWNIKA

121

Nie należy ich używać do obsługi oczekiwanych wartości zwrotnych. Jeśli dane s ą wczytywane z pliku, to kiedyś musimy natknąć się na jego koniec. Koniec pliku należy wówczas obsłużyć przy zastosowaniu wartości zwrotnej funkcji, a nie wyjątku. W Javie można napisać:

Stri ng fname = "nazwaPl i ku " ; try { Fi l ei nputStream i n = new Fi l ei nputStream ( fname) ; i nt c ; whi l e ( (c = i n . read ( ) ) ! = - 1 ) System . out . pri n t ( (char) c) ; i n . cl os e ( ) ; catch ( Fi l eNotFoundExcepti on e) { System . er r . pri ntl n (fname + " n i e został znal ezi ony " ) ; catch ( IO Excepti on e) { System . err . pri ntl n ( " IOExcept i o n : " + e) ; e . pri ntStackTrace ( ) ;

Powyższa pętla wczytuje znaki aż do napotkania końca pliku - zdarzenie to jest sygnali­ zowane poprzez zwrócenie wartości - 1 przez funkcję read. Jeśli jednak nie powiedzie się ope­ racja otwierania pliku, następuje zgłoszenie wyjątku zamiast ustawienia strumienia wejściowego na wartość nul l , co miałoby miejsce w językach c i c + + . w końcu, jeśli w bloku try dojdzie do wykrycia jakiegoś innego rodzaju błędu wejścia-wyjścia, zostanie on również potraktowany jako wyjątek i przechwycony przez klauzulę IOExcept i on. Wyjątki są często nadużywane. Ponieważ służą do zmieniania przepływu sterowania w pro­ gramie, mogą prowadzić do powstawania zawiłych konstrukcji i zwiększają ryzyko występowa­ nia błędów. Trudności z otwarciem pliku trudno traktować jako wyjątkową sytuację. Genero­ wanie wyjątku w takich przypadkach jest naszym zdaniem grubą przesadą. Aparat wyjątków należy zachować do obsługi naprawdę nietypowych sytuacji, np. przepełnienia systemu plików czy błędów w obliczeniach na liczbach zmiennoprzecinkowych. W języku C mechanizm obsługi wyjątków można zbudować na bazie pary funkcji setjmp i l ongjmp. Jednak sposób użycia tych funkcji jest na tyle skomplikowany, że nie będziemy się tu nad nimi rozwodzić. Co z odzyskiwaniem zasobów w przypadku wystąpienia błędów? Czy biblioteka powinna próbować je odzyskać? Rzadko jest to konieczne, ale zawsze warto pozostawić informacje w nienaru­ szonym i nieszkodliwym stanie, jeśli to tylko możliwe. Nie ma wątpliwości, że należy odzyskać nieużywaną pamięć. Zmiennym, które nadal mogą być dostępne, należy przypisać jakieś sen­ sowne wartości. Częstym źródłem błędów są próby użycia wskaźnika na zwolniony fragment pamięci. Jeżeli procedury obsługi błędów będą zerować wskaźniki po zwolnieniu wskazywa­ nych przez nie zasobów, takie przypadki nie pozostaną niewykryte. Próbę rozwiązania tych problemów podjęliśmy, pisząc funkcję reset w bibliotece CSV. Ogólnie rzecz biorąc, staraj się tak zaprojektować bibliotekę, aby nadawała się do użytku nawet po wystąpieniu błędów.

4.8. Interfejsy użytkownika Do tej pory była mowa tylko o interfejsach sprzęgających różne komponenty programowe. Ist­ nieje jednak jeszcze inny ważny rodzaj interfejsu: między programem a człowiekiem, kt6ry go używa.

1 22

4. INTERFEJSY

Większość prezentowanych w tej książce przykładowych programów służy do przetwarza­ nia tekstu, a więc ich interfejsy są nieskomplikowane. Jak pamiętamy z ostatniego podroz­ działu, należy wykrywać błędy i zgłaszać fakt ich wystąpienia oraz starać się odzyskać utracone zasoby zawsze, gdy ma to sens. Informacje o błędach powinny być kompletne i zrozumiałe także poza kontekstem. Zatem zamiast drukować lakoniczne komunikaty:

wykonan i e estrdup ni eudane lepiej poinformować użytkownika, że:

markov : wywołan i e estrdup ( "Derri d a " ) n i e powi odło s i ę : brak pami ęci Dodanie informacji w taki sposób nic nas nie kosztuje, a może pomóc użytkownikowi zna­ leźć przyczynę problemu lub dostarczyć poprawne dane wejściowe. Gdy wystąpi błąd, program powinien wyświetlać informacje o właściwym sposobie użycia funkcji, jak w poniższym przykładzie: /* usage: drukuje informację o sposobie użycia i ko1iczy działanie */

voi d usage (vo i d ) { fpri ntf( stderr, " Sposób użyc i a : %s [-d] [-n ns łów] " " [-s wartoscpocz] [pl i ki . . . ] \n " , progname () ) ; exi t (2) ;

Nazwa programu wskazuje źródło komunikatu, co nabiera szczególnego znaczenia, jeśli fragment stanowi część jakiegoś dużego procesu. Gdyby został wyświetlony tylko komunikat w stylu błąd s kładni albo wykonan i e estrdup n i eudane, to użytkownik prawdopodobnie nie miałby pojęcia, skąd te informacje pochodzą. W treści komunikatów o błędach, wierszu poleceń i oknach dialogowych powinna znajdować się informacja o poprawnym formacie danych wejściowych. Zamiast pisać, że wartość parame­ tru jest za duża, podaj prawidłowy przedział wartości dla tego parametru. W miarę możliwości należy wyświetlić poprawny tekst wejściowy, np. całe polecenie wiersza poleceń z prawidłowo ustawionym parametrem. Jest to korzystne nie tylko dlatego, że podpowiada użytkownikowi, jak powinny wyglądać dane wejściowe, lecz także dlatego, iż informację taką można zapisać w pliku albo skopiować za pomocą myszy i użyć gdzieś indziej. To wskazuje na pewną wadę okien dialogowych: ich zawartość trudno pobrać do późniejszego użycia. Jednym z efektywnych sposobów tworzenia dobrych interfejsów użytkownika do odbiera­ nia danych jest zaprojektowanie specjalnego języka do ustawiania parametrów, kontrolowania tego, co się dzieje itd. Dobra notacja nie tylko ułatwia korzystanie z programu, lecz także po­ maga utrzymać porządek w implementacji. Temat tworzenia interfejsów w oparciu o języki pro­ gramowania omawiamy w rozdziale 9. Programowanie defensywne (ang. defensive programming), czyli pisanie programów odpor­ nych na niepoprawne dane wejściowe, jest ważną techniką, gdyż chroni użytkowników przed nimi samymi oraz stanowi aparat zabezpieczający. Więcej na ten temat piszemy w rozdziale 6. poświęconym testowaniu programów. Dla większości ludzi interfejs graficzny to naturalny interfejs ich komputera. Ponieważ programowanie graficznych interfejsów użytkownika to niezwykle obszerna dziedzina, ograni­ czymy się do zwięzłego przedstawienia tylko kilku kwestii, które są istotne z naszego punktu widzenia. Po pierwsze trudno się tworzy dobre interfejsy, gdyż ich powodzenie i przydatność

LEKTURA UZUPEŁNIAJĄCA

1 23

zależą od zachowań i oczekiwań ludzi. Po drugie w systemach wyposażonych w graficzny in­ terfejs użytkownika zazwyczaj więcej jest kodu obsługującego interakcje z użytkownikiem niż realizującego algorytmy. Niemniej jednak zarówno zewnętrzny projekt, jak i wewnętrzna implementacja interfejsu użytkownika podlegają tym samym zasadom. Z punktu widzenia użytkownika łatwy w użyciu interfejs to taki, który utworzono przy zachowaniu zasad dobrego stylu, a więc prosty, klarowny, regularny, jednolity, znany i odpowiednio ograniczony. Niestosowanie się do tych wytycznych podczas tworzenia interfejsu często prowadzi do powstania niezgrabnych i odpychających efektów. Należy dbać o jednolitość i regularność, w tym także o spójne stosowanie określeń, jedno­ stek, formatów, układów, krojów pisma, kolorów, rozmiarów i wszystkich innych opcji udo­ stępnianych przez graficzny interfejs użytkownika. Ile jest słów w języku angielskim, których można użyć do zamknięcia programu albo okna dialogowego? Jest ich cała masa, od Abandon do control-Z. Taka różnorodność sprawia problemy nawet rodzimym użytkownikom języka an­ gielskiego, nie mówiąc już o innych. Bardzo ważną rolę interfejsy odgrywają w programach graficznych, które zazwyczaj są bar­ dzo dużymi i skomplikowanymi systemami wykorzystującymi kompletnie inny model wej­ ściowy niż skanowanie sekwencyjnie pobieranego tekstu. Doskonałym narzędziem do tworze­ nia interfejsów użytkownika jest programowanie obiektowe, ponieważ w obiektach można zamykać wszystkie informacje o stanie i zachowaniach okien, a dziedziczenie pozwala łączyć podobieństwa w klasach bazowych i rozróżniać poszczególne rodzaje obiektów przy użyciu klas pochodnych.

Lektura uzupełniająca Mimo iż niektóre szczegóły techniczne opisane w książce Mityczny osobomiesiąc Fredericka P. Brooksa (WNT, 2000, wyd. oryg. Addison-Wesley, 1975) są już przestarzałe, książka ta jest cu­ downą lekturą, a przedstawione w niej spostrzeżenia na temat programowania do dziś nie stra­ ciły aktualności. W prawie każdej książce poświęconej programowaniu można znaleźć cenne informacje na temat programowania interfejsów użytkownika. Jedną z takich książek jest Large-Scale C+ + Software Design Johna Lakosa (Addison-Wesley, 1996), w której autor dzieli się swoją prak­ tyczną wiedzą na temat budowy bardzo dużych programów przy użyciu języka c+ + i zarzą­ dzania nimi. Dobrym źródłem wiedzy dla programistów języka C jest książka Davida Hansona pt. C Interfaces and Implementations (Addison-Wesley, 1997). W książce Rapid Development Steve'a McConnella (Microsoft Press, 1996) znajdziemy zna­ komity opis tworzenia oprogramowania w zespołach ze szczególnym naciskiem na rolę proto­ typów w tym procesie. Jest kilka ciekawych książek o programowaniu interfejsów użytkownika, w których prezen­ towane są różne sposoby patrzenia na to zagadnienie. Polecamy następujące pozycje: Designing Visual Interfaces. Communication Oriented Techniques Kevina Mulleta i Darrella Sano (Prentice Hall, 1993), Designing the User Interface. Strategies for Ejfective Human-Computer Interaction Bena Shneidermana (wyd. 3, Addison-Wesley, 1 997), About Face. The Essentials of User Inte1face Design Alana Coopera (IDG, 1 995) oraz User Inte1face Design Harolda Thimbleby'ego (Addison­ Wesley, 1990).

1 24

4. INTERFEJSY

5

Usuwanie błędów

bug b. Usterka lub bląd w maszynie, planie itp. pach. USA. 1 1 marca 1 889 Pall Mall Gaz. 1 /1 : Powiadomiono

mnie, że pan Edison nie śpi już od dwóch dni, próbując znaleźć usterkę (ang. bug) w swoim fonografie - wyrażenie oznaczające poszukiwanie rozwiązania problemu i sugerujące, że gdzieś wewnątrz ukrył się wyimaginowany insekt, który powoduje trudności. Oxford English Dictionary, wyd. 2.

W poprzednich czterech rozdziałach przedstawiliśmy sporo przykładów kodu i za każdym razem udawaliśmy, że wszystkie one od razu prawidłowo działały. Oczywiście tak nie było - w każ­ dym z nich początkowo aż roiło się od błędów. Słowo bug mimo iż nie powstało w środowisku programistycznym, jest niewątpliwie jednym z najczęściej używanych słów w tej dziedzinie. Dlaczego tworzenie oprogramowania jest takie trudne? Jednym z powodów jest to, że na złożoność programów ma wpływ liczba interakcji wystę­ pujących między ich składnikami, a programy są pełne składników i relacji. Istnieje wiele technik służących do zmniejszania liczby powiązań między komponentami. Zalicza się do nich ukrywanie informacji, abstrakcję i interfejsy oraz właściwości języka, które służą do ich reali­ zowania. Są również techniki zapewniające integralność projektów programów - dowodzenie poprawności programów, modelowanie, analiza wymagań, formalna weryfikacja - ale żadna z nich nie zmieniła sposobu, w jaki tworzy się oprogramowanie. Wszystkie okazały się sku­ teczne tylko w rozwiązywaniu bardzo małych problemów. Rzeczywistość jest taka, że zawsze znajdą się błędy, które będziemy wykrywać za pomocą testowania i eliminować za pomocą technik usuwania błędów (ang. debugging). Dobry programista wie, że usuwanie błędów zajmuje tyle samo czasu, co pisanie kodu, i dlatego zawsze stara się wyciągać z nich wnioski. Każdy wykryty błąd jest nauką na przyszłość, jak uniknąć powtórki takiej sytuacji lub jak rozpoznać, że miała ona miejsce. Usuwanie błędów to trudna i nieprzewidywalnie czasochłonna sztuka, dlatego należy zro­ bić wszystko, aby mieć z nią jak najmniej do czynienia. Sposobów na skrócenie czasu usuwania usterek jest wiele, np. staranne opracowywanie projektu, pisanie w dobrym stylu, sprawdzanie

1 26

5. USUWANIE BŁĘDÓW

warunków brzegowych, stosowanie asercji i testów sensowności, programowanie defensywne, projektowanie dobrych interfejsów, ograniczanie ilości danych globalnych oraz korzystanie z narzędzi diagnostycznych. Profilaktyka zawsze jest lepsza od leczenia. Jaka jest rola języka? Największą siłą od zawsze kształtującą ewolucję języków programo­ wania jest chęć zapobiegania występowaniu błędów poprzez odpowiednie dobranie właściwości języka. Niektóre cechy języków programowania pozwalają wyeliminować całe grupy błędów, np. sprawdzanie zakresu w operacjach indeksowania, ograniczenie lub wręcz wyłączenie możliwości stosowania wskaźników, automatyczne odzyskiwanie pamięci, łańcuchowe typy danych, kon­ trola typów wejścia-wyjścia i rygorystyczna kontrola typów. Z drugiej strony pewne własności języków zwiększają prawdopodobieństwo powstawania błędów: instrukcje goto, zmienne globalne, nieograniczony dostęp do wskaźników i automatyczne konwersje typów. Programiści powinni wiedzieć, które właściwości języka są potencjalnie ryzykowne, i zachować szczególną ostroż­ ność przy ich używaniu. Ponadto powinni włączyć wszystkie narzędzia diagnostyczne kom­ pilatora i zwracać uwagę na zgłaszane przez niego ostrzeżenia. Właściwości językowe, które uniemożliwiają powstawanie pewnych błędów, mają swoją cenę. Jeśli język programowania wysokiego poziomu automatycznie usuwa niektóre błędy, ceną jest to, że łatwiej jest nam popełniać błędy wyższego poziomu. Żaden język nie sprawi, że całkiem przestaniemy popełniać błędy. Chociaż wolelibyśmy, aby było inaczej, każdy programista najwięcej czasu spędza na testo­ waniu kodu i usuwaniu błędów. W tym rozdziale omówimy techniki produktywnego i szyb­ kiego usuwania błędów. Do testowania wrócimy jeszcze w rozdziale 6.

5 . 1 . Programy diagnostyczne Kompilatory najważniejszych języków programowania są wyposażone w zaawansowane pro­ gramy diagnostyczne (ang. debugger). Narzędzia takie wchodzą w skład wielu zintegrowanych środowisk programistycznych oferujących w jednym pakiecie narzędzia do pisania i edytowa­ nia kodu, kompilacji oraz wykonywania utworzonych programów. Programy diagnostyczne mają graficzne interfejsy, za pomocą których można wykonywać kod programu po jednej in­ strukcji lub funkcji albo zatrzymywać wykonywanie po wykonaniu określonych wierszy lub spełnieniu zdefiniowanych warunków. Ponadto oferują możliwość formatowania i wyświetla­ nia bieżących wartości zmiennych. Program diagnostyczny można uruchomić bezpośrednio, jeśli wiadomo, że wystąpił błąd. Niektóre takie programy automatycznie przejmują sterowanie, gdy wykryją, iż coś się nie po­ wiodło w czasie wykonywania programu. Zwykle wykrycie miejsca wystąpienia błędu jest nie­ trudne. W tym celu należy tylko sprawdzić sekwencję funkcji, które były w tym czasie wykonywane (stos wywołań) oraz wyświetlić wartości zmiennych lokalnych i globalnych. Tyle informacji często wystarcza do znalezienia źródła problemu. Jeśli to zawiedzie, można skorzystać z punk­ tów wstrzymania i funkcji wykonywania programu krok po kroku, aby znaleźć miejsce, w którym po raz pierwszy wystąpiły jakieś anomalie. W rękach doświadczonego programisty korzystającego z dobrego środowiska program dia­ gnostyczny może być bardzo efektywnym i wydajnym narzędziem, które pozwala zaoszczędzić mnóstwo nerwów. Skoro dostępne są tak wspaniałe narzędzia, po co ktoś miałby usuwać błędy, nie korzystając z ich pomocy? Po co usuwaniu błędów poświęcać aż cały rozdział? Istnieje ku temu kilka dobrych powodów, zarówno obiektywnych, jak i wynikających z na­ szego osobistego doświadczenia. Dla niektórych języków spoza głównego nurtu nie ma żadne­ go programu diagnostycznego albo, jeżeli jest, jego funkcjonalność jest bardzo ograniczona.

5.2. DOBRE POMYSŁY, ŁATWE BŁĘDY

1 27

Ponadto działanie narzędzi diagnostycznych zależy od systemu operacyjnego, a więc nie zaw­ sze możesz mieć dostęp do swoich ulubionych programów tego rodzaju. Programy diagno­ styczne słabo radzą sobie z niektórymi rodzajami programów, np. wieloprocesowymi i wielowąt­ kowymi, systemami operacyjnymi i systemami rozproszonymi. W takich przypadkach konieczne jest użycie technik niższego poziomu. Programista jest wówczas zdany na siebie, do dyspozycji ma tylko instrukcje drukujące oraz własne doświadczenie i umiejętność analizowania kodu. Osobiście staramy się nie nadużywać programów diagnostycznych i ograniczamy się do sprawdzenia za ich pomocą stosu wywołań oraz wartości paru zmiennych. Jednym z powodów podjęcia takiej decyzji jest to, że można bardzo łatwo pogubić się w skomplikowanej plątaninie struktur danych i ścieżek wykonawczych. Naszym zdaniem wykonywanie kodu krok po kroku jest mniej produktywne niż jego dokładniejsze przeanalizowanie oraz dodanie kilku instrukcji wyjściowych i samosprawdzającego się kodu w krytycznych miejscach. Na przejrzenie danych zwróconych przez kilka roztropnie rozmieszczonych instrukcji drukujących potrzeba mniej czasu niż na wykonywanie kolejnych instrukcji za pomocą kliknięć myszą. Podjęcie decyzji, gdzie wstawić instrukcję drukowania, zajmuje mniej czasu niż przechodzenie do krytycznego fragmentu kodu po jednej instrukcji, nawet jeśli dokładnie wiadomo, które to miejsce. Co ważniejsze, instrukcje diagnostyczne pozostają w programie, a sesje programu diagnostycznego znikają. Szukanie błędów po omacku za pomocą programu diagnostycznego rzadko bywa produk­ tywne. O wiele lepiej jest użyć go do sprawdzenia stanu programu w chwili wystąpienia usterki i na podstawie zdobytych informacji zastanowić się, jak mogło do tej sytuacji dojść. Programy diagnostyczne bywają niezwykle skomplikowane i trudne do opanowania. Zwłaszcza począt­ kujący programista może mieć z nich sto pociech i tysiąc utrapień. Jeśli programowi diagno­ stycznemu zada się niewłaściwe pytanie, to zwykle zwróci on odpowiedź, ale nie wiadomo, czy poprawną. Mimo to program diagnostyczny może być niezwykle pomocny i każdy programista powinien mieć go pod ręką. W wielu przypadkach jest to pierwsze narzędzie, z którego pomocy się ko­ rzysta. Jeśli jednak nie masz programu diagnostycznego albo napotkasz wyjątkowo trudny do rozwiązania problem, dzięki technikom opisanym w tym rozdziale i tak szybko wyjdziesz z opresji. Ponadto nauczysz się dzięki nim efektywniej korzystać z programów diagnostycznych, gdyż dotyczą tego, jak analizować błędy i szukać ich prawdopodobnych przyczyn.

5 .2. Dobre pomysły, łatwe błędy Oho! Coś jest nie tak. Mój program padł, wydrukował bzdury albo nie chce przestać działać. Co robić? Początkujący programiści w takich sytuacjach najczęściej zrzucają winę na kompilator, bi­ bliotekę i wszystko, tylko nie ich kod. Doświadczeni programiści też by tak chcieli, ale będąc realistami, doskonale wiedzą, że większość błędów powstaje wyłącznie z ich winy. Na szczęście głównie robimy proste błędy, które można wyeliminować prostymi technikami. Przeanalizuj zwrócone przez program błędne dane i spróbuj wywnioskować, w jaki sposób mogły powstać. Przejrzyj dane diagnostyczne wyprodukowane przed wystąpieniem awarii. Jeśli masz taką możliwość, sprawdź stos wywołań. Po wykonaniu tych czynności będziesz już mieć jakieś pojęcie na temat tego, co i gdzie się stało. Przemyśl to. Jak mogło do tego dojść? Przeanalizuj zachowanie programu od początku i zastanów się, co mogło spowodować jego wadliwe działanie. Diagnostyka błędów wymaga analizowania w myślach przeszłości, podobnie jak wykrywa­ nie sprawców morderstw. Zdarzyło się coś niemożliwego, a jedyna informacja, jaką posiadamy,

1 28

5. USUWANIE BŁĘDÓW

to fakt, że rzeczywiście miało to miejsce. Aby odkryć przyczynę problemów, musimy się cofnąć w czasie. Po znalezieniu pełnego wyjaśnienia będziemy wiedzieć, jak naprawić program, a przy okazji prawdopodobnie odkryjemy jeszcze kilka innych rzeczy, których się nie spodziewaliśmy.

Szukaj znajomych wzorców. Odpowiedz sobie na pytanie, czy już coś takiego widziałeś. Od­ powiedź typu „Gdzieś już to widziałem" zwykle stanowi pierwszy krok do zrozumienia, a nie­ jednokrotnie oznacza nawet rozwiązanie. Często występujące błędy mają pewne cechy szcze­ gólne. Przykładowo początkujący programiści często piszą tak: i nt n ; scanf ( " %d " , n) ; zamiast tak:

i nt n ; scanf ( "%d " , &n) ; co zwykle kończy się próbą odczytu danych z miejsca poza wyznaczonym obszarem pamię­ ci przy pobieraniu wiersza danych wejściowych. Wykładowcy języka C natychmiast rozpoznają ten problem. Niewyczerpanym źródłem prostych błędów są źle dobrane typy danych i ich konwersje w funkcjach pri n t f i scanf:

i nt n 1; doub l e d PI; pri ntf( "%d %f\n " , d , n) ; ;

;

Znakiem szczególnym tego rodzaju błędu jest czasami pojawienie się niedorzecznych war­ tości: wielkich liczb całkowitych albo niewiarygodnie małych lub dużych wartości zmienno­ przecinkowych. Powyższy program uruchomiony na komputerze SPARC firmy Sun zwrócił następującą astronomiczną liczbę (z konieczności podzieloną na kilka wierszy):

1074340347 268156158598852001534108794260233396350\ 19365859717932180477 14963795307788611480564140\ 079682 1289594743537151 163524101175474084764156\ 4227714083238396234301 44 . 000000 Kolejny pospolity błąd dotyczy wczytywania liczb typu doub 1 e za pomocą funkcji scanf przy użyciu ciągu %f zamiast %l f. Niektóre kompilatory wyłapują takie błędy, ponieważ sprawdzają zgodność typów argumentów funkcji scanf i pri n t f z łańcuchami formatu. Przy włączonych wszystkich ostrzeżeniach kompilator gcc w systemie GNU dla powyższego wywo­ łania funkcji pri n t f zwróci następujące informacje:

x.c:9: x.c:9:

warn i ng : warni ng :

i nt format , doub l e arg (arg 2) doubl e format , di fferent type arg

(arg

3)

Kolejny rodzaj błędu, który łatwo rozpoznać po znakach szczególnych, to brak inicjalizacji zmiennej lokalnej. Wynikiem tego zaniedbania jest zwykle niesłychanie duża wartość, będąca pozostałością po tym, co uprzednio znajdowało się w tym miejscu w pamięci. Niektóre kompi­ latory mogą przestrzegać przed takimi błędami, aczkolwiek do tego konieczne może być włą-

5.2. DOBRE POMYSŁY, ŁATWE BŁĘDY

1 29

czenie opcji sprawdzania podczas kompilacji, a poza tym - żaden kompilator nie wychwyci wszystkiego. Także pamięć alokowana za pomocą takich funkcji, jak ma 1 1 oc, rea 1 1 oc i new, może być bezużyteczna, jeśli nie zostanie zainicjalizowana.

Przeanalizuj ostatnią zmianę. Jakie zmiany w programie zostały ostatnio wprowadzone? Jeśli rozwijając program, za każdym razem dodajesz do niego tylko jedną rzecz, to są wyłącznie dwie możliwości: nowy kod spowodował wystąpienie błędu albo ujawnił błąd w starym kodzie. W znalezieniu problemu pomocne jest dokładne przejrzenie ostatnich zmian. Jeśli błąd wystę­ puje w nowej wersji programu, a nie ma go w starszej, to nowy kod jest częścią problemu. Dla­ tego trzeba zawsze zachowywać przynajmniej poprzednią wersję programu, aby w razie kłopo­ tów móc porównać zachowanie z najnowszą wersją. Ponadto należy prowadzić rejestr wprowadzanych zmian i naprawianych błędów, by nie musieć zdobywać tych informacji na nowo, gdy trzeba będzie naprawić kolejny błąd. Pomocne są w tym systemy kontroli kodu źró­ dłowego i inne techniki śledzenia historii zmian.

Nie popełniaj dwukrotnie tego samego błędu. Gdy naprawisz jakiś błąd, zastanów się, czy nie mógł on wystąpić jeszcze gdzieś indziej. Taka sytuacja przydarzyła się jednemu z nas krótko przed rozpoczęciem pisania tego rozdziału. Miało to miejsce w prostym, pisanym dla kolegi prototypie przedstawiającym schemat obsługi opcjonalnych argumentów: for (i = l ; i < argc ; i ++) i f (argv [ i ] [O] ! = ' ' ) l* Koniec opcji *I brea k ; swi tch (arg v [ i ] [l] ) { case ' o ' : /* Nazwapliku wyjściowego */ outname = argv [ i ] ; brea k ; case ' f ' : from = atoi (argv [ i ] ) ; brea k ; case ' t ' : to = atoi (argv [ i ] ) ; brea k ; -

Niedługo p o wypróbowaniu programu kolega poinformował nas, ż e d o nazwy pliku zawsze dołączany był przedrostek -o. Było nam wstyd, ale błąd okazał się łatwy do naprawienia. Po­ prawiliśmy jedną instrukcję: outname = &argv [ i ] [2] ; Po naprawieniu tego błędu i odesłaniu programu do użytkownika niebawem przyszła ko­ lejna wiadomość. Tym razem program niepoprawnie obsługiwał argumenty typu - f 1 2 3 : po konwersji wartość liczbowa zawsze wynosiła zero. To ten sam błąd, co wcześniej. Poprawiliśmy zatem następną klauzulę case: from = atoi ( &argv [ i ] [2] ) ; Ponieważ autor się spieszył, nie zauważył, że ten sam błąd występował jeszcze w dwóch in­ nych miejscach, przez co zanim udało się ostatecznie oczyścić program z kilku wystąpień iden­ tycznego błędu, potrzebna była jeszcze jedna wymiana doświadczeń z naszym kolegą.

1 30

5. USUWANIE BŁĘDÓW

W łatwym kodzie nietrudno popełnić błąd, ponieważ widząc znany problem, przestajemy być ostrożni. Nawet jeśli kod jest tak prosty, że mógłbyś go napisać z zamkniętymi oczami, lepiej nie zamykaj oczu podczas jego pisania.

Nie odkładaj poprawiania błędów na później. Pośpiech przy wykonywaniu pracy może mieć szkodliwe skutki także w innych sytuacjach. Nigdy nie ignoruj awarii. Zawsze od razu popraw błąd, bo może się nie powtórzyć, aż będzie za późno. Słynny stał się przykład takiego niedopa­ trzenia w misji sondy „Pathfinder" wysłanej na Marsa. Po jej pomyślnym lądowaniu na po­ wierzchni planety w lipcu 1997 roku komputery pokładowe resetowały się mniej więcej raz na dzień, co stanowiło wielką zagadkę dla inżynierów. Gdy znaleźli przyczynę problemów, zdali sobie sprawę, że mieli już z tym do czynienia. Takie zachowania komputerów zdarzały się już w fazie wstępnych testów, ale zostały zlekceważone, ponieważ inżynierowie pracowali wówczas nad czymś innym. Zostali więc zmuszeni do zajęcia się tym dopiero później, gdy maszyna znajdowała się miliony kilometrów od nich i znacznie trudniej było ją naprawić.

Sprawdzaj stos wywołań. Mimo iż programy diagnostyczne pozwalają badać programy pod­ czas działania, to najczęściej są wykorzystywane do analizowania stanu programu, który prze­ stał działać. Do najbardziej przydatnych informacji dostarczanych przez program diagnostycz­ ny należy numer wiersza kodu źródłowego, w którym wystąpił problem. Cenną wskazówką są również nieprawdopodobne wartości argumentów (puste wskaźniki, bardzo duże wartości cał­ kowite, podczas gdy spodziewane są małe, ujemne wartości tam, gdzie powinny być dodatnie, łańcuchy znaków nienależących do alfabetu). Oto typowy przykład z opisu algorytmów sortowania przedstawionego w rozdziale 2. Aby posortować tablicę liczb całkowitych, należy wywołać funkcję q sort, przekazując jej jako ar­ gument funkcję i cmp porównującą liczby całkowite: i nt arr[N] ; qsort (arr, N , s i zeof(arr [O] ) , i cmp) ; Załóżmy, że pomyłkowo podano nazwę scmp funkcji porównującej łańcuchy: i nt arr[N] ; qsort (arr, N , s i zeof(arr [O] ) , scmp) ; Jako że kompilator w tym przypadku nie może wykryć niezgodności typów, nieuchronnie napytaliśmy sobie biedy. Program ulega awarii spowodowanej próbą dostępu do niedozwolo­ nego miejsca w pamięci. Program diagnostyczny dbx zwraca następujące informacje o stosie wywołań (przeredagowane, aby zmieściły się na stronie): O 1 2 3 4 5

strcmp(Oxl a2 , Oxl c2) [ " strcmp . s " : 3 1] scmp (pl = Ox10001048 , p2 Ox1000105c) [ " badqs . c " : 13] qst (Ox10001048, Ox10001074, Ox400b20 , Ox4) [ "qsort . c " : 147] qsort (Ox10001048 , Oxl c2 , Ox4 , Ox400b20) [ "qsort . c " : 63] mai n () [ " badqs . c " : 45] _i start ( ) [ " crtlti n i t . s " : l3] =

Z tych danych wynika, że awaria nastąpiła w funkcji strcmp. Widać, że przekazywane do niej dwa wskaźniki są o wiele za małe, co niewątpliwie jest oznaką kłopotów. W stosie wywołań zostały podane orientacyjne numery wierszy, w których nastąpiło wywołanie każdej funkcji. Wiersz nr 13 w naszym pliku badqs.c zawiera takie wywołanie:

5.3. BRAK POMYSŁÓW, TRUDNE BŁĘDY

131

return strcmp ( v l , v2) ; wskazujące na źródło błędu. Przy użyciu programu diagnostycznego można również wyświetlić wartości zmiennych lo­ kalnych i globalnych, które także mogą naprowadzić nas na jakiś trop. Najpierw przeczytaj, a potem poprawiaj. Jedną z najbardziej niedocenianych efektywnych technik wykrywania błędów jest uważne przeczytanie kodu i zastanowienie się nad nim bez do­ konywania jakichkolwiek zmian. Pokusa, aby chwycić za klawiaturę i zacząć wprowadzać zmiany, jest bardzo duża, ale należy się jej oprzeć. Istnieje duże ryzyko, że w ten sposób nie dowiesz się, co tak naprawdę szwankuje, i zmienisz nie to, co trzeba, pogarszając jeszcze tylko sytuację. Za­ pisanie najważniejszej części programu na papierze pozwala spojrzeć na niego z nieco innej perspektywy, niż oglądając go na ekranie, i zachęca do refleksji. Nie stosuj jednak tej techniki rutynowo. Drukowanie kodu programu to marnotrawstwo drzew, a poza tym i tak trudno ogarnąć całą strukturę kodu, jeśli zajmuje on kilka stron. Co więcej, po wprowadzeniu pierw­ szej zmiany cały wydruk nadaje się do wyrzucenia. Zrób sobie krótką przerwę. Czasami w kodzie widzisz to, co chciałbyś widzieć, a nie to, co jest w nim rzeczywiście zapisane. Jeśli na chwilę się oderwiesz, to po powrocie może zaczniesz więcej uwagi zwracać na prawdziwe znaczenie kodu. Oprzyj się pokusie poprawiania kodu natychmiast. Warto chwilę się przed tym zastanowić.

Objaśnij swój kod komuś innemu. Dobrym sposobem jest objaśnienie napisanego przez siebie kodu innej osobie. Zdarza się, że w ten sposób sami odkrywamy sedno problemu. Czasami wy­ starczy tylko powiedzieć kilka zdań, aby stwierdzić ze wstydem: „Nieważne, już wiem, co jest nie tak. Przepraszam, że Ci przeszkadzam". To niezwykle skuteczna metoda. W rolę słuchacza może się wcielić nawet osoba niebędąca programistą. W pewnym uniwersyteckim ośrodku komputerowym przy stanowisku pracy pomocy technicznej umieszczono pluszowego misia. Studenci chcący uzyskać pomoc najpierw musieli swój problem objaśnić misiowi i dopiero po­ tem mogli porozmawiać z człowiekiem.

5 .3 . Brak pomysłów, trudne błędy „Nie mam zielonego pojęcia, o co może chodzić". Jeśli kompletnie nie wiesz, w czym może tkwić problem, to zaczynają się schody.

Wymuś powtarzalność błędu. Pierwszą czynnością, którą należy wykonać, jest sprawienie, aby błąd pojawiał się na żądanie. Tropienie błędu pojawiającego się tylko raz na jakiś czas nie jest przyjemne. Poświęć chwilę na sporządzenie danych wejściowych i opracowanie takich pa­ rametrów, które pozwolą Ci niezawodnie spowodować wystąpienie błędu za każdym razem. Następnie zapakuj to wszystko w jeden pakiet, aby móc go przywoływać jednym przyciskiem albo kilkoma klawiszami. Jeśli błąd jest trudny do wytropienia, czynności te trzeba będzie po­ wtórzyć wielokrotnie, a więc lepiej je sobie maksymalnie uprościć. Jeśli błędu nie da się odtworzyć za każdym razem, spróbuj zrozumieć dlaczego. Czy często­ tliwość jego występowania zależy od jakichś specyficznych warunków? Nawet jeżeli nie możesz wymusić pojawienia się błędu za każdym razem, warto spróbować przynajmniej skrócić czas oczekiwania na jego wystąpienie. Jeśli program może dostarczać danych diagnostycznych, skorzystaj z tej możliwości. Pro­ gramy symulacyjne, takie jak program generujący łańcuchy Markowa z rozdziału 3., powinny zawierać opcję generowania danych diagnostycznych, np. w celu sprawdzenia wartości początkowej

1 32

5. USUWANIE BŁĘDÓW

generatora liczb losowych, dzięki którym można spróbować odtworzyć uzyskane wyniki. Wiele programów zawiera takie opcje i warto je uwzględnić także w swoich programach.

Dziel i rządź. Czy dane wejściowe wywołujące awarię programu można jakoś zmniejszyć albo bardziej skoncentrować? Stwórz minimalny zestaw danych wejściowych, które powodują wy­ stępowanie błędu, aby zredukować liczbę możliwości. Jakie zmiany powodują, że błąd przestaje się pokazywać? Spróbuj wyodrębnić takie przypadki testowe, które precyzyjnie �oncentrują się na szukanym błędzie. Każdy taki przypadek powinien być zaplanowany na uzyskanie określone­ go wyniku, potwierdzającego lub wykluczającego pewną hipotezę na temat źródła problemów. Użyj algorytmu przeszukiwania binarnego. Odrzuć połowę danych wejściowych i sprawdź, czy program nadal zwraca niepoprawny wynik. Jeśli nie, wróć do poprzedniego stanu i odrzuć drugą połowę danych wejściowych, a pierwszą tym razem pozostaw. Tę samą metodę można zastosować w odniesieniu do tekstu programu. Usuń jakąś część kodu źródłowego, która Twoim zdaniem nie powinna mieć związku z występującym błędem, i sprawdź, co się stanie. Przy ma­ nipulowaniu dużymi przypadkami testowymi i dużymi ilościami kodu źródłowego programu bardzo pomocny jest edytor kodu z opcją cofania zmian, która zapewnia, że nie utracimy błędu. Przeprowadź numeryczną analizę usterek. Czasami na trop błędu można wpaść, analizując pewne liczbowe cechy usterki. Po napisaniu jednego z podrozdziałów tej książki spostrzegli­ śmy, że niektóre litery gdzieś się z niego ulotniły. To było bardzo dziwne. Ponieważ tekst zo­ stał skopiowany i wklejony do pliku z innego miejsca, doszliśmy do wniosku, że problem tkwi w funkcji kopiowania lub wklejania edytora tekstu. Ale od czego rozpocząć poszukiwanie błę­ du? Postanowiliśmy dokładniej przyjrzeć się danym i odkryliśmy, że braki znaków występują w równych odstępach w tekście. Obliczyliśmy, że odległość między dwoma kolejnymi brakami zawsze wynosiła 1 023 bajty. Taka regularność jest bardzo podejrzana. Poszukaliśmy w kodzie źródłowym edytora wartości zbliżonych do 1 024 i znaleźliśmy kilka rzeczy wartych uwagi. Jedna z nich znajdowała się w świeżo napisanym kodzie, a więc postanowiliśmy zacząć od niej. Szybko spostrzegliśmy błąd. Była to klasyczna pomyłka o jeden, która powodowała, że zerowy bajt kasował ostatni znak w buforze o rozmiarze 1 024 bajtów. Na trop błędu wpadliśmy dzięki przeanalizowaniu liczbowych właściwości związanych z uster­ ką. Ile czasu nam to zajęło? Kilka minut spędziliśmy w osłupieniu, pięć minut zajęło nam od­ krycie prawidłowości w znikaniu znaków i kolejnych pięciu minut potrzebowaliśmy na znale­ zienie i usunięcie błędu. Rozwiązanie tego problemu przy użyciu programu diagnostycznego byłoby bardzo trudne, gdyż w grę wchodziły dwa wieloprocesowe programy obsługiwane za pomocą myszy i komunikujące się ze sobą poprzez system plików.

Wyświetlaj dodatkowe informacje, aby zorientować się, jak działa program. Jeśli nie rozu­ miesz, co robi kod, to najłatwiejszym i najmniej kosztownym wydajnościowo sposobem na do­ wiedzenie się tego jest dodanie instrukcji wyświetlających różne informacje. W ten sposób można upewnić się co do słuszności swoich ocen lub zweryfikować hipotezy na temat tego, co działa źle. Jeśli np. wydaje Ci się, że niemożliwe jest dotarcie do pewnej części kodu, dodaj in­ strukcję wyświetlającą informację: „Nie można tu wejść". Jeżeli później komunikat ten zosta­ nie pokazany, przesuń wyświetlającą go instrukcję nieco wyżej, aby dowiedzieć się, w którym miejscu zaczynają się kłopoty. Analogicznie możesz też wyświetlać informację: „Udało się tu wejść" i przesuwać ją stopniowo coraz dalej, by znaleźć ostatnie miejsce, w którym nic złego się nie dzieje. Komunikaty powinny różnić się od siebie, aby za każdym razem było wiadomo, który został wyświetlony. Komunikaty powinny być zwięzłe i zawsze mieć jednakowy format, aby dawały się łatwo przeanalizować programiście lub programom pomocniczym, takim jak np. narzędzie grep słu­ żące do porównywania wzorców. Programy podobne do grep są nieocenionym wsparciem przy

5.3.

BRAK POMYSŁÓW, TRUDNE BŁĘDY

1 33

przeszukiwaniu tekstu - prostą implementację takiego narzędzia przedstawiamy w rozdziale 9. Jeśli wyświetlasz wartości zmiennych, to za każdym razem formatuj komunikat w taki sam sposób. W językach C i C+ + wskaźniki prezentuj w postaci liczb szesnastkowych przy użyciu specyfikatorów formatu %x lub %p. Dzięki temu dowiesz się, czy dwa wskaźniki mają tę samą wartość bądź są ze sobą w jakiś sposób powiązane. Naucz się odczytywać wartości wskaźników oraz rozpoznawać prawdopodobne i nieprawdopodobne wartości, np. zero, liczby ujemne, nie­ typowe wartości i małe liczby. Także znajomość formatów adresów przydaje się podczas uży­ wania programu diagnostycznego. Jeśli jest możliwość, że program zwróci bardzo dużą ilość danych, to może dane te wystar­ czy wydrukować w postaci pojedynczych liter, np. A, B itd., aby zwięźle pokazać, dokąd pro­ gram doszedł.

Pisz samosprawdzający się kod. Jeśli potrzebujesz więcej informacji, to możesz napisać wła­ sną funkcję sprawdzającą określony warunek, wyświetlającą wartości odpowiednich zmiennych i zamykającą program: /* check: sprawdza warunek, drukuje i kończy działanie */

voi d check (char *s) {

i f (varl > var2) pri ntf( "%s : varl %d var2 %d\n " , s , varl , var2) ; ffl ush ( stdout) ; /* Zapewnia wysłanie wszystkich danych na wyjście */ abort { ) ; /* Sygnalizuje nienormalne zako1iczenie działania programu */

Funkcja check wywołuje standardową funkcję języka C o nazwie abort, która przedwcze­ śnie kończy działanie programu w celu umożliwienia jego analizy w programie diagnostycznym. Oczywiście funkcję check można też zmienić w taki sposób, aby po wydrukowaniu informacji nie zamykała programu. Następnie wywołaj funkcję check wszędzie tam, gdzie tego potrzebujesz:

check ( " Przed podejrzanym kodem" ) ; /* . . . Podejrzany kod . . . */

check ( "Za podejrzanym kodem " ) ; Po naprawieniu błędu nie usuwaj funkcji check z kodu źródłowego. Umieść ją w komenta­ rzu albo wyłącz ją za pomocą opcji programu diagnostycznego, aby móc jej użyć ponownie, gdy wystąpi kolejny trudny do rozwiązania problem. Jeśli pojawią się takie problemy, zakres obowiązków funkcji można rozszerzyć np. o weryfikację i wyświetlanie struktur danych. Można nawet zastosować bardziej ogólne podejście i napisać procedurę na bieżąco sprawdzającą spójność struktur danych i innych informacji. W programach, w których wykorzystywane są skomplikowane struktury danych, warto takie funkcje napisać, zanim jeszcze pojawią się problemy, i uczynić je integralną częścią programu. Wówczas w razie kłopotów można je bez przeszkód włączyć. Nie ograniczaj się do korzystania z nich tylko pod­ czas usuwania błędów. Możesz ich używać we wszystkich fazach rozwoju programu, a jeśli nie pochłaniają zbyt dużo zasobów, to nawet warto je pozostawić włączone cały czas. W dużych programach, takich jak systemy komutacyjne w komunikacji, często znaczną część kodu stanowią podprogramy monitorujące przepływające informacje i sprzęt i zgłaszające wszelkie usterki, niekiedy nawet automatycznie je naprawiając.

1 34

5. USUWANIE BŁĘDÓW

Utwórz dziennik. Kolejnym sposobem jest utworzenie pliku dziennika, w którym będą zapi­ sywane dane diagnostyczne w ściśle określonym formacie. W razie wystąpienia awarii w pliku takim powinien znaleźć się zapis tego, co działo się tuż przed tym wydarzeniem. Serwery sie­ ciowe i inne programy działające w sieci utrzymują dzienniki, w których zapisują ogromne ilości informacji o ruchu sieciowym - na ich podstawie kontrolują siebie i swoich klientów. Poniżej przedstawiamy fragment takiego pliku pochodzącego z lokalnego systemu (tekst dopasowany do strony):

[Sun Dec 27 1 6 : 1 9 : 24 1998] HTTPd : access to /usr/l ocal /httpd/cgi -bi n/test . html fai l ed for ml . cs . bel l -l abs . com, reason : c l i ent deni ed by server (CGI non-executabl e) from htt p : //m2 . c s . bel l -l abs . com/cgi-bi n/test . pl Aby w pliku dziennika pojawiły się rekordy danych, trzeba pamiętać o zapisaniu w nim zawartości buforów wejścia i wyjścia. Funkcje wyjściowe, takie jak pri ntf, zwykle buforują swoje wyniki, aby zoptymalizować działanie operacji drukowania. Przy nienormalnym zakoń­ czeniu pracy programu informacje te mogą zostać utracone. W j_ęzyku C zapisanie wszystkich tego typu danych przed zamknięciem programu można wymusić za pomocą funkcji ffl ush. Jej odpowiednikiem w językach c+ + i Java jest funkcja fl u s h zapisująca dane ze strumieni wyj­ ściowych. Jeżeli nie przeszkadzają Ci dodatkowe koszty wydajnościowe, problem możesz roz­ wiązać raz na zawsze, wyłączając buforowanie operacji zapisu danych w dzienniku. Służą do tego standardowe funkcje o nazwach setbuf i setvbuf. Wywołanie funkcji s et buf ( fp , NULL) spowoduje wyłączenie buforowania w strumieniu fp. Standardowe strumienie błędów (s tderr, cerr i System. err) mają domyślnie wyłączone buforowanie.

Rysuj obrazy. Czasami w testowaniu i usuwaniu błędów doskonałą pomocą są obrazy. Oczywi­ ście najbardziej pomagają w zrozumieniu struktur danych, o czym przekonaliśmy się w roz­ dziale 2., i w pisaniu programów graficznych, ale to nie jedyne ich zastosowania. Na wykresie punktowym lepiej widać rozkład wartości niż w kolumnach liczb. Na histogramie można ła­ twiej wychwycić anomalie w ocenach z egzaminów, losowych liczbach, rozmiarach kubełków alokowanych przez specjalne funkcje i używanych w tablicach mieszania itd. Jeśli nie rozumiesz, co dzieje się w Twoim programie, spróbuj sobie pomóc, opatrując struktury danych danymi statystycznymi, które dodatkowo przedstaw w postaci wykresu. Po­ niżej zaprezentowano wykresy sporządzone dla programu Markowa z rozdziału 3. w wersji na­ pisanej w języku C. Na oś x zostały naniesione długości łańcuchów mieszania, a na ośy - licz­ by elementów w tych łańcuchach. Jako danych wejściowych użyliśmy naszego standardowego tekstu z Księgi Psalmów (42 685 słów, 22 482 przedrostki). Pierwsze dwa wykresy zostały spo­ rządzone dla dobrych mnożników 31 i 37, a trzeci - dla koszmarnej wartości 128. W dwóch pierwszych przypadkach długość żadnego łańcucha nie przekracza 15 lub 16 elementów, a więk­ szość łańcuchów składa się z 5 i 6 elementów. W trzecim przypadku dane są bardziej rozpro­ szone, najdłuższy łańcuch ma 187 elementów i występuje bardzo dużo łańcuchów zawierają­ cych po 20 i więcej elementów.

1 35

5.4. OSTATNIA DESKA RATUNKU

5000

3000 2000 1 000 o

• •

• •• • • • • • • • •

4000 -

-· I

o

• • • •

I

I

10

20

Mnożnik 3 1

-· I

30

o

• • • • • I

--

10

.„

•

••

„.

• •• • •

• I

20

Mnożnik 37

30

I

I

o

10

•

-. .... ...„ I

20

30

Mnożnik 1 28

Korzystaj z narzędzi. Dobrze użyj narzędzi oferowanych przez swoje środowisko pracy. Na przykład program porównujący pliki, taki jak di ff, zestawia wyniki programu, którego wyko­ nywanie zakończyło się powodzeniem, i takiego, którego wykonywanie zakończyło się niepo­ wodzeniem, dzięki czemu można przeanalizować różnice. Jeśli program diagnostyczny zwraca duże ilości danych, to przeszukuj je za pomocą takiego programu jak grep oraz analizuj przy użyciu edytora. Wstrzymaj się od drukowania na papierze danych diagnostycznych: kompute­ ry lepiej radzą sobie z analizą dużych ilości danych niż ludzie. Użyj skryptów powłoki, aby zautomatyzować proces przetwarzania danych diagnostycznych. Pisz proste programy do weryfikacji hipotez i swojego zrozumienia sposobu działania kodu. Czy można np. zwolnić pusty wskaźnik? i nt mai n (vo i d) { free (NULL) ; return O ;

Programy do kontroli kodu źródłowego, takie jak RCS, umożliwiają rejestrację kolejnych wersji programu, dzięki czemu można sprawdzić, jakie zmiany zostały wprowadzone, i w razie potrzeby przywrócić jedną ze starszych wersji. Oprócz funkcji podglądu najnowszych zmian programy te oferują również możliwość znalezienia najczęściej modyfikowanych fragmentów kodu. W tych miejscach często kryją się rozmaite błędy.

Pisz dokumentację. Jeśli poszukiwania źródła problemów będą się przeciągać, po pewnym czasie zapomnisz, co już zostało sprawdzone, a czego jeszcze nie wiesz. Jeżeli zaczniesz zapisy­ wać wykonane testy i ich wyniki, to będziesz mieć pewność, że niczego nie przeoczysz. Notując informacje o problemie, lepiej zapamiętasz, że kiedyś już coś podobnego widziałeś, a przy oka­ zji będziesz mieć pomoc, gdy zechcesz objaśnić problem komuś innemu.

5 .4. Ostatnia deska ratunku Co robić, jeśli żadna z wymienionych technik nie pomaga? Teraz może nadeszła pora na wy­ konanie programu krok po kroku w programie diagnostycznym. Jeśli masz kompletnie błędne wyobrażenie o tym, jak coś działa, przez co szukasz problemu w niewłaściwym miejscu albo szukasz tam, gdzie trzeba, lecz go nie widzisz, program diagnostyczny może zmusić Cię do

1 36

5. USUWANIE BŁĘDÓW

spojrzenia na sprawy z innej perspektywy. Błędy niedające się wykryć z powodu niewłaściwego rozumienia istoty problemu są najgorsze. W takich przypadkach mechaniczna pomoc jest bez­ cenna. Czasami błędne przekonanie dotyczy bardzo prostych zagadnień, są to np.: niepoprawna kolejność wykonywania operatorów, użycie niewłaściwego operatora, wcięcia kodu niezgodne z jego strukturą czy błędy zakresu dostępności zmiennych polegające na tym, że zmienna lo­ kalna zasłania zmienną globalną albo zmienna globalna wcina się w zakres lokalny. Programi­ ści często zapominają przykładowo o tym, że operatory & i I stoją dalej w kolejce do wykonania niż operatory == i ! =. Dlatego zdarza im się pisać taki kod: ?

if (x & 1

==

O)

i nie mogą zrozumieć, dlaczego ten warunek nigdy nie jest spełniony. Czasami poślizgnie się palec i omyłkowo zamiast jednego znaku równości napiszą się dwa albo odwrotnie:

wh i l e ( ( c getchar ( ) ) ! i f (c ' \n ' ) break ; ==

=

EOF)

=

Albo podczas pracy nad programem nie zostanie usunięty niepotrzebny kod:

for (i = O; i < n ; i ++) ; a [i ++] = O ; Niektóre problemy wynikają z pośpiechu:

swi tch (c) { case l < I : made = LES S ; break ; ' case > ' : made GREATER; break ; defua l t : made = EQUAL; break ; =

?

Czasami wpisanie argumentów w niepoprawnej kolejności powoduje błąd, którego nie można wykryć przez mechanizm sprawdzania typów, np.:

memset ( p , n , O) ; l* Zapisuje n zer wp */ zamiast

memset (p , O , n ) ;

/* Zapisuje n zer w p */

Czasami coś zostaje zmienione bez wiedzy programisty, np. nie wiemy, że jakaś procedura może zmieniać pewne globalne lub współużytkowane zmienne.

5.4. OSTATNIA DESKA RATUNKU

1 37

Nieraz użyty algorytm lub struktura danych zawierają fatalny błąd, którego po prostu nie dostrzegamy. Przygotowując materiały do omówienia list powiązanych, sporządziliśmy pakiet funkcji służących do tworzenia nowych elementów listy oraz dołączania ich na początku i koń­ cu struktury danych itp. (funkcje te można obejrzeć w rozdziale 2.). Oczywiście sprawdziliśmy, czy wszystko jest w porządku za pomocą specjalnie napisanego w tym celu programu testowego. Kilka pierwszych testów zostało zakończonych pomyślnie, ale w pewnym momencie nastąpiła efektowna awaria. Oto kod źródłowy tamtego programu:

whi l e (scanf( "%s %d " , name , &va l ue) ! = EOF) { p newi tem (name , val ue) ; l i st l = addfront ( l i st l , p) ; l i st2 addend ( l i st 2 , p) ; 7 ? } for (p = l i st l ; p ! = NULL; p = p->next) pri ntf ( "%s %d\n " , p->name , p->va l ue) ; =

=

Aż trudno uwierzyć, ile kłopotów sprawiło nam dostrzeżenie, że pierwsza pętla umieszczała ten sam węzeł p w obu listach, przez co gdy przystępowaliśmy do drukowania, wskaźniki były beznadziejnie pomieszane. Takie błędy są trudne do wykrycia, ponieważ podświadomie widzimy to, co chcielibyśmy widzieć. Dlatego w takich przypadkach pomocny jest program diagnostyczny, który zmusza nas do zastanowienia się nad innymi możliwościami i prześledzenia rzeczywistego działania programu zamiast myślenia o tym, co on powinien robić. Czasami problem wynika z błędu w ogólnej strukturze programu. Aby wykryć coś takiego, trzeba ponownie przejrzeć swoje wstęp­ ne założenia. Zauważmy przy okazji, że w przykładzie dotyczącym list błąd znajdował się w kodzie te­ stującym, co znacznie utrudniało jego znalezienie. To straszne, jak łatwo można zmarnować czas na poszukiwaniu błędów, których nie ma, bo problem tkwi w programie testującym, albo na testowaniu niewłaściwej wersji programu tudzież ponieważ zaniedbało się aktualizację bądź kompilację programu przed wznowieniem testowania. Jeśli mimo znacznego wysiłku nie uda Ci się znaleźć błędu, to zrób sobie przerwę. Odpocznij i chwilowo zajmij się czymś innym. Porozmawiaj z kolegą i poproś go o pomoc. Rozwiązanie może pojawić się nagle, nie wiadomo skąd, a nawet jeśli nie, po powrocie do pracy nie będziesz już tkwić w tym samym zaułku. Zdarza się też, choć niezwykle rzadko, że źródłem problemów jest kompilator, biblioteka, system operacyjny, a nawet sprzęt. Można to podejrzewać zwłaszcza wówczas, gdy błąd wystą­ pił bezpośrednio po wprowadzeniu zmian w środowisku. Nigdy nie należy rozpoczynać szuka­ nia błędów od tych miejsc, ale po wykluczeniu wszystkich innych możliwości to może być ostatnie, co nam zostanie. Kiedyś przenosiliśmy duży program do formatowania tekstu z sys­ temu Unix do komputera PC. Kompilacja zakończyła się bez żadnych problemów, ale program działał bardzo dziwnie: opuszczał mniej więcej co drugi znak w danych wejściowych. Pierwszą naszą myślą było to, że ma to jakiś związek z używaniem 1 6-bitowych liczb całkowitych za­ miast 32-bitowych albo z kolejnością bajtów. Jednak po wydrukowaniu znaków, tak jak były przed­ stawiane pętli głównej, odkryliśmy, że błąd tkwił w standardowym pliku nagłówka ctype.h dostarczanym przez producenta kompilatora. Zawierał on implementację funkcji i s pri nt w postaci makra funkcyjnego:

#defi ne i spri nt(c) ( (c) >= 040 && (c) < 0 177) a główna pętla pobierania danych była zdefiniowana następująco:

1 38 ? whi l e (i spri nt (c

5. USUWANIE BŁĘDÓW

=

getchar () ) )

Za każdym razem, gdy na wejściu pojawiała się spacja ( o wartości ósemkowej 40, którą sto­ suje się w złym stylu zamiast zapisu ' ' ) lub znak o wyższym numerze, funkcja getchar była wywoływana po raz drugi, ponieważ makro ewaluowało swój argument dwa razy, przy czym pierwszy znak znikał bezpowrotnie. Nasz kod źródłowy może nie był szczytem elegancji warunek pętli mógłby być prostszy - ale plik nagłówkowy od dostawcy kompilatora bez naj­ mniejszych wątpliwości zawierał błąd. Przykłady tego błędu można spotkać do dziś. Poniższe makro pochodzi z wciąż używanych plików nagłówkowych innego producenta: #defi ne _i scsym(c) (i sal num(c) 1 1 ( (c) == ' ' ) ) Obfitym źródłem błędów powodujących nienormalne działanie programów są wycieki pamięci, tzn. przypadki nieodzyskania nieużywanych już fragmentów pamięci. Kolejnym jest niezamy­ kanie plików, które prowadzi do zapełnienia tablicy plików otwartych, przez co nie można otwierać następnych. Awarie programów zawierających wycieki pamięci często wyglądają bar­ dzo tajemniczo. Ponieważ do usterki dochodzi po wyczerpaniu pewnych zasobów, nie da się odtworzyć specyficznych zdarzeń. Z rzadka kłopoty sprawia sprzęt. W procesorze Pentium z 1994 roku występował błąd, któ­ ry powodował, że niektóre obliczenia na liczbach zmiennoprzecinkowych dawały złe wyniki. Ta szeroko nagłośniona usterka w projekcie urządzenia dużo firmę kosztowała, ale gdy już ją zidentyfikowano, błąd dało się powtarzać. Jeden z najdziwniejszych błędów, jakie widzieliśmy w swojej karierze, znajdował się w starym programie kalkulatora działającym w systemie dwu­ procesorowym. Czasami dla wyrażenia 0/5 zwracał wartość 0 . 5, a niekiedy drukował jakąś in­ ną wartość, typu O . 7 432, choć trzeba przyznać, że jak już to robił, to konsekwentnie. Nie dało się w żaden sposób przewidzieć, czy w danym przypadku wynik będzie poprawny, czy nie. W końcu odkryto, iż źródłem problemu jest usterka w jednostce odpowiedzialnej za obliczenia zmiennoprzecinkowe w jednym z procesorów. Ponieważ do wykonywania kalkulatora był lo­ sowo wybierany albo jeden, albo drugi procesor, raz wyniki były poprawne, a innym razem niedorzeczne. Wiele lat temu używaliśmy maszyny, której wewnętrzną temperaturę można było oszacować na podstawie liczby niepoprawnych bitów niskich w obliczeniach zmiennoprzecinkowych. Oblu­ zowała się jedna z kart układu elektronicznego i w miarę jak rosła temperatura, karta ta od­ chylała się coraz bardziej, co powodowało, że więcej bitów zostawało odciętych od płyty mon­ tażowej.

5 . 5 . Błędy niepowtarzalne Najtrudniejsze do wytropienia są te błędy, które pojawiają się nieregularnie - najczęściej przyczyną ich powstawania nie jest banalne uszkodzenie sprzętu. Jednak cenną wskazówką jest już sam fakt, że tak się zachowują. Można dedukować, że prawdopodobną przyczyną błędu jest nie usterka w algorytmie, lecz raczej to, iż program korzysta z danych, które za każdym razem są inne. Sprawdź, czy wszystkie zmienne są zainicjalizowane. Możliwe, że któraś z nich otrzymuje losową wartość odpowiadającą temu, co było ostatnio zapisane w przypisywanym jej obszarze

5.5. BŁĘDY NIEPOWTARZALNE

1 39

pamięci. W językach C i C+ + najczęstszymi sprawcami są zmienne lokalne funkcji i pamięć uzyskiwana za pomocą funkcji alokujących. Wszystkim zmiennym przypisz konkretne warto­ ści. Jeśli w programie używana jest wartość początkowa generatora liczb losowych, której czę­ sto nadaje się wartość na podstawie aktualnej daty, to przypisz jej jakąś stałą wartość, np. O. Jeżeli dodanie kodu diagnostycznego powoduje zmianę zachowania lub wręcz zniknięcie błędu, to można podejrzewać nieprawidłowość przy alokacji pamięci - jakaś instrukcja zapi­ suje dane poza przydzielonym obszarem i dodanie kodu diagnostycznego wprowadza modyfi­ kację rozmieszczenia elementów w pamięci, której skutkiem jest zmiana efektu wywoływanego przez błąd. Większość funkcji wyjściowych, od pri ntf po funkcje okien dialogowych, alokuje pamięć samodzielnie, co dodatkowo zaciemnia obraz. Jeśli miejsce awarii wydaje się odległe od w�zystkiego, co mogłoby być zepsute, to najbar­ dziej prawdopodobną przyczyną problemu jest błędne zmienienie zawartości obszaru pamięci w miejscu, które jest używane dopiero później. Czasami problem dotyczy tzw. wiszącego wskaźnika, czyli omyłkowego zwrócenia przez funkcję wskaźnika na zmienną lokalną i póź­ niejszego jego użycia. Ś rodkiem profilaktycznym przed taką odroczoną katastrofą jest zwróce­ nie adresu zmiennej lokalnej:

char *msg ( i nt n, char *s} { char buf[lOO] ; spri ntf (buf, "Błąd %d : %s\ n " , n , s } ; return buf;

Zanim wskaźnik zwrócony przez funkcję msg zostanie użyty, będzie już wskazywał nic nie­ znaczące miejsce w pamięci. Musisz przydzielić pamięć za pomocą funkcji ma 1 1 oc, użyć sta­ tycznej tablicy albo zażądać, aby wywołujący dostarczył pamięć. Użycie dynamicznie alokowanej wartości już po jej zwolnieniu objawia się w podobny spo­ sób. Wspominaliśmy o tym w rozdziale 2., przy okazji omawiania funkcji freea 1 1 . Poniższy kod zawiera błąd:

for (p = l i stp ; p ! = NULL; p = p->next) free (p) ; Pamięci, która została zwolniona, nie wolno używać, ponieważ jej zawartość mogła się zmienić i nie ma pewności, że instrukcja p->next wciąż wskazuje właściwe miejsce w pamięci. W niektórych implementacjach funkcji ma 1 1 oc i free dwukrotne zwolnienie elementu po­ woduje uszkodzenie wewnętrznych struktur danych, ale nie wywołuje to żadnych kłopotów przez dłuższy czas, dopóki kolejne wywołanie nie wywróci się na tym bałaganie. Pewne funkcje alokacyjne mają opcje diagnostyczne, za pomocą których można sprawdzić spójność pola dzia­ łań przed każdym wywołaniem. Włącz je, jeśli próbujesz wytropić nieregularnie zachowujący się błąd. Jeżeli w ten sposób nic nie wskórasz, możesz napisać własną funkcję alokującą, która mogłaby sprawdzać niespójność swoich własnych zachowań albo zapisywać w dzienniku wszystkie wywołania, aby można je było później przeanalizować. Napisanie funkcji alokującej pamięć, gdy nie zależy nam bardzo na szybkości działania, jest łatwe, a więc strategię tę można wykonać, jeżeli problem jest poważny. Istnieją też świetne komercyjne narzędzia służące do sprawdzania zarządzania pamięcią oraz wykrywające błędy i wycieki pamięci. Jeśli nie masz do nich dostępu, możesz wykorzystać niektóre z ich zalet, pisząc własne funkcje ma 1 1 oc i free.

1 40

5. USUWANIE BŁĘDÓW

Jeżeli jedna osoba nie ma problemów z programem, a inna ma, to znaczy, że istnieje jakaś usterka, która ujawnia się tylko w określonych warunkach. Odpowiedzialne za to mogą być jakieś pliki wczytane przez program, prawa dostępu do plików, zmienne środowiskowe, ścieżki dostępu poleceń, ustawienia domyślne lub pliki używane podczas uruchamiania programu. Trudno cokolwiek w takich sytuacjach doradzić, ponieważ aby odtworzyć środowisko, w którytn program zawodzi, trzeba być tą drugą osobą.

Ćwiczenie 5.1. Napisz własne wersje funkcji mal l oc i free, których będzie można użyć do rozwiązywania problemów z zarządzaniem pamięcią. Jednym z rozwiązań może być sprawdza­ nie w każdym wywołaniu całej przestrzeni roboczej. Odmiennym podejściem jest zapisywanie danych diagnostycznych w dzienniku, aby mogły zostać przetworzone przez inny program. Bez względu na to, którą metodę wybierzesz, na początku i końcu każdego alokowanego bloku dodaj znaczniki, by ujawnić ewentualne przypadki przekroczenia zakresu z obu stron.

5 .6. Narzędzia diagnostyczne W znajdowaniu błędów pomocne są nie tylko programy diagno styczne. Istnieje wiele innych narzędzi, które mogą nam pomóc dotrzeć do ważnych informacji w wielkich zbiorach danych, znaleźć anomalie lub tak zmienić układ danych, aby łatwiej można było zobaczyć, co się dzieje. Wiele z nich znajduje się w standardowym wyposażeniu warsztatu. Niektóre zostały napisane w celu znalezienia konkretnego błędu lub przeanalizowania specyficznego problemu. W tym podrozdziale omówimy prosty program o nazwie stri n g s, który jest szczególnie pomocny w przeglądaniu plików składających się głównie ze znaków niedrukowalnych, a więc np. plików wykonywalnych i tajemniczych formatów binarnych używanych przez niektóre edytory tekstu. We wnętrzu często kryją się różne cenne informacje, takie jak tekst dokumen­ tu, komunikaty o błędach i nieudokumentowanych opcjach, nazwy plików i katalogów, a także nazwy funkcji, które mogły być wywołane przez program. Programu stri ngs używamy również do znajdowania tekstu w innych plikach binarnych. Wiele plików graficznych zawiera znaki ASCII opisujące program, w którym zostały utworzone, a pliki skompresowane i archiwa (np. ZIP) mogą zawierać nazwy plików. Wszystkie te infor­ macje można odkryć za pomocą programu stri ngs. W systemach uniksowych istnieje już implementacja programu stri ngs, chociaż nieco inna od tej, którą przedstawimy tutaj. Rozpoznaje ona programy na wejściu i bada tylko tekst i seg­ menty danych, ignorując tablicę symboli. Za pomocą opcji - a można ją zmusić do zbadania całego pliku. Program stri ngs pobiera tekst ASCII z plików binarnych, tak że można go później wczy­ tać lub przetworzyć przez inne programy. Jeśli znaleziony komunikat o błędzie nie ma żadnego identyfikatora, to może być trudno odgadnąć, jaki program go zgłosił, nie mówiąc już, dlacze­ go to zrobił. Wówczas może pomóc przeszukanie podejrzanych katalogów przy użyciu polece­ nia zbliżonego do zapisanego niżej :

% stri ngs * . exe * . d l l I grep ' Taj emni czy komuni kat ' Funkcja s t r i n g s wczytuje plik i drukuje wszystkie łańcuchy składające się przynajmniej z M I NLEN 6 drukowalnych znaków. =

5.6. NARZĘDZIA DIAGNOSTYCZNE

141

/* strings: pobiera znaki drukowalne ze strumienia */

voi d stri ngs (char *name, F I LE *fi n) { i nt c , i ; char buf [BUFS I Z] ; do {

/* Jeden raz dla każdego łańcucha */

for ( i = O ; (c = getc (fi n ) ) ! = EOF ; ) { i f ( ! i spri nt (c) ) b reak; buf[i ++] = c; if ( i >= BUFS I Z ) b reak; i f { i >= MINLEN) /* Drukuje, jeśli łańcuchjest wystarczająco długi */ pri ntf( "%s : % . *s\n " , name , i , buf) ; whi l e (c ! = EOF) ;

Łańcuch formatu % * s użyty w wywołaniu funkcji pri ntf pobiera długość łańcucha z na­ stępnego argumentu (i ), ponieważ łańcuch (buf) nie jest zakończony zerem. Pętla do-whi l e znajduje i drukuje każdy łańcuch, a działanie kończy, gdy napotka znak końca pliku. Dzięki temu, że na końcu funkcji znajduje się sprawdzenie końca pliku, funkcja getc oraz pętle łańcuchowe mogą mieć wspólny warunek zakończenia i jedno wywołanie funkcji pri ntf może obsługiwać koniec łańcucha, koniec pliku oraz zbyt długie łańcuchy. W standardowej pętli zewnętrznej ze sprawdzeniem warunku na początku lub pojedynczej pętli z funkcją getc i bardziej skomplikowanym kodem źródłowym konieczne by było dwu­ krotne wywołanie funkcji pri ntf. Takie rozwiązanie zastosowaliśmy na początku, ale zrobiliśmy błąd w instrukcji wywołującej funkcję pri ntf. Poprawiliśmy go w jednym miejscu, lecz zapo­ mnieliśmy o jeszcze dwóch innych („Czy popełniłem ten sam błąd jeszcze gdzieś indziej?"). Wówczas stało się jasne, że program trzeba napisać ponownie, aby było w nim mniej powtó­ rzeń kodu. Tak doszliśmy do pętli do-wh i l e. Funkcja mai n programu stri ngs wywołuje funkcję strings dla każdego pliku przekazanego jej jako argument: •

/* main: znajduje znaki drukowalne w plikach */

i nt mai n ( i nt argc, char *argv [] ) { i nt i ; F I LE *fi n ; setprogname ( " s tri ngs " ) ; i f ( argc == 1 ) epri ntf("Sposób użyci a : nazwy pl i ków" ) ; el se { for (i 1 ; i < arg c ; i ++) { i f ( (fi n = fopen (argv [i ] , " rb " ) ) == NULL) wepri ntf ( " N i e można otworzye pl i ku %s : " , argv [ i ] ) ; e l se { stri ngs (argv [i ] , f i n ) ; fclose (fi n) ; =

1 42

5. USUWANIE BŁĘDÓW

return O ;

Może się dziwisz, że funkcja s t r i ngs nie pobiera danych z e swojego standardowego stru­ mienia wejściowego, gdy nie zostaną podane żadne pliki. Początkowo to robiła. Aby wyjaśnić, dlaczego teraz tego nie robi, musimy opowiedzieć historię pewnego błędu. Oczywistym testem, za pomocą którego można sprawdzić program stri ngs, jest urucho­ mienie go na nim samym. Program działał prawidłowo w systemie Unix, ale w systemie Win­ dows 95 polecenie

C : \> stri ngs
! Th i s program cannot be run i n DOS mode ' . rdata @ . data . i data . rel oc Pierwszy wiersz wygląda jak komunikat o błędzie, przez co zmarnowaliśmy trochę czasu na dowiedzenie się, że jest to łańcuch zapisany w programie, a dane wyjściowe są poprawne, przy­ najmniej jak na razie. Czasami zdarza się, iż sesja diagnostyczna zostaje przerwana z powodu niezrozumienia źródła pochodzenia komunikatu. Ale danych wyjściowych powinno być więcej, więc gdzie się podziały? Wreszcie którejś no­ cy oświeciło mnie („Gdzieś już to widziałem!"). Jest to problem z przenośnością, o którym sze­ rzej piszemy w rozdziale 8. Pierwsza wersja programu wczytywała dane tylko ze standardowego wejścia i używała do tego celu funkcji getchar. Ale w systemie Windows funkcja ta zwraca znak końca pliku, jeśli w danych tekstowych napotka konkretny bajt (OxlA, czyli znak Ctrl+Z). To powodowało przedwczesne kończenie pracy programu. Jest to całkowicie poprawne zachowanie, ale nie tego oczekiwaliśmy, biorąc pod uwagę na­ sze doświadczenia z używania programu w systemie Unix. Rozwiązaniem jest otwarcie pliku w trybie binarnym przy użyciu trybu „rb". Ale strumień stdi n jest już otwarty i nie da się zmienić jego trybu w żaden standardowy sposób (można by było użyć funkcji takich jak fdopen i setmode, ale nie należą one do standardu języka C).W efekcie stajemy przed wyborem jednej z kilku nieprzyjemnych możliwości: zmusić użytkownika do podania nazwy pliku, dzięki czemu program będzie dobrze działał w systemie Windows, choć jest to nietypowe rozwiązanie dla systemu Unix; po cichu tworzyć niepoprawne odpowiedzi, gdy użytkownik systemu Windows usiłuje wczytać dane ze standardowego wejścia; albo zastosować kompilację warunkową, by dostosować zachowanie programu do różnych systemów, co zmniejsza jego przenośność. Zde­ cydowaliśmy się na pierwszą z wymienionych możliwości, ponieważ dzięki temu program wszędzie będzie działał tak samo.

Ćwiczenie 5.2. Program stri ngs drukuje łańcuchy zawierające przynajmniej MIN LEN znaków, co czasami powoduje zwrócenie większej ilości danych, niż potrzeba. Zmodyfikuj program stri ngs tak, aby przyjmował opcjonalny argument służący do określania minimalnej długości łańcucha.

1 43

5.7. BŁĘDY POPEŁNIONE PRZEZ INNYCH

Ćwiczenie

5.3. Napisz funkcję

vi s

kopiującą dane wejściowe na wyjście i zamieniającą bajty

niedrukowalne, takie jak znak Backspace, znaki sterujące i znaki nienależące do zestawu ASCII na symbole w formacie W przeciwieństwie do

\Xhh, przy czym hh oznacza szesnastkową reprezentację danego znaku. stri ngs funkcja v i s jest najbardziej przydatna przy analizowaniu da­

nych zawierających niewielką liczbę znaków niedrukowalnych.

Ćwiczenie

5.4. Jaki wynik zwróci funkcja

można zrobić, aby funkcja

v i s, jeśli na wejściu v i s zwracała niedwuznaczne wyniki?

otrzyma łańcuch

\XOA?

Co

Ćwiczenie 5.5. Rozszerz zakres działania funkcji, tak aby przetwarzała sekwencje plików, łamała długie wiersze w dowolnym miejscu i usuwała wszystkie niedrukowalne znaki. Jakie jeszcze inne zadania zgodne z przeznaczeniem programu mogłaby spełniać ta funkcja?

5 .7. Błędy popełnione przez innych Niewielu programistów ma przyjemność tworzyć nowy system od podstaw. Znacznie częściej używają, modyfikują, a więc i poprawiają, kod napisany przez innych programistów. Wszystko, co napisaliśmy do tej pory na temat znajdowania i eliminowania błędów, ma za­ stosowanie także do błędów popełnionych przez kogoś innego. Przed przystąpieniem do pracy konieczne jest jednak zbadanie organizacji programu oraz zrozumienie sposobu myślenia i pracy poprzednika. W pewnym bardzo dużym projekcie programistycznym użyto określenia „odkry­ cie'', stanowiącego całkiem dobrą przenośnię. Zadanie polega na odkryciu, o co chodzi w ko­ dzie, którego my nie napisaliśmy. W takich przypadkach bardzo pomocne są różne narzędzia. Używając programów do prze­ szukiwania tekstu, takich jak neratory odsyłaczy:g (ang.

g rep, można znaleźć wszystkie wystąpienia wybranej nazwy.

Ge­

cross-referencer) pozwalają zapoznać się ze strukturą programu. Wy­

kres przedstawiający wywołania funkcji jest pomocny, jeśli nie jest zbyt duży. Wykonywanie kodu po jednej instrukcji za pomocą programu diagnostycznego pozwala odkryć kolejność zda­ rzeń. Zaglądając do historii wersji programu, można dowiedzieć się, jak program rozwijał się w czasie. Częste zmiany oznaczają, że kod jest słabo zrozumiany albo podlega zmieniającym się wymaganiom, a więc może stanowić potencjalne źródło błędów. Czasami musisz szukać błędów w oprogramowaniu, za które nie odpowiadasz i którego kod źródłowy nie jest dostępny. W takich przypadkach musisz zidentyfikować i scharakteryzować błąd na tyle dobrze, aby móc go precyzyjnie omówić w raporcie i przy okazji opracować jakieś dobre „obejście" pozwalające go wyeliminować. Kiedy wyda Ci się, że znalazłeś błąd w nie swoim programie, przede wszystkim upewnij się, iż to na pewno jest błąd, aby nie marnować czasu autora i nie narazić się na utratę reputacji. Gdy znajdziesz błąd w kompilatorze, również upewnij się, że to rzeczywiście błąd kompila­ tora, a nie Twojego programu. Przykładowo w językach Ci C+ + nie określono, czy operacja bitowego przesunięcia w prawo powinna wstawiać bity zerowe (przesunięcie logiczne), czy po­ wielać bit znaku (przesunięcie arytmetyczne). Z tego powodu niektórzy początkujący progra­ miści myślą, że konstrukcje typu

? ?

i -1; pri ntf ( "%d\n " , =

» 1) ;

1 44

5. USUWANIE BŁĘDÓW

są błędne, jeśli nie zwrócą oczekiwanego wyniku. Jest to jednak kwestia przenośności, gdyż powyższy kod może różnie się zachowywać w rozmaitych systemach i nie będzie to oznaczało błędu. Sprawdź swój test w różnych systemach i upewnij się, że dobrze rozumiesz, co się dzieje. Najlepiej skontroluj też definicję języka. Sprawdź, czy błąd nie jest znany. Czy masz najnowszą wersję programu? Czy istnieje lista poprawionych błędów? Większość programów jest wydawana w wielu różnych wersjach. Jeśli znajdziesz usterkę w wersji 4.0bl , to wcale nie musi jej być w wersji 4.04b2 albo może w jej miejsce powstać nowa. W każdym razie niewielu programistów pasjonuje się poprawianiem błędów w starszych wersjach programów. Wreszcie postaw się w roli osoby, która otrzyma Twój raport. Na pewno chcesz dostarczyć właścicielowi programu jak najlepszy przypadek testowy. Nie będziesz zbyt pomocny, jeśli błąd uda Ci się ujawnić tylko przy dużych ilościach danych wejściowych, w wyszukanym śro­ dowisku albo przy zastosowaniu wielu plików pomocniczych. Postaraj się ograniczyć test do jak najmniejszego samodzielnego pakietu. Dołącz wszystkie mogące się przydać informacje, takie jak wersja programu, rodzaj użytego kompilatora, system operacyjny czy opis sprzętu. Dla błędnej wersji funkcji i spri nt z podrozdziału 5.4 moglibyśmy dostarczyć poniższy pro­ gram testowy: I* Program testowy ujawniający błąd wfunkcji isprint */

i nt mai n (voi d) { i nt c ; whi l e ( i spri nt (c = getchar () ) I I c ! = EOF) pri ntf ( " %c " , c } ; return O ;

Jako przypadek testowy może posłużyć dowolny wiersz tekstu zawierający drukowalne znaki, ponieważ na wyjściu pojawi się tylko połowa danych wejściowych: % echo 1234567890 I i spri nt_test 24680 % Najlepsze powiadomienia o błędach to takie, które do zademonstrowania błędu wymagają użycia jednego lub najwyżej dwóch wierszy danych wejściowych w świeżym systemie i zawie­ rają rozwiązanie. Wysyłaj takie powiadomienia o błędach, jakie sam chciałbyś otrzymywać.

5.8. Podsumowanie Przy odrobinie dobrych chęci usuwanie błędów może być dobrą rozrywką, jak rozwiązywanie łamigłówek. Jednak bez względu na to, czy nam się to podoba, czy nie, sztukę tę będziemy uprawiać często i regularnie. Ponieważ fajnie by było, gdyby błędy nie istniały, staramy się pi­ sać jak najlepszy kod od samego początku. W dobrze napisanym kodzie nie tylko jest mniej błędów, lecz także łatwiej je znaleźć, jeśli już się pojawią. Po zauważeniu błędu w programie należy najpierw zastanowić się, co można wywniosko­ wać z jego cech szczególnych. Skąd mógł się wziąć? Czy wygląda znajomo? Czy zmieniło się coś w programie·? Czy w danych, które spowodowały jego wystąpienie, jest coś szczególnego? Czasami wystarczy kilka dobrze dobranych przypadków testowych i kilka instrukcji drukujących.

LEKTURA UZUPEŁNIAJĄCA

1 45

Jeśli nie ma żadnych tropów, to i tak najlepiej jest zacząć od dokładnego przemyślenia sprawy i próby zawężenia liczby podejrzanych miejsc. Jedną z możliwości jest stopniowe ogra­ niczanie zbioru danych wejściowych, aby uzyskać niewielki zestaw powodujący awarię. Inną możliwością jest usuwanie po kolei fragmentów kodu źródłowego, które nie powinny mieć z tym nic wspólnego. Można do programu dodać kod sprawdzający, który włącza się dopiero po wykonaniu przez program określonej liczby działań. Wszystkie wymienione techniki to elementy ogólnej strategii „dziel i rządź", która równie dobrze sprawdza się zarówno w diagno­ zowaniu programów, jak i w polityce i działaniach wojennych. Korzystaj także z innych pomocy. Niezwykle przydatne bywa objaśnienie działania kodu komuś innemu (choćby pluszowemu misiowi). Posłuż się programem diagnostycznym do sprawdzenia zawartości stosu wywołań. Użyj któregoś z komercyjnych narzędzi do wykry­ wania wycieków pamięci, przypadków naruszenia granic tablic, podejrzanego kodu itp. Z możliwo­ ści wykonywania kodu po jednej instrukcji skorzystaj wówczas, gdy stanie się jasne, że źle ro­ zumiesz, jak działa kod. Poznaj siebie i rodzaje błędów, które popełniasz. Kiedy znajdziesz i usuniesz jakiś błąd, sprawdź, czy w innych miejscach programu nie ma jeszcze podobnych usterek. Zastanów się, co się stało, aby móc w przyszłości uniknąć powtórzenia tej sytuacji.

Lektura uzupełniająca Mnóstwo cennych informacji na temat usuwania błędów można znaleźć w książkach Steve'a Maguire'a Writing Solid Code (Microsoft Press, 1 993) i Steve'a McConella Kod doskonały (Helion, 2010).

1 46

5. USUWANIE BŁĘDÓW

6 Testowanie

W zwykłych obliczeniach, czy to wykonywanych ręcznie, czy maszynowo, sprawdza się każdy etap obliczeń, a jeśli wystąpi błąd, to się go szuka, przechodząc wstecz od miejsca, w którym został po raz pierwszy zauważony.

Norbert Wiener, Cybemetics

O testowaniu i usuwaniu błędów często mówi się jak o jednym i tym samym, ale to przecież dwie zupełnie różne rzeczy. W uproszczeniu można powiedzieć, że usuwanie błędów to czyn­ ności, które się wykonuje, gdy wiadomo, że program zawiera błąd. Natomiast testowanie to systematyczne podejmowanie prób uszkodzenia programu, który w naszym mniemaniu działa poprawnie. Edsger Dijkstra poczynił słynne spostrzeżenie, że za pomocą testów można udowodnić ist­ nienie błędów, ale nie da się dowieść ich braku. Dijkstra liczył również na to, iż można tworzyć poprawne programy, jeśli nada się im właściwą strukturę, dzięki której nie byłoby błędów i nie trzeba by przeprowadzać testów. Mimo iż jest to szczytny cel, nie da się go osiągnąć przy two­ rzeniu większych programów. Dlatego w tym rozdziale omówimy szybkie i efektywne techniki znajdowania błędów. Dobrze jest zacząć od zastanowienia się nad potencjalnymi problemami już w czasie pisa­ nia kodu. Systematyczne wykonywanie testów, zaczynając od najprostszych i stopniowo prze­ chodząc do coraz bardziej wyszukanych, zapewnia to, że program od samych podstaw działa poprawnie i taki pozostaje również w późniejszych fazach rozwoju. Automatyzacja procesu te­ stowania eliminuje potrzebę angażowania czasu programisty i zachęca do prowadzenia bardziej drobiazgowych testów. Ponadto programiści przez lata praktyki nauczyli się wielu sprytnych sztuczek. Jednym ze sposobów na uzyskanie wolnego od błędów kodu jest napisanie go za pomocą programu. Wszystkie zadania programistyczne, które są rozumiane tak dobrze, że pisanie roz­ wiązującego je kodu wydaje się czynnością mechaniczną, należy zautomatyzować. Metodę taką można często zastosować wówczas, gdy program może zostać wygenerowany na podstawie spe­ cyfikacji przy użyciu jakiegoś specjalistycznego języka. Na przykład wszyscy kompilujemy kod napisany w jednym z języków wysokiego poziomu na kod w języku symbolicznym, definiujemy

1 48

6. TESTOWANIE

wzorce tekstowe za pomocą wyrażeń regularnych, używamy formuł typu SUMA (Al : A50) do pre­ zentowania działań na wybranych zakresach komórek w arkuszach kalkulacyjnych. W takich przypadkach, jeśli generator lub translator nie zawierają błędów i specyfikacja również jest bez­ błędna, utworzony program także musi być poprawny. Szerzej na ten temat piszemy w rozdziale 9. W tym rozdziale omówimy sposoby tworzenia testów na podstawie zwięzłych specyfikacji.

6. 1 . Testuj kod podczas jego pisania Im szybciej wykryje się usterkę, tym lepiej. Jeśli będziesz systematycznie zastanawiać się nad tym, co piszesz, to wiele nieskomplikowanych właściwości programu zweryfikujesz na bieżąco. Dzięki temu przed pierwszą kompilacją kod będzie już przynajmniej raz przetestowany. Wówczas niektóre rodzaje błędów nie będą miały nawet szans powstać.

Testuj warunki brzegowe. Jedna z technik to testowanie warunków brzegowych (ang. boun­ dary condition testing). Po napisaniu każdego niewielkiego, ale mającego jakieś znaczenie frag­ mentu kodu - np. pętli albo instrukcji warunkowej - sprawdza się przykładowo, czy pętla wykonuje odpowiednią liczbę powtórzeń albo czy instrukcja warunkowa poprawnie rozgałęzia ścieżkę wykonywania programu. Nazywa się to testowaniem warunków brzegowych, ponieważ sprawdzane są naturalne granice programu i przyjmowanych przez niego danych, a więc np. brak danych lub pusty zbiór danych na wejściu, tylko jeden element informacji wejściowych, dokładnie wypełniona tablica itd. W metodzie tej wykorzystuje się spostrzeżenie, że większość błędów występuje w warunkach ekstremalnych. Jeśli program ma ulec awarii, najprawdopo­ dobniej przydarzy się to w pobliżu jakiejś granicy. Albo odwrotnie - jeżeli program poradzi sobie w warunkach brzegowych, to istnieje duże prawdopodobieństwo, że i w pozostałych sy­ tuacjach będzie działał prawidłowo. Poniższy kawałek programu, wzorowany na funkcji fgets, wczytuje znaki, aż napotka znak nowego wiersza lub zapełni bufor: i nt i ; char s [MAX] ; for (i

=

O; (s[i]

getchar ( ) ) ! = ' \n ' & & i < MAX - 1 ; ++i )

s [- - i ] = ' \O ' ; Przypuśćmy, że właśnie napisaliśmy tę pętlę. Przeprowadź w myślach eksperyment, jak wczytuje ona jeden wiersz tekstu. Pierwszy warunek brzegowy do przetestowania jest najprost­ szy: pusty wiersz. Jeśli na początek użyjemy wiersza zawierającego tylko jeden znak nowego wiersza, to spostrzeżemy, że pętla zatrzyma się po pierwszym powtórzeniu, w którym wartość i ustawi na zero, co zmniejszy i w ostatnim wierszu do - 1, a to z kolei spowoduje zapisanie bajta zerowego pod indeksem s [ - 1 ] , czyli w miejscu znajdującym się przed początkiem tablicy. Te­ stowanie warunku brzegowego zaowocowało wykryciem błędu. Gdybyśmy pętlę zapisali tak, jak konwencjonalnie zapisuje się konstrukcje napełniające ta­ blice znakami pobieranymi z wejścia, to otrzymalibyśmy taki wynik:

for (i O; i < MAX- 1 ; i ++) i f ( (s [ i ] getchar ( ) ) break ; s [i ] ' \O ' ; =

=

?

=

' \n ' )

1 49

6.1. TESTUJ KOD PODCZAS JEGO PISANIA

Powtarzając poprzedni test, bez trudu odkryjemy, że teraz wiersze zawierające tylko jeden znak nowego wiersza są obsługiwane poprawnie: i ma wartość O, pierwszy znak wejściowy po­ woduje wyjście z pętli, a znak ' \O ' zostaje zapisany pod indeksem s [OJ . Przeprowadzenie te­ stów na danych zawierających jeden znak i dwa zwykłe znaki ze znakiem nowego wiersza za nimi utwierdza nas w przekonaniu, że przy tym brzegu pętla działa poprawnie. Są jednak jeszcze inne warunki brzegowe, które trzeba zweryfikować. Ochroną programu przed bardzo długimi wierszami danych wejściowych i wierszami niezawierającymi znaku no­ wego wiersza jest warunek stwierdzający, że wartość i nie może przekroczyć wartości MAX-1. C o się jednak stanie, jeśli n a wejściu program otrzyma puste dane, tzn. funkcja getcha r już w pierwszym wywołaniu otrzyma znak końca pliku (EOF)? Musimy to sprawdzić:

?

for ( i =O ; i < MAX-1 ; i ++) i f ( (s [ i ] getchar ( ) ) brea k ; s [i ] = ' \O ' ; =

I

\n

I

11

S

[i]

EOF)

Techniką testowania warunków brzegowych można wykryć wiele błędów, ale nie wszystkie. Do tego przykładu wrócimy jeszcze w rozdziale 8., w którym wykażemy, że powyższy kod zawiera jeszcze błąd związany z przenośnością. Następnym krokiem jest przetestowanie przeciwnego brzegu danych wejściowych, tzn. przy­ padków, gdy tablica jest prawie pełna, pełna i przepełniona, zwłaszcza w momencie pojawienia się znaku nowego wiersza. Nie będziemy się szczegółowo o tym rozpisywać, ale warto wykonać takie testy w ramach ćwiczenia. Skoro mowa o warunkach brzegowych, należy zadać sobie py­ tanie, co zrobić w sytuacji, gdy bufor zostanie napełniony, zanim pojawi się znak ' \O ' . Taką lukę w specyfikacji powinno się uzupełnić jak najwcześniej, a testowanie warunków brzego­ wych ułatwia jej szybkie wykrycie. Testowanie warunków brzegowych jest skuteczną techniką wykrywania pomyłek o jeden. Przy odrobinie praktyki prowadzenie testów wchodzi człowiekowi w nawyk, dzięki czemu wiele banalnych błędów zostaje wyeliminowanych, zanim jeszcze się pojawią.

Sprawdzaj warunki wstępne i końcowe. Innym sposobem eliminowania błędów, nim się po­ jawią, jest sprawdzanie, czy przed wykonaniem (warunek wstępny) lub po wykonaniu (waru­ nek końcowy) pewnego fragmentu kodu są spełnione określone warunki. Typowym przykła­ dem sprawdzania warunku wstępnego jest upewnienie się, że wartości na wejściu mieszczą się w wyznaczonym zakresie. Poniższa funkcja obliczająca wartość średnią n elementów tablicy ma kłopoty, jeśli wartość n jest równa O lub mniejsza: doub l e avg (doub l e a [] , i nt n) { i nt i ; doub l e sum; sum = O . O ; for ( i = O ; i < n ; i ++) sum += a [i l ; return sum / n ;

Jak powinna się zachować funkcja avg, jeśli n ma wartość O ? Tablica niezawierająca ele­ mentów to też coś znaczący obiekt, ale jej średnia wartość to nonsens. Czy funkcja avg powinna zgłaszać problem dzielenia przez zero? Czy powinna zamykać program? Czy ma sygnalizować

1 50

6. TESTOWANIE

problem w stosownym komunikacie? Może powinna zwracać jakąś nieszkodliwą wartość? A co się stanie, jeśli wartość n będzie ujemna? To jest bez sensu, ale może się zdarzyć. Zgodnie z tym, co napisaliśmy w rozdziale 4., w przypadku n o wartości równej O lub mniejszej najprawdopodob­ niej zdecydowalibyśmy się na zwracanie wartości O:

return n <= O ? O.O : sum/ n ; Ale nie można tego stwierdzić definitywnie, bo jest t o zależne o d konkretnej sytuacji. Jedno jest pewne: nie należy tego problemu ignorować. W artykule zamieszczonym w „Scienti­ fic American" z listopada 1998 roku opisano zdarzenie, które miało miejsce na okręcie „York­ town" wyposażonym w wyrzutnie pocisków naprowadzanych. Jeden z członków załogi przez pomyłkę wprowadził zero, co spowodowało wykonanie dzielenia przez zero. Błąd wywołał efekt domina i doszło do wyłączenia układu napędowego jednostki. Okręt „Yorktown" był unieruchomiony przez kilka godzin tylko dlatego, że program nie sprawdzał poprawności da­ nych wejściowych.

Stosuj asercje. W nagłówku języków C i C+ + dostępny jest mechanizm znany pod nazwą asercji, który zachęca do stosowania warunków wstępnych i końcowych. Ponieważ niespełnienie warunku asercji powoduje przerwanie działania pr.o gramu, najczęściej asercje rezerwuje się do użytku w przypadkach, gdy awaria jest nieprzewidywalna i nie ma sposobu, aby wyjść z niej obronną ręką. Powyższy kod moglibyśmy wzbogacić o asercję przed pętlą: as sert (n > O) ; Jeśli warunek asercji nie będzie spełniony, to program zostanie zamknięty i wyświetli się standardowy komunikat:

Assert i on fai l eci : n > O , fi l e avgtest . c , l i ne 7 Abort (crash) Asercje są szczególnie pomocne przy sprawdzaniu poprawności właściwości interfejsów, ponieważ przyciągają uwagę do braku spójności między wywołującym a wywoływanym i mogą nawet wskazać winnego wypadku. Jeśli warunek, że n jest większe od zera, nie zostanie speł­ niony przy wywołaniu funkcji, to winnym zaistniałej sytuacji jest raczej wywołujący, a nie funkcja avg. Jeżeli interfejs zostanie zmieniony, ale zapomnimy poprawić jakąś procedurę, która z niego korzysta, do wykrycia takiego błędu możemy użyć asercji, gdyż spowoduje on poważne kłopoty.

Programuj defensywnie. Użyteczną techniką jest dodanie kodu obsługującego przypadki, któ­ re nie miały prawa się zdarzyć, czyli sytuacji, które według logiki nie powinny mieć miejsca, ale jednak przydarzyły się z powodu jakichś błędów w kodzie. Jednym z przykładów takiego programowania jest dodanie do funkcji avg testu wykrywającego zerowy i ujemny rozmiar ta­ blicy. Innym jest program przetwarzający informacje o stopniach, który może oczekiwać, że nie wystąpią ujemne ani bardzo duże wartości, ale mimo to powinien je na wszelki wypadek sprawdzać:

i f (gracie < O 1 1 gracie > 100) /* To nie może się zdarzyć *I 1 etter = ' ? ' ; el se i f (gracie >= 90)

6.1. TESTUJ KOD PODCZAS JEGO PISANIA

l etter

=

151

'A' ;

el se

Jest to przykład programowania defensywnego: zapewnienie w programie mechanizmu chroniącego go przed niepoprawnymi i niedozwolonymi wartościami. W ten sposób można wcześnie wykryć takie błędy, jak użycie pustego wskaźnika, użycie indeksu spoza dozwolonego zakresu, dzielenie przez zero itp. Programowanie defensywne (niezamierzone skojarzenie z ter­ minologią wojskową) bez trudu pozwoliłoby wykryć błąd dzielenia przez zero na krążowniku „Yorktown".

Sprawdzaj wartości zwracane przez funkcje. Sposobem obrony przed błędami, o którym często zapominamy, jest sprawdzanie, czy funkcje biblioteczne i wywołania systemowe nie zwracają informacji o błędach. Zawsze należy kontrolować, czy takie procedury pobierające dane, jak fread i scanf, nie informują o problemie. To samo dotyczy operacji otwierania plików, takich jak funkcja fopen. Jeśli operacja odczytu lub otwarcia pliku nie powiedzie się, program nie może dalej prawidłowo działać. Sprawdzając kod zwrócony przez takie funkcje wyjściowe, jak fpri ntf czy fwri te, można wykryć błędy wynikające z próby zapisu danych w pliku, gdy brakuje miejsca na dysku. Wy­ starczające może być sprawdzenie wartości zwrotnej funkcji fcl ose, która w razie wystąpienia jakiegokolwiek błędu zwraca znak końca pliku i O w pozostałych przypadkach.

fp = fopen (out fi l e , "w" ) ; /* Zapisuje dane wpliku outfile */ wh i 1 e ( . . ) fpri ntf(fp, . . . } ; i f (fc l ose (fp) == EOF) /* Jakieś błędy? */ .

/* Wystąpi/jakiś błąd wyjścia */

Błędy wyjścia mogą być bardzo poważne. Jeśli zapisywany plik jest nową wersją jakiegoś cennego pliku, to sprawdzenie zapobiegnie usunięciu starego pliku, gdy zapis w nowym się nie powiedzie. Wysiłek związany z przeprowadzaniem testów w czasie pisania kodu jest symboliczny, a korzyści z tego są bardzo duże. Myślenie o testowaniu w czasie pisania sprawia, że powstaje kod wyższej jakości, ponieważ wówczas programista najlepiej sobie uświadamia, co program powinien robić. Jeśli natomiast będziesz czekać, aż coś się zepsuje, to z pewnością zapomnisz, jak Twój kod działa. Będziesz zmuszony jeszcze raz go rozszyfrować pod presją czasu, czego skutkiem będą mniej przemyślane i mniej solidne rozwiązania, gdyż szybko odświeżone wia­ domości zwykle są niepełne.

Ćwiczenie 6.1. Przetestuj warunki graniczne poniższych programów i napraw je zgodnie z za­ sadami opisanymi w rozdziale 1. i poradami zawartymi w niniejszym rozdziale.

a) Ten program powinien obliczać silnię: i nt factori al ( i nt n) i nt fac ; fac = l ; whi l e (n--)

1 52

6 . TESTOWANIE

fac a = n ; return fac ;

b) Ten program powinien drukować znaki z podanego łańcucha, po jednym w wierszu: i = O; do { putchars ( s [ i ++] ) ; putchar ( ' \n ' ) ; whi l e ( s [i ] ! = ' \O ' ) ;

c) Ten program powinien kopiować łańcuchy ze źródła do miejsca docelowego: voi d strcpy {char *des t , char *src) { i nt i ; for ( i = O ; src [i ] ! = ' \O ' ; i ++) dest [i] = src [i ] ;

d) Również kopiowanie łańcuchów, lecz tym razem program powinien kopiować n znaków z s do t : voi d s trncpy { char * t , c h a r * s , i nt n) { whi l e (n > O && *s ! = ' \O ' ) { *t = * s ; t++ ; s++ ; n-- ;

e) Porównywanie liczb : i f {i > j ) pri ntf( "Wartosc %d j est wi ększa od %d . \n " , i , j ) ; el se pri ntf( "Wartosc %d j est mn i ej sz a od %d . \ n " , i , j ) ; t) Sprawdzanie rodzaju znaków:

i f {C >= ' A ' && c <= ' Z ' ) i f ( c <= ' L ' ) cout << " Pi erwsza połowa al fabetu" ; el se cout « " Druga połowa a l fabetu " ;

Ćwiczenie 6.2. Podczas gdy piszemy tę książkę, a jest koniec roku 1998, nad nami wisi widmo błędu roku 2000, który będzie prawdopodobnie największym problemem warunku brzegowego w historii.

6.2. SYSTEMATYCZNE TESTOWANIE

153

a) Jakich dat użyłbyś do testowania, aby dowiedzieć się, czy system nie ulegnie awarii w roku 2000? Przyjmując, że testy pochłaniają dużo zasobów, w jakiej kolejności byś je wykonywał po wypróbowaniu daty 1 stycznia 2000?

b) Jak przetestujesz standardową funkcję et i me, która zwraca łańcuchową reprezentację daty w następującej formie?

Fri Dec 31 23 : 58 : 27 EST 1999\n\O Zakładając, że Twój program zawiera wywołanie funkcji et i me, jak napiszesz kod, aby był chroniony przed jej wadliwą implementacją?

c) Jak przetestujesz program kalendarza drukujący dane w takim formacie? Styczefi 2000 Nd Pn Wt Śr Czw 1 2 3 4 5 6 9 10 11 12 13 16 17 18 19 20 23 2 4 25 26 2 7 30 31

Pt S 7 8 14 15 21 22 28 29

d) Jakie inne wartości brzegowe dotyczące czasu potrafisz wymyślić dla systemów, których używasz? Jak je przetestujesz, aby sprawdzić, czy są poprawnie obsługiwane?

6.2. Systematyczne testowanie Ważne jest, aby testy programu prowadzić systematycznie. Dzięki temu zawsze wiadomo, co jest testowane i jakich wyników można się spodziewać. Należy pilnować porządku, by niczego nie przeoczyć, i wszystko zapisywać, aby wiedzieć, ile już zostało zrobione.

Testuj stopniowo. Zestaw testów powinien być rozwijany na równi z programem. Podejście polegające na tym, że najpierw pisze się cały program, a następnie przystępuje do testowania wszystkiego naraz, jest znacznie trudniejsze do zrealizowania i zajmuje o wiele więcej czasu niż testowanie stopniowe. Napisz kawałek programu, przetestuj go, dopisz kolejny kawałek i zno­ wu wszystko przetestuj itd. Jeśli równocześnie pracujesz nad dwoma pakietami, które były rozwijane i testowane z osobna, to gdy już je w końcu połączysz, sprawdź, czy dobrze ze sobą współpracują. Na przykład w rozdziale 4. najpierw napisaliśmy tylko tyle kodu, aby program wczytywał dane. Dzięki temu mogliśmy przetestować przetwarzanie danych wejściowych. Następnym krokiem było podzielenie wierszy pobranego tekstu według przecinków. Gdy te części programu już działały, przeszliśmy do pól ujętych w cudzysłowy, a później do testowania wszystkiego razem. Zacznij od testowania najprostszych części. Podejście stopniowego testowania odnosi się również do sposobu testowania właściwości. Na pierwszy ogień przy testowaniu powinny iść najprostsze i najczęściej używane elementy programu. Dopiero po upewnieniu się, że działają one prawidłowo, można przejść dalej. Dzięki temu na każdym etapie wykonuje się bardziej do­ kładne testy i zyskuje pewność, iż podstawowe mechanizmy działają poprawnie. Proste testy

1 54

6. TESTOWANIE

pozwalają wykryć proste błędy. Każdy test stanowi wstęp do wyeliminowania kolejnych poten­ cjalnych błędów. Mimo iż każdy następny błąd trudniej jest wywołać niż poprzedni, nie znaczy to, że też trudniej go naprawić. W tym podrozdziale omówimy sposoby doboru testów, które będą skuteczne, oraz kolej­ ność ich stosowania. Natomiast w dwóch kolejnych podrozdziałach napiszemy, jak zmechani­ zować proces testowania programu, aby był on przeprowadzany jak najbardziej efektywnie. Pierwszym krokiem, przynajmniej jeśli chodzi o małe programy i pojedyncze funkcje, jest roz­ szerzenie omówionej wcześniej metody testowania warunków brzegowych: systematyczne te­ stowanie niewielkich przypadków. Przypuśćmy, że mamy funkcję przeszukującą metodą binarną tablicę liczb całkowitych. Jej testowanie powinniśmy rozpocząć od następujących testów, zaczynając od najprostszego: • przeszukanie tablicy niezawierającej żadnych elementów; • przeszukanie tablicy zawierającej jeden element przy użyciu wartości testowej, która jest • mniejsza od jedynego elementu tablicy, • równa jedynemu elementowi tablicy, • większa od jedynego elementu tablicy; • przeszukanie tablicy zawierającej dwa elementy przy użyciu dwóch wartości testowych, które • sprawdzają wszystkie pięć możliwych pozycji; • sprawdzenie zachowania przy występowaniu duplikatów elementów i wartości testowych • mniejszych niż wartość w tablicy, • równych wartości w tablicy, • większych od wartości w tablicy; • przeszukanie tablicy zawierającej trzy elementy w taki sam sposób, jak tablicy zawierającej dwa elementy; • przeszukanie tablicy zawierającej cztery elementy w taki sam sposób, jak tablic zawierających dwa i trzy elementy. Jeśli funkcja przejdzie wszystkie te testy bez szwanku, można z dużym prawdopodobieństwem sądzić, że jest w dobrym stanie, ale można też wymyślić jeszcze inne metody sprawdzenia. Ten zestaw testów jest na tyle mały, że można go wykonywać ręcznie, ale znacznie lepszym rozwiązaniem jest utworzenie ramy testowej w celu zautomatyzowania procesu. Poniżej przed­ stawiamy najprostszy program, jaki udało nam się napisać. Wczytuje on wiersze tekstu zawie­ rające klucz, który ma zostać znaleziony, i rozmiar tablicy. Następnie tworzy tablicę o poda­ nym rozmiarze, przechowującą wartości 1, 3, 5 . . Później szuka w tablicy wspomnianego klucza. .

/* 11zai11: platforma testowa dla funkcji binsearch */

i nt mai n (vo i d) { i nt i , key , nel em , arr[lOOO] ;

whi l e ( s canf ( "%d %d " , &key, &nel em) ! = EOF) { for (i = O ; i < nel em; i ++) arr[i] = 2*i + l ; printf( "%d\n " , b i nsearch { key , arr, nel em) ) ; return O ;

6.2. SYSTEMATYCZNE TESTOWANIE

155

Ten prosty przykład pokazuje, że rama testowa, aby była użyteczna, wcale nie musi być duża. Poza tym łatwo można ją rozbudować o kolejne testy, zmniejszając tym samym liczbę obowiązków programisty.

Sprawdź, jakich danych na wyjściu można się spodziewać. Aby test się powiódł, musimy wiedzieć, jaki jest poprawny wynik. Jeśli tego nie wiadomo, to marnujemy czas. Może się to wydawać oczywiste, ponieważ w wielu przypadkach nietrudno stwierdzić, czy program działa, czy nie. Na przykład kopia albo jest kopią pliku, albo nią nie jest. Wynikiem działania funkcji sortującej są posortowane dane albo nie; wynik musi też być permutacją danych wejściowych. Ale większość programów jest znacznie trudniej scharakteryzować; należą do nich: kom­ pilatory (czy wynik stanowi prawidłowe odzwierciedlenie danych wejściowych?), algorytmy numeryczne (czy wynik mieści się w granicach tolerancji?), programy graficzne (czy piksele znajdują się na właściwym miejscu?) itd. W takich przypadkach bardzo ważne jest porównanie wyniku ze znanymi wartościami. •

Aby przetestować kompilator, skompiluj i uruchom pliki testowe. Programy testowe po­ winny z kolei generować dane, które następnie należy porównać ze znanymi danymi.

•

Aby przetestować program numeryczny, utwórz przypadki testowe dotyczące warunków brzegowych działania algorytmu, banalne przypadki testowe oraz trudne przypadki testowe. Program do całkowania można przykładowo przetestować, sprawdzając, czy jego wyniki są ciągłe i czy zgadzają się ze ściśle określoną postacią rozwiązań.

•

Aby przetestować program graficzny, nie wystarczy tylko sprawdzić, czy potrafi on nary­ sować prostokąt. Zamiast tego należy taki prostokąt wczytać z powrotem z ekranu i zoba­ czyć, czy jego krawędzie znajdują się dokładnie tam, gdzie powinny.

Jeśli istnieje program działający odwrotnie do testowanego, to sprawdź, czy uda się przy jego użyciu odzyskać oryginalne dane. Przykładem odwrotnie działających algorytmów jest szyfro­ wanie i deszyfrowanie danych. Jeżeli więc zaszyfrujesz jakieś informacje i nie możesz ich póź­ niej odszyfrować, oznacza to, że w algorytmie tkwi błąd. Analogicznie przeciwieństwami powinny być kompresja bezstratna i rozwijanie. Programy, które łączą pliki w paczki, muszą umieć je rozpakowywać do pierwotnej postaci. Czasami odwrotność można wyrazić na kilka sposobów, wówczas należy sprawdzić wszystkie przypadki.

Sprawdzaj, czy program zachowuje właściwości. Niektóre programy zachowują pewne wła­ ściwości swoich danych wejściowych. Takie narzędzia, jak funkcje we (liczy wiersze, słowa i znaki) i s um (oblicza sumę kontrolną), mogą służyć do sprawdzenia, czy wyniki mają ten sam rozmiar, zawierają taką samą liczbę słów lub te same bajty w określonej kolejności itd. Niektóre programy sprawdzają, czy pliki są identyczne (cmp), albo zwracają informacje o różnicach w porów­ nywanych plikach (di ff). Programy te są dostępne do użytku w wielu środowiskach i naprawdę warto je mieć. Programu sprawdzającego częstość występowania bajtów można użyć do zbadania, czy zo­ stały zachowane dane, oraz wykrywania takich anomalii, jak nietekstowe znaki w plikach, któ­ re z założenia powinny być tekstowe. Oto jedna z wersji, którą nazwaliśmy freq : # i ncl ude #i ncl ude #i ncl ude unsi gned l ong count [UCHAR_MAX+l] ; /* main: wyświetla liczniki częstości występowania bajtów */

1 56

6 . TESTOWANIE

i nt mai n (vo i d ) { i nt c ; whi l e ( (c = getchar ( ) ) ! = EOF) count [c] ++ ; for (c = O ; c <= UCHAR MAX ; c++) i f ( count [c] ! = of pri n t f ( 11 % . 2x %c %l u\n11 , c , i spri nt (c) ? c : return O ;

count [c] ) ;

To, czy wybrane właściwości zostały zachowane, można także sprawdzić wewnątrz progra­ mu. Funkcja licząca elementy w strukturze danych stanowi bardzo prosty mechanizm spraw­ dzania spójności danych. Tablica mieszania powinna mieć tę właściwość, że każdy włożony do niej element musi dać się z niej wyjąć. Można to łatwo sprawdzić za pomocą funkcji zapisującej całą zawartość tablicy w pliku lub innej tablicy. Liczba elementów włożonych do struktury danych pomniejszona o liczbę operacji usunięcia elementu powinna zawsze zgadzać się z liczbą elementów aktualnie znajdujących się w strukturze danych. Można to łatwo sprawdzić.

Porównuj niezależne implementacje. Niezależne od siebie implementacje tej samej biblioteki lub jednego programu powinny zwracać takie same wyniki. Na przykład dwa kompilatory po­ winny tworzyć programy, które na tej samej maszynie zachowują się tak samo, przynajmniej w większości przypadków. Czasami wynik można obliczyć na dwa różne sposoby albo napisać prostszą wersję progra­ mu, która jest wolniejsza, ale może służyć do celów porównawczych. Jeśli dwa niezwiązane ze sobą programy zwracają takie same wyniki, istnieje duże prawdopodobieństwo, że są popraw­ ne. Jeżeli zwracają różne wyniki, to przynajmniej jeden z nich zawiera błąd. Jeden z nas pracował kiedyś z inną osobą nad kompilatorem dla nowej maszyny. Zadanie wykrywania błędów w wygenerowanym przez kompilator kodzie zostało podzielone: jedna osoba pisała oprogramowanie kodujące instrukcje dla maszyny docelowej, a druga - dezasem­ bler dla programu diagnostycznego. Dzięki temu żaden błąd implementacji lub interpretacji zbioru rozkazów nie mógł się powtórzyć w tych dwóch składnikach. Kiedy kompilator źle za­ kodował instrukcję, dezasembler zawsze to wychwytywał. Wszystkie dane wyjściowe kompila­ tora były przepuszczane przez dezasembler i porównywane z wydrukami diagnostycznymi kompilatora. Strategia ta była bardzo skuteczna i pozwalała natychmiast wykrywać wszystkie błędy w obu częściach programu. Jedyna trudność, która przedłużała diagnozowanie, wystę­ powała wówczas, gdy obie osoby niepoprawnie interpretowały niejednoznaczny fragment opisu architektury.

Sprawdzaj pokrycie kodu testami. Jednym z celów testowania jest zapewnienie tego, żeby każda instrukcja programu została wykonana przynajmniej raz w czasie procedury testowej. Te­ stowania nie można uznać za kompletne, jeśli choćby jeden wiersz kodu pozostanie niesprawdzony przez chociaż jeden test. Często trudno osiągnąć ten cel. Nawet jeżeli pominie się instrukcje, które „nie powinny zostać wykonane'', trudno zmusić program do wykonania niektórych frag­ mentów kodu przy użyciu zwykłych danych wejściowych. Istnieją komercyjne narzędzia do mierzenia pokrycia kodu testami. Do kompilatorów czę­ sto są dołączane narzędzia profilujące, które służą do obliczania częstości wykonywania po­ szczególnych instrukcji programu. Na podstawie tych informacji można ocenić, jakie pokrycie oferują stosowane testy.

6.3. AUTOMATYZACJA TESTÓW

157

Za pomocą technik opisanych w tej części przetestowaliśmy program Markowa z rozdziału 3. Szczegółowo testy te opiszemy pod koniec tego rozdziału.

Ćwiczenie 6.3. Opisz, jak przetestowałbyś program freq. Ćwiczenie 6.4. Zaprojektuj i zaimplementuj nową wersję programu freq, która będzie mierzyć częstość występowania wartości innych typów, np. 32-bitowych liczb całkowitych albo liczb zmiennoprzecinkowych. Czy potrafisz napisać jedną elegancką wersję programu obsługującą różne typy?

6.3. Automatyzacja testów Wykonywanie wielu testów ręcznie jest bardzo żmudne i niepewne. Aby solidnie przetestować kod, konieczne jest użycie dużej liczby testów, danych wejściowych i porównań danych wyj­ ściowych. Czynności te powinny być wykonywane przez programy, które się nie męczą i nie nudzą. Warto poświęcić chwilę czasu na napisanie skryptu lub prostego programu, w którym zostaną zapisane wszystkie testy. Taki zestaw testowy można uruchamiać za pomocą (dosłow­ nie lub w przenośni) jednego przycisku. Im łatwiej wykonać zestaw testów, tym częściej bę­ dziesz z niego korzystać i istnieje mniejsze ryzyko, że go nie użyjesz, jeśli będziesz mieć mało czasu. Napisaliśmy zestaw testów do sprawdzania wszystkich programów przedstawionych w tej książce i uruchamialiśmy go za każdym razem, gdy wprowadziliśmy jakieś zmiany. Nie­ które testy są wykonywane automatycznie po każdej zakończonej powodzeniem kompilacji.

Automatyzuj testowanie regresywne. Podstawową formą automatyzacji testów jest testowanie regresywne (ang. regression testing). Polega ono na porównaniu nowej wersji czegoś z poprzed­ nią wersją. Przy naprawianiu błędów programiści zwykle sprawdzają tylko, czy naniesione przez nich poprawki działają. Zapominają o tym, że wprowadzenie zmian mogło spowodować usterkę w innych częściach programu. Celem testowania regresywnego jest upewnienie się, iż zachowanie programu zmieniło się tylko w oczekiwany sposób. Niektóre systemy oferują bogate zestawy narzędzi ułatwiających automatyzację testów. Przy użyciu języków skryptowych można pisać proste skrypty uruchamiające zestawy testów. W systemie Unix dostępne są programy do porównywania plików, jak di ff i cmp, których można używać do porównywania danych wyjściowych. Program sort łączy elementy wspólne. Program grep filtruje wyniki testów, a programy we, s um i freq tworzą zestawienia wyników testów. Przy użyciu tych wszystkich narzędzi można łatwo stworzyć ramę testową, która może nie będzie wystarczająco funkcjonalna, aby użyć jej w dużych projektach, ale na pewno wystar­ czy dla pojedynczych programistów i niewielkich zespołów. Poniżej znajduje się skrypt służący do testowania regresywnego pewnego programu o na­ zwie ka. Skrypt ten uruchamia starą (o 1 d_ ka) i nową (new_ ka) wersję programu na dużej liczbie plików z danymi testowymi i informuje o wszystkich różnicach w danych wyjściowych obu programów. Jest to skrypt powłoki systemu Unix, ale można go bez trudu przekształcić na ję­ zyk Perl albo dowolny inny język skryptowy: for i i n ka data . * do al d ka $i >outl new)a $ i >out2 i f ! cmp -s outl out2

# Pętla pobierająca pliki z danymi testowymi # Uruchomienie starej wersji programu # Uruchomienie nowej wersji programu # Porównanie plików z wynikami

158

6. TESTOWANIE

then done

fi

echo $i : BAD

# Różnica: drukuje komunikat o błędzie

Skrypt testowy powinien działać niezauważalnie i zwracać wyniki tylko wówczas, gdy wy­ darzy się coś niespodziewanego, tak jak powyższy. Równie dobrze moglibyśmy w trakcie te­ stowania każdego pliku wyświetlać jego nazwę i dodawać komunikat o błędzie, gdy coś zosta­ nie wykryte. Taki wskaźnik postępu testowania pomaga znaleźć niektóre rodzaje problemów, takie jak nieskończone pętle lub wykonanie niewłaściwych testów, ale jeśli nie są wykrywane żadne usterki, to takie wyświetlanie niepotrzebnych informacji tylko denerwuje programistę. Argument -s powoduje, że program cmp informuje o stanie, ale nie wytwarza danych wyj­ ściowych. Jeśli porównywane pliki są identyczne, to stan zgłaszany przez program cmp jest prawdą, wyrażenie ! cmp jest fałszywe i nic nie zostaje wydrukowane. Jeśli natomiast nowe i stare dane czymś się różnią, cmp zwraca fałsz oraz następuje wydruk nazwy pliku i tekstu ostrzeżenia. W testowaniu regresywnym przyjmuje się milczące założenie, że poprzednia wersja pro­ gramu zwraca poprawny wynik. Trzeba o to skrupulatnie dbać już od samego początku i nie dopuścić, aby cokolwiek się w tej kwestii zmieniło. Jeśli do testowania regresywnego wkradnie się niezauważenie jakiś nieprawidłowy wynik, będzie bardzo trudno to wykryć i wszystko, co od tego zależy, będzie również skażone tym błędem. Dobrze jest od czasu do czasu sprawdzić sam test regresywny, aby się upewnić, że nie zawiera błędów.

Twórz samodzielne testy. Uzupełnieniem testowania regresywnego są samodzielne testy, a więc takie, które zawierają odpowiednie dane wejściowe i oczekiwane dane wyjściowe. Po­ uczające może być nasze doświadczenie zdobyte przy testowaniu w języku Awk. Wiele kon­ strukcji programistycznych testuje się w ten sposób, że przepuszcza się specjalnie spreparowa­ ne porcje danych przez niewielkie programy i sprawdza poprawność zwracanych przez nie wyników. Poniżej przedstawiamy fragment dużego zbioru rozmaitych testów, który sprawdza pewne zawiłe wyrażenie inkrementacyjne. Test ten uruchamia nową wersję Awku (newawk) na krótkim programie napisanym w tym samym języku. Dane wyjściowe wysyła do jednego pliku, a poprawny wynik zapisuje w drugim za pomocą instrukcji echo. Następnie porównuje te dwa pliki i informuje o różnicach między nimi, jeśli jakieś znajdzie. # Test inkrementacji pola: $i++ oznacza ($i)++, a nie $(i++)

echo 3 5 I newawk ' { i l ; print $ i ++ ; pri nt $ 1 , i } ' >outl echo ' 3 4 1 ' >out2 # Poprawny wynik i f ! cmp -s outl out2 # Wyniki są różne then echo ' BAD : test zwi ększan i a pol a zakończony n i epowodzen i em ' fi =

Pierwszy komentarz stanowi część danych testowych i dokumentuje, co ten test sprawdza. Czasami można stworzyć dużą liczbę testów i za bardzo się nie napracować. Do testowania prostych wyrażeń utworzyliśmy niewielki specjalny język do opisu testów, danych wejścio­ wych i spodziewanych wyników. Poniżej znajduje się krótki test służący do weryfikacji niektó­ rych sposobów reprezentacji wartości liczbowej 1 w Awku: try { i f { $ 1 1 tak tak 1 .O

==

1) pri nt "yes " ; el se pri nt "no" }

1 59

6.4. RAMY TESTOWE

l EO O . lEl lOE-1 Ol +l lOE-2 10

tak tak tak tak tak nie nie

W pierwszym wierszu znajduje się program, który ma zostać przetestowany (wszystko, co znajduje się za słowem t ry). W pozostałych wierszach mieszczą się dane wejściowe i oczekiwa­ ne wyniki - są one od siebie oddzielone znakiem tabulacji. Pierwszy test oznacza, że jeśli pole wejściowe ma wartość 1, to wynikiem powinien być łańcuch tak. Siedem pierwszych testów ma wydrukować tak, a dwa ostatnie n i e. Program napisany w języku Awk (bo w jakim by innym?) konwertuje każdy test w komplet­ ny program w języku Awk, następnie przepuszcza przez niego wszystkie wiersze danych wej­ ściowych i porównuje rzeczywisty wynik z wynikiem spodziewanym. Informuje tylko o tych przypadkach, gdy wyniki są niepoprawne. Podobnej techniki używa się do testowania działania wyrażeń regularnych i poleceń pod­ stawiania. Niewielki język do pisania testów ułatwia tworzenie dużej ich liczby. Użycie pro­ gramu do napisania programu testującego inny program daje jeszcze większe możliwości (więcej na temat niewielkich języków i wykorzystania programów do pisania programów napisaliśmy w rozdziale 9.). Liczba wszystkich testów dla języka Awk wynosi kilka tysięcy. Wszystkie je można uru­ chomić za pomocą jednego polecenia i jeśli nie zostaną znalezione żadne błędy, testy te nie zwrócą żadnych danych. Gdy do języka zostanie dodana jakaś nowa właściwość albo gdy zosta­ nie naprawiony jakiś błąd, dodaje się nowe testy, aby sprawdzić, czy wszystko poprawnie działa. Cały pakiet testów jest wykonywany po wprowadzeniu każdej, nawet najdrobniejszej zmiany. Operacja ta zajmuje tylko kilka minut. Testy czasami znajdują kompletnie nieoczekiwane błędy i już nieraz uratowały twórców języka Awk przed publicznym ośmieszeniem. Co należy zrobić, gdy wykryje się błąd? Jeśli istniejący test go nie wykrywa, utwórz nowy test, który będzie to robił, i sprawdź go przez uruchomienie na zawierającej usterkę wersji kodu. Taki błąd może czasami wskazać, jakie inne testy należy utworzyć, albo uwidocznić całą nową grupę rzeczy, które trzeba sprawdzić. Może dałoby się też wzmocnić mechanizmy obronne programu, aby wykrywały błąd wewnętrznie. Nigdy nie pozbywaj się żadnego testu. Może Ci on pomóc stwierdzić, czy dana informacja o błędzie jest aktualna lub dotyczy czegoś, co zostało już poprawione. Prowadź dokumentację błędów, zmian i napraw. Pomoże Ci to identyfikować stare problemy i poprawiać nowe błędy. W większości firm zajmujących się tworzeniem oprogramowania komercyjnego prowadzenie takiej dokumentacji jest obowiązkowe. Jeśli programujesz na własną rękę, możesz to traktować jak małą inwestycję, która wielokrotnie się zwróci. -

Ćwiczenie 6.5. Zaprojektuj zestaw testów dla funkcji pri ntf, używając jak największej liczby narzędzi pomocniczych.

6.4. Ramy testowe Wszystko, co napisaliśmy do tej pory, dotyczy głównie testowania pojedynczych samodziel­ nych programów w ich ostatecznej postaci. Nie jest to jednak jedyny sposób automatyzacji te­ stów ani najbardziej prawdopodobny sposób testowania części dużych programów podczas ich

1 60

6. TESTOWANIE

budowy, zwłaszcza gdy pracujesz jako członek zespołu. Nie jest to też najlepsza metoda testo­ wania niewielkich składników czegoś większego. W celu przetestowania wybranego składnika w odosobnieniu zwykle trzeba utworzyć spe­ cjalny szkielet czy ramę, stanowiące podporę i interfejs dla reszty systemu, w którym będzie działać testowana część. Łatwo tworzy się ramy do testowania funkcji matematycznych i łańcuchowych, procedur sortujących itp„ gdyż najczęściej głównym zadaniem takiej ramy jest konfiguracja parametrów wejściowych, wywoływanie funkcji, które mają zostać przetestowane, i sprawdzanie wyników. Znacznie trudniej skonstruować ramę do testowania częściowo ukończonego programu. Zilustrujemy to na przykładzie utworzenia testu funkcji memset - jednej z funkcji operu­ jących na pamięci, które znajdują się w bibliotece standardowej języków C i C+ + . Ponieważ bardzo ważna jest szybkość działania, większość tych funkcji napisano w języku asemblera dla konkretnej maszyny. Jednak im lepiej funkcja jest zoptymalizowana, tym większe prawdopo­ dobieństwo, że zawiera błąd, a więc tym bardziej szczegółowego testowania wymaga. Pierwszym krokiem jest opracowanie najprostszych możliwych wersji funkcji w języku C, o których wiadomo, że działają poprawnie. Będą one służyć jako punkt odniesienia przy ocenie wydajności, i co ważniejsze - przy ocenie poprawności. Aby przejść do nowego środowiska, należy przenieść do niego te proste wersje i używać ich, póki nie uda się doprowadzić do odpowiedniego stanu wersji zoptymalizowanych. Funkcja memset ( s , c , n) wstawia bajt c do n bajtów pamięci, rozpoczynając od miejsca o adresie s, i zwraca s. Implementacja tej funkcji, jeśli szybkość działania nie jest najważniejsza, jest bardzo prosta: ·

/* memset: ustawia n pierwszych bajtów od adresu s na c */

voi d *memset (voi d *s , i nt c , s i z e-t n ) { si ze_t i ; char * p ; p = (char *) s ; for ( i O ; i < n ; i ++) p[i] c; return s ; =

=

Jeśli jednak warunkiem jest szybkie działanie funkcji, stosuje się rozmaite sztuczki, takie jak zapisywanie pełnych 32- lub 64-bitowych słów naraz. Łatwo popełnić przy tym błąd, dlatego skrupulatne testowanie jest konieczne. Do testowania zostanie wykorzystany wyczerpujący zestaw testów i sprawdzeń warunków brzegowych dotyczących miejsc, w których mogą prawdopodobnie wystąpić błędy. W przy­ padku funkcji memset oczywistymi wartościami granicznymi zmiennej n są O, l i 2, a także po­ tęgi dwójki i wartości do nich zbliżone, i to zarówno niewielkie, jak i duże, takie jak z16 (odpo­ wiada naturalnej granicy w wielu maszynach, w których słowo składa się z 16 bitów). Potęgi dwójki zasługują na szczególną uwagę, ponieważ jednym ze sposobów optymalizacji szybkości działania funkcji memset jest ustawianie wartości wielu bitów jednocześnie. Można to osiągnąć poprzez użycie specjalnych instrukcji albo próbę zapisu całych słów zamiast poszczególnych bajtów. Analogicznie powinniśmy sprawdzać oba końce tablicy przy różnych wartościach wy­ równania, aby wykryć ewentualne pomyłki zależne od błędnego adresu początkowego lub rozmiaru tablicy. Docelową tablicę umieścimy w większej tablicy, aby uzyskać margines bez­ pieczeństwa po każdej stronie i ułatwić sobie zmienianie wyrównania.

161

6.4. RAMY TESTOWE

Sprawdzimy także różne wartości zmiennej c , m.in. O, Ox7f (największa wartość ze znakiem w 8 bajtach), Ox80 i OxFF (w celu zbadania potencjalnych błędów związanych z występowaniem wartości ze znakiem i bez znaku), jak również pewne wartości znacznie przekraczające pojem­ ność 1 bajta (aby upewnić się, że używany jest tylko 1 bajt). Oprócz tego powinniśmy zainicja­ lizować pamięć jakimiś znanymi wartościami różnymi od badanych wartości zmiennej c, aby móc dowiedzieć się, czy funkcja memset nie zapisuje danych poza przydzielonym obszarem. Możemy użyć prostej implementacji standardowego porównywania w teście, który alokuje dwie tablice, a następnie porównuje ich zachowania na kombinacjach wartości n, c i przesunięć wewnątrz tablicy: bi g = maksymal ny l ewy marg i nes + maksymal na wartość + maksymal ny prawy margi nes SO = mal l oc (b i g) s l = mal l oc (b i g } dl a każdej komb i nacj i parametrów testowych n , c i offset : ustaw w tabl i cach sO i s l znane wartości wykonaj powol ną wersj ę funkcj i memset (sO + offset , c, n) wykonaj szybką wersję funkcj i memse t ( s l + offset , c, n) sprawdź wartości zwrotne porównaj zawartość tabl i c sO i sl bajt po baj c i e Błąd, który spowoduje, ż e funkcja memset zapisze dane poza granicą tablicy, najprawdopo­ dobniej zmieni bajty znajdujące się w pobliżu początku lub końca tej tablicy, a więc dzięki po­ zostawieniu marginesu łatwiej wykryć takie uszkodzone bajty i unika się ryzyka uszkodzenia przez funkcję innej części programu. Aby dowiedzieć się, czy coś jest zapisywane poza grani­ cami tablicy, należy porównać wszystkie bajty tablic s O i s l, nie tylko n bajtów, które powinny zostać zapisane. W związku z tym dobry zestaw testów mógłby składać się z wszystkich kombinacji nastę­ pujących wartości: offset = 10, 1 1 , . . . , 20 c = O , 1, Ox7F , OxBO, OxFF, Ox1 1 223344 n = O, 1 , 2, 3, 4, 5 , 7 , 8, 9, 1 5 , 1 6 , 17 , 3 1 , 3 2 ' 33 ' . 6553 5 ' 65536 , 65537 .

„

Zbiór wartości zmiennej n powinien zawierać przynajmniej liczby i 1, 2; oraz 2; + 1 , dla wartości i z przedziału od O do 16. Wartości te nie powinny być wbudowane w główną część ramy testowej, lecz znajdować się w tablicach tworzonych ręcznie lub przez program. Automatyczne generowanie tych wartości jest lepsze, ponieważ ułatwia dodawanie potęg dwójki oraz przesunięć i znaków. Testy te pozwolą bardzo dokładnie przebadać funkcję memset, mimo że na ich utworzenie i wykonanie potrzeba bardzo niewiele czasu, gdyż z powyższych wartości można utworzyć nie­ co mniej niż 3 500 przypadków. Testy są również całkowicie przenośne, dzięki czemu można ich używać w dowolnym środowisku. Jako ostrzeżenie opowiemy Ci pewną historię. Użyczyliśmy kiedyś kopii testów do testo­ wania funkcji mems et pewnej osobie, która budowała system operacyjny i tworzyła biblioteki dla nowego procesora. Kilka miesięcy później także my (czyli autorzy oryginalnego testu) za­ częliśmy używać tej maszyny i stwierdziliśmy, że pewna duża aplikacja nie przechodziła testów. Po zbadaniu problemu odkryliśmy drobny błąd związany z rozszerzeniem znakowym w im­ plementacji funkcji memset w języku asemblera. Z nieznanych nam przyczyn programista bi­ blioteki usunął z testów funkcji memset sprawdzanie wartości zmiennej c większych od Ox7F. -

1 62

6. TESTOWANIE

Oczywiście gdy zorientowaliśmy się, że źródłem problemów może być funkcja memset, znaleź­ liśmy błąd, wykonując na niej oryginalny zestaw testów. Funkcje takie jak memset łatwo jest wyczerpująco przetestować, ponieważ są wystarczająco nieskomplikowane, aby dało się udowodnić, że zastosowane przypadki testowe badają wszyst­ kie możliwe ścieżki wykonywania kodu, a więc w pełni go pokrywają. Na przykład można prze­ testować funkcję memmove pod względem wszystkich możliwych kombinacji możliwości nakładania się fragmentów pamięci, kierunków przesuwania danych oraz wyrównania ich. Nie jest to wy­ czerpujący test wszystkich operacji kopiowania, lecz drobiazgowe testowanie reprezentacji każdego rodzaju różnych sytuacji na wejściu. Tak jak w przypadku każdej metody testowania do weryfikacji testowanych operacji rama testowa potrzebuje poprawnych odpowiedzi. Ważną techniką, zastosowaną przez nas podczas testowania funkcji memset, jest porównanie prostej wersji, która powinna być poprawna, z nową wersją, która może zawierać błędy. Porównywanie to można wykonywać etapami, tak jak w przy­ kładzie opisanym poniżej. Jeden z nas implementował kiedyś bibliotekę grafiki rastrowej zawierającej operator, który kopiował bloki pikseli z jednego obrazu na inny. W zależności od parametrów operacja ta mogła być prostym kopiowaniem zawartości pamięci bądź wymagała konwersji wartości pikseli z jed­ nej przestrzeni kolorów na inną, mogła wymagać ułożenia „kafelkowego" obiektów, jeśli dane wejściowe były kopiowane wielokrotnie w postaci prostokątnych obszarów, lub być kombina­ cją wszystkich wymienionych operacji. Specyfikacja operatora była prosta, lecz aby napisać je­ go wydajną implementację, trzeba było dodać mnóstwo kodu obsługującego wiele specjalnych przypadków. By mieć pewność, że kod działa poprawnie, konieczne okazało się zastosowanie solidnej strategii testowania. Najpierw ręcznie napisano prosty kod poprawnie wykonujący operację na jednym pikselu. Program ten wykorzystano do weryfikacji obsługi jednego piksela przez wersję biblioteczną. Po ukończeniu tego etapu można było ufać wynikom biblioteki zwracanym dla operacji na pojedyn­ czych pikselach. Następnie funkcja biblioteczna działająca na pojedynczych pikselach została użyta przez ręcznie napisany kod do utworzenia bardzo wolnej wersji operatora, która działała na jednym poziomym rzędzie pikseli. Tę wersję operatora porównano ze znacznie wydajniejszą wersją bi­ blioteczną obsługującą pojedyncze wiersze. Po ukończeniu tego etapu można było ufać wyni­ kom biblioteki zwracanym dla operacji na pojedynczych poziomych rzędach pikseli. Kontynuując ten proces, wierszy użyto do budowy prostokątów, prostokątów do budowy kafelków itd. W trakcie pracy wykryto wiele błędów, z których część znajdowała się w samym teście, ale na tym właśnie polega tajemnica efektywności tej metody: testowano dwie niezależ­ ne implementacje, stopniowo budując zaufanie do każdej z nich. Jeśli jakiś test się nie powiódł, system drukował szczegółowe informacje, dzięki którym łatwiej było znaleźć źródło problemu i przy okazji zweryfikować działanie samego testu. Przez wiele lat modyfikacji i przenoszenia biblioteki nasz zestaw testowy wielokrotnie udowodnił, że jest bezcennym narzędziem do wykrywania błędów. Ze względu na warstwową budowę zestawu testów za każdym razem trzeba było przepro­ wadzać wszystkie testy, aby utwierdzić się w przekonaniu, że biblioteka nie zawiera błędów. Przypadkowo zestaw ten nie był wyczerpujący, lecz probabilistyczny: generował losowe przy­ padki testowe, które, jeśli tylko mogły działać wystarczająco długo, badały każdy zakątek kodu. Przy ogromnej liczbie możliwych przypadków testowych taka strategia była efektywniejsza niż konstruowanie obszernego zestawu testowego samodzielnie i znacznie bardziej efektywna niż wyczerpujące testowanie.

Ćwiczenie 6.6. Utwórz platformę testową dla funkcji memset, stosując się do naszych wskazówek.

6.5. TESTOWANIE PRZECIĄŻENIOWE

1 63

Ćwiczenie 6.7. Utwórz testy dla pozostałych funkcji z rodziny mem . . . Ćwiczenie 6.8. Określ procedurę testowania procedur działających na liczbach, takich jak sq rt, s i n itp., które znajdują się w pliku nagłówkowym math.h. Jakie wartości wejściowe mają sens? Jakie niezależne testy można przeprowadzić?

Ćwiczenie 6.9. Zdefiniuj mechanizmy testowania funkcji z rodziny str . . . w języku C, takich jak np. strcmp. Niektóre z nich, zwłaszcza funkcje dzielące łańcuchy na leksemy, jak strtok i stres pn, s ą znacznie bardziej skomplikowane o d funkcji z rodziny mem . . . , a więc d o ich te­ stowania trzeba użyć bardziej wyszukanych technik.

6.5 . Testowanie przeciążeniowe Kolejną skuteczną techniką testowania jest użycie dużej ilości danych wygenerowanych auto­ matycznie. Takie wygenerowane maszynowo wielkie zbiory informacji całkiem inaczej oddziałują na program niż dane ręcznie wprowadzane przez programistę. Sam rozmiar zbioru danych mo­ że przyczynić się do wystąpienia awarii w programie, ponieważ może spowodować przepełnie­ nie buforów wejściowych, tablic oraz liczników. Jest to bardzo skuteczny sposób znajdowania niestrzeżonych miejsc przechowywania danych w programie. Ludzie zwykle unikają rzeczy „niemożliwych'', takich jak puste, nieuporządkowane lub wychodzące poza dozwolony zakres dane wejściowe, oraz bardzo rzadko tworzą długie nazwy i wielkie wartości. Natomiast kompu­ tery przeciwnie - tworzą dane ściśle według określonego algorytmu i nie mają pojęcia, czego należałoby unikać. Poniżej znajduje się jeden przykładowy wiersz danych wytworzony przez kompilator Microsoft Visual C+ + 5.0 podczas kompilacji programu ma rkov w wersji napisanej w języku C+ + z użyciem biblioteki STL. Wiersz z konieczności został podzielony na kilka części: xtree ( l14 ) : warn i ng C4786 : ' std : : _Tree , std : : a l l ocator > , std : : al l ocator
al l ocator>>>>> : : i terato r ' : i dent i f i er was truncated to ' 255 ' characters i n the debug i nformati on Kompilator ostrzega nas, że wygenerował nazwę zmiennej składającą się aż z 1 594 znaków, ale że tylko 255 znaków zostało zachowanych w danych diagnostycznych. Nie wszystkie pro­ gramy mają mechanizmy chroniące je przed skutkami użycia tak długich nazw zmiennych. Innym sposobem na przypuszczenie ataku na program w nadziei, że uda się coś zepsuć, jest wprowadzenie (niekoniecznie poprawnych) danych losowych. To jest logiczne rozszerzenie rozumowania typu „ludzie tak nie robią". Na przykład niektóre komercyjne kompilatory języ­ ka C są testowane przy użyciu losowo generowanych, ale poprawnych składniowo programów. Celem tych działań jest wykorzystanie specyfikacji problemu - w tym przypadku standardu języka C - do utworzenia programu, który wytwarza dziwaczne, ale poprawne dane testowe. W takich testach usterki wykrywa się za pomocą wbudowanych testów i algorytmów ochronnych programu, ponieważ sprawdzenie, czy program zwrócił poprawne wyniki, jest ra­ czej niemożliwe. Bardziej chodzi o wywołanie awarii albo sytuacji, która „nie miała prawa się zdarzyć'', niż o odkrycie jakichś typowych błędów. Ponadto jest to dobry sposób na sprawdze­ nie działania procedur obsługi błędów. Przy normalnych danych wejściowych większość błędów

1 64

6. TESTOWANIE

nie występuje, a więc kod służący do ich obsługi nie jest sprawdzany. Błędy zwykle kryją się w rozmaitych trudno dostępnych zakamarkach. Jednak po przekroczeniu pewnej bariery tego typu testowanie traci swoje walory: zaczynają być znajdowane tak nieprawdopodobne proble­ my, że nie warto nawet tracić czasu na zajmowanie się nimi. W niektórych testach celowo wykorzystuje się szkodliwe dane wejściowe. W trakcie wła­ mań do programów często stosuje się bardzo duże albo nieprawidłowe z punktu widzenia pro­ gramu dane, które kasują cenne informacje. Warto poszukać takich słabych punktów i je wy­ eliminować. Na tego rodzaju ataki podatne są niektóre funkcje z biblioteki standardowej. Na przykład nigdy nie należy używać standardowej funkcji gets, ponieważ nie pozwala ona w żaden sposób ograniczyć długości przyjmowanego na wejściu łańcucha znaków. Zamiast niej zawsze używaj funkcji fgets ( b u f , s i zeof {buf) , stdi n ) . Także samo wywołanie scanf ( "%s " , buf) nie ogranicza ilości danych wejściowych. Dlatego w wywołaniach tej funkcji zwykle należy bezpośrednio określać długość wiersza danych, np.: scanf ( "%20" , buf) . W podrozdziale 3.3 pokazaliśmy, jak rozwiązać ten problem dla ogólnego rozmiaru bufora. Każda procedura, która bezpośrednio lub pośrednio odbiera dane z zewnątrz programu, powinna je sprawdzać przed ich użyciem. Zaprezentowany niżej program, przepisany z jednego podręcznika, powinien wczytać wpisaną przez użytkownika liczbę całkowitą i wyświetlać ostrzeżenie, jeśli liczba ta jest zbyt długa. Celem tego programu jest pokazanie, jak radzić sobie z problemem z funkcją gets, ale to rozwiązanie nie zawsze działa. #defi ne MAXNUM 10 i nt mai n (void) { char num [MAXNUM] ; memset (num, O , s i zeof(num) ) ; printf("Wprowadf j aką§ l i czbę: " ) ; get s (num) ; i f (num [MAXNUM-1] ! = O) pri ntf ( "Wprowadzona l i czba jest za duża . \n " ) ; /*

„.

*/

Jeśli podana na wejściu liczba będzie składała się z dziesięciu cyfr, to ostatnie zero w tablicy num zastąpi niezerowa wartość, która teoretycznie zostanie wykryta po powrocie z funkcji gets. To niestety nie wystarczy. Mający złe zamiary uŻytkownik może wpisać jeszcze więcej cyfr, powodując skasowanie czegoś ważniejszego, np. adresu powrotu z wywołania funkcji, co spra­ wi, że program nigdy nie wykona instrukcji i f, lecz zwróci jakąś nieprzyjazną wartość. Z tego powodu przepuszczanie bez sprawdzenia takich wartości jest potencjalnym zagrożeniem bez­ pieczeństwa. Myli się ten, kto sądzi, że to tylko podręcznikowy przykład, który nie ma nic wspólnego z realnym światem. W lipcu 1 998 roku błąd tego typu wykryto w kilku znanych programach do obsługi poczty elektronicznej. Oto, co na ten temat pisał „New York Times": Powstanie tej luki w zabezpieczeniach spowodował tzw. „błąd przepełnienia bufora". Programiści powinni wyposażać programy w algorytmy sprawdzające, czy przyjmowane dane są bezpieczne i czy mają dozwolony rozmiar. Jeżeli przyjmowana porcja danych jest zbyt duża, może spowodować przepełnienie „bufora" - specjalnie wydzielonego obszaru pamięci, w którym dane są tymczasowo przechowywane. Jeśli tak się stanie, program do obsługi poczty ulega awarii, a wrogi programista może za pomocą różnych sztuczek zmusić komputer do uruchomienia w zamian jakiegoś szkodliwego programu.

6.5. TESTOWANIE PRZECIĄŻENIOWE

1 65

Taki sam atak przypuszczono także w słynnej sprawie „robaka internetowego" w 1988 roku. Także programy przetwarzające dane z formularzy HTML są podatne na ataki polegające na zapisywaniu bardzo długich łańcuchów znaków w małych tablicach: stati c char query [1024] ; char {

*read-form(voi d) i nt q s i z e ; q s i ze atoi (getenv ( " CONTENT LENGTH " ) ) ; fread (query, q s i z e , 1 , std i n) ; return query; =

W tym programie przyjęto założenie, że na wejściu nie pojawią się więcej niż 1 024 bajty danych, przez co kod ten, podobnie jak funkcja gets, jest wrażliwy na ataki polegające na przepełnieniu bufora. Także bardziej swojskie przepełnienia mogą powodować duże problemy. Jeśli zostanie nie­ postrzeżenie przekroczony zakres wartości liczb całkowitych, to rezultat tego może być opła­ kany. Przeanalizujmy zapisany niżej kod przydzielający pamięć: char * p ; p = (char *) mal l oc (x * y * z ) ; Jeśli wynik działania x * y * z przekroczy zakres liczb całkowitych, to funkcja ma 1 1 oc może utworzyć i utworzy tablicę o sensownym rozmiarze, ale indeks p [x] będzie mógł wska­ zywać miejsce leżące poza przydzielonym obszarem w pamięci. Przypuśćmy, że w rozpatrywa­ nym systemie liczby całkowite są 16-bitowe, a każda ze zmiennych x, y i z ma wartość 41. Wówczas wynikiem działania X * y * z będzie liczba 68 921, czyli 3 385 modulo 2 16 • w związku z tym funkcja ma 1 1 oc przydzieli tylko 3 385 bajtów. Każdy indeks o wartości wyższej niż ta liczba będzie odwołaniem poza przydzielony obszar. Innym źródłem błędów przepełnienia są konwersje typów danych. W tym przypadku samo wykrycie błędu może być niewystarczające. Rakieta „Ariane 5" eksplodowała w czasie swojego dziewiczego lotu w czerwcu 1996 roku, ponieważ odziedziczyła pakiet nawigacyjny po rakiecie „Ariane 4" i nie przeprowadzono dostatecznych testów. Nowa rakieta była szybsza od po­ przedniczki, czego skutkiem było to, że niektóre zmienne w oprogramowaniu nawigacji przyjmowały większe wartości. Krótko po starcie w programie doszło do próby wykonania konwersji bardzo dużej 64-bitowej liczby zmiennoprzecinkowej na 1 6-bitowy typ całkowity ze znakiem, co spowodowało przepełnienie. Błąd został wykryty, ale algorytm, który go prze­ chwycił, podjął decyzję o zamknięciu całego podsystemu. W wyniku tego rakieta obróciła się i eksplodowała. Pech chciał, że kod, który zawiódł, generował informacje dotyczące stanu bez­ władności przydame tylko na ziemi. Gdyby go wyłączono przed startem, nic złego by się nie stało. Jeśli chodzi o bardziej przyziemne sprawy, zdarza się czasami, że dane binarne wywołują awarię programów, które oczekują danych tekstowych, zwłaszcza jeśli miałyby to być dane z 7-bitowego zestawu znaków ASCII. Przesyłanie danych binarnych (np. skompilowany pro­ gram) do niepodejrzewającego podstępu programu spodziewającego się tekstu może być bardzo pouczające. Dobrze przygotowanych przypadków testowych często można używać do testowania róż­ nych programów. Na przykład zawsze należy sprawdzić, co się stanie, jeśli program wczytujący pliki otrzyma na wejściu pusty plik. Każdy program wczytujący tekst należy przetestować na

1 66

6. TESTOWANIE

plikach binarnych, a program, który wczytuje wiersze tekstu - na bardzo długich i pustych wierszach oraz danych całkowicie pozbawionych znaków nowego wiersza. Warto mieć taki ze­ staw testów zawsze pod ręką, aby móc za ich pomocą sprawdzić każdy program, bez konieczno­ ści zaczynania wszystkiego od nowa za każdym razem. Można też napisać program tworzący pliki testowe na żądanie. Kiedy Steve Bourne pisał swoją powłokę dla systemu Unix (która jest teraz znana pod na­ zwą powłoki Bourne'a), to utworzył katalog zawierający 254 pliki o jednoznakowych nazwach - po jednej dla każdego bajta z wyjątkiem znaku \O i ukośnika, ponieważ tych dwóch zna­ ków nie można używać w nazwach plików w systemie Unix. Wykorzystywał go do wszelkich testów dotyczących dopasowywania wzorców i podziału tekstu na leksemy (katalog testowy był oczywiście tworzony przez program). Przez wiele lat katalog ten był zmorą programów do przeszukiwania drzewa plików. Wyciskał z nich siódme poty. '

'

Ćwiczenie 6.10. Spróbuj utworzyć plik, który spowoduje awarię Twojego ulubionego edytora tekstu, kompilatora lub innego programu.

6.6. Porady dotyczące testowania Doświadczeni testerzy stosują wiele rozmaitych sztuczek i technik, aby przyspieszyć swoją pra­ cę. W tym podrozdziale przedstawimy kilka naszych ulubionych technik. Każdy program powinien sprawdzać granice tabeli (jeśli język programowania nie robi tego automatycznie), ale jeśli rozmiary tablic są duże w porównaniu z typową porcją danych wej­ ściowych, to kod sprawdzający granice tablic może nigdy nie zostać przetestowany. Aby przete­ stować także te procedury, od czasu do czasu zmniejsz na krótko rozmiary tablic, co jest znacznie łatwiejsze niż tworzenie dużych przypadków testowych. Stosując podobną technikę, przetestowa­ liśmy kod powiększający tablicę, który zaprezentowaliśmy w rozdziale 2., i bibliotekę CSV, po­ kazaną w rozdziale 4. W istocie zostawiliśmy nawet te niewielkie wartości początkowe na stałe, ponieważ dodatkową złożoność początkową tego rozwiązania można zaniedbać. Zmuś funkcję mieszającą do zwracania stałej wartości, aby dzięki temu wszystkie elementy zostały zapisane w jednym kubełku. To pozwoli Ci zbadać algorytm tworzenia łańcuchów ele­ mentów oraz podpowie, jaka jest wydajność programu w najgorszym przypadku. Napisz własną wersję funkcji alokującej pamięć, która celowo po krótkim czasie będzie po­ pełniać błąd. Następnie użyj jej do sprawdzenia, jak Twój program radzi sobie z błędami braku pamięci. Poniższa funkcja zwraca wartość NULL po dziesiątym wywołaniu: /* testmal/oc: zwraca wartość NULL po 1 O. wywołaniu */

void *testmal l oc (s i ze-t n) { stat i c i nt count O; i f (++count > 1 0 ) return NULL; el se return mal l oc (n ) ; =

Zanim przekażesz program do użyrku, wyłącz w nim wszystkie warunki ograniczające wy­ dajność. Kiedyś szukaliśmy przyczyn niskiej wydajności kompilatora i okazało się, że była nią funkcja, która zawsze zwracała zero, ponieważ ktoś nie usunął kodu testowego.

6.7. KTO ZAJMUJE SIĘ TESTOWANIEM

167

Tablice i zmienne inicjalizuj różnymi wartościami, zamiast wszystkim domyślnie przypi­ sywać zero. Dzięki temu, jeśli sięgniesz poza granice tablicy albo użyjesz niezainicjalizowanej zmiennej, masz większe szanse, że to zauważysz. Stała OxDEADBEEF zdecydowanie wyróżnia się wśród danych zwracanych przez programy diagnostyczne. Niektóre funkcje alokujące pamięć używają takich wartości, aby pomóc w wykrywaniu niezainicjalizowanych danych. Zmieniaj zestaw testów, zwłaszcza jeśli ręcznie tworzysz niewielkie testy. Bardzo łatwo można popaść w rutynę, testując zawsze ten sam aspekt programu, i nie zauważyć, że w innym miejscu też mógł powstać błąd. Nie kontynuuj pracy nad nowymi obiektami i nie testuj istniejących, jeżeli wiesz, że pro­ gram zawiera jakieś błędy. Mogą one wpływać na otrzymywane wyniki. W wynikach testów powinny znajdować się informacje o ustawieniach wszystkich parame­ trów wejściowych, aby można było te testy dokładnie powtórzyć. Jeśli w programie są używane liczby losowe, znajdź sposób na ustawianie i drukowanie wartości początkowej generatora, nie­ zależnie od tego, czy testy również są losowe. Upewnij się, że dane wejściowe testu i odpowia­ dające im wyniki są poprawnie zidentyfikowane, aby można je było zrozumieć i odtworzyć. Zawsze dobrze jest mieć możliwość kontrolowania liczby i typu danych wyjściowych pod­ czas działania programu. Dodatkowe wyniki mogą być pomocne podczas testowania. Wykonuj testy na wielu różnych maszynach, w kompilatorach i systemach operacyjnych. Każda kombinacja tych trzech czynników może ujawnić błędy, których nie dałoby się wykryć w innych warunkach, np. zależne od kolejności bajtów, rozmiaru liczb całkowitych, sposobu postępowania z pustymi wskaźnikami, obsługi znaków powrotu karetki i nowego wiersza, a także specyfiki bibliotek i plików nagłówkowych. Testy na różnych maszynach pozwalają również od­ kryć problemy związane z łączeniem poszczególnych składników w jedną całość w celu przygo­ towania programu do użytku oraz mogą wykryć niezamierzone zależności od środowiska, w którym były tworzone (więcej na ten temat piszemy w rozdziale 8.). W rozdziale 7. omówimy testowanie wydajności programów.

6. 7. Kto zajmuje się testowaniem Działania wykonywane przez twórcę implementacji lub kogoś innego, kto ma dostęp do kodu źródłowego programu, nazywa się testowaniem białej skrzynki (określenie to powstało przez słabą analogię do testowania czarnej skrzynki, czyli takiego, w którym osoba testująca nie ma dostępu do kodu źródłowego; lepsze byłoby określenie „testowanie przejrzystej skrzynki"). Testy zawsze należy wykonać samodzielnie. Nie powinno się liczyć na to, że jakaś firma lub jakiś użytkownik zrobią to za nas. Jednak przy testowaniu własnego kodu można bardzo łatwo ulec złudzeniu, że wykonujemy bardzo skrupulatne testy, gdy w istocie tak nie jest. Dlatego staraj się zapomnieć o kodzie źródłowym i zająć testowaniem przypadków trudnych, a nie ła­ twych. Don Knuth tak opisuje, jak tworzył testy do swojego programu TEX: „Wprowadzam się w najzłośliwszy i najpaskudniejszy nastrój, w jaki tylko zdołam się wprawić, a następnie piszę najbardziej podstępny kod, jaki tylko zdołam wymyślić. Później kod ten wbudowuję w jeszcze obrzydliwsze konstrukcje, które są wręcz prawie nieprzyzwoite". Celem testowania jest znalezienie błędów, a nie stwierdzenie, że program działa. Dlatego testy powinny być trudne, a wykrycie za ich pomocą błędów nie oznacza Twojej niekompetencji, lecz przeciwnie - jest potwierdzeniem słuszności zastosowanych metod. Podczas testowania czarnej skrzynki osoba wykonująca testy nie ma dostępu do kodu źródło­ wego testowanego programu i nic nie wie o jego wewnętrznej strukturze. Tak znajduje się in­ nego rodzaju błędy, ponieważ testujący szuka ich w inny sposób. Dobrym miejscem do rozpo­ częcia testowania czarnej skrzynki są warunki brzegowe. Później warto sprawdzić, jak program

168

6 . TESTOWANIE

radzi sobie z dużymi zbiorami danych oraz nietypowymi i niepoprawnymi danymi wejścio­ wymi. Oczywiście należy również przetestować program w typowych, zwykłych warunkach, aby zweryfikować jego podstawową funkcjonalność. Następnym etapem w procesie testowania jest przekazanie programu użytkownikom po­ trafiącym robić z programem takie rzeczy, których nigdy byśmy się nie spodziewali. Ta faza testów powinna występować jeszcze przed przekazaniem programu do ogólnego obrotu, ale niestety wiele programów trafia na rynek bez żadnego porządnego testowania. Jednym ze spo­ sobów przetestowania programu na dużej liczbie użytkowników jest opublikowanie go w wersji beta, ale nie można tego traktować jako zastępnika porządnego, systematycznego testowania. Jednak w miarę jak system się rozrasta i komplikuje, a terminy zaczynają coraz bardziej gonić, presja, aby oddać oprogramowanie do uŻytku bez odpowiednich testów, staje się coraz większa. Trudno testuje się programy interaktywne, zwłaszcza takie, do których obsługi używana jest mysz. Część testów można wykonać przy użyciu skryptów (ich właściwości zależą od języ­ ka, środowiska itp.). Programami interaktywnymi powinno dać się sterować przy użyciu skryp­ tów symulujących ludzkie zachowania, aby można było je testować za pomocą automatów. Jed­ ną ze stosowanych technik jest podglądanie i odtwarzanie zachowań prawdziwych uŻytkowników. Innym sposobem może być utworzenie języka skryptowego do opisu kolejności i czasu trwania zdarzeń. Na zakończenie zastanów się, jak przetestować same testy. W rozdziale 5. wspomnieliśmy o tym, ile kłopotów sprawił nam błąd w teście programu do obsługi list. Jeśli do testów regresywnych wkradnie się błąd, może on bruździć przez długi czas. Wyniki testów nic nam nie powiedzą o rze­ czywistym stanie programu, jeżeli testy same zawierają błędy.

6.8. Testowanie programu markov Program realizujący algorytm Markowa, który opisaliśmy w rozdziale 3„ jest na tyle skompli­ kowany, że wymaga starannego przetestowania. Trudno zweryfikować poprawność jego wyni­ ków, ponieważ z założenia zwraca bezsensowny tekst, a ponadto napisaliśmy go w kilku języ­ kach programowania. Co gorsza, wyniki tego programu są losowe, a więc za każdym razem inne. Jak możemy wykorzystać wiedzę zdobytą w tym rozdziale do przetestowania wspomnianego programu? Pierwszy zestaw testów będzie zawierał zbiór niewielkich plików, które pozwolą sprawdzić warunki brzegowe. Dzięki nim upewnimy się, że program prawidłowo działa na danych skła­ dających się z zaledwie kilku słów. Dla przedrostków złożonych z dwóch słów użyjemy pięciu plików zawierających odpowiednio (każde słowo znajduje się w osobnym wierszu):

(pusty pl i k) a a a a

b b b

c c

d

W przypadku każdego z tych plików na wyjściu powinno pojawić się dokładnie to samo, co zostało podane na wejściu. Testy ujawniły kilka pomyłek o jeden, popełnionych przy inicjali­ zowaniu tablicy oraz uruchamianiu i wyłączaniu generatora. Drugi test miał na celu sprawdzenie algorytmów przechowywania danych. Dla przedrost­ ków dwuwyrazowych każde słowo, każda para słów i każda trójka słów, które pojawiły się na wyjściu, musi również występować w danych wejściowych. Napisaliśmy w języku Awk pro-

6.8. TESTOWANIE PROGRAMU MARKOV

1 69

gram wczytujący oryginalne dane do gigantycznej tablicy, tworzący tablicę z wszystkich par i trójek słów, a następnie wczytujący wyniki programu markov do innej tablicy i porównujący zawartość obu tych tablic: # Test programu markov: sprawdza, czy wszystkie słowa, pary słów i trójki słów zwrócone na wyjściu # w tablicy ARGV[2] znajdują się również w oryginalnych danych wejściowych w tablicy ARGV[J]

BEG I N { whi l e (get l i ne O) for ( i = l; i <= N F ; i ++) # S łowa wej ś c i owe wd [++nw] = $ i s i ng l e [$ i ] ++ } for (i = l ; i < nw; i ++) pai r [wd [ i ] ,wd[i +l] ] ++ for ( i l ; i < nw- 1 ; i ++) tri p l e [wd [ i ] , wd [ i +l] , wd [i +2] ] ++ =

whi l e (getl i ne O) { outwd [++ow] = $0 # Słowa wyj ści owe i f ( ! (SO i n s i ngl e) ) pri nt "Ni eoczekiwane s łowo " , $0 for ( i = l ; i < ow; i ++) i f ( ! ( (outwd [ i ] , outwd [ i +l] ) in pai r) ) pri nt "Ni eoczekiwana para " , outwd [i ] , outwd [i +l] for (i = l; i < ow- 1 ; i ++) i f ( ! ( (outwd [ i ] , outwd [ i +l] , outwd [i +2] ) i n tri p l e) ) pri nt " N i eoczeki wana trój ka " , outwd [ i ] , outwd [i+l] , outwd [i +2]

Naszym celem nie było napisanie wydajnego testu, lecz raczej uzyskanie możliwie jak naj­ prostszego programu testującego. Porównanie wyjściowego pliku zawierającego 10 tysięcy słów z plikiem wejściowym zawierającym 42 685 słów zajmuje mu około sześciu do siedmiu sekund, a więc niewiele więcej, niż niektóre wersje programu ma rkov potrzebowały na wygenerowanie wyniku. Sprawdzając przechowywanie danych, wykryliśmy poważny błąd w implementacji napisanej w Javie: program od czasu do czasu nadpisywał elementy w tablicy mieszania, po­ nieważ zamiast tworzyć kopie przedrostków, używał referencji. Ten test dowodzi, że czasami łatwiej sprawdzić właściwości danych wyjściowych, niż te dane wytworzyć. Na przykład łatwiej sprawdzić, czy zawartość pliku jest posortowana, niż ją posortować. Trzeci test ma charakter statystyczny. Na wejściu podajemy następującą sekwencję znaków: a b c a b c . . . abd . . . Między każdą parą ciągów abd występuje dziesięć ciągów abc. Jeśli losowe wybieranie działa prawidłowo, to w danych wyjściowych powinno się znajdować około dziesięć razy więcej liter c niż d. Sprawdzamy to oczywiście za pomocą funkcji freq. Po przeprowadzeniu analizy statystycznej stwierdziliśmy, że w danych zwracanych przez program napisany w Javie, który dla każdego przyrostka miał licznik, znajdowało się około dwadzieścia razy więcej liter c niż d, a więc dwa razy za dużo. Po krótkiej konsternacji przy­ pomnieliśmy sobie, że generator liczb losowych w Javie zwraca zarówno dodatnie, jak i ujemne liczby całkowite.

1 70

6. TESTOWANIE

W końcu wprowadziliśmy do programu zwykły tekst w języku angielskim, aby przekonać się, czy zwróci piękny nonsens. Oczywiście taki sam test przeprowadziliśmy też we wczesnej fazie pracy nad programem. Ale nie przestaliśmy testować, gdy program obsługiwał typowe dane, ponieważ najgorsze sytuacje zdarzają się w praktyce. Uzyskiwanie dobrych wyników w ła­ twych przypadkach może prowadzić na manowce. Trzeba też przetestować trudniejsze przy­ padki. Najlepszym sposobem na ominięcie tej pułapki jest automatyzacja i systematyczne wy­ konywanie testów. Wszystkie testy były zautomatyzowane. Skrypt powłoki generował dane wejściowe, wyko­ nywał i synchronizował testy oraz drukował informacje o wszelkich anomaliach na wyjściu. Można go było konfigurować, dzięki czemu wszystkie testy nadawały się do zastosowania przy każdej wersji programu markov. Cały zestaw testów powtarzaliśmy za każdym razem, gdy wprowa­ dziliśmy jakąkolwiek zmianę w programie, aby sprawdzić, czy nic się nie zepsuło.

6.9. Podsumowanie Im staranniej podejdziesz do pisania kodu od samego początku, tym mniej będzie w nim błę­ dów i tym większą będziesz mieć pewność, że testy wyczerpująco go sprawdziły. Testując wa­ runki brzegowe w trakcie pisania, można skutecznie wyeliminować wiele głupich, drobnych usterek. Systematyczne testowanie ma na celu pilnowanie potencjalnych miejsc wystąpienia błędów w zorganizowany sposób. Błędy najczęściej pojawiają się na różnych granicach, które można badać zarówno ręcznie, jak i programowo. Testowanie, jeśli to tylko możliwe, należy wykonywać w sposób zautomatyzowany, ponieważ komputery nie robią błędów ani się nie mę­ czą i nie dadzą się nabrać, że coś dobrze działa, jeśli tak nie jest. Testowanie regresywne po­ zwala przekonać się, czy program w aktualnej wersji nadal zwraca takie same wyniki, jak jego poprzednie wersje. Wykonywanie testów po wprowadzeniu każdej niewielkiej zmiany jest efektyw­ ną metodą wykrycia źródeł problemów, ponieważ nowe błędy najczęściej pojawiają się w świeżo napisanym kodzie. Najważniejsza zasada testowania brzmi: testuj swój kod.

Li teratura uzupełnia jąca Jednym ze sposobów na naukę testowania jest studiowanie przykładów najlepszych ogólnodo­ stępnych programów. Don Knuth w artykule The Errors of TEX opublikowanym w magazynie „Software - Practice and Experience" (1989, R. 19, nr 7, s. 607 - 685) opisuje wszystkie błędy znalezione w jego programie oraz omawia swoje techniki testowania. Doskonałym przykładem wyczerpującego testowania jest test TRIP dla programu TEX. Także język Perl jest zaopatrzony w rozbudowany zestaw testowy, który ma za zadanie weryfikację jego poprawności po kompilacji i instalacji w nowym systemie. Dodatkowo zawiera różne moduły, np. MakeMaker i TestHarness, które pomagają w tworzeniu testów rozszerzeń języka. Jon Bentley napisał serię artykułów, które zostały opublikowane w magazynie „Communi­ cations of the ACM" i które następnie ponownie zamieszczono w książkach Programming Pearls i More Programming Pearls wydanych odpowiednio w latach 1986 i 1988 przez wydawnictwo Addison-Wesley. Znajduje się w nich wiele wzmianek na temat testowania, zwłaszcza dotyczą­ cych ram organizacyjnych i służących do mechanizacji wszechstronnych testów.

7

Wydajność

Jak sam był niegdyś wielki - w obietnicach, A w ich spełnieniu, jak jest dziś - nicością.

W. Szekspir, Sławna historia życia Henryka VIII (przeł. L. Ulrich, Dzieła dramatyczne, t. IV. Warszawa, PIW 1 958)

Dawno, dawno temu programiści dwoili się i troili, aby ich programy jak najefektywniej wyko­ rzystywały dostępne zasoby, ponieważ ówczesne komputery były wolne i drogie. Dziś te urzą­ dzenia są znacznie tańsze i o wiele szybsze, a więc nie ma już konieczności wyciskania z nich wszystkiego, co się da. Czy nadal warto dbać o wydajność? Tak, ale pod warunkiem, że jest do tego ważny powód, program działa naprawdę wolno oraz można przypuszczać, iż przyspieszenie działania programu nie naruszy jego poprawności, niezawodności i klarowności. Szybki program, który zwraca niepoprawne wyniki, to żadna oszczędność czasu W związku z tym pierwsza zasada optymalizacji brzmi: nie rób tego. Czy program jest już wystarczająco dobry? Czy wiedząc, do czego i w jakim środowisku program będzie używany, możesz stwierdzić, że jego przyspieszenie przyniesie jakieś realne korzyści? Programy pisane przez studentów w ramach ćwiczeń nigdy nie są później używane, a więc ich szybkość rzadko ma znaczenie. Również szybkość działania programów do użytku osobistego, okazjonalnych narzędzi, ram testowych, eksperymentalnych aplikacji i prototypów nie jest ważna. Natomiast w produktach komercyjnych i ważnych składnikach programów, np. bibliotekach graficznych, prędkość jest jednym z najważniejszych parametrów. Dlatego musimy dobrze zrozumieć, jak należy podchodzić do kwestii wydajności. Kiedy trzeba spróbować przyspieszyć działanie programu? Jak to zrobić? Jakich efektów można się spodziewać? W tym rozdziale opisujemy sposoby przyspieszania działania progra­ mów i ograniczania ilości używanej przez nie pamięci. Zazwyczaj najważniejsza jest prędkość, dlatego skupimy się głównie na tym aspekcie. Optymalizacja wykorzystania pamięci (głównej i dyskowej) również bywa konieczna, choć rzadziej. Dlatego jej także poświęcimy nieco czasu i miejsca. Zgodnie z tym, co napisaliśmy w rozdziale 2„ najlepszą strategią, jaką możemy przyjąć, jest używanie najprostszych i najbardziej przejrzystych algorytmów i struktur danych, które wystarczą do wykonania określonego zadania. Następnie powinno się sprawdzić wydajność programu

1 72

7. WYDAJNOŚĆ

i ewentualnie w razie potrzeby zoptymalizować go. Włącz w kompilatorze opcje generowania jak najszybszego kodu. Sprawdź, jakie zmiany w samym programie odniosą największy skutek. Wprowadzaj po jednej zmianie i sprawdzaj, co się dzieje. Zachowaj też prostsze wersje progra­ mu, aby móc porównać z nimi te nowsze. Wykonywanie pomiarów to jedna z najważniejszych czynności wykonywanych podczas optymalizacji wydajności, ponieważ zwykłe rozumowanie i intuicja często zawodzą i trzeba je wspomagać takimi narzędziami, jak polecenia mierzenia czasu i programy profilujące. Popra­ wianie wydajności programów ma wiele wspólnego z testowaniem. Tu również korzysta się z takich technik, jak automatyzacja, skrupulatne zapisywanie wprowadzanych zmian oraz testowanie regresywne mające na celu sprawdzenie, czy zmiany nie spowodowały usterek i nie zniweczyły wcześniejszych ulepszeń. Jeśli od podstaw będziesz mądrze dobierać algorytmy i starannie pisać kod, to po zakoń­ czeniu pracy żadna optymalizacja może nie być potrzebna. Często w dobrze zaprojektowanym kodzie nawet niewielkie zmiany pozwalają rozwiązać problemy z wydajnością. Natomiast źle zaprojektowany kod zwykle wymaga poważnych zmian na dużych obszarach.

7 1 Wąskie gardło .

.

Na początku pozwolimy sobie opisać własny przypadek, gdy to usunęliśmy wąskie gardło w zasadniczym programie naszego lokalnego systemu. Docierająca do nas poczta elektroniczna przechodzi przez maszynę, nazywaną bramą, która łączy naszą wewnętrzną sieć z internetem zewnętrznym. Wiadomości elektroniczne przycho­ dzące z zewnątrz - ponieważ jest nas kilka tysięcy osób, każdego dnia przepływają dziesiątki tysięcy wiadomości - docierają do bramy, skąd zostają przekazane do sieci wewnętrznej. Dzięki temu rozdzieleniu nasza prywatna sieć jest oddzielona od publicznego internetu i możemy każdemu uźytkownikowi udostępnić tę samą nazwę maszyny (bramy). Jednym z zadań bramy jest odfiltrowywanie spamu, czyli niechcianej poczty zawierającej reklamy produktów wątpliwej jakości. Po zakończeniu prób powodzeniem filtr został zainsta­ lowany na stałe jako usługa dostępna dla wszystkich użytkowników bramy. Wówczas od razu uwidocznił się problem. Maszyna reprezentująca bramę nie dość że była już nieco wiekowa, to na dodatek już wcześniej miała sporo pracy, a teraz po prostu zadanie ją przerosło, ponieważ program filtrujący działał bardzo powoli. W rzeczywistości więcej czasu zajmowało samo fil­ trowanie poczty niż wszystkie inne czynności przetwarzania poszczególnych wiadomości. To szybko doprowadziło do powstania długiej kolejki listów e-mail, których dostarczanie było opóźnione o kilka godzin przez system próbujący nadążyć z wykonywaniem zadań. To jest przykład rzeczywistego problemu z wydajnością: program działał zbyt wolno, przez co ludzie musieli znosić długie opóźnienia w dostarczaniu poczty. Działanie programu trzeba było koniecznie przyspieszyć. W uproszczeniu zasadę działania filtra niechcianych wiadomości można opisać następują­ co: każda przychodząca wiadomość jest traktowana jak pojedynczy łańcuch znaków. Program wyszukujący wzorce tekstowe analizuje taki łańcuch w poszukiwaniu wyrażeń, które pojawiają się w znanych wiadomościach spamowych, takich jak np. „Powiadomienie o wygranej" albo „Wygrana na loterii''. Technika ta działa niezwykle skutecznie, gdyż większość niechcianych wiadomości powtarza się wielokrotnie. Jeśli jakaś niechciana wiadomość prześliźnie się przez filtr, to zostaje dodana do jego bazy danych, aby następnym razem została już przechwycona. Ponieważ żadne z istniejących narzędzi do wyszukiwania łańcuchów tekstu, takich jak np. grep, nie oferowało odpowiedniej kombinacji szybkości przetwarzania i wygody użycia, zdecy­ dowano się na napisanie specjalnego filtra. Pierwsza wersja kodu była bardzo prosta. Program

7.1. WĄSKIE GARDŁO

1 73

ten przeszukiwał wszystkie wiadomości w celu sprawdzenia, czy nie zawierają któregoś z „za­ kazanych" wyrażeń (wzorców): /* isspam: sprawdza, czy w łańcuchu mesg występuje podłańcuch pat */

i nt i sspam(char *mesg)

i nt i ; for ( i O ; i < npat ; i ++) if (strst r (mesg , pat [i ] ) != NULL) { pri ntf ( " Spam: dopasowanie z ' %s ' \n " , pat [i ] ) ; return 1 ; =

return O ;

Jak można to przyspieszyć? Łańcuch musi zostać przeszukany, a najlepszym sposobem na zrobienie tego jest użycie funkcji strstr z biblioteki standardowej języka C - funkcja ta jest standardowa i bardzo wydajna. Po sporządzeniu profilu programu (o profilowaniu piszemy więcej w następnym podroz­ dziale) okazało się, że implementacja funkcji strstr miała pewne właściwości, które były wy­ jątkowo niekorzystne przy użyciu jej jako podstawy filtra spamu. Zmieniając sposób działania, zoptymalizowaliśmy funkcję strstr pod kątem tego konkretnego problemu. Ówczesna implementacja funkcji strstr wyglądała następująco: /* Prosta wersjafankcji strstr: używafankcji strchr do wyszukiwania pierwszego znaku */

char *strstr (const char *s l , const char *s2) { i nt n ; n strl en (s2) ; for ( ; ; ) { sl = strchr ( s l , s2 [0] ) ; i f ( s l == NULL) return NULL; if (strncmp ( s l , s2 , n ) == O) return (char *) s l ; s l++; =

Funkcję tę napisano z myślą o jak najlepszej wydajności, i rzeczywiście - w typowych za­ stosowaniach działała bardzo szybko, ponieważ korzystała z wysoce zoptymalizowanych pro­ cedur bibliotecznych. Za pomocą funkcji strchr znajdowała kolejne wystąpienia pierwszego znaku wzorca, a następnie wywoływała funkcję strncmp w celu sprawdzenia, czy reszta łańcu­ cha odpowiadała pozostałej części wzorca. Dzięki temu pomijała większość tekstu wiadomości i przechodziła od razu do pierwszego wystąpienia pierwszego znaku pasującego do wzorca, a później szybko sprawdzała, co jest dalej. Jak to możliwe, że taki algorytm nie był wydajny? Istnieje kilka powodów. Po pierwsze funkcja strncmp pobiera jako argument długość wzorca, który musi obliczyć funkcja strl en. Ponieważ jednak wzorce są ustawione na stałe, to nie ma potrzeby obliczać ich długości za każdym razem od nowa. Po drugie funkcja strncmp zawiera skomplikowaną pętlę. Porównuje ona bajty dwóch łań­ cuchów i jednocześnie pilnuje, czy w którymś z nich nie pojawia się końcowy bajt \0, oraz

1 74

7. WYDAJNOŚĆ

utrzymuje licznik długości parametru. Długości wszystkich łańcuchów są znane z góry (acz­ kolwiek nie dla funkcji strncmp), dlatego te dodatkowe komplikacje są niepotrzebne. Wiemy, że długości się zgadzają, a więc szukanie bajta \O jest stratą czasu. Po trzecie funkcja strchr jest skomplikowana, ponieważ oprócz szukania znaku musi jed­ nocześnie uważać na znak \O oznaczający koniec wiadomości. Dla każdego wywołania funkcji i s spam wiadomość jest stała, a więc czas spędzony na poszukiwaniu znaku \O jest zmarnowany, gdyż z góry wiadomo, gdzie jest koniec wiadomości. W końcu mimo iż funkcje strncmp, strchr i strl en są wydajne, gdy używa się ich poje­ dynczo, to narzut spowodowany ich wywoływaniem jest porównywalny z kosztem wykonywa­ nych przez nie operacji. Działanie programu przyspieszymy, jeśli całą pracę zlecimy specjalnej, dobrze zaprojektowanej wersji funkcji strstr i całkiem pozbędziemy się wywołań pozostałych funkcji. Tego typu sytuacje często są źródłem problemów z wydajnością - procedura lub interfejs dobrze działają w typowych warunkach, ale w niezwykłych przypadkach, które stanowią cen­ tralny punkt programu, stają się niewydajne. Istniejąca funkcja strstr była dostatecznie wy­ dajna, jeśli wzorzec i łańcuch były krótkie i zmieniały się przy każdym wywołaniu. Jeśli jednak łańcuch jest długi i stały, to dodatkowy narzut jest bardzo duży. W związku z tym funkcja strstr została napisana od nowa tak, aby przeglądała treść wia­ domości i wzorzec, jednocześnie wyszukując dopasowania, i robiła to wszystko bez wywoływania żadnych dodatkowych procedur. Zachowanie takiej implementacji można przewidzieć: w niektó­ rych przypadkach działa wolniej, ale w filtrze spamu jest wyjątkowo szybka, a poza tym nigdy jej wydajność nie jest bardzo słaba. W celu zweryfikowania poprawności i wydajności nowej procedury opracowano zestaw testów. Znalazły się w nim nie tylko proste przypadki, jak szu­ kanie słowa w zdaniu, lecz także patologiczne sytuacje, takie jak szukanie wzorca pojedynczego x w łańcuchu składającym się z kilku tysięcy liter e oraz wzorca kilku tysięcy liter x w jednej literze e - oba te przypadki byłyby słabo obsługiwane przez prostą wersję funkcji. Takie eks­ tremalne sytuacje są kluczowym elementem branym pod uwagę przy szacowaniu wydajności. Do biblioteki wstawiono nową wersję funkcji s t r s t r, co spowodowało 30-procentowy przyrost wydajności filtra - całkiem sporo, jak na zmianę tylko jednej procedury. Niestety, to wciąż było za mało. Przy rozwiązywaniu problemów ważne jest zadawanie właściwych pytań. Do tej pory inte­ resowaliśmy się tylko sposobami maksymalizacji szybkości wyszukiwania wzorców tekstowych w łańcuchach znaków. Trudność wiąże się jednak z wyszukiwaniem dużych, stałych wzorców tekstowych w długich zmiennych łańcuchach. Tak formułując problem, można zauważyć, że funkcja strstr nie jest idealnym narzędziem do jego rozwiązania. Najlepszym sposobem na przyspieszenie działania programu jest użycie lepszego algoryt­ mu. Gdy sedno problemu stanie się jasne, można zastanowić się, jaki algorytm będzie najlepszy do jego rozwiązania. Podstawowa pętla for (i = O ; i < npat ; i ++) i f (strstr (mesg , pat [ i ] ) ! = NULL) return 1 ; skanuje wiadomość npat razy. Przyjmując, że nie znajdzie ani jednego łańcucha pasującego do wzorca, każdy bajt wiadomości zostanie przez nią zbadany n pat razy, co oznacza ogólną liczbę porównań na poziomie strl en (mesg) *npat. Lepszym rozwiązaniem byłoby odwrócenie pętli, tak aby wiadomość była skanowana raz w pę­ tli zewnętrznej, a wyszukiwanie wzorców odbywało się równolegle w pętli wewnętrznej :

1 75

7.1. WĄSKIE GARDŁO

for (j O ; mesg [j] ! = ' \O ' ; j++) i f (Znal ezi ono dopasowani e j ak i egoś wzorca, które zaczyna s i ę od mi ej sca mes g [j ] ) return 1 ; =

Poprawę wydajności można uzyskać dzięki zauważeniu prostego faktu. Aby dowiedzieć się, czy jakiś wzorzec pasuje do wiadomości w miejscu j, nie musimy przeglądać wszystkich wzorców, lecz tylko te, które zaczynają się od takiego samego znaku, jak mesg [j J . Można obliczyć, że dla 52 wielkich i małych liter liczba porównań powinna wynieść mniej więcej strl en (mesg) *npat/52. Wprawdzie częstość występowania liter w różnych miejscach w słowach nie jest równomierna - np. znacznie częściej na początku wyrazu można spotkać literę s niż x - a więc nie uzyskamy 52-krotnej poprawy wydajności, ale jakiś zysk będzie na pewno. W związku z tym tworzymy tablicę mieszania, w której funkcję klucza będzie pełnić pierwszy znak wzorca. Po wykonaniu pewnych obliczeń w celu utworzenia tablicy zawierającej wzorce zaczynające się od każdego znaku funkcja i s spam nadal jest krótka: i nt pat l en [NPAT] ; i nt start i ng [UCHAR MAX+l] [NSTART] ; i nt nstart i ng [UCHAR_MAX+l] ;

/*Długość wzorca */ /* Wzorce zaczynające się od znaku*/ /* Liczba taldch wzorców */

/* isspam: szuka w mesg wzorców pat */

i nt i sspam(char *mesg) { i nt i , j , k ; unsi gned char c ;

for (j = O ; (c = mesg [j] ) ! = ' \O ' ; j++) { for (i = O ; i < nstarti ng [c] ; i ++) { k = start i ng [c] [ i ] ; i f (memcmp (mesg+j , pat [k] , patl en[k] ) == O) { pri ntf ( " Spam: dopasowan i e z '%s ' \n " , pat [k] ) ; return 1 ;

return O ;

Dwuwymiarowa tablica start i ng [cJ [J dla każdego znaku c przechowuje wskaźniki na te wzorce, które zaczynają się od tego znaku. Towarzysząca jej tablica nstart i ng [cJ przechowuje informacje o tym, ile wzorców zaczyna się od znaku c. Gdyby nie było tych tablic, pętla we­ wnętrzna wykonywałaby od O do npat, a więc około tysiąca cykli. Natomiast teraz jest wyko­ nywana tylko od zera do dwudziestu razy, a w elemencie patl en [kJ przechowywany jest obli­ czony wcześniej wynik wywołania strl en (pat [kJ ) . Na rysunku widoczym na następnej stronie przedstawiono schemat opisywanych struktur danych dla trzech wzorców zaczynających się od litery b. Kod tworzący te tablice jest prosty: i nt i ; unsi gned char c ; for ( i = O ; i < npat ; i ++} { c pat [i ] [O] ; =

1 76

7. WYDAJNOŚĆ

i f (nstart i ng [c] >; NSTART) epri ntf( "Za dużo wzorców (>;%d) zaczyna s i ę od ' %c "' , NSTART, c ) ; start i ng [c] [nstart i ng [c] ++] ; i ; patl en [i ] ; strl en (pat [ i ] ) ;

nstart i ng :

3

start i ng :

[ .b' J

1 71 35197 1

pat l en :

[1 7 ]

4

[35 ]

9

[ 97 ]

14

pat :

W zależności od danych wejściowych ten filtr spamu jest od pięciu do dziesięciu razy szyb­ szy niż wersja, w której została użyta zmodyfikowana funkcja strstr, oraz od siedmiu do pięt­ nastu razy szybszy niż pierwotna implementacja. Nie udało się uzyskać przyspieszenia rzędu pięćdziesięciu dwóch razy częściowo ze względu na nierównomierną dystrybucję liter, czę­ ściowo dlatego, że w nowej wersji pętla jest bardziej skomplikowana, a po części dlatego, iż wciąż jest wykonywanych wiele nieudanych porównań. Niemniej jednak filtr spamu przestał już być wąskim gardłem. Problem z wydajnością został rozwiązany. W pozostałej części rozdziału omówimy techniki wykrywania problemów z wydajnością, znajdowania kodu odpowiedzialnego za spowolnienie oraz metody jego przyspieszania. Wcze­ śniej jednak spróbujemy wyciągnąć wnioski z przykładu filtra spamu. Przede wszystkim upewnij się, że w danym przypadku wydajność ma jakieś znaczenie. Gdyby filtr spamu nie sta­ nowił wąskiego gardła, to wszystkie nasze wysiłki byłyby grą niewartą świeczki. Gdy upewnili­ śmy się, że problem rzeczywiście istnieje, skorzystaliśmy z profilowania i innych technik, aby przeanalizować działanie programu i dowiedzieć się, w czym tkwi sedno tego problemu. Na­ stępnie upewniliśmy się, że rozwiązujemy właściwy problem, czyli zbadaliśmy cały program, a nie skoncentrowaliśmy się wyłącznie na funkcji strstr, która wydawała się oczywistym po­ dejrzanym, a okazało się, iż była niewinna. W końcu rozwiązaliśmy problem przez zastosowanie lepszego algorytmu i sprawdziliśmy, czy rzeczywiście działał szybciej. Kiedy uzyskaliśmy wy­ starczający efekt, zakończyliśmy pracę. Nie należy popadać w przesadę.

Ćwiczenie 7.1. Tablica odwzorowująca jeden znak na zbiór wzorców spowodowała poprawę wydajności o rząd wielkości. Zaimplementuj funkcję i s spam z użyciem dwóch znaków jako indeksu. Jaką to spowoduje poprawę? Są to proste specjalne przypadki struktury danych o na­ zwie drzew tńe. Większość z nich pozwala zwiększyć szybkość działania programu kosztem większego zużycia pamięci.

1 77

7.2. MIERZENIE CZASU WYKONYWANIA I PROFILOWANIE PRO GRAMU

7 2 Mierzenie czasu wykonywania i profilowanie program u .

.

Zautomatyzuj mierzenie czasu. W większości systemów dostępne jest polecenie pozwalające sprawdzić, ile czasu zajęło wykonywanie danego programu. W systemie Unix ma ono nazwę time: % t i me s l owprogram real user SYS %

7.O 6.2 0.1

Rezultatem wykonania powyższego polecenia są trzy liczby określające upływ czasu w se­ kundach. Pierwsza z nich (real ) określa, ile czasu zajęło wykonywanie programu; druga (us er) oznacza czas użycia procesora do wykonania programu użytkownika; trzecia (SYS) czas uży­ cia procesora przez system operacyjny w celu wykonywania programu. Jeśli w Twoim systemie jest podobne polecenie, to go użyj. Wartości uzyskane przy jego użyciu będą znacznie bardziej precyzyjne i godne zaufania niż pomiary wykonywane za pomocą stopera. Prowadź też skru­ pulatne notatki. Modyfikując program i mierząc jego wydajność, z czasem nazbierasz tyle in­ formacji, że zaczniesz się w nich gubić (która wersja działała o 20% szybciej?). Wiele metod te­ stowania, które opisaliśmy w poprzednim rozdziale, można zastosować także do mierzenia i poprawiania wydajności programów. Używaj komputera do przeprowadzania i mierzenia swoich zestawów testów i, co najważniejsze, stosuj testowanie regresywne, aby upewnić się, że razem ze zmianami nie wprowadzasz do programu błędów. Jeśli system nie udostępnia polecenia mierzenia czasu albo chcesz zbadać funkcję w izola­ cji, możesz bez trudu skonstruować ramę do pomiaru czasu, podobną do ramy do testowania. W językach C i C+ + dostępna jest standardowa funkcja O nazwie Cl OC k, która informuje, ile czasu procesora wykorzystano w danej chwili . Aby zmierzyć czas użycia procesora przez wybraną funkcję, należy funkcję c l o c k wywołać przed wywołaniem i po wywołaniu badanej funkcji: -

# i ncl ude # i ncl ude c l oc k_t before; doub l e el apsed ; before c l ock() ; l ong runni ng funct i o n ( ) ; el apsed = c l oc k ( ) - before; pri ntf ( " Funkcj a wykorzystała % . 3 f sekund\n " , el apsed/CLOCKS_PER_SEC) ; =

Współczynnik skalowania C LOCKS_PER_S EC reprezentuje liczbę tyknięć zegara w ciągu se­ kundy zgłaszaną przez funkcję cl ock. Jeśli wykonanie badanej funkcji zajmuje tylko niewielką cząstkę sekundy, należy ją wykonać wielokrotnie za pomocą pętli. Trzeba tylko pamiętać, aby doliczyć czas wykonywania pętli, jeśli jest on znaczący:

I

before for (i

= =

cl ock ( ) ; O; i < 1000; i ++)

1 78

7. WYDAJNOŚĆ

short runn i ng funct i on ( ) ; el apsed =-(c l o c k ()-before ) / (doubl e) i ; W Javie za pomocą metody klasy Da t e można sprawdzić ogólny upływ czasu, który jest przybliżony do czasu pracy procesora: Date before = new Date ( ) ; l ong runni ng functi o n ( ) ; Date-after =-new Date ( ) ; l ong el apsed = after . getT i me ( ) - before . getTime ( ) ; Metoda getTime zwraca wartość wyrażoną w milisekundach.

Używaj programu profilującego. Obok precyzyjnej metody pomiaru upływu czasu najważniej­ szym narzędziem służącym do analizy wydajności programów jest tzw. program profilujący (ang. profiler). Profil to zestawienie informacji na temat czasu wykonywania poszczególnych operacji przez program. Niektóre programy profilujące podają informacje o wszystkich funk­ cjach, liczbie ich wywołań oraz jaką część ogólnego czasu wykonywania programu zajęło ich wykonanie. Inne programy profilujące pokazują, ile razy została· użyta każda instrukcja. In­ strukcje wykonywane wielokrotnie zajmują najwięcej ogólnego czasu, natomiast obecność in­ strukcji, które w ogóle nie są używane, może świadczyć o istnieniu bezuŻytecznego kodu lub kodu nieuwzględnianego w testach. Profilowanie to doskonała metoda znajdowania w programie gorących punktów, czyli funkcji lub fragmentów, których wykonanie zajmuje najwięcej czasu. Do interpretacji wyni­ ków programów profilujących trzeba jednak podchodzić ostrożnie. Biorąc pod uwagę poziom zaawansowania kompilatorów, złożoność pamięci podręcznej i głównej oraz sam fakt, że pro­ gram profilujący również ma wpływ na wydajność badanego programu, trzeba pamiętać, że uzyskane dane statystyczne są tylko wartościami przybliżonymi. W artykule opublikowanym w 1971 roku Donald Knuth wprowadził pojęcie profilowania i napisał, że „mniej niż 4% całości programu zajmuje ponad połowę czasu jego wykonywania". Oznacza to, iż za pomocą profilowania należy znajdować najbardziej czasochłonne części pro­ gramu, poprawiać je, o ile to możliwe, a następnie ponownie dokonać pomiarów, aby spraw­ dzić, czy nie pojawił się jakiś nowy gorący punkt. Czasami już po jednym cyklu lub dwóch cy­ klach z programu znikają najbardziej oczywiste gorące punkty. Profilowanie najczęściej włącza się za pomocą specjalnego znacznika lub specjalnej opcji kompilatora. Po zakończeniu wykonywania programu specjalne narzędzie analityczne wyświe­ tla wyniki. W systemie Unix najczęściej używa się znacznika - p i narzędzia o nazwie prof:

% cc -p spamtest . c -o spamtest % spamtest % prof spamtest Poniższa tabela przedstawia profil wygenerowany dla specjalnej wersji filtra spamu, który utworzyliśmy w celach testowych. Używamy w nim stałej wiadomości i stałego zbioru 217 wy­ rażeń dopasowywanych do wiadomości 10 tysięcy razy. Program ten korzystał z oryginalnej wersji funkcji strst r, która wywoływała inne standardowe funkcje, i został uruchomiony na maszynie z procesorem MIPS 10000 250 MHz. Wyniki dostosowano do rozmiaru strony. Zwróć uwagę, jak rozmiary danych wejściowych (217 wyrażeń) i liczba wykonań programu (10 tysięcy) stanowią test spójności w kolumnie zatytułowanej „wywołania'', która zawiera liczby wywołań każdej funkcji.

1 79

7.2. MIERZENIE CZASU WYKONYWANIA I PROFILOWANIE PROGRAMU

12234768552 : 13961810001 : 5 5 , 847 : 1 , 141 :

Li czba wszystki ch wykonanych i nstrukcj i Li czba wszystki ch wykonanych cykl i Cał kowi ty czas wykonywan i a (w sekundach) Średn i a l i czba cykl i na rozkaz

s

%

45,260

81,0%

81,0%

11 314 990 ooo

9 440 1 10 ooo

48 350 ooo

strchr

6,081

10,9%

91,9%

1 520 280 ooo

1 566 460 ooo

46 180 ooo

strncmp

2,592

4,6%

96,6%

648 080 ooo

854 500 ooo

2 170 ooo

strstr

% kum.

cykle

wywołania

instrukcje

funkcja

1,825

3,3%

99,8%

456 225 559

344 882 2 1 3

2 170 435

strl en

0,088

0,2%

100,0%

21 950 ooo

28 510 ooo

10 ooo

i sspam

0,000

0,0%

100,0%

100 025

100 028

mai n

0,000

0,0%

100,0%

53 677

70 268

219

_memccpy

0,000

0,0%

100,0%

48 888

46 403

217

strcpy fgets

0,000

0,0%

100,0%

17 989

19 894

219

0,000

0,0%

100,0%

16 798

17 547

230

0,000

0,0%

100,0%

10 305

10 900

204

real free

0,000

0,0%

100,0%

6 293

7 161

217

estrdup

mal l oc

0,000

0,0%

100,0%

6 032

8 575

231

cl eanfree

0,000

0,0%

100,0%

5 932

5 729

readpat

0,000

0,0%

100,0%

5 899

6 339

219

getl i ne

0,000

0,0%

100,0%

5 500

5 720

220

mal l oc

Jest oczywiste, że funkcje strchr i strncmp, obie wywoływane przez funkcję strs tr, kom­ pletnie zdominowały program. Knuth miał rację: niewielka część programu zużywa większość czasu wykonywania. W pierwszym profilu programu najczęściej odkrywa się, że jakaś najbar­ dziej czasochłonna funkcja zajmuje połowę, a czasami nawet więcej czasu wykonywania, tak jak w przedstawionym przypadku. Dzięki temu nietrudno podjąć decyzję, na czym należy się skoncentrować.

Skup się na gorących punktach. Po przepisaniu funkcji strstr jeszcze raz sporządziliśmy profil programu s pamtest, aby odkryć, że 99,8% ogólnego czasu wykonywania zajmowała sama funkcja strs tr, mimo że program działał już znacznie szybciej. Jeśli jedna funkcja stanowi w programie tak wąskie gardło, to są tylko dwa wyjścia: zmienić algorytm funkcji na lepszy albo całkowicie pozbyć się funkcji i zmienić strukturę programu. My zdecydowaliśmy się na tę drugą zmianę. W poniższej tabeli przedstawiamy początkowy fragment profilu programu s pamtest, w którym użyliśmy ostatecznej, szybkiej wersji funkcji i s s pam. Jak widać, ogólny czas wykonywania został znacznie skrócony, gorącym punktem jest teraz funkcja memcmp, ale i funkcja i s spam stanowi znaczną część obliczeń. Kod tego pro­ gramu jest bardziej skomplikowany niż w wersji z użyciem funkcji strstr, ale rekompensuje nam to z nawiązką pozbycie się funkcji strl en i strchr z funkcji i ss pam i zastąpienie funkcji strncmp funkcją memcmp, która wykonuje mniej pracy na każdym bajcie.

1 80

7. WYDAJNOŚĆ

s

%

3,524

56,9%

% kum.

cykle

instrukcje

wywołania

56,9%

880 890 ooo

1 027 590 ooo

46 1 80 ooo

funkcja

memcmp

2,662

43,0%

100,0%

665 550 ooo

902 920 ooo

10 ooo

i sspam

0,001

0,0%

100,0%

140 304

106 043

652

str l en

0,000

0,0%

100,0%

100 025

100 028

mai n

Warto poświęcić trochę czasu na porównanie liczb cykli i wywołań w obu profilach. Za­ uważ, że liczba wywołań funkcji strl en spadła z kilku milionów do zaledwie 652, a funkcje st rncmp i memcmp są wywoływane po tyle samo razy. Zwróć również uwagę, że funkcja i s s pam, która przejęła zadania funkcji strchr, nadal zużywa znacznie mniej cykli, niż zużywała funk­ cja strchr, ponieważ w każdym kroku bada tylko te wzorce, które trzeba. Na podstawie analizy tych liczb można wyciągnąć jeszcze więcej wniosków dotyczących szczegółów wykonywania. Wiele gorących punktów można wyeliminować albo przynajmniej ochłodzić poprzez zasto­ sowanie prostszych technik niż te, których my użyliśmy w naszym filtrze. Kiedyś w profilu sporządzonym dla języka Awk odkryliśmy, że pewna funkcja w czasie testu regresywnego zo­ stała wykonana ponad milion razy. Działo się to w tej pętli: for (j = i ; j < MAXFLD; j++} cl ear(j ) ; Powyższa pętla czyszcząca pola przed wczytaniem nowego wiersza danych zajmowała po­ łowę czasu wykonywania. Stała MAXFLD, oznaczająca maksymalną dozwoloną liczbę pól w wier­ szu wejściowym, miała wartość 200. Jednak w większości zastosowań języka Awk liczba pól wynosiła zaledwie dwa lub trzy. W związku z tym ogromne ilości czasu były marnowane na czyszczenie pól, które nigdy nie zostały użyte. Zastąpienie tej stałej poprzednią wartością okre­ ślającą maksymalną liczbę pól dało 25-procentową poprawę ogólnej szybkości działania. Po­ prawka polegała na zmianie górnego limitu pętli: for (j = i ; j < maxfl d ; j++} cl ear (j ) ; maxfl d = i ;

Korzystaj z pomocy graficznych. Wyniki pomiarów wydajności szczególnie dobrze prezentują się graficznie. Na rysunku można uwidocznić efekty zmian parametrów, dokonać porównania al­ gorytmów i struktur danych, a czasami nawet wskazać niespodziewane zachowania. Na przed­ stawionych w rozdziale 5. wykresach długości łańcuchów dla różnych wartości mnożnika było wyraźnie widać, że niektóre mnożniki są znacznie lepsze od innych. Poniższy wykres przedstawia wpływ wielkości tablicy mieszania na czas działania progra­ mu markov w wersji napisanej w języku C, której na wejściu podano tekst z Księgi Psalmów (42 685 słów, 22 482 przedrostki). Przeprowadziliśmy dwa eksperymenty. W pierwszym użyliśmy tablic o rozmiarach będących potęgami liczby 2 - od 2 do 16 384. W drugim natomiast jako rozmiary tablic zastosowaliśmy największe liczby pierwsze mniejsze od poszczególnych potęg dwójki. Chcieliśmy się dowiedzieć, czy użycie liczby pierwszej jako rozmiaru tablicy ma jakiś znaczący wpływ na wydajność.

181

7.3. STRATEGIE PRZYSPIESZANIA

Potęga l iczby 2

SO 20 10 Czas działania (s)

Liczba pie rwsza ·.

5 2 1 0,5 0,2 -

t--����,..-,��,.----� 10

1 00

1 000

1 0000

Rozmiar ta b l icy mieszania

Z wykresu wynika, że czas działania programu dla tych danych wejściowych nie jest zależ­ ny od rozmiaru tablicy, jeśli ma ona rozmiar większy niż tysiąc elementów. Nie widać też pra­ wie żadnej różnicy między rozmiarami będącymi potęgami liczby dwa i liczbami pierwszymi.

Ćwiczenie 7.2. Bez względu na to, czy Twój system ma polecenie t i me, czy nie, napisz własny algorytm do mierzenia czasu przy użyciu funkcji c l ock i getTi me. Porównaj zwracane przez niego wyniki z wynikami pomiarów zwykłego zegara. Jak inne procesy wykonywane w kompu­ terze wpływają na pomiary czasu? Ćwiczenie 7.3. Z informacji w pierwszym profilu wynika, że funkcja strchr została wywołana 48 350 OOO razy, a strncmp tylko 46 180 OOO razy. Wyjaśnij, skąd się wzięła ta różnica.

7.3. Strategie przyspieszania Zanim zaczniesz modyfikować program, aby go przyspieszyć, upewnij się, czy istotnie jest za wolny, oraz użyj narzędzi do mierzenia czasu i profilowania, aby sprawdzić, na co jest zużywane najwięcej czasu. Kiedy dowiesz się, w czym tkwi problem, masz do wyboru kilka możliwości. Przedstawiamy niektóre z nich w kolejności od najkorzystniejszej.

Użyj lepszego algorytmu albo lepszej struktury danych. Najważniejszymi czynnikami mają­ cymi wpływ na szybkość działania programu są algorytmy i struktury danych. Wydajny algo­ rytm od niewydajnego może dzielić przepaść. Zmiana struktury danych w naszym filtrze spamu spowodowała dziesięciokrotne przyspieszenie pracy programu. Gdyby w nowym algorytmie zmienić jeszcze kolejność wykonywania obliczeń, to można by uzyskać jeszcze lepszy rezultat, np. O(nlogn) zamiast O(n2). Temat ten omówiliśmy w rozdziale 2., a więc nie będziemy się już tutaj nad tym rozwodzić. Upewnij się, że rzeczywista złożoność obliczeniowa programu odpowiada Twoim przewi­ dywaniom. Rozbieżność w tej kwestii może wskazywać na istnienie jakiegoś ukrytego błędu powodującego pogorszenie wydajności. Zapisany niżej, na pozór liniowy algorytm przeglądający łańcuchy

1 82

7. WYDAJNOŚĆ

for (i = O ; i < strl e n ( s ) ; i ++) i f ( s [i ] == c)

w rzeczywistości ma kwadratową złożoność obliczeniową: jeśli łańcuch s zawiera n znaków, to funkcja str l en za każdym razem przegląda n znaków tego łańcucha i pętla wykonuje n po­ wtórzeń.

Włącz opcje optymalizacji kodu w kompilatorze. Jedną z niewymagających żadnego wysiłku metod przyspieszania programu jest włączenie opcji optymalizacji kodu w kompilatorze. No­ woczesne kompilatory wykonują to zadanie tak dobrze, że z powodzeniem mogą zastąpić wiele drobniejszych zmian wprowadzanych przez programistów. Przy domyślnych ustawieniach większość kompilatorów języków C i C+ + nie robi zbyt dużo w celu optymalizacji kodu. Do włączania optymalizatora (lepszym określeniem byłoby słowo „poprawiacz") służy specjalna opcja kompilatora. Prawdopodobnie opcja ta byłaby włą­ czona domyślnie, gdyby nie to, że optymalizacja może wprowadzać w błąd programy diagno­ styczne, które działają na poziomie kodu źródłowego. Dlatego programiści powinni pamiętać o włączeniu optymalizacji, gdy uznają, że program jest już wolny od błędów. Kompilator zwykle poprawia wydajność w zakresie od kilku efo nawet 200%. Zdarza się jednak też tak, że zamiast zwiększenia szybkości program po optymalizacji zaczyna działać wolniej. Dlatego przed przekazaniem produktu do użytku należy sprawdzić efekt tych działań. Porównaliśmy skutki optymalizacji kilku różnych wersji naszego filtra spamu. W przypadku zestawu testowego, w którym została użyta ostateczna wersja algorytmu wyszukującego wzorce, optymalizacja skróciła czas wykonywania z 8,1 sekundy do 5,9 sekundy, co oznacza 25procentowy zysk w wydajności. Natomiast w wersji, w której była używana funkcja strstr, optymalizacja nie dała żadnego rezultatu, ponieważ funkcję strstr zoptymalizowano już pod­ czas dodawania jej do biblioteki. Optymalizacja działa tylko na kod źródłowy, który jest kom­ pilowany w danej chwili i nie dotyczy bibliotek systemowych. Jednak niektóre kompilatory mają tzw. globalne optymalizatory analizują one program całościowo w celu znalezienia miejsc nadających się do optymalizacji. Jeśli dysponujesz takim kompilatorem w swoim syste­ mie, to wypróbuj tę opcję. Może Ci ona przynieść kilka dodatkowych cykli oszczędności. Jedna rzecz, o której zawsze warto pamiętać, to fakt, że im agresywniej kompilator optyma­ lizuje kod, tym większe ryzyko, iż wprowadzi on do skompilowanego programu jakieś błędy. Dlatego po włączeniu optymalizatora ponownie przeprowadź testy regresywne, tak jak to ro­ bisz po każdej innej modyfikacji programu. -

Reguluj kod. Wybór algorytmu zaczyna mieć znaczenie dopiero przy odpowiednio dużych zbiorach danych wejściowych. Ponadto ulepszenia algorytmów mają wpływ na działanie pro­ gramu na wszystkich maszynach, w kompilatorach i językach programowania. Jeśli jednak mimo użycia właściwego algorytmu szybkość działania programu wciąż jest niezadowalająca, można spróbować podregulować kod źródłowy, tzn. wprowadzić drobne zmiany w pętlach i wyrażeniach, aby przyspieszyć wykonywanie niektórych czynności. Kod źródłowy funkcji i s s pam, który pokazaliśmy na końcu podrozdziału 7.1, nie był re­ gulowany. Poniżej przedstawiamy, jaką poprawę wydajności da się uzyskać, jeśli jeszcze dore­ gulujemy ten kod. Gwoli przypomnienia jeszcze raz pokazujemy użytą tam pętlę: for (j

=

O; (c = mes g [j ] ) ! = ' \O ' ; j ++) { for (i = O ; i < n starti ng [c] ; i ++) k = start i ng [c] [ i ] ; i f (memcmp (mesg+j , pat [k] , patl en [k] ) == O) { pri ntf ( "Spam : dopasowan i e z ' %s ' \n " , pat [k] ) ;

7.3. STRATEGIE PRZYSPIESZANIA

1 83

return 1 ;

Po kompilacji z włączonym optymalizatorem wykonanie tej wersji kodu w naszym zestawie testowym zajmuje 6,6 sekundy. W warunku wewnętrznej pętli znajduje się indeks tablicy (nstarti ng [c] ), którego wartość jest ustawiana w każdej iteracji pętli zewnętrznej. Możemy pozbyć się wielokrotnego obliczania tej wartości, jeśli zapiszemy ją w zmiennej lokalnej : for

(j = O ; (c = mesg [j] ) ! = ' \O ' ; j++) { n = nstart i ng [c] ; for (i = O ; i < n ; i ++) k = start i ng [c] [i ] ;

Dzięki tej modyfikacji czas wykonywania został skrócony do 5,9 sekundy, a więc o około 1 0%. Jest to typowe osiągnięcie w wyniku regulacji kodu. W kodzie jest jeszcze jedna zmienna, którą możemy wyciągnąć: wartość indeksu start i ng [c] również jest stała. Wydaje się, że wy­ ciągnięcie tego działania poza pętlę również powinno poprawić wydajność, lecz w naszych te­ stach nie wykryliśmy żadnej znaczącej zmiany. To także jest typowa cecha regulacji kodu: nie­ które zabiegi pomagają, a inne nie. Aby się dowiedzieć, jak jest, trzeba wykonać pomiary. Ponadto wyniki są różne w zależności od komputera i kompilatora. Moglibyśmy wprowadzić jeszcze jedną zmianę w naszym filtrze. Pętla wewnętrzna porów­ nuje z łańcuchem cały wzorzec, ale algorytm zapewnia to, że pierwszy znak zawsze pasuje. W związku z tym można by było tak dostroić kod, aby funkcja memcmp zaczynała pracę o jeden bajt dalej. Wypróbowaliśmy to i uzyskaliśmy 3-procentową poprawę wydajności, a więc nie­ wiele, chociaż trzeba przyznać, że musieliśmy zmienić tylko trzy wiersze kodu, z których jeden dotyczył obliczeń wstępnych.

Nie optymalizuj tego, co i tak nie ma znaczenia. Czasami regulacja kodu nic nie daje, ponie­ waż jest wykonywana w miejscu, które nie ma żadnego znaczenia. Optymalizując kod, miej pew­ ność, że to właśnie jego wykonanie zajmuje najwięcej czasu. Historia, którą tu przytoczymy, może nie być prawdziwa, ale i tak ją opowiemy. Podczas analizy wydajności sprzętu pewnego starego komputera wyprodukowanego przez nieistniejącą już firmę wykryto, że 50% czasu po­ chłaniało wykonywanie jednej sekwencji kilku instrukcji. Inżynierowie utworzyli specjalną instrukcję, która pełniła funkcję tej sekwencji, ponownie skompilowali system i nie stwierdzili żadnej różnicy. Zoptymalizowali jałową pętlę systemu operacyjnego. Ile wysiłku należy włożyć w przyspieszanie działania programu? Głównym kryterium w podejmowaniu tej decyzji jest to, czy przewidywane korzyści są warte zachodu. Można przy­ jąć ogólną zasadę, że programista nie powinien poświęcać na optymalizację więcej czasu, niż uda się zaoszczędzić podczas całego późniejszego cyklu użytkowania programu. Zgodnie z tą regułą zmiana algorytmu w postaci funkcji i s spam była opłacalna: jej wprowadzenie zajęło jeden dzień, a pozwoliło zaoszczędzić kilka godzin każdego dnia. Usunięcie indeksu tablicy z pętli wewnętrznej było mniej korzystne, ale również warte zachodu, ponieważ program świadczy usługi dla bardzo dużej liczby osób. Usługi publiczne, takie jak filtry spamu czy biblioteki, prawie zawsze warto optymalizować. Natomiast przyspieszanie programów testowych to prawie zawsze strata czasu. A jeśli dany program ma działać bez przerwy cały rok, to wyciśnij z niego wszystko, co się da. Jeśli znajdziesz sposób, jak uzyskać IO-procentową poprawę wydajności, być może warto będzie go nawet na chwilę zatrzymać, aby wprowadzić zmiany, nawet gdy pro­ gram jest w użyciu już od miesiąca.

1 84

7. WYDAJNOŚĆ

Do tej kategorii należą również wszystkie programy obecne na rynku konkurencji, a więc gry, kompilatory, procesory tekstu, arkusze kalkulacyjne i systemy bazodanowe. Sukces komercyj­ ny często odnosi ten program, który jest najszybszy, przynajmniej w testach porównawczych. Po dokonaniu zmian zawsze należy zmierzyć czas wykonywania programu, aby dowiedzieć się, czy zmiany te przyniosły efekty. Czasami dwie zmiany wprowadzone do programu mogą oddziaływać między sobą i się wzajemnie neutralizować. Warto też pamiętać, że margines błę­ du pomiarów czasu bywa tak duży, iż niekiedy trudno wyciągnąć jakieś wnioski na temat po­ prawy wydajności. Nawet w systemach używanych przez jedną osobę fluktuacje czasu mogą być nieprzewidywalne. Jeśli wahania zegara wewnętrznego (a raczej zwracanych przez niego wskazań) wynoszą 10%, to zmiany wydajności na poziomie tylko 1 0% trudno odróżnić od zwy­ czajnych fluktuacji.

7 4 Regulowanie kodu .

.

Kiedy zostanie wykryty gorący punkt w programie, można temu zaradzić na wiele sposobów. Poniżej przedstawiamy kilka propozycji, z których należy korzystać ostrożnie i które zawsze należy uzupełniać testowaniem regresywnym, aby upewnić się, iż ko d nadal działa poprawnie. Pamiętaj, że dobry kompilator niektóre z tych czynności wykona za Ciebie, a jeśli niepotrzeb­ nie skomplikujesz kod, to możesz mu nawet w tym przeszkodzić. Cokolwiek zrobisz, wykonaj pomiary, aby upewnić się, że przynioslo to zamierzone efekty.

Zbieraj wyniki wyrażeń. Jeśli jakieś czasochłonne obliczenia występują w wielu miejscach w pro­ gramie, wykonaj je tylko raz i wynik zapisz w zmiennej. Na przykład w rozdziale 1 . przedsta­ wiliśmy makro obliczające odległość poprzez wywołanie funkcji sqrt dwa razy pod rząd dla takich samych wartości. Tamten kod wyglądał tak: sqrt (dx*dx + dy*dy) + ( (sqrt (dx*dx + dy*dy) > O) ? . . . ) Pierwiastek wystarczy obliczyć tylko raz, a następnie jego wartość można wykorzystać dwa razy. Jeśli obliczenia są wykonywane wewnątrz pętli, ale nie zależą od niczego, co się w tej pętli zmienia, to przenieś je na zewnętrz, tak jak poniżej. Zamiast pisać: for (i = O ; i < nstarti ng [c] ; i ++) { napisz n nstarti ng [c] ; for (i O; i < n ; i ++) { =

Zastąp czasochłonne operacje lżejszymi. Określenie zmniejszenie mocy (ang. reduction in strength) nazywa metodę optymalizacji polegającą na zamianie kosztownych operacji na tań­ sze. W dawnych czasach oznaczało to wymianę operacji mnożenia na operację dodawania albo przesunięcia, ale teraz na niewiele się to już zdaje. Dzielenie i obliczanie reszty z dzielenia jest jednak wykonywane znacznie wolniej niż mnożenie. W związku z tym można nieco zyskać, jeśli uda się dzielenie zamienić na mnożenie przez odwrotność dzielnika albo obliczanie reszty na operację maskowania, jeżeli dzielnik jest potęgą dwójki. W językach C i C+ + można uzy­ skać przyspieszenie poprzez zamianę indeksów tablicy na wskaźniki, aczkolwiek większość

7.4. REGULOWANIE KODU

1 85

kompilatorów robi to automatycznie. Także zastąpienie wywołania funkcji prostym obliczeniem może być godne uwagi. Odległość na płaszczyźnie oblicza się według wzoru sqrt ( dx*dx+dy*dy), a więc b y dowiedzieć się, który z dwóch punktów znajduje się dalej, trzeba b y obliczyć dwa pierwiastki kwadratowe. Jednak tę samą informację można uzyskać przez porównanie kwadra­ tów odległości: i f (dxl*dxl+dyl*dyl < dx2*dx2+dy2*dy2)

Wynik tego porównania będzie taki sam, jak porównania pierwiastków kwadratowych tych wyrażeń. Inna możliwość występuje w programach poszukujących wzorców tekstowych, takich jak nasz filtr spamu i program grep. Jeśli wzorzec zaczyna się od konkretnego znaku, to można szybko przeszukać tekst wejściowy w celu znalezienia tego znaku. Jeżeli poszukiwanie zakoń­ czy się niepowodzeniem, to można całkiem zaniechać wywoływania cięższego mechanizmu do przeszukiwania tekstu.

Rozwijaj lub całkiem eliminuj pętle. Konfiguracja i wykonanie pętli zajmuje trochę czasu. Jeśli zawartość pętli jest niezbyt obszerna, a liczba powtórzeń niewielka, to można zoptymali­ zować kod poprzez zapisanie wszystkich iteracji sekwencyjnie. Na przykład poniższą pętlę for (i = O ; i < 3 ; i ++) a [ i ] = b [ i ] + c [i ] ; można rozwinąć tak: a [O] = b [O] + c [O] ; a [l] = b [l] + c [l] ; a [2] = b [2] + c [2] ; W ten sposób wyeliminowaliśmy narzut powodowany przez uruchamianie pętli, zwłaszcza rozgałęzienie, które może spowalniać nowoczesne procesory, przerywając przepływ sterowania. Jeśli pętla jest dłuższa, to można zastosować podobne przekształcenie w celu zmniejszenia liczby iteracji, a więc zamiast for (i = O ; i < 3*n ; i ++) a [ i ] = b [ i ] + c [i ] ; można napisać for (i = O ; i < 3*n ; i += 3) { a [ i +O] = b [i +O] + c [i +O] ; a [ i +l] b [i +l] + c [i + l] ; a [i +2] = b [i +2] + c [i +2] ;

Metodę tę można stosować tylko wówczas, gdy długość jest wielokrotnością rozmiaru kro­ ku. W przeciwnym razie potrzebny by był dodatkowy kod do obsługi końcówek, w którym łatwo popełnić błąd i który odbiera część zysku z optymalizacji.

1 86

7. WYDAJNOŚĆ

Zapisuj w pamięci podręcznej często używane wartości. Wartości zapisanych w pamięci podręcznej nie trzeba wielokrotnie obliczać. Idea pamięci podręcznej opiera się na wykorzy­ staniu zasady lokalności (ang. locality), tzn. spostrzeżenia, że programy (a także ludzie) zwykle częściej wykorzystują pobliskie i niedawno używane elementy niż starsze i bardziej odległe da­ ne. W sprzęcie komputerowym pamięć podręczna jest wykorzystywana w bardzo szerokim za­ kresie. W istocie dodanie jej do komputera potrafi znacznie zwiększyć jego szybkość działania. To samo dotyczy oprogramowania. Na przykład przeglądarki internetowe zapisują w pamięci podręcznej strony internetowe i obrazy, aby wyeliminować konieczność pobierania ich wol­ nym łączem internetowym. W pewnym programie do podglądu wydruku, który napisaliśmy wiele lat temu, nienależące do alfabetu znaki, jak np. V2, trzeba było wyszukiwać w tabeli. Z naszych pomiarów wynikało, że specjalne znaki były bardzo często używane do rysowania wierszy zawierających długie szeregi takich samych znaków. Wystarczyło zapisać w pamięci podręcznej tylko jeden najczęściej używany taki znak, aby zdecydowanie przyspieszyć działa­ nie programu na typowych zbiorach danych wejściowych. Idealnie, jeśli operacja zapisu danych w pamięci podręcznej jest niewidoczna z zewnątrz, dzięki czemu jedyny wpływ, jaki wywiera ona na resztę programu, to przyspieszenie. Dlatego we wspomnianym programie do tworzenia podglądu wydruku interfejs do funkcji rysującej znaki pozostał bez zmian. Jej wywołanie nadal wyglądało tak: drawchar (c) ; Oryginalna wersja funkcji drawchar wywoływała funkcję show(l ookup (c) ) . W implemen­ tacji z użyciem pamięci podręcznej do przechowywania ostatnio używanego znaku i jego kodu były stosowane wewnętrzne zmienne statyczne:

i f (c ! = l astc) { /* Aktualizacjapamięcipodręcznej */ l astc c; l astcode l ookup (c) ; =

=

show ( l astcode) ;

Napisz własną wyspecjalizowaną funkcję do alokowania pamięci. Często jedynym gorącym punktem programu jest alokacja pamięci, która objawia się dużą liczbą wywołań funkcji ma 1 l oc lub new. Jeśli większość tych operacji dotyczy przydziału bloku pamięci o takim samym -

rozmiarze, to można zaoszczędzić dużo czasu przez zamianę ogólnego alokatora na wywołania specjalnej funkcji alokującej. Taka specjalna funkcja powinna wywoływać jeden raz funkcję ma 1 1 oc w celu utworzenia dużej tablicy fragmentów pamięci i rozdawania ich po jednym, zgodnie z zapotrzebowaniem. Zwolnione elementy należy zwracać z powrotem do listy pamięci wolnej, aby móc ich ponownie szybko użyć. Jeśli przydzielane bloki są podobnych rozmiarów, to możesz zaoszczędzić czas kosztem pamięci, zawsze przydzielając ilość pamięci równą największemu żądaniu. Może to być bardzo efektywny sposób obsługi krótkich łańcuchów znaków, jeżeli wszystkim łańcuchom nieprze­ kraczającym określonej długości będzie się przydzielać tę samą ilość pamięci. W niektórych algorytmach stosuje się alokację pamięci przy użyciu stosu. Polega to na wy­ konaniu całego szeregu operacji przydziału pamięci, a następnie zwolnieniu całego zbioru na­ raz. Funkcja alokująca pobiera jeden duży obszar pamięci dla siebie i traktuje go jak stos, tzn. dodaje elementy, gdy tak trzeba, i usuwa je wszystkie jednocześnie po zakończeniu pracy. W niektórych bibliotekach języka C istnieje funkcja a 1 1 oca, która działa w ten sposób, ale nie jest standardowa. Jako źródła pamięci używa lokalnego stosu wywołań i zwalnia wszystkie elementy, gdy funkcja, która ją wywołała, zakończy działanie.

7.4. REGULOWANIE KODU

1 87

Przechowuj dane wejściowe i wyjściowe w buforze. Buforowanie umożliwia gromadzenie transakcji, co pozwala zminimalizować koszt przeprowadzania często wykonywanych operacji oraz wykonywać kosztowne operacje tylko wtedy, gdy jest to konieczne. Dzięki temu koszt operacji zostaje rozłożony na wiele wartości danych. Na przykład kiedy program w języku C wywołuje funkcję pri ntf, znaki zostają wysłane do bufora i nie ruszają się stamtąd, dopóki bufor się nie zapełni albo nie zostanie opróżniony na wyraźne polecenie programisty. System operacyjny może natomiast odkładać zapis danych na dysku. Wadą tego rozwiązania jest to, że aby uwidocznić dane, trzeba opróżnić bufory wyjściowe. Najgorsze, co się może zdarzyć w ta­ kich przypadkach, to utrata danych znajdujących się w buforze wyjściowym, jeśli program ule­ gnie awarii.

Specjalne przypadki obsługuj osobno. Specjalne funkcje alokujące pamięć, które obsługują obiekty o takim samym rozmiarze za pomocą odrębnego algorytmu, pozwalają ograniczyć na­ kłady czasowe i pamięciowe ogólnych funkcji alokujących i przy okazji zmniejszają fragmenta­ cję pamięci. W bibliotece graficznej systemu Inferno podstawową funkcję rysowania zaimplemen­ towano tak prosto, jak to było możliwe. Następnie działającą już funkcję wzbogacano o pojedyncze dodatki optymalizujące jej działanie w różnych specjalnych przypadkach (znaj dowanych za pomocą profilowania). Zawsze istniała możliwość porównania zoptymalizowanej wersji funkcji z wersją podstawową. W końcu dodano tylko kilka optymalizacji, ponieważ funkcja rysowania najczęściej była wywoływana w celu rysowania znaków. Nie było zatem sensu głowić się nad wszystkimi przypadkami. Obliczaj wyniki zawczasu. Działanie programu można czasami przyspieszyć poprzez oblicze­ nie wartości zawczasu, aby były gotowe do użycia, gdy będą potrzebne. Przykład zastosowania tej metody widzieliśmy w filtrze spamu, który obliczał wartość str l en (pat [ i ] ) i zapisywał ją pod indeksem patl en [i ] . Jeśli system graficzny musi wielokrotnie obliczać wartość jakiejś funkcji matematycznej, takiej jak sinus, ale tylko dla określonego zbioru dyskretnych wartości, np. całkowitych wartości stopni, to działanie tego programu można przyspieszyć, jeśli już wcześniej programowo przygotuje się tablicę 360 elementów (albo zdefiniuje się je jako zwykłe dane) i wartości będą pobierane za pomocą indeksów. Jest to przykład oszczędzania czasu kosz­ tem pamięci. Jest wiele okazji do zastąpienia obliczeń gotowymi danymi albo wykonania obli­ czeń już w czasie kompilacji w celu zaoszczędzenia czasu, a niekiedy i pamięci. Przykładowo funkcje znajdujące się w pliku nagłówkowym ctype.h, takie jak i sdi g i t, prawie zawsze maj ą w implementacji tablice, z których pobierają dane za pomocą indeksów, zamiast wykonywać operacje porównywania. Używaj wartości przybliżonych. Jeśli dokładność obliczeń nie jest najważniejsza, to używaj mniej precyzyjnych typów danych. W maszynach starszych i takich, które programowo imitują operacje na liczbach zmiennoprzecinkowych, operacje arytmetyczne na liczbach zmiennoprze­ cinkowych pojedynczej precyzji są zwykle wykonywane szybciej niż na liczbach o podwójnej precyzji. Dlatego jeśli chcesz zaoszczędzić na czasie, używaj typu fl oat zamiast doubl e. Po­ dobna sztuczka jest stosowana w niektórych nowoczesnych procesorach grafiki. Standard arytmetyki liczb zmiennoprzecinkowych IEEE wymaga stosowania „stopniowego niedomia­ ru", gdy wyniki obliczeń zbliżają się do dolnej granicy reprezentowalnych wartości, lecz obli­ czenia z tym związane są skomplikowane. W przypadku obrazów nie jest to potrzebne, a poza tym znacznie szybsze i w pełni akceptowalne jest proste skracanie do zera. To pozwala nie tyl­ ko zaoszczędzić na czasie, gdy wystąpi niedomiar, lecz także uprościć sprzęt obsługujący ope­ racje arytmetyczne. Innym przykładem użycia wartości przybliżonych jest użycie całkowitych wartości funkcji sinus i cosinus.

1 88

7. WYDAJNOŚĆ

Przepisz kod w języku programowania niższego poziomu. Programy napisane w językach niskiego poziomu zwykle działają szybciej, ale odbywa się to kosztem czasu pracy programisty. W związku z tym, jeśli zasadniczą część programu napisanego w języku C+ + albo Javie napi­ sze się w języku C albo zastąpi interpretowany skrypt skompilowanym programem, można znacznie zwiększyć wydajność całego programu. Czasami można też osiągnąć duże przyspieszenie, używając kodu zależnego od maszyny. Metodę tę należy jednak traktować jako ostatnią deskę ratunku, gdyż w ten sposób żegnamy się z przenośnością i utrudniamy modyfikowanie i ogólnie utrzymanie programu w przyszłości. Prawie zawsze operacje wyrażone w języku asemblera są względnie niewielkimi funkcjami, które powinny być wbudowane w bibliotekę. Do typowych przedstawicieli takich funkcji nale­ żą memset i memmove oraz operacje graficzne. Tego typu pracę rozpoczyna się od napisania jak najklarowniejszego kodu w języku wysokopoziomowym i poddaniu go takim testom, jak opi­ sane w rozdziale 6. dla funkcji mems et, aby mieć pewność, że nie zawiera żadnych błędów. To będzie przenośna wersja, która działa wszędzie, lecz powoli. Kiedy przeniesiesz się do innego środowiska, możesz najpierw zacząć korzystać z wersji, o której wiadomo, że będzie działać. Później pisze się wersję w języku asemblera i wyczerpująco się ją testuje, porównując do wersji przenośnej. Kiedy pojawiają się błędy, to zawsze jednym z podejrzanych jest nieprzenośny kod. Dlatego dobrze jest mieć drugą implementację do porównania. . Ćwiczenie 7.4. Jedną z metod przyspieszenia działania funkcji memset jest zmuszenie jej do używania całych słów zamiast pojedynczych bajtów. Taki sposób działania powinien lepiej od­ powiadać wymogom sprzętu oraz może zredukować narzut pętli od czterech do ośmiu razy. Wadą tego rozwiązania jest konieczność obsłużenia rozmaitych przypadków brzegowych, po­ wstających, gdy obiekty nie są ułożone równo w słowach oraz gdy ich rozmiary nie są wielo­ krotnościami rozmiaru słów. Napisz wersję funkcji memset, która będzie używać takiej opty­ malizacji. Porównaj jej wydajność z wydajnością istniejącej wersji bibliotecznej i z wydajnością prostej pętli przetwarzającej po jednym bajcie naraz. Ćwiczenie 7 .5. Napisz funkcję alokującą pamięć o nazwie sma 1 1 oc dla łańcuchów w stylu języ­ ka C, która dla krótkich łańcuchów używa specjalnego alokatora, a dla długich - wywołuje funkcję ma 1 1 oc. W obu przypadkach musisz zdefiniować strukturę (s truct) do reprezentacji łańcuchów. Na jakiej podstawie podejmiesz decyzję, czy użyć funkcji sma 1 1 oc, czy ma 1 1 oc?

7.5. Oszczędzanie pamięci Kiedyś pamięć uchodziła za jeden z najcenniejszych komputerowych zasobów. Przez to, że ciągle jej brakowało, napisano mnóstwo złego kodu, aby tylko wycisnąć z tych niewielkich za­ pasów wszystko, co się da. Jako przykład takiego sposobu programowania często podaje się nie­ sławny „błąd roku 2000". Kiedy pamięci naprawdę brakowało, nawet te 2 bajty potrzebne do zapisania liczby 19 wydawały się rozrzutnością. Niezależnie, czy rzeczywistą przyczyną po­ wstania tego problemu naprawdę była chęć oszczędzenia pamięci - taki kod równie dobrze mógł zostać napisany dlatego, że ludzie na co dzień zwykle mówią o datach z pominięciem określenia wieku - czy nie, przykład ten stanowi doskonałą ilustrację niebezpieczeństw, jakie czyhają na tych, którzy dopuszczają się krótkowzrocznej optymalizacji. Czasy się jednak zmieniły i zarówno pamięć główna, jak i drugorzędna stały się niezwykle tanie. Dlatego pierwsza zasada optymalizacji wykorzystania pamięci powinna brzmieć podobnie do pierwszej zasady optymalizacji szybkości działania: nie trudź się bez potrzeby.

7.5. OSZCZĘDZANIE PAMIĘCI

1 89

Są jednak wciąż sytuacje, w których konieczne jest optymalne gospodarowanie pamięcią. Jeśli program nie zmieści się w całości w dostępnej pamięci głównej, to pewne jego części zo­ staną poddane stronicowaniu, które może go bardzo spowolnić. Obserwujemy to, kiedy nowo zakupione przez nas programy trwonią bez opamiętania naszą pamięć. Taka jest smutna rze­ czywistość, że wraz z uaktualnieniem oprogramowania często musimy rozszerzyć zasoby pa­ mięci w komputerze.

Oszczędzaj pamięć, stosując jak najmniejsze typy danych. Jednym z kroków do polepszenia wydajności pamięciowej jest dokonanie drobnych zmian mających na celu lepsze wykorzysta­ nie pamięci, np. poprzez użycie jak najmniejszych typów danych, które są odpowiednie do określonego zadania. To znaczy, że można np. zamienić typ i nt na s hort, jeśli tylko przecho­ wywane dane się w nim zmieszczą. W ten sposób często zapisuje się współrzędne w dwuwy­ miarowych systemach graficznych, ponieważ jest mało prawdopodobne, aby na ekranie wystą­ piły współrzędne o wartości przekraczającej możliwości 16 bitów pamięci. Analogicznie czasami można zamienić typ doubl e na fl oat. W tym przypadku istnieje groźba utraty precyzji, gdyż typy fl oat zwykle przechowują nie więcej niż 6 lub 7 miejsc dziesiętnych. W takich i innych podobnych przypadkach konieczne mogą być jeszcze inne zmiany, a kon­ kretnie użycie specyfikatorów formatu w wywołaniach funkcji pri ntf i scanf. Logicznym rozszerzeniem tej metody jest kodowanie informacji w jednym bajcie lub nawet jeszcze mniejszej liczbie bitów, nawet jednym, jeśli to tylko możliwe. Nie używaj pól bitowych dostępnych w językach C i C+ + . Występują ogromne trudności z ich przenośnością, a co wię­ cej - powodują one generowanie bardzo dużych ilości niewydajnego kodu. W zamian opera­ cje, których potrzebujesz, koduj w postaci funkcji pobierających i ustawiających pojedyncze bity w słowach lub tablicach słów za pomocą przesunięć i masek bitowych. Poniższa funkcja zwraca zbiór kilku kolejnych bitów ze środka słowa: /* getbits: pobiera n bitów, zaczynając od miejsca p */ /* Bity są numerowane od zera (najmniej znaczącego) */

unsi gned i nt getbi ts ( unsi gned i nt x , i nt p , i nt n ) { return (x >> (p+l-n) ) & - (-0 << n ) ;

Jeśli taka funkcja będzie działać zbyt wolno, to można ją zoptymalizować, stosując techniki opisane wcześniej w tym rozdziale. W języku C+ + można użyć techniki przeciążania operato­ rów, aby dostęp do bitów wyglądał jak zwykłe indeksowanie.

Nie zapisuj tego, co możesz łatwo obliczyć. Tego typu zmiany przynoszą niestety niewielkie korzyści, podobne do efektów, które można osiągnąć za pomocą regulacji kodu. Najlepsze efek­ ty dają zmiany struktury danych w połączeniu z wymianą algorytmów. Oto przykład. Wiele lat temu jeden z nas został poproszony o pomoc przez kolegę, który próbował wykonać obliczenia na tak dużej macierzy, że aby zmieściła się w pamięci, trzeba było ponownie uruchomić kom­ puter i ogolić system operacyjny z wszystkich procesów. Człowiek ten chciał się dowiedzieć, czy da się z tym coś zrobić, bo tamten sposób był strasznie kłopotliwy. Gdy go spytaliśmy, co to była za macierz, usłyszeliśmy, że większość jej zawartości stanowiły zera, a reszta to były liczby całkowite. W istocie tylko nieco mniej niż 5% wszystkich elementów macierzy miało wartość różną od zera. Od razu nasunęła nam się myśl, że można by utworzyć reprezentację, w której pamięci zapisywane byłyby tylko elementy różne od zera, a dostęp do elementów m [ i ] [j ] mógłby być realizowany za pomocą wywołania funkcji m ( i , j ) . Dane można przecho­ wywać na kilka sposobów. Najprostsze wydaje się użycie tablicy wskaźników, po jednym dla

1 90

7. WYDAJNOŚĆ

każdego wiersza, z których każdy wskazywałby na tablicę numerów kolumn i odpowiadających im wartości. Ten sposób wymaga użycia większej ilości pamięci do przechowywania niezero­ wych elementów, ale i tak pozwala zaoszczędzić pamięć w ogólnym rozrachunku. Ponadto, mimo iż dostęp do elementów stanie się wolniejszy, to i tak będzie lepszy niż ponowne uru­ chamianie systemu operacyjnego. Puenta jest taka: kolega zastosował się do naszych wskazó­ wek i był w pełni usatysfakcjonowany. Podobnie rozwiązaliśmy nowszą wersję tego samego problemu. W programie do projekto­ wania parametrów systemu radiowego potrzebny był sposób reprezentacji terenu i mocy sy­ gnałów radiowych na bardzo dużym obszarze (o długości od 100 do 200 kilometrów) z roz­ dzielczością 100 metrów. Gdyby takie ilości danych zapisano w postaci prostokątnej tablicy, zajęłaby ona całą pamięć główną i wymusiła stronicowanie, które dramatycznie obniżyłoby wydajność programu. Spostrzegliśmy jednak, że przecież na dużych obszarach teren i wartości siły sygnału mogą być takie same, a więc problem można rozwiązać poprzez użycie hierar­ chicznej struktury łączącej regiony o takich samych wartościach w pojedyncze komórki. Problem ten występuje w wielu różnych postaciach i tyle samo jest metod jego reprezenta­ cji, ale wszystkie łączy jedna podstawowa cecha: przechowywanie powtarzających się wartości w sposób niejawny lub w jakiejś zwartej postaci oraz przeznaczenie większej ilości czasu i miej­ sca na pozostałe wartości. Jeśli wartości powtarzają się bardzo często, metoda ta jest bardzo skuteczna. Program powinien być tak zorganizowany, aby ta specyficzna reprezentacja skomplikowa­ nych typów danych była ukryta w klasie lub zbiorze funkcji operujących na prywatnym typie danych. Dzięki temu można mieć pewność, że żadne zmiany w reprezentacji nie będą miały wpływu na resztę programu. Niektóre problemy z efektywnością wykorzystania pamięci mają również związek z ze­ wnętrzną reprezentacją informacji, i dotyczy to zarówno konwersji, jak i przechowywania da­ nych. Ogólnie rzecz biorąc, informacje najlepiej jest w miarę możliwości przechowywać w po­ staci tekstu zamiast w formacie binarnym. Tekst jest przenośny, łatwy do odczytania i nadaje się do przetwarzania przez wszelkiego rodzaju narzędzia. Natomiast formaty binarne nie mają żadnej z wymienionych zalet. Najczęstszy argument przytaczany na korzyść formatów binarnych dotyczy szybkości, ale należy sceptycznie traktować te rewelacje, gdyż czasami różnice między tymi dwoma formatami zapisu danych wcale nie są takie duże. Oszczędzanie pamięci często odbywa się kosztem szybkości działania programu. Pewna aplikacja musiała przesyłać między dwoma programami duży plik graficzny. Ponieważ typowy rozmiar obrazu zapisanego w prostym formacie o nazwie PPM wynosi około 1 MB, pomyśleli­ śmy, że możemy znacznie przyspieszyć przesył, jeśli format ten przekonwertujemy na skom­ presowany format GIF, w którym typowy rozmiar pliku wynosi około 50 KB. Niestety, oka­ zało się, że kodowanie i dekodowanie zajmowało tyle samo czasu, co przesłanie większego obrazu, a więc nic w ten sposób nie zyskaliśmy. Kod obsługujący format GIF składał się z około pięciuset wierszy, natomiast program obsługujący format PPM - z dziesięciu. W związku z tym postanowiliśmy zrezygnować z formatu GIF, aby ułatwić sobie pracę nad programem. Opisywana aplikacja nadal używa wyłącznie formatu PPM. Oczywiście sytuacja mogłaby wy­ glądać inaczej, gdyby plik był przesyłany bardzo wolnym łączem. Wówczas kompresja do for­ matu GIF byłaby znacznie bardziej opłacalna.

191

7.6. SZACOWANIE

7.6. Szacowanie Trudno oszacować z wyprzedzeniem, jak szybko będzie działał program, nie mówiąc już o tym, jak trudno jest oszacować koszt wybranych instrukcji językowych albo rozkazów maszyno­ wych. Łatwo natomiast utworzyć model kosztów (ang. cost model) dla języka programowania lub systemu, na podstawie którego można przynajmniej z grubsza się zorientować, ile czasu zajmie wykonywanie najważniejszych działań. Jedną z metod, której często używa się do szacowania typowych j ęzyków programowania, jest utworzenie programu mierzącego czas wykonywania jakiegoś zbioru reprezentatywnych sekwencji kodu. Trzeba przezwyciężyć pewne trudności, takie jak problem z uzyskaniem po­ wtarzalnych wyników czy odrzucenie nieistotnego narzutu, ale mimo to można uzyskać cał­ kiem wartościowe informacje bez wkładania w to zbyt wiele wysiłku. Na przykład mamy pro­ gram tworzący model kosztów dla języków C i C + + , który szacuje koszt poszczególnych instrukcji, wykonując je wiele milionów razy w pętli i obliczając średni czas wykonywania. W komputerze MIPS R l OOOO 250 MHz program ten zwraca następujące dane (czasy są podane w nanosekundach na operację). na typ i e i nt

Operacje i l++ i1 i1 i1 i1 i1

i2 i2 i2 i2 i2

+ i3 - i3 * i3 I i3 % i3

Operacje f1 f1 f1 f1 = f1 =

na f2 f2 f2 f2 f2

typ i e fl oat

Operacje dl = dl = dl dl = dl =

na d2 d2 d2 d2 d2

=

+ f3 f3 * f3 I f3 typ i e doubl e + * /

d3 d3 d3 d3

Konwersje l i czbowe i1 f1 f1 = i 1

8 12 12 12 1 14 114 8 12 12 11 28 8 12 12 11 58 8 8

Operacje na liczbach całkowitych są szybkie, oprócz dzielenia i dzielenia modulo. Operacje na liczbach typów zmiennoprzecinkowych są tak samo szybkie albo szybsze, co jest zaskakujące dla tych osób, które wychowały się w czasach, gdy działania na liczbach zmiennoprzecinko­ wych były znacznie bardziej czasochłonne od działań na liczbach całkowitych. Inne podstawowe operacje również są całkiem szybkie, także wywołania funkcji, które są przedstawione w trzech ostatnich wierszach poniższego zestawienia: Operacje na wektorach typu i nt V [i] = i v [v [i ] ] i v [v [v [ i ] ] ] = =

49 81 100

1 92 Struktury steruj ące i f (i == 5 ) i l++ i f ( i ! = 5 ) i l++ whi l e (i < O) i l++ il suml ( i 2 ) il sum2 ( i 2 , i 3 ) il sum3 ( i 2 , i 3 , i 4)

7. WYDAJNOŚĆ

4 12 3 57 58 54

Natomiast operacje wejścia i wyjścia nie są już takie wydajne, podobnie jak większość in­ nych funkcji bibliotecznych: Operacje wej ści a i wyj śc i a fput s ( s , fp) fgets ( s , 9, fp) fpri ntf(fp , "%d\n " , i ) fscanf(fp , "%d " , &i 1)

270 222 1820 2070

mal l oc free(mal l oc (8) )

342

Funkcj e łańcuchowe strcpy ( s , " 0123456789 " ) il strcmp ( s , s) i l = strcmp ( s , " a l23456789" )

157 176 64

Konwersje łańcuchowo-l i czbowe i l = atoi ( " l2345 " ) sscanf ( " l2345 " , "%d " , &i l ) spri ntf ( s , "%d " , i ) fl = atof ( " l23 . 45 " ) sscanf ( " l23 . 45 " , "%f" , &fl ) spri ntf ( s , "%6 . 2f" , 123 . 45)

402 2376 1492 4098 6438 3902

Wartości pomiarów dla funkcji ma 1 1 ac i free prawdopodobnie nie odpowiadają rzeczywi­ stości, ponieważ zwalnianie pamięci od razu po jej alokowaniu nie jest typowym sposobem użycia tych funkcji. Na zakończenie jeszcze funkcje matematyczne: Funkcj e matematyczne i l = ran d ( ) f 1 = l og (f2) f1 exp (f2) f1 s i n (f2) f1 sqrt ( f2)

135 418 462 514 112

Oczywiście wartości t e na innym sprzęcie przedstawiałyby się inaczej, ale n a podstawie tych informacji można się zorientować, jak ogólnie wygląda czas wykonywania poszczególnych operacji. Można je też wykorzystać do porównania względnych kosztów użycia operacji wejścia i wyjścia z kosztami operacji podstawowych albo do podjęcia decyzji, czy przepisać dane wyra­ żenie od nowa, czy użyć funkcji rozwijanej. Na wyniki może wpływać wiele czynników. Jednym z nich jest poziom optymalizacji usta­ wiony w kompilatorze. Nowoczesne kompilatory potrafią znaleźć takie rzeczy do zoptymalizo­ wania, które przeoczą programiści. Ponadto nowoczesne procesory są tak skomplikowane, że

7.7. PODSUMOWANIE

1 93

tylko najlepsze kompilatory potrafią wykorzystać oferowane przez nie możliwości współbież­ nego wykonywania rozkazów, przetwarzania potokowego, pobierania rozkazów i danych z wy­ przedzeniem itp. Kolejnym czynnikiem, który może znacząco wpływać na wyniki pomiarów wydajności, jest architektura komputera. Pamięć podręczna może znacznie przyspieszać działanie komputera, a projektanci sprzętu sporo czasu poświęcają na próby ukrycia faktu, że pamięć główna jest du­ żo wolniejsza od pamięci podręcznej. Same dane na temat taktowania procesora, np. 400 MHz, stanowią jakąś informację, ale nie dają pełnego obrazu. Jeden z naszych starych procesorów Pentium 200 MHz jest znacznie wolniejszy od jeszcze starszego Pentium 100 MHz, ponieważ ten drugi ma dużą pamięć podręczną drugiego poziomu, a pierwszy nie ma jej wcale. Także odmienne generacje procesorów, nawet wyposażone w taki sam zbiór rozkazów, potrzebują różnych liczb cykli zegara na wykonanie określonych operacji.

Ćwiczenie 7.6. Utwórz zestaw testów do oszacowania kosztu wykonania podstawowych opera­ cji w dostępnych Ci komputerach i kompilatorach oraz przeanalizuj podobieństwa i różnice w ich wydajności.

Ćwiczenie 7.7. Stwórz model kosztów dla operacji wysokopoziomowych w języku C + + . Wśród badanych właściwości możesz umieścić np. tworzenie, kopiowanie i usuwanie obiektów klas, wywołania funkcji składowych obiektów, funkcje wirtualne, funkcje rozwijane, bibliotekę i ostream i bibliotekę STL. Samodzielnie wybierz niewielki zestaw najbardziej reprezentatywnych operacji.

Ćwiczenie 7.8. Wykonaj powyższe ćwiczenie jeszcze raz, dla Javy.

7. 7. Podsumowanie Jeśli zastosujesz właściwy algorytm, to po zakończeniu pracy optymalizacja programu będzie Twoim najmniejszym zmartwieniem. Jeżeli już jednak wyniknie potrzeba optymalizacji, typo­ wy schemat pracy jest następujący: wykonaj pomiary, skup swoją uwagę na kilku obszarach, których optymalizacja przyniesie największe korzyści, sprawdź poprawność programu i jeszcze raz wykonaj pomiary. Zakończ pracę natychmiast, gdy uzyskasz zadowalający efekt, i zachowaj najprostszą wersję programu, aby móc jej użyć w testach porównawczych. Jeśli planujesz podjąć się optymalizacji szybkości programu i wykorzystania przez niego pamięci, to dobrym pomysłem jest opracowanie kilku testów wzorcowych i sformułowanie problemu, aby można było samodzielnie szacować i sprawdzać wydajność programu. Jeżeli ist­ nieją już standardowe testy wzorcowe, to użyj ich. Jeśli program jest względnie samodzielny, można spróbować znaleźć lub utworzyć zbiór typowych danych wejściowych. Mogą one równie dobrze stanowić część zestawu testów. W taki sposób powstają zestawy testów wzorcowych dla systemów komercyjnych i akademickich, takich jak kompilatory, komputery itp. Na przykład dla języka Awk utworzono około dwudziestu niewielkich programów, które pokrywają testami większość najczęściej używanych elementów tego języka. Programy te uruchamia się na bardzo dużym pliku, aby sprawdzić, czy wyniki są zawsze takie same i czy nie ma jakichś błędów po­ garszających wydajność. Ponadto mamy zbiór standardowych dużych plików z danymi, któ­ rych można używać w pomiarach czasu wykonywania. Niekiedy korzystne jest, jeśli pliki takie mają dające się łatwo weryfikować właściwości, np. rozmiar będący potęgą liczby 2 albo 10. Wykonywanie testów wzorcowych można zautomatyzować za pomocą specjalnej ramy te­ stowej, podobnej do tej, którą opisaliśmy w rozdziale 6. dla testowania. Testy mierzące czas są wykonywane automatycznie. W danych wyjściowych znajdują się wystarczające informacje,

1 94

7. WYDAJNOŚĆ

aby je zrozumieć i zidentyfikować. Prowadzone są zapiski, dzięki którym można zauważyć tendencje i znaczące zmiany. Przy okazji warto wspomnieć, że bardzo trudno utworzyć dobry test wzorcowy, a niektóre firmy „dostrajają" swoje produkty, tak aby wypadały jak najlepiej w takich testach. Dlatego do wyników wszelkich testów wzorcowych trzeba podchodzić ostrożnie.

Lektura uzupełniająca Opis filtra spamu powstał w oparciu o pracę Boba Flandreny i Kena Thompsona. Ich filtr za­ wiera wyrażenia regularne pozwalające wykonywać bardziej zaawansowane porównania oraz automatycznie klasyfikuje wiadomości (na pewno spam, możliwe, że spam oraz z pewnością nie spam) w zależności od tego, do których łańcuchów zostaną dopasowane. W czasopiśmie „Software - Practice and Experience" ( 1971, R. 1, nr 2, s. 105 - 133) został opublikowany artykuł Knutha na temat profilowania pt. An Empirical Study of FORTRAN Programs. Treść artykułu skupia się na statystycznej analizie zbioru programów znalezionych w koszach na śmieci i ogólnodostępnych katalogach w maszynach znajdujących się w ośrodku komputerowym. Kilka świetnych przykładów ulepszeń algorytmów i regulacji kodu znajduje się w książkach Programming Pearls i More Programming Pearls Jona Bentleya (Addison-Wesley, 1986 i 1988). Ponadto w publikacjach tych można znaleźć ciekawe wypowiedzi na temat ram do optymali­ zowania wydajności i wykorzystywania danych z profili. Dobrym źródłem wiedzy na temat optymalizacji wydajności programów dla komputerów osobistych jest książka pt. Inner Loops Ricka Bootha, aczkolwiek należy pamiętać, że procesory rozwijają się tak szybko, iż niektóre szczegóły już po krótkim czasie stają się nieaktualne. Szczegółowe omówienie zagadnień dotyczących wydajności nowoczesnych komputerów można znaleźć w serii książek o architekturze komputerów Johna Hennessy'ego i Davida Pat­ tersona (np. w książce pt. Computer Organization and Design. The Hardware/Software Interface Morgan Kaufman, 1997).

Przenośność

W końcu standaryzacja, podobnie jak konwencjonalizacja, może być tylko kolejnym przejawem ścisłego porządku. Jednak w przeciwieństwie do konwencjonalizacji standaryzację w nowoczesnej architekturze prZYjęlo się traktować jako wzbogacający element będący wytworem naszej technologii, choć budzący lęk przed potencjalną dominacją i brutalnością.

Robert Venturi, Complexity and Contradiction in Architecture

Trudno napisać program, który działa wydajnie i bezbłędnie. Dlatego gdy już uda się stworzyć program spełniający te warunki w jednym środowisku, to przy przenoszeniu go na inny kom­ pilator, procesor lub system operacyjny wolelibyśmy uniknąć powtarzania włożonego weń wy­ siłku. Najlepiej by było, gdybyśmy w ogóle nie musieli nic zmieniać. Taki ideał nazywa się przenośnością (ang. portability). W praktyce pod pojęciem przeno­ śności rozumie się to, że przystosowanie programu do nowego środowiska będzie łatwiejsze niż napisanie go tam całkiem od nowa. Im mniej modyfikacji potrzeba, tym program jest bardziej przenośny. Może zastanawiasz się, po co w ogóle przejmujemy się przenośnością. Jeśli program ma działać tylko w jednym środowisku w określonych warunkach, to czemu tracić czas na posze­ rzanie jego zakresu dostępności? Po pierwsze każdy udany program już z samej definicji będzie używany w niespodziewanych zastosowaniach i miejscach. Jeżeli utworzymy bardziej ogólny program, niż wymaga tego specyfikacja, to w przyszłości lepiej będzie nam służył i łatwiej bę­ dzie nam go utrzymywać. Po drugie środowiska się zmieniają. Zmiany mogą mieć związek np. z uaktualnieniem kompilatora, systemu operacyjnego albo sprzętu. Im mniej wykorzystamy w programie specyficznych właściwości, tym mniejsze ryzyko, że ulegnie on awarii, i tym więk­ sza szansa, iż dostosuje się do zmieniających się warunków. W końcu najważniejsze: program przenośny to lepszy program. Wysiłek włożony w zapewnienie programowi przenośności zwraca się w postaci lepiej przemyślanego projektu, lepszej konstrukcji i bardziej wyczerpu­ jącego przetestowania. Techniki tworzenia przenośnych programów są ściśle związane z ogólną metodyką dobrego programowania. Oczywiście stopień przenośności programu weryfikuje rzeczywistość. Nie istnieje program idealnie przenośny, a co najwyżej taki, którego nie sprawdzono w wystarczającej liczbie środo­ wisk. Dlatego w swojej pracy powinniśmy dążyć do uzyskania kodu działającego bez zmian

.­

1 96

8. PRZENOŚNOŚĆ

prawie wszędzie. Nawet jeśli nie uda się w pełni osiągnąć postawionego celu, czas spędzony na udoskonalaniu przenośności podczas tworzenia programu odzyskamy, gdy program będzie trzeba zaktualizować. Nasza rada jest taka: staraj się pisać oprogramowanie tak, aby działało na przecięciu róż­ nych standardów, interfejsów i środowisk, które musi obsługiwać. Zamiast naprawiać każdy problem z przenośnością, jaki uda się wykryć przez dodanie specjalnego kodu, lepiej przystosuj program do nowych ograniczeń. Do sprawowania kontroli nad nieprzenośnym kodem, którego nie da się wyeliminować, używaj abstrakcji i hermetyzacji. Pozostając na przecięciu ograniczeń i lokalizując zależności systemowe, utworzysz przejrzystszy i bardziej ogólny kod, który będzie łatwiej przenosić.

8. 1 . Język Trzymaj się standardu. Pierwszym krokiem na drodze do uzyskania przenośnego programu jest użycie języka wysokiego poziomu i trzymanie się jego standardu, jeśli istnieje. Plików bi­ narnych nie przenosi się dobrze, ale kod źródłowy jak najbardziej. Jednak nawet mimo tego sposób translacji przez kompilator kodu źródłowego na maszynowy nie jest ściśle zdefiniowa­ ny, nawet w językach ujętych w standardzie. Niewiele szeroko używanych języków ma tylko jedną implementację. Zazwyczaj istnieją wersje opracowane przez różnych producentów, wer­ sje przeznaczone dla odmiennych systemów operacyjnych oraz wersje, które przeszły ewolucję w czasie. Interpretacja kodu w tych wszystkich przypadkach może się różnić. Dlaczego standard nie jest ścisłą definicją? Niektóre standardy są niepełne i brak w nich np. definicji zachowań w przypadku interakcji różnych właściwości. Czasami celowo pozosta­ wia się „niedomówienia". Na przykład w językach C i C + + typ char może być ze znakiem lub bez i niekoniecznie musi zajmować dokładnie 8 bitów. Pozostawienie rozwiązania takich kwe­ stii twórcy kompilatora umożliwia optymalizację implementacji oraz pozwala uniknąć uzależ­ nienia języka od konkretnego sprzętu. Ceną za to jest utrudnienie pracy programistom. Pozo­ stawienie nieokreślonych właściwości języka mogą wymuszać też przyjęte normy i względy techniczne. W końcu języki mają misterną konstrukcję, a kompilatory są skomplikowane, co oznacza, że zarówno w interpretacji, jak i implementacji będą pojawiać się błędy. Niektóre języki w ogóle nie mają standardu. Oficjalny standard ANSI/ISO języka C opubli­ kowano w 1988 roku, natomiast standard ISO języka C + + został zatwierdzony dopiero w 1998 roku. W czasie, gdy piszemy ten tekst, nie wszystkie używane kompilatory są zgodne z oficjal­ ną specyfikacją. Język Java jest nowy i miną jeszcze lata, zanim zostanie ustandaryzowany. Standard języka najczęściej opracowuje się po to, aby zunifikować niezgodne ze sobą imple­ mentacje, i dopiero wówczas, gdy jest on na tyle powszechnie używany, że opłaci się to robić. Mimo to w tym czasie trzeba pisać programy i dostosowywać je do działania w różnych środo­ wiskach. Dlatego, mimo iż czytając podręczniki i standardy, można odnieść wrażenie, że wszystko jest rygorystycznie zdefiniowane, w rzeczywistości żaden język nie jest zdefiniowany w pełni i różne jego implementacje mogą odmiennie, a jednocześnie poprawnie, interpretować niektóre instruk­ cje. Czasami nawet pojawiają się błędy. Podczas pisania pierwszej wersji tego rozdziału na­ tknęliśmy się na ciekawy przypadek. Poniższa zewnętrzna deklaracja jest niepoprawna zarówno w języku c, jak i c+ + :

?

*x []

;

{ " abc " } ;

8.1. JĘZYK

1 97

Na kilkanaście przetestowanych kompilatorów kilka poprawnie wykryło brak określnika typu char dla zmiennej x, kilka ostrzegło o niezgodności typów (prawdopodobnie opierając się na starej definicji języka, niepoprawnie wydedukowały, że x jest tablicą wskaźników typu i nt), a niektóre skompilowały ten niepoprawny kod bez problemu.

Używaj typowych elementów języka. Brak reakcji niektórych kompilatorów na ten błąd to niefortunne zdarzenie, ale sytuacja ta zwraca uwagę na pewien ważny aspekt przenośności. Ję­ zyki programowania mają ciemne miejsca, w których stosuje się różne praktyki - np. pola bi­ towe w językach C i C+ + - i najlepiej omijać je z daleka. Używaj tylko tych właściwości języka, które są jednoznacznie zdefiniowane i dobrze poznane. Istnieje większa szansa, że właściwości takie będą szerzej dostępne i jednakowo interpretowane. Nazywamy to głównym nurtem (ang. mainstream) języka. Trudno jest określić, które konstrukcje języka należą do głównego nurtu, ale łatwo wskazać te, które do niego nie należą. Gwarancją kłopotów są wszystkie nowości, takie jak komentarze zaczynające się od znaków / / i typ comp 1 ex w języku C, a także konstrukcje specyficzne dla tylko jednej architektury, np. słowa kluczowe near i far. Jeśli jakaś konstrukcja jest tak rzadko używana lub niejasna, że aby ją zrozumieć, musisz skorzystać z pomocy eksperta od danego języka, to nie używaj jej. w tym tekście skupimy się na językach ogólnego przeznaczenia c i c+ + , które są po­ wszechnie używane do pisania przenośnych programów. Standard języka C ma już ponad 10 lat i język ten jest bardzo stabilny, ale trwają prace nad nowym standardem, więc należy się spo­ dziewać zamieszania. Natomiast język C+ + jest bardzo świeży, przez co nie wszystkie imple­ mentacje zdążono dopracować. Czym jest główny nurt w języku C? Określenie to najczęściej odnosi się do ustalonego spo­ sobu używania języka, ale czasami lepiej jest myśleć przyszłościowo. Na przykład w pierwotnej wersji języka C nie trzeba było pisać prototypów funkcji. Funkcję sqrt można było zdefinio­ wać następująco: doubl e sqrt ( ) ; Ta instrukcja definiuje typ wartości zwromej, ale nie określa żadnych parametrów. W standar­ dzie ANSI tego języka dodano prototypy, które definiują wszystko: doub l e sqrt (doubl e) ; Kompilatory zgodne ze standardem ANSI C muszą akceptować także starszą składnię, ale mimo tego powinniśmy zawsze pisać prototypy dla wszystkich swoich funkcji. Dzięki temu powstaje bezpieczniejszy kod - wywołania funkcji podlegają pełnej kontroli typów - oraz, jeśli wystąpią zmiany w interfejsach, kompilator je wychwyci. Jeżeli napiszemy takie wywołanie funkcji: func ( 7 , P I ) ; a funkcja func nie będzie miała prototypu, to kompilator nie będzie mógł sprawdzić, czy funkcja ta jest wywoływana poprawnie. Gdyby później w bibliotece wprowadzono takie zmia­ ny, że funkcja func miałaby trzy argumenty, to konieczność poprawienia kodu mogłaby nam umknąć, ponieważ stara składnia wyłącza sprawdzanie typów argumentów funkcji.

198

8. PRZENOŚNOŚĆ

Język c+ + jest bardziej obszerny i świeższy, a więc trudniej wyodrębnić w nim główny nurt. Na przykład, mimo iż oczekuje się, że do głównego nurtu wejdzie biblioteka STL, nie stanie się to natychmiast, a niektóre dostępne obecnie implementacje nie obsługują jej w ogóle.

Uważaj na pułapki językowe. Jak wspominaliśmy, w standardach celowo niektórych rzeczy się nie definiuje lub nie określa. Najczęściej ma to na celu pozostawienie twórcom kompilato­ rów większej swobody. Lista takich elementów jest zniechęcająco długa.

Rozmiary typów danych. Rozmiary podstawowych typów danych w językach C i C+ + są nie­ zdefiniowane. Oprócz poniższych reguł:

s i zeof (char) s i zeof (fl oat)

s i zeof (short) s i zeof ( i nt) s i zeof (doubl e)

s i zeof (l ong)

oraz wymogu, że typ char musi mieć co najmniej 8 bitów, typy s hort i i nt 1 6, a l ong nie mniej niż 32, nic nie jest pewne. Nawet wartość wskaźnika nie musi mieścić się w zakresie typu i nt. Rozmiary poszczególnych typów w danym kompilatorze można łatwo sprawdzić: -

I* sizeof wyświetla rozmiary podstawowych typów danych *I

i nt mai n (voi d ) { pri ntf(" char %d , short %d , i nt %d , l ong %d , " , s i zeof (char) , s i zeof(short) , s i zeof ( i nt ) , s i zeof ( l ong) ) ; pri ntf ( " fl oat %d , doubl e %d , void* %d\n " , s i zeof(fl oat) , s i z eof(doubl e) , s i zeof(vo i d *) ) ; return O ;

Wynik powyższego programu w większości używanych przez nas regularnie maszyn jest taki sam:

char l , short 2, i nt 4, l ong 4, fl oat 4, doub l e 8, voi d* 4 Ale możliwe są też inne wartości. W niektórych 64-bitowych maszynach otrzymujemy na­ stępujące wyniki:

char 1 , short 2, i nt 4, l ong 8, fl oat 4, doub l e 8, voi d* 8 Typowe wczesne kompilatory używane w komputerach osobistych zwracały następujące informacje:

char 1, short 2, i nt 2, l ong 4, fl oat 4, doubl e 8 , void* 2 Początkowo komputery osobiste obsługiwały kilka rodzajów wskaźników. Kopiowanie w tym bałaganie doprowadziło do wynalezienia takich modyfikatorów wskaźników, jak far i near, z których żaden nie jest standardowy, ale których resztki w postaci zarezerwowanych słów wciąż straszą w nowych kompilatorach. Jeśli używany przez Ciebie kompilator może zmieniać rozmiary typów podstawowych lub jeśli masz maszyny o różnych parametrach, to spróbuj skompilować i przetestować swój program w odmiennych warunkach.

1 99

8.1. JĘZYK

Standardowy plik nagłówkowy stddefh zawiera definicje kilku typów, które mogą pomóc w utrzymaniu przenośności. Najczęściej używanym jest s i ze_t - całkowitoliczbowy typ bez znaku zwracany przez operator si zeof. Wartości tego typu są zwracane przez funkcje takie jak strl en i używane jako argumenty przez wiele innych funkcji, np. przez ma 1 1 oc. Czerpiąc z tych doświadczeń, twórcy języka Java ściśle zdefiniowali rozmiary wszystkich podstawowych typów danych: typ byte zajmuje 8 bitów, typy char i s hort - po 16, i nt - 32, a l ong - 64. Nie rozpisujemy się o potencjalnych trudnościach związanych z wykonywaniem obliczeń na liczbach zmiennoprzecinkowych, ponieważ na ten temat można by napisać całą odrębną książkę. Na szczęście wykonywanie operacji na liczbach zmiennoprzecinkowych w większości maszyn jest zgodne ze standardem IEEE, dzięki czemu właściwości obliczeń przy użyciu tych liczb są dobrze zdefiniowane.

Kolejność wykonywania obliczeń. W językach C i C+ + kolejność obliczania argumentów wyrażeń, efektów ubocznych i argumentów funkcji nie jest zdefiniowana. Na przykład w po­ niższym przypisaniu

I?

n

=

(getchar( ()

«

8) I getchar ( ) ;

drugie wywołanie funkcji getchar może zostać wykonane jako pierwsze, ponieważ sposób zapisu wyrażenia nie musi odpowiadać sposobowi jego wykonania. W instrukcji

ptr [count]

=

name [++count] ;

wartość zmiennej count może zostać zwiększona przed jej użyciem lub po jej użyciu jako indeksu tablicy ptr, a w poniższej instrukcji

printf( "%c %c\n " , getchar() , getchar ( ) ) ; pierwszy znak pobrany na wejściu może zostać wydrukowany jako drugi. Natomiast w tej instrukcji

pri ntf( "%f %s\n " , l og ( - 1 . 23) , strerror(errno) ) ; wartość errno może zostać obliczona przed wywołaniem funkcji l og. Istnieją pewne zasady dotyczące obliczania określonych wyrażeń. Z definicji wszystkie efekty uboczne i wywołania funkcji muszą zostać zakończone przy każdym średniku lub gdy wywoływana jest kolejna funkcja. Kolejnością wykonywania działań operatorów && i 1 1 jest kolejność od lewej do prawej, przy czym operatory te są wykonywane, dopóki tylko jest to ko­ nieczne do określenia ich wartości logicznej (włącznie z efektami ubocznymi). Po obliczeniu warunku (włącznie z efektami ubocznymi) operatora ? : wykonywane jest dokładnie jedno z dwóch przypisanych mu wyrażeń. W Javie kolejność wykonywania działań jest ściślej określona. Wyrażenia, łącznie z efek­ tami ubocznymi, muszą być obliczane od lewej do prawej strony, aczkolwiek w jednym autory­ tatywnym podręczniku można znaleźć radę, aby nigdy nie uzależniać najważniejszej części kodu od tych reguł. Wskazówka ta jest bardzo cenna, jeśli kod napisany w Javie miałby kiedykol­ wiek zostać przepisany w języku C lub C + + , w których reguły takie nie istnieją. Konwersja między różnymi językami to przykład ekstremalnego, ale czasami racjonalnego sposobu testowa­ nia przenośności.

200

8. PRZENOŚNOŚĆ

Kwestia znaku w typie char. W językach C i C + + nie określono, czy typ danych char powi­ nien mieć znak, czy nie. Ta niejednoznaczność może powodować problemy w kodzie, w którym używane są wartości typów char i i nt, np. zawierającym wywołanie funkcji char ( ) operującej na wartościach typu i nt. Jeśli napiszemy char c ; /* Powinien być int */ c = getchar () ; to w przypadku typu char bez znaku zmienna c będzie miała wartość z przedziału od O do 255; natomiast jeśli typ char będzie ze znakiem, wartość zmiennej c będzie zawierać się w prze­ dziale od -128 do 127 (w konfiguracjach sprzętowych z uzupełnieniem dwójkowym z prawie uniwersalną 8-bitową definicją znaku). Konsekwencje tego są widoczne wówczas, gdy dany znak ma zostać użyty jako indeks w tablicy lub porównany ze znakiem końca pliku, który w nagłówku std i o ma najczęściej wartość 1 Poniżej przedstawiamy przykładowy kod z pod­ rozdziału 6.1., w którym ustaliliśmy kilka warunków brzegowych. Jeśli typ danych char jest bez znaku, to wynik porównania s [ i ] EOF będzie zawsze negatywny: -

.

==

i nt i ; char s [MAX] ; for (i = O ; i < MAX- 1 ; i ++) if ( (s [i ] = getchar ( ) ) brea k ; s [i ] = ' \O ' ;

'

\n

'

1 1 s [i ]

EOF)

Gdy funkcja getchar zwróci znak końca pliku (EOF), pod indeksem s [ i ] będzie przecho­ wywana wartość 255 (Ox FF, czyli wynik konwersji liczby -1 na typ char bez znaku). Jeśli war­ tość s [ i ] będzie miała typ char bez znaku, to do porównywania ze stałą EOF zostanie użyta wartość 255, co zawsze da wynik negatywny. Kod ten nie będzie jednak poprawny nawet wówczas, gdy typ char będzie ze znakiem. Wynik porównywania ze znakiem końca pliku okaże się pozytywny, ale poprawny bajt wej­ ściowy OxFF będzie wyglądał jak znak końca pliku, co spowoduje przedwczesne zamknięcie pętli. Dlatego bez względu na rodzaj typu char zwróconą przez funkcję getchar wartość należy zawsze przechowywać w zmiennej typu i nt, jeśli ma ona być porównywana ze znakiem końca pliku. Oto ta sama pętla w wersji przenośnej :

i nt c, i ; char s [MAX] ; for (i = O; i < MAX- 1 ; i ++) { i f ( (c = getchar ( ) ) = = ' \n ' 1 1 c brea k ; s [i ] = c ; s [i ]

=

EOF)

' \O ' ;

W Javie nie ma kwalifikatora u n s i gned, oznaczającego typ danych bez znaku. Typy całko­ wite są ze znakiem, a 1 6-bitowy typ char jest bez znaku.

Przesunięcie arytmetyczne a logiczne. Przesunięcie w prawo wartości typów ze znakiem za pomocą operatora » może być arytmetyczne (w wyniku przesunięcia bit znaku jest powielany) lub logiczne (puste miejsca są zapełniane zerami). Ponownie twórcy języka Java wyciągnęli

8.1. JĘZYK

20 1

wnioski z trudności języków C i C+ + i zarezerwowali operator » dla przesunięcia arytme­ tycznego, a dla przesunięcia logicznego zdefiniowali nowy operator >».

Kolejność bajtów. Kolejność bajtów w typach s hort, i nt i l ong jest niezdefiniowana. Pod najniższym adresem może być przechowywany zarówno najbardziej, jak i najmniej znaczący bajt. Tę zależną od sprzętu kwestię szerzej omówimy w dalszej części rozdziału.

Ułożenie składowych struktur i klas. Rozmieszczenie elementów wewnątrz struktur, klas i unii jest nieokreślone z tym wyjątkiem, że składowe są układane zgodnie z kolejnością dekla­ racji. Na przykład w tej strukturze struct X { char c ; i nt i ; ); adres zmiennej i może wskazywać miejsce oddalone o 2, 4 bajty lub 8 bajtów od początku struktury. Istnieje garstka urządzeń, w których typ i nt można przechowywać pod nieparzy­ stymi adresami, ale w większości sprzętów typy podstawowe składające się z n bajtów muszą być przechowywane w pamięci pod adresami o numerach będących wielokrotnościami warto­ ści n. Jeśli np. typ doubl e zajmuje 8 bajtów, wartości tego typu są przechowywane pod adresa­ mi o numerach będących wielokrotnościami liczby 8. Oprócz tego twórca kompilatora może wprowadzić dodatkowe usprawnienia, takie jak np. wymuszenie wyrównania w celu optymali­ zacji wydajności. Nigdy nie należy zakładać, że elementy struktury zajmują przylegające bloki pamięci. Ograniczenia dotyczące ułożenia składowych wymuszają powstawanie „dziur". Przedstawiona powyżej struktura X będzie zawierała przynajmniej jeden nieużywany bajt pamięci. Istnienie tych luk może powodować, że rozmiar struktury będzie większy niż suma rozmiarów jej skła­ dowych oraz będzie zmieniać się w zależności od maszyny. Jeśli chcesz zarezerwować pamięć do przechowywania takiej struktury, to musisz zażądać s i zeof ( struct X) bajtów, a nie s i zeof (char) + s i zeof ( i nt) bajtów.

Pola bitowe. Pola bitowe są tak silnie uzależnione od sprzętu, że w ogóle nie należy ich używać. Przedstawioną dotychczas długą listę problemów można streścić w formie kilku reguł. Nie używaj efektów ubocznych z wyjątkiem kilku idiomatycznych konstrukcji typu

a [i ++] = O ; c *p++; *s++ *t++ ; =

=

Nie porównuj wartości typu char ze znakiem końca pliku. Zawsze sprawdzaj rozmiar ty­ pów i obiektów za pomocą operatora si zeof. Nigdy nie przesuwaj w prawo wartości ze zna­ kiem. Za każdym razem sprawdź, czy typ danych, którego zamierzasz użyć do przechowywania wartości, ma wystarczająco szeroki zakres.

Wypróbuj program w kilku kompilatorach. Łatwo można ulec złudzeniu, że wszystko wiemy o przenośności, ale kompilatory potrafią znajdować takie problemy, których my nie zauważa­ my, a poza tym różne kompilatory mogą odmiennie interpretować nasz kod, a więc powinni­ . śmy korzystać z ich pomocy. Włącz wszystkie os trzeżenia w kompilatorze. Wypróbuj różne kompilatory na tej samej maszynie i na różnych maszynach. Spróbuj skompilować program w języku c w kompilatorze języka c + + .

202

8. PRZENOŚNOŚĆ

Ponieważ tolerancja kompilatorów jest różna, sam fakt przeprowadzenia udanej kompilacji programu nie stanowi nawet gwarancji, że program ten ma poprawną składnię. Jeśli jednak kompilacja zakończy się pomyślnie w kilku kompilatorach, to nasze szanse rosną. Wszystkie przedstawione w tej książce programy w języku C skompilowaliśmy w trzech kompilatorach działających w trzech niepowiązanych ze sobą systemach operacyjnych (Unix, Plan 9 i Win­ dows) i dwóch kompilatorach języka C + + . Było to bardzo pouczające doświadczenie - zna­ leźliśmy dzięki niemu kilkadziesiąt błędów związanych z przenośnością, których żaden czło­ wiek nie byłby w stanie wykryć. Wszystkie były bardzo łatwe do usunięcia. Oczywiście kompilatory również mogą powodować problemy z przenośnością, ponieważ mogą dokonywać różnych wyborów w niejednoznacznych przypadkach. Ale nasze podejście daje nam nadzieję. Zamiast pisać kod potęgujący różnice między systemami, środowiskami i kom­ pilatorami, staramy się tworzyć oprogramowanie, które zachowuje się zawsze tak samo, bez względu na przeciwności. Mówiąc krótko, pozbywamy się tych konstrukcji, które z dużym prawdo­ podobieństwem mogą być zróżnicowane.

8.2. Nagłówki i biblioteki W nagłówkach i bibliotekach są udostępniane usługi, które rozszerzają podstawowe właściwo­ ści języka programowania. Wśród przykładów takich rozszerzeń można wymienić obsługę wej­ ścia i wyjścia w nagłówku stdi o języka C, nagłówku i ostream języka C+ + oraz pakiecie java . i o języka Java. Ś ciślej mówiąc, wymienione dodatki nie należą do języka, ale są zdefi­ niowane wraz z nim i powinny być dostępne w każdym środowisku, które ten język obsługuje. Ponieważ jednak biblioteki udostępniają niezliczone ilości funkcji i często muszą zawierać rozwiązania problemów specyficznych dla konkretnych systemów operacyjnych, w nich rów­ nież mogą być ukryte cechy utrudniające przenośność.

Używaj standardowych bibliotek. Ogólna wskazówka jest w tym przypadku taka sama, jak ta dotycząca języka: trzymaj się standardu i używaj jego starszych, już dobrze poznanych skład­ ników. W języku C są zdefiniowane standardowe biblioteki funkcji wejścia i wyjścia, operacji na łańcuchach, testów do klasyfikowania znaków, procedur do alokowania pamięci i wielu in­ nych zadań. Jeśli interakcje z systemem operacyjnym zaprogramujesz przy użyciu tych funkcji, to jest duża szansa, że Twój kod będzie działał i zachowywał się podobnie w różnych syste­ mach. Nadal musisz jednak zachować czujność, gdyż każda biblioteka ma wiele implementacji, a pewne z nich mogą zawierać właściwości, które nie są zdefiniowane w standardzie. Standard ANSI języka C nie definiuje funkcji do kopiowania łańcuchów o nazwie strdup, a mimo to w większości środowisk można ją spotkać, nawet w tych, które deklarują zgodność ze standardem. Doświadczony programista może używać tej funkcji z przyzwyczajenia i nawet nie zostać ostrzeżonym, że jest to funkcja niestandardowa. Później jego program może nie za­ działać, jeśli zostanie przeniesiony do środowiska, w którym tej funkcji nie ma. Jest to jeden z największych problemów z przenośnością powodowanych przez biblioteki. Jedynym dobrym wyjściem jest trzymanie się standardu i testowanie programu w różnych środowiskach. Pliki nagłówkowe i definicje pakietów tworzą interfejs do standardowych funkcji. Z na­ główkami jest taki problem, że często są bardzo zagmatwane, gdyż próbuje się w nich umieszczać konstrukcje dla różnych języków programowania. Na przykład nierzadko jeden plik stdio.h ob­ sługuje kompilatory języków C w wersji sprzed powstania standardu ANSI, ANSI C, a nawet C+ + . Takie pliki zawsze są pełne dyrektyw kompilacji warunkowej, takich jak #i f i #i fdef. Ponieważ język preprocesora nie jest zbyt rozbudowany, pliki te są skomplikowane i trudne do odczyru, a czasami zawierają też błędy.

8.2. NAGŁÓWKI I BIBLIOTEKI

203

Poniższy fragment kodu, pochodzący z pliku nagłówkowego z jednego z naszych systemów, jest jednym z lepszych, ponieważ został zgrabnie sformatowany:

? ?

?

#i fdef OLD C extern i nt fread ( ) ; extern i nt fwri te () ; #el se # i f defi ned ( STDC ) 1 1 defi ned ( cpl uspl us) extern s i ze t fread (vo i d * , s i ze-t , s i ze t, FI LE*) ; extern s i ze=t fwri te(const v o i d*, s i z e_t, s i ze_t , FI LE*) ; # el se /* not _STDC_ l i _cplusplus *I extern s i ze t fread ( ) ; extern s i ze=t fwri t e ( ) ; # end i f /* e/se not _STDC_ l i _cplusplus *I #end i f

Mimo iż ten przykład jest względnie przejrzysty, na jego podstawie widać, że pliki nagłów­ kowe (i programy) o takiej strukturze są zawiłe i trudne do rozszyfrowania. Prościej by było, gdyby dla każdego kompilatora lub środowiska był tworzony osobny plik. Chociaż wówczas trzeba by utrzymywać wiele plików, to każdy z nich stanowiłby odrębną i odpowiednią dla da­ nego systemu jednostkę. To zmniejszyłoby ryzyko wystąpienia błędów, takich jak użycie funk­ cji s trdup w środowisku zgodnym ze standardem C. Ponadto pliki nagłówkowe mogą „zaśmiecać" przestrzeń nazw deklaracjami funkcji o na­ zwach takich samych, jak użyte w programie. Na przykład nasza funkcja do zgłaszania komu­ nikatów ostrzegawczych miała początkowo nazwę wpri n t f, ale odkryliśmy, że w niektórych środowiskach w nagłówku stdio.h znajduje się już definicja funkcji o takiej nazwie utworzona w celu zapewnienia zgodności z mającym się dopiero pojawić nowym standardem języka C. Aby móc skompilować program w tych systemach, byliśmy zmuszeni zmienić nazwę naszej funkcji na wepri ntf. Gdyby problem wynikał nie z uzasadnionej zmiany specyfikacji, lecz z błędu implementacyjnego, to rozwiązalibyśmy go, zmieniając przeszkadzającą nam nazwę przy dołą­ czaniu nagłówka: I* Niektóre wersje nagłówka stdio używająfunkcji wprintf, której deklarację tu usuwamy *I

?

#defi ne wpri ntf stdi o_wpri ntf #i ncl ude #undef wpri ntf

I* Kod z wykorzystaniem naszejfunkcji wprintfO... *I

Za pomocą tych dyrektyw zamieniliśmy wszystkie wystąpienia nazwy wpri nt f w pliku na­ główkowym na nazwę stdi o_wpri ntf, aby nie kolidowała z naszą funkcją. Teraz możemy bez przeszkód używać naszej funkcji wpri nt f, ale ceną za to jest trochę nieeleganckiego kodu i ry­ zyko, że jakaś biblioteka, którą dołączymy do programu, będzie chciała wywołać oficjalną wer­ sję funkcji wpri ntf. Jeśli problem dotyczy tylko jednej funkcji, to gra nie jest warta świeczki, ale w niektórych systemach jest taki bałagan, że czasami nie ma innego wyjścia, jak tylko za­ stosować radykalne rozwiązania. Pamiętaj, aby napisać w komentarzu, do czego służy taka konstrukcja, oraz nie pogarszaj sytuacji kolejnymi dyrektywami kompilacji warunkowej. Jeżeli w pewnych środowiskach znajduje się definicja funkcji wpri n t f, to musisz przyjąć założenie, że jest ona wszędzie. Dzięki temu poprawka będzie zawsze działała i nie będzie trzeba używać instrukcji #i fdef. W wielu sytuacjach łatwiej, a na pewno bezpieczniej, jest po prostu zmienić nazwę swojej funkcji, niż szarpać się z nagłówkiem, i takie właśnie rozwiązanie zastosowaliśmy w naszym kodzie.

204

8. PRZENOŚNOŚĆ

Nawet jeśli chcesz ściśle trzymać się zasad, a środowisko, z którego korzystasz, jest czyste, łatwo możesz przekroczyć granice, nieświadomie zakładając, że jakaś Twoja ulubiona kon­ strukcja jest dostępna wszędzie. Na przykład w języku ANSI C jest zdefiniowanych 6 sygna­ łów, które można przechwytywać za pomocą standardowej funkcji s i gna l . Standard POSIX definiuje takich sygnałów 1 9, a większość systemów uniksowych 32 lub więcej. Jeśli chcesz skorzystać z sygnału nienależącego do standardu ANSI C, to musisz wybrać między funkcjo­ nalnością a przenośnością, czyli zdecydować, co jest dla Ciebie ważniejsze. Istnieje wiele innych standardów, które nie należą do definicji żadnego języka programo­ wania. Wśród przykładów można tu wymienić interfejsy sieciowe i systemów operacyjnych, interfejsy graficzne itp. Niektóre z nich, np. POSIX, są przeznaczone do użytku w wielu sys­ temach, natomiast inne, np. rozmaite API dla systemu Microsoft Windows, są przeznaczone tylko dla wybranego systemu. Przedstawione powyżej rady odnoszą się również do nich. Twoje programy będą łatwiejsze do przenoszenia, jeśli do ich budowy użyjesz dobrze znanych i szero­ ko wykorzystywanych standardów oraz będziesz używać ich najważniejszych i najczęściej używa­ nych elementów. -

8.3. Organizacja programu Można wyróżnić dwa różne podejścia do kwestii przenośności programów, które będziemy określać jako wykorzystanie sumy i części wspólnej zbiorów właściwości. Pierwsze podejście polega na wykorzystaniu w programie najlepszych właściwości wszystkich określonych syste­ mów i uzależnienie procesów kompilacji i instalacji od cech lokalnego środowiska. Tak po­ wstały kod obsługuje sumę wszystkich najlepszych elementów, tzn. wykorzystuje to, co najlepsze w każdym systemie. Wśród wad tego podejścia można wymienić rozmiar i poziom złożoności instalacji oraz komplikację kodu wynikającą z zastosowania w nim warunków kompilacyjnych.

Używaj tylko konstrukcji dostępnych wszędzie. Polecamy zastosowanie drugiego podejścia, tzn. korzystania tylko z rzeczy, które są dostępne we wszystkich docelowych systemach. Jeśli czegoś brakuje w którymś z systemów, to zrezygnuj z tego. Potencjalną trudnością, która może się pojawić przy stosowaniu tego podejścia, jest to, że ograniczenie do zbioru tylko uniwersal­ nych właściwości może uniemożliwić obsługę niektórych systemów albo wymusić zredukowa­ nie funkcjonalności programu. Ponadto w pewnych środowiskach może przez to ucierpieć wy­ dajność. Porównamy te dwa podejścia, analizując kilka przykładów utworzonych z zastosowaniem zasady wykorzystania sumy właściwości i implementując je ponownie z zastosowaniem podejścia zbioru wspólnego. Przekonasz się, że kod powstały przy użyciu sumy właściwości jest z zasady nieprzenośny, mimo iż założenie było inne, natomiast kod powstały przy użyciu zbioru wspól­ nego jest nie tylko przenośny, lecz także prostszy. W tym krótkim przykładzie próbujemy poradzić sobie ze środowiskiem, w którym z jakichś nieznanych nam przyczyn nie ma standardowego pliku nagłówkowego stdlib.h :

# i f defi ned (STDC_HEADERS) / / defi ned (_LI BC) #i ncl ude #el se extern v o i d *mal l oc (unsi gned i nt ) ; extern voi d *real l oc (voi d *, unsi gned i nt ) ; #end i f

205

8.3. ORGANIZACJA PROGRAMU

Tego rodzaju sztuczki są dopuszczalne tylko wtedy, gdy stosuje się je od czasu do czasu. Ponadto aż ciśnie się na usta pytanie, ile jeszcze innych funkcji z nagłówka stdl i b w końcu znajdzie się w tym lub podobnym kodzie warunkowym. Na przykład jeśli ktoś używa funkcji ma 1 1 oc i rea 1 1 oc, to na pewno będzie też potrzebować funkcji free. Co jeśli typ i nt bez znaku będzie miał inny rozmiar niż s i ze_t, który jest prawidłowym typem argumentów funkcji ma 1 1 oc i rea 1 1 oc? Poza tym skąd wiadomo, czy STDC H EADERS i _ LI BC są zdefiniowane, a jeśli tak, to czy są zdefiniowane poprawnie? Skąd możemy wiedzieć, czy w innym środowisku nie ma nazwy, którą należałoby zamienić? Każdy tego typu kod warunkowy jest niekompletny i nie­ przenośny, gdyż wcześniej czy później w końcu znajdzie się taki system, który nie będzie speł­ niał tego warunku, co zmusi nas do użycia dyrektyw # i fdef. Gdybyśmy mogli pozbyć się tych dyrektyw warunkowej kompilacji, to uniknęlibyśmy przyszłych problemów. Niemniej jednak przedstawiony w tym przykładzie problem jest realny, a więc zastanówmy się, jak go rozwiązać raz a dobrze. Najlepiej gdybyśmy przyjęli założenie, że standardowe na­ główki są dostępne. Jeśli ich nie ma, to nie nasz problem. Jeżeli to nam nie wystarczy, najprost­ sze wydaje się dostarczanie wraz z programem pliku nagłówkowego zawierającego definicje funk­ cji ma 1 1 oc, rea 1 1 oc i free w dokładnie takiej postaci, w jakiej są zdefiniowane w standardzie ANSI C. Zawsze można dodać ten plik, zamiast łatać kod ze wszystkich stron. Dzięki temu zawsze będziemy mieć pewność, że potrzebny nam interfejs j est dostępny. _

Unikaj kompilacji warunkowej. Trudno zapanować nad dyrektywami kompilacji warunkowej #i fdef i innymi, ponieważ są one rozproszone po całym kodzie źródłowym. #i fdef NATIVE char *astr i ng = " Przekonwertuj ASC I I na rodzimy zestaw znaków" #el se #i fdef MAC " Przekonwertuj na format p 1 i ku tekstowego systemu Mac " ; char *as tri ng #el se #i fdef DOS char *astri ng " Przekonwertuj na format pl i ku tekstowego systemu DOS " ; #el se char aastring " Przekonwertuj n a format pl i ku tekstowego systemu Uni x " ; #end i f /* ?DOS */ #end i f /* ?MAC *I #end i f /* ?NATIVE */ =

=

Kod ten wyglądałby lepiej, gdyby zamiast stosu dyrektyw #end i f na końcu po każdej defi­ nicji zastosowano dyrektywę #el i f. Prawdziwy problem dotyczy jednak czegoś innego. Mimo intencji twórcy, kod ten jest bardzo słabo przenośny, ponieważ w każdym systemie zachowuje się inaczej i dla każdego nowego środowiska wymaga dodania nowej dyrektywy #i fdef. Znacznie prostsza, całkowicie przenośna i niosąca tyle samo informacji byłaby jedna ogólna instrukcja:

char *astri ng = " Przekonwertuj na l okal ny format tekstowy " ; Taka instrukcja nie wymaga stosowania żadnych warunków, ponieważ jest taka sama we wszystkich systemach. Mieszanie instrukcji sterujących przepływem sterowania w czasie kompilacji (dyrektyw #i fdef) z instrukcjami kontroli przepływu sterowania w czasie działania programu to znacznie gorsze rozwiązanie, gdyż taki kod jest nieczytelny.

206 ? ? ?

8. PRZENOŚNOŚĆ

#i fndef D I SKSYS for (i l; <= msg->dbgmsg . msg_total ; i ++) #end i f #i fdef D I SKSYS i dbgmsgno; if ( i <= msg->dbgmsg . msg_total ) #end i f { =

=

? ? ?

i f (msg->dbgmsg . msg_total i) # i fndef D I S KSYS break ; /* Nie ma więcej komunikatów *I ==

jeszcze około 30 wierszy dyrektyw komp i l acj i warunkowej

#endi f }

?

Nawet pozornie nieszkodliwe dyrektywy kompilacji warunkowej często można zastąpić bardziej przejrzystym kodem. Na przykład dyrektywy #i fdef są często wykorzystywane do sterowania kodem diagnostycznym:

#i fdef DEBUG pri ntf ( . . . ) ; #end i f

? ?

Ale równie dobrze sprawdzi się m zwykła instrukcja i f ze stałym warunkiem:

enum { DEBUG = O } ; i f (DEBUG) { pri ntf(

„ .

);

Jeśli wartość stałej DEBUG będzie wynosić zero, to większość kompilatorów nie wygeneruje dla tej instrukcji żadnego kodu, ale sprawdzi składnię wykluczanego kodu. Natomiast dyrek­ tywy #i fdef mogą skrywać błędy składni, które po włączeniu tych dyrektyw mogą uniemożli­ wić kompilację. Czasami dyrektywy kompilacji warunkowej są używane do wyłączania dużych partii kodu:

#i fdef notdef /* Niezdefiniowany symbol */ #end i f lub

#if

o

#endi f Ale zamiast takiego warunkowego kodu można używać plików warunkowo zastępowanych podczas kompilacji Wrócimy jeszcze do tego temam w następnym podrozdziale. Jeśli musisz dostosować program do nowego środowiska, to nie zaczynaj pracy od skopio­ wania całego programu. W zamian dostosuj istniejący kod źródłowy. Prawdopodobnie ko-

8.3. ORGANIZACJA PROGRAMU

207

nieczne będą zmiany w głównej części kodu źródłowego i jeżeli będziesz pracować na kopii, to bardzo szybko otrzymasz dwie oddalające się od siebie wersje programu. O ile to możliwe, zaw­ sze powinna być tylko jedna wersja kodu źródłowego programu. Jeśli musisz coś zmienić, aby móc przenieść program do nowego środowiska, postaraj się to zrobić tak, aby te zmiany dzia­ łały wszędzie. W razie konieczności zmień wewnętrzne interfejsy, ale zachowaj spójność kodu i nie używaj dyrektyw #i fdef. Dzięki temu program będzie stawał się coraz bardziej przenośny, a nie wyspecjalizowany. Zawężaj część wspólną, zamiast poszerzać sumę. Odradzaliśmy używanie kompilacji warunkowej i na poparcie naszych tez przedstawiliśmy kilka przykładów problemów, które technika ta może powodować. Ale nie wspomnieliśmy jeszcze ani słowem o najgorszym: kodu takiego prawie nie da się przetestować. Dyrektywy #i fdef zamieniają jeden program w dwa oddzielnie kompilowane programy. Trudno się do­ wiedzieć, czy wszystkie możliwe warianty zostały skompilowane i przetestowane. Jeśli zmie­ nimy coś w jednym bloku #i fdef, to przypuszczalnie będziemy musieli też zmienić pozostałe, a zmiany takie można przetestować tylko w środowiskach, które powodują użycie poszczegól­ nych bloków. Jeżeli podobna zmiana jest konieczna dla innych konfiguracji, to nie można ich przetestować. Ponadto gdy dodamy nowy blok #i fdef, trudno jest wyizolować tę zmianę, aby dowiedzieć się, jakie inne warunki również powinny być spełnione oraz gdzie jeszcze ten sam problem może wymagać naszej uwagi. W końcu, jeśli w kodzie jest coś, co jest warunkowo po­ mijane, to kompilator tego nie zauważy. Może to być kompletna bzdura, a my nie dowiemy się o jej istnieniu, dopóki jakiś biedny klient nie spróbuje skompilować programu w środowisku, w którym zostanie ona użyta. Ten kod będzie skompilowany tylko wtedy, gdy stała _MAC bę­ dzie zdefiniowana:

#i fdef MAC pri ii't f ( " To jest Maci ntosh\r" ) ; #el se To spowoduje błąd s kładni owy w i nnych systemach #end i f Podsumowując, stanowczo zachęcamy do używania tylko tych rzeczy, które można znaleźć we wszystkich docelowych systemach. Dzięki temu możemy skompilować i przetestować cały kod. Jeśli występują jakieś problemy z przenośnością, piszemy kod od nowa tak, aby je wyelimino­ wać, a nie stosujemy kompilacji warunkowej. W ten sposób poziom przenośności programu będzie stale rosnąć i sam kod będzie coraz lepszy, a nie coraz bardziej skomplikowany. W niektórych dużych systemach znajduje się skrypt konfiguracyjny dostosowujący kod do lokalnego środowiska. W czasie kompilacji skrypt ten sprawdza właściwości środowiska - lo­ kalizację plików nagłówkowych i bibliotek, porządek bajtów w słowach, rozmiar typów, znane niepoprawne implementacje (zaskakująco liczne) itp. - i generuje odpowiednio dobrane pa­ rametry konfiguracyjne lub plik make. Te często obszerne i zawiłe skrypty mogą stanowić znaczną część całego oprogramowania, a ponadto, aby poprawnie realizowały swoje zadania, wymagają ciągłej uwagi. Czasami stosowanie takich technik jest konieczne, ale im bardziej kod jest przenośny i im mniej zawiera dyrektyw #i fdef, tym łatwiejsza i bardziej niezawodna bę­ dzie jego konfiguracja i instalacja.

Ćwiczenie 8.1. Sprawdź, jak Twój kompilator obsługuje kod znajdujący się w takim bloku wa­ runkowym:

const i nt DEBUG = O ; /* lub enum { DEBUG = O}; */ /* lub fina/ boolean DEBUG =fa/se; */

208 if

8. PRZENOŚNOŚĆ

(DEBUG)

Co powoduje sprawdzenie składni? Kiedy jest generowany kod? Jeśli masz dostęp do in­ nych kompilatorów, to jak wypada porównanie wyników?

8.4. Izolacja Mimo i ż chcielibyśmy mieć tylko jedną wersję kodu źródłowego programu, która kompiluje się bez konieczności wprowadzania zmian we wszystkich systemach, może to być nierealne. Lecz błędem jest rozrzucanie po całym kodzie nieprzenośnych fragmentów kodu. Jest to jeden z problemów stwarzanych przez kompilację warunkową.

Zależności systemowe umieszczaj w osobnych plikach. Jeśli dla różnych systemów potrzeb­ ne są odmienne fragmenty kodu, różnice powinny być zlokalizowane w osobnych plikach, po jednym dla każdego systemu. Na przykład edytor tekstu Sam działa w systemie Unix, Win­ dows i kilku innych systemach operacyjnych. Interfejsy tych wszystkich środowisk są bardzo różne, a mimo to większość kodu źródłowego wspomnianego edytora jest w każdym z nich identyczna. Kod dotyczący poszczególnych środowisk jest zapisany w osobnych plikach, np. w pliku unix.c znajduje się kod specyficzny dla systemu Unix, a w pliku windows.c kod dla środowiska Windows. Pliki te stanowią implementację przenośnego interfejsu do systemu ope­ racyjnego i ukrywają różnice. W efekcie edytor Sam jest napisany dla swojego własnego wirtu­ alnego systemu operacyjnego, który jest przenoszony do prawdziwych systemów. Do tego trzeba było napisać kilkaset wierszy kodu w języku C w celu zaimplementowania kilku niewielkich, ale nieprzenośnych operacji wykorzystujących lokalne wywołania systemowe. Ś rodowiska graficzne obsługiwanych systemów nie mają ze sobą prawie nic wspólnego. Program radzi sobie z tym w ten sposób, że ma własną przenośną bibliotekę graficzną. Mimo iż zbudowanie takiej biblioteki wymaga znacznie więcej wysiłku niż zmuszenie kodu, aby dosto­ sował się do danego systemu - na przykład kod sprzęgający program z systemem X Window jest prawie tak duży, jak połowa reszty edytora Sam - w dłuższym rozrachunku jest to opła­ calne. Ponadto dodatkową korzyścią jest to, że powstała biblioteka graficzna, przy użyciu któ­ rej utworzono kilka innych przenośnych programów. Sam jest starym programem. Obecnie istnieją przenośne środowiska graficzne dostępne na rozmaitych platformach, np. OpenGL, Tclffk czy graficzne biblioteki Javy. Programy napisa­ ne przy użyciu tych bibliotek mogą działać w większej liczbie systemów, niż gdyby zostały na­ pisane z wykorzystaniem jakiejś specyficznej biblioteki systemowej. -

Ukrywaj zależności systemowe za interfejsami. Abstrakcja to doskonałe narzędzie do od­ dzielania przenośnych części programu od nieprzenośnych. Dobrym tego przykładem są bi­ blioteki wejścia-wyjścia znajdujące się w większości języków programowania: stanowią one abstrakcję pamięci drugiego rzędu w postaci plików, które można otwierać i zamykać oraz od­ czytywać i zapisywać bez odwoływania się do ich fizycznej lokalizacji czy struktury. Programy trzymające się ściśle interfejsu będą działać we wszystkich systemach, które ten interfejs im­ plementują. lmplementacja·programu Sam jest kolejnym przykładem abstrakcji. Znajduje się w nim in­ terfejs do systemu plików i operacji graficznych i program korzysta tylko z tego interfejsu. Na-

209

8.5. WYMIANA DANYCH

tomiast interfejs korzysta z wszystkich dobrodziejstw systemu operacyjnego. Takie korzystanie z systemu wymagałoby użycia różnych implementacji w różnych systemach, ale dzięki użyciu interfejsu program jest niezależny i nie wymaga żadnych zmian podczas przenoszenia. Dobrą ilustracją tego, jak daleko można się posunąć, jest rozwiązanie kwestii przenośności w Javie. Programy napisane w tym języku są tłumaczone na język „maszyny wirtualnej", tzn. wirtualnego komputera, który może być zaimplementowany w każdym systemie. Biblioteki Javy dają jednolity dostęp do właściwości systemu operacyjnego, włącznie z bibliotekami gra­ ficznymi, interfejsem użytkownika, interfejsem sieciowym itd. Biblioteki umożliwiają korzy­ stanie z wszystkiego, co udostępnia system. Teoretycznie każdy program napisany w Javie (nawet po tłumaczeniu) powinien się uruchomić w każdym systemie bez żadnych zmian.

8 . 5 . Wymiana danych Najprostszym sposobem na przenoszenie informacji między dwoma systemami jest przekaza­ nie ich w formacie tekstowym, który bardzo łatwo się przenosi.

Wymieniaj dane w formacie tekstowym. Tekst łatwo poddaje się obróbce za pomocą rozma­ .itych programów i bez trudu można go wykorzystywać w nietypowych zastosowaniach. Jeśli np. tekst zwrócony przez jeden program nie w pełni nadaje się do użycia na wejściu innego programu, to można go dostosować za pomocą skryptu w języku Perl albo Awk. Korzystając z programu grep, można wybierać lub usuwać linie tekstu, a stosując edytor tekstu, można wy­ konać bardziej skomplikowane modyfikacje. Ponadto pliki tekstowe łatwo dokumentować, aczkol­ wiek w wielu przypadkach nie jest to w ogóle potrzebne, gdyż ludzie mogą odczytać ich zawar­ tość. Komentarz w pliku tekstowym może wskazywać, jaka wersja programu jest potrzebna do przetworzenia danych. Na przykład pierwszy wiersz pliku PostScript określa kodowanie: % ! PS-Adobe-2 . 0 Natomiast do edycji plików binarnych są potrzebne specjalne narzędzia i rzadko można ich używać razem nawet na w tym samym komputerze. Istnieje wiele znanych programów służą­ cych do konwersji danych binarnych dowolnego typu na tekst, aby można je było przesyłać, zbytnio nie ryzykując uszkodzenia. Spośród wielu tych programów można wymienić binhex dla systemów Mac OS, uuencode i uudecode dla Uniksa oraz różne narzędzia wykorzystujące kodowanie MIME do przesyłania danych binarnych w wiadomościach e-mail. W rozdziale 9. opiszemy rodzinę procedur służących do pakowania danych binarnych i rozpakowywania ich do przenośnej postaci nadającej się do przesyłania. Sama liczba takich narzędzi świadczy o skali problemu związanego z używaniem formatów binarnych. Jest jeden irytujący nierozwiązany problem dotyczący wymiany informacji w postaci tek­ stowej : w komputerach osobistych do oznaczania końca wiersza są stosowane znaki powrotu karetki ( ' \ r ' ) i nowego wiersza ( ' \n ' ), natomiast w systemach uniksowych używany jest do tego tylko znak nowego wiersza. Znak powrotu karetki jest pozostałością po „starożytnych" urządzeniach zwanych dalekopisami, w których istniała operacja powrotu karetki (ang. caniage return CR), przesuwająca mechanizm piszący do początku wiersza, oraz osobna operacja przejścia do nowego wiersza (ang. linefeed LF). Mimo iż w dzisiejszych komputerach osobistych nie pozostał nawet ślad po operacji po­ wrotu karetki, tworzone dla nich programy nadal wymagają tej kombinacji znaków (popular­ nie zwanej CRLF; należy wymawiać: kerlif) na końcu każdego wiersza. Jeśli nie będzie żadnego -

-

210

8 . PRZENOŚNOŚĆ

znaku powrotu karetki, to cały plik może zostać zinterpretowany jako jeden gigantyczny łań­ cuch tekstu. Wyniki liczenia wierszy lub znaków będą wówczas niepoprawne albo mogą się zmieniać w nieoczekiwany sposób. Pewne programy elegancko się dostosowują, ale nie wszyst­ kie. Nie tylko komputery osobiste tu zawiniły. Także niektóre nowoczesne standardy, takie jak np. protokół HTTP, ze względu na zabiegi mające na celu zachowanie zgodności używają zna­ ków CRLF do oddzielania wierszy tekstu. Nasza rada jest taka, aby używać standardowych interfejsów, które zapewniają jednakowe traktowanie znaków CRLF we wszystkich systemach. Jest to osiągane przez usunięcie znaku \r z danych wejściowych i dodanie go z powrotem do danych wyjściowych (w komputerach PC) albo używanie tylko znaku \n zamiast znaków CRLF do oddzielania wierszy tekstu (w systemie Unix). W przypadku plików, które muszą być przesyłane między tymi dwoma rodzajami systemów, konieczne jest zastosowanie programu do konwersji między wspomnianymi formatami.

Ćwiczenie 8.2. Napisz program usuwający z pliku niepotrzebne znaki powrotu karetki. Napisz drugi program, który dodaje te znaki z powrotem, zamieniając każdy znak nowego wiersza na znak powrotu karetki i nowego wiersza. Jak przetestujesz te programy?

8.6. Kolejność bajtów Mimo licznych wad, o których była mowa powyżej, formaty binarne są czasami potrzebne. Mogą one zajmować znacznie mniej miejsca i dać się szybciej dekodować, co ma duże znacze­ nie w wielu sytuacjach związanych z pracą w sieci. Niestety, formaty binarne są obciążone po­ ważnymi wadami dotyczącymi przenośności. Przynajmniej jedna z kwestii została już rozwiązana: we wszystkich nowoczesnych kompu­ terach bajt składa się z 8 bitów. Lecz w różnych architekturach stosuje się różne reprezentacje obiektów o rozmiarze większym od 1 bajta. Z tego powodu przystosowanie programu do jedne­ go rodzaju reprezentacji jest błędem. Krótki typ całkowitoliczbowy (zwykle 16-bitowy, czyli zawierający 2 bajty) może mieć niski bajt zapisany pod niższym adresem niż bajt wysoki (little­ endian) lub pod wyższym (big-endian). Wybór ten jest dokonywany arbitralnie, a niektóre ma­ szyny obsługują nawet obie metody zapisu bajtów. W związku z tym, mimo iż komputery w obu przypadkach traktują pamięć jako szereg słów ustawionych w takiej samej kolejności, bajty w poszczególnych słowach interpretują odwrot­ nie. Na poniższym rysunku 4 bajty zaczynające się od pozycji O w maszynach z porządkiem bajtów big-endian będą reprezentować szesnastkową liczbę całkowitą Ox11223344, a w maszy­ nach z porządkiem bajtów little-endian wartość Ox44332 2 1 1 . -

o

2

3

4

5

6

7

8

I I I I I I I I Aby praktycznie przekonać się o różnicach w kolejności bajtów, wypróbuj poniższy program: /* Kolejność bajtów: wyświetla bajty wartości typu long */

i nt mai n (vo i d ) { unsi gned l ong x ; unsi gned char *p ;

8.6. KOLEJNOŚĆ BAJTÓW

21 1

i nt i ; /* 1 1 22 33 44 => porządek big-endian *I /* 44 33 22 1 1 => porządek little-endian */ /* x Oxl l 22334455667788UL; dla typów long w architekturze 64-bitowej */ =

x Ox1 1223344U L ; p (unsi gned char *) &x; for ( i = O ; i < s i zeof(l ong) ; i ++) *p++) ; pri ntf( "%x pri ntf ( " \ n " ) ; return O ; =

=

11 ,

W maszynach z malejącym porządkiem bajtów program ten zwróci następujący wynik:

11 22 33 44 W komputerach z rosnącym porządkiem bajtów wynik będzie taki:

44 33 22 1 1 Natomiast w maszynach PDP-l l ( 16-bitowych starych maszynach, które czasami można jeszcze spotkać w układach wbudowanych) otrzymamy taki wynik:

22 11 44 33 W maszynach z 64-bitowym typem l ang możemy zastosować większą wartość stałej, aby uzyskać podobne wyniki. Ten program może się wydawać głupi, lecz jeśli chcemy wysłać liczbę całkowitą przez wą­ ski kanał o szerokości tylko 1 bajta, taki jak połączenie sieciowe, to musimy zdecydować, od którego bajta zacząć przesyłanie. Decyzja ta sprowadza się w istocie do wyboru pomiędzy ro­ snącym a malejącym porządkiem bajtów. Innymi słowy, ten program robi jawnie to, co poniż­ sza instrukcja robi niejawnie:

fwri te(&x, s i zeof (x) , 1 , stdout ) ; Zapisywanie danych typu i nt (albo s hort lub l ang) na jednym komputerze i wczytywanie ich jako typu i nt na innym to nie najlepszy sposób pracy. Jeśli np. na komputerze źródłowym do zapisu danych zostanie użyty poniższy kod:

unsi gned short x ; fwri te(&x, s i zeof (x) , 1 , stdout ) ; a na komputerze docelowym taki:

unsi gned short x ; fread ( &x , s i zeof (x) , l , std i n ) ; to gdy maszyny te stosują inną kolejność bajtów, wartość zmiennej x zostanie zniekształcona. Jeżeli np. x będzie miało początkowo wartość OxlOOO, to zostanie odebrane jako Ox0010.

212

8. PRZENOŚNOŚĆ

Do rozwiązania tego problemu często używa się kompilacji warunkowej i stosuje się zamianę bajtów:

short x ; fread (&x , s i zeof(x) , 1 , stdi n ) ; #i fdef BIG ENDIAN I* Zamiana bajtów *I

x ( (x&OxFF) << 8) I ( (x>>8) & OXFF) ; #end i f =

Gdy trzeba wymienić bajty w wielu 2- i 4-bajtowych wartościach całkowitych, podejście to staje się bardzo niewygodne. Zwykle kończy się na tym, że bajty są wymieniane częściej niż raz podczas przesyłania z miejsca w miejsce. Jeśli sytuacja wygląda źle dla typu s hort, to dla dłuższych typów jest jeszcze gorsza, ponie­ waż w nich jest więcej możliwych permutacji bajtów. Jeżeli dodać do tego różne sposoby wy­ pełnienia luk między składowymi struktur, ograniczenia dotyczące rozmieszczenia bajtów oraz dziwne metody porządkowania bajtów stosowane w niektórych starszych urządzeniach, to pro­ blem wydaje się niemożliwy do rozwiązania.

Do wymiany danych używaj stałego porządku bajtów. Wbrew pozorom wspomniany problem da się rozwiązać. Zapisuj bajty w kanonicznym porządku przy użyciu przenośnego kodu:

unsi gned short x ; putchar(x » 8) ; /* Zapisuje bajt wysoki *I putchar(x & OxFF) ; /* Zapisuje bajt niski *I a następnie wczytuj je pojedynczo z powrotem i składaj w całość:

unsi gned short x ; x = getchar() « 8 ; /* Pobiera bajt wysoki *I x I = getcha r ( ) & OxFF; /* Pobiera bajt niski *I Podejście to można uogólnić na struktury, jeśli będzie się wartości struktur zapisywać w określonej kolejności po I bajcie bez dopełnienia. Nie ma znaczenia, jaką kolejność bajtów się wybierze, ważne jest tylko, aby cały czas stosować tę samą metodę. Jedyny warunek jest taki, aby zarówno nadawca, jak i odbiorca zgadzali się co do kolejności i liczby bajtów w każdym obiekcie. W następnym rozdziale pokażemy kilka procedur służących do pakowania i rozpa­ kowywania ogólnych danych. Przetwarzanie danych po I bajcie może wydawać się kosztowne, ale w porównaniu z opera­ cją wejścia-wyjścia, która wymaga pakowania i rozpakowywania danych, koszt ten jest niewiel­ ki. Weźmy na przykład system X Window, w którym klient przesyła dane, stosując własną kolejność bajtów, a serwer musi rozpakować to, co otrzyma od klienta. Podejście to pozwala za­ oszczędzić kilka instrukcji po stronie klienta, ale za to serwer j est większy i bardziej skompli­ kowany, ponieważ musi jednocześnie obsługiwać różne rodzaje uporządkowania bajtów (równie dobrze serwer mógłby obsługiwać współbieżnie działających klientów z rosnącym i malejącym porządkiem bajtów) przez co złożoność obliczeniowa i rozmiar kodu są wówczas znacznie większe. Poza tym jest to środowisko graficzne, a więc narzut spowodowany pakowaniem baj­ tów będzie i tak znacznie mniejszy niż koszt wykonania operacji graficznej. System X Window negocjuje kolejność bajtów dla danego klienta i wymaga od serwera, aby potrafił obsługiwać oba przypadki. Natomiast system operacyjny Plan 9 określa kolejność bajtów w komunikatach do serwera plików (lub grafiki), po czym dane zostają spakowane i rozpakowane

8.7. PRZENOŚNOŚĆ A UAKTUALNIANIE

213

za pomocą przenośnego kodu, takiego jak powyższy. W praktyce wpływ tego procesu na czas działania programu jest niezauważalny. W porównaniu z operacjami wejścia-wyjścia koszt pa­ kowania danych jest zaniedbywalnie niski. Java jest językiem wyższego poziomu niż języki c i c+ + i całkowicie ukrywa kolejność bajtów. W bibliotekach dostępny jest interfejs o nazwie Seri a 1 i zab1 e, który określa sposób pakowania danych przeznaczonych do wymiany. Jeśli jednak korzystasz z języka C lub C+ +, to musisz sam zadbać o swoje interesy. Klu­ czowe znaczenie w podejściu przesyłania danych po 1 bajcie ma fakt, że rozwiązuje ono pro­ blem bez użycia dyrektyw #i fdef dla wszystkich maszyn, w których bajt składa się z 8 bitów. Szerzej na ten temat piszemy w następnym rozdziale. Niemniej jednak w wielu przypadkach najlepszym rozwiązaniem jest konwersja danych na format tekstowy, który (z wyjątkiem kwestii znaków CRLF) jest całkowicie przenośny. Repre­ zentacja w tym formacie jest zawsze jednoznaczna. Niestety, nie zawsze format ten jest najlepszym rozwiązaniem. Niekiedy w grę mogą wchodzić ograniczenia pamięciowe lub czasowe, a poza tym niektóre rodzaje informacji, zwłaszcza liczby zmiennoprzecinkowe, mogą utracić precyzję z powodu zaokrąglania wykonywanego np. przez funkcje pri ntf i scanf. Jeśli nie możesz sobie pozwolić na utratę precyzji danych zmiennoprzecinkowych, zaopatrz się w dobrą, sformatowa­ ną bibliotekę wejścia-wyjścia. Takie biblioteki istnieją, ale to nie znaczy, że na pewno są w śro­ dowisku, z którego korzystasz. Wyjątkowo trudno jest zapewnić przenośną reprezentację liczb zmiennoprzecinkowych w formacie binarnym, ale jeśli zachowa się szczególną uwagę, to można posłużyć się też tekstem. Z używaniem funkcji standardowych do obsługi plików binarnych wiąże się jeden delikat­ ny problem dotyczący przenośności - pliki binarne należy otwierać w trybie binarnym:

FILE *fi n ;

fi n = fopen (bi nary_fi l e , " rb" ) ; c = getc (fi n) ; Opuszczenie litery b w systemach uniksowych niczego nie zmieni, ale w systemie Windows pierwszy bajt Control-Z (032 w systemie ósemkowym i lA w systemie szesnastkowym) na wejściu powoduje zakończenie wczytywania danych (tak się stało w programie stri ngs, który omówi­ liśmy w rozdziale 5.). Z drugiej strony użycie trybu binarnego do odczytu plików tekstowych spowoduje zachowanie znaku \ r w danych wejściowych i niewygenerowanie go w danych wyj­ ściowych.

8. 7. Przenośność a uaktualnianie Jednym z najbardziej irytujących źródeł problemów z przenośnością jest oprogramowanie sys­ temowe, które zmienia się w trakcie cyklu użytkowania. Zmiany te mogą wystąpić w każdym interfejsie systemu i spowodować powstanie niepotrzebnych problemów ze zgodnością między istniejącymi wersjami programów.

Jeśli zmieniasz specyfikację, to zmień też nazwę. Naszym ulubionym (jeśli tak można powie­ dzieć) przykładem jest zmienianie właściwości uniksowego polecenia ec ho, które początkowo tylko wysyłało na wyjście swoje argumenty:

214

8. PRZENOŚNOŚĆ

% echo Wi taj , świ eci e Wi taj , świ eci e % Z czasem jednak polecenie to zaczęło odgrywać kluczową rolę w wielu skryptach powłoki i za­ częto odczuwać potrzebę możliwości formatowania danych wyjściowych. W związku z tym zmie­ niono polecenie echo tak, aby intetpretowało swoje argumenty, podobnie jak funkcja pri ntf:

% echo ' Wi taj , \nświ eci e ' Wi taj , świ eci e % Ten przydatny dodatek wywołał problemy z przenośnością wszystkich skryptów powłoki, w których było użyte polecenie echo w pierwotnej wersji. Teraz wynik polecenia

% echo $ PATH zależy od tego, którą wersją polecenia echo dysponujemy. Jeśli wartość zmiennej przypad­ kiem zawierałaby znak ukośnika, co może się zdarzyć w systemach DOS i Windows, to znak ten zostałby poddany interpretacji. Jest to taka sama różnica, jak między wywołaniem pri ntf (str) i pri ntf ( "%s " , str), jeżeli str zawiera znak procenta. Ten niewielki wycinek historii polecenia echo ilustruje sedno problemu: zmiany wprowa­ dzane w systemach mogą powodować powstawanie różnych wersji oprogramowania, które celowo zachowują się inaczej, co prowadzi do niezamierzonych problemów z przenośnością. A nie są to problemy łatwe do rozwiązania. Znacznie mniej byłoby kłopotów, gdyby nowej wersji polecenia echo nadano inną nazwę. Jako bardziej bezpośredni przykład weźmy uniksowe polecenie s um, które drukuje rozmiar i sumę kontrolną pliku. Zgodnie z intencją twórców miało ono służyć do weryfikacji popraw­ ności przesyłanych danych:

% sum fi l e 52313 2 fi l e % % kop iowan i e p l i ku fi l e do innego komputera % % tel net i nnykomputer $ $ sum fi l e 52313 2 fi l e $ Suma kontrolna po przesłaniu danych jest taka sama, jak przed ich przesłaniem, a więc z dużym prawdopodobieństwem możemy zakładać, że obie kopie danych są identyczne. Później nastąpił wysyp systemów, powstawały kolejne mutacje i ktoś spostrzegł, że algorytm obliczania sumy kontrolnej nie był idealny, więc zmodyfikowano polecenie s um, aby korzystało z lepszego algorytmu. Ktoś inny również to zauważył i zastosował nowy, ulepszony algorytm. Sytuacja ta powtórzyła się wielokrotnie i dziś mamy masę wersji polecenia s um, z których każda zwraca inne wyniki. Skopiowaliśmy jeden plik do kilku innych komputerów, aby zobaczyć, co nam pokaże polecenie s um:

8.8. INTERNACJONALIZACJA

215

% sum fi l e 523 13 2 fi l e % % Kop iowan i e p l i ku fi l e do komputera nr 2 % Kop i owan i e p l i ku fi l e do komputera nr 3 % tel net machi ne2 $ $ sum fi l e fi l e eaa0d468 713 $ tel net machi ne3 > >

sum fi l e 62992 1 fi l e

>

Czy to plik jest uszkodzony, czy mamy dwie różne wersje polecenia sum? Może jedno i drugie? W związku z tym polecenie sum jest kompletną porażką pod względem przenośności. Program, który miał pomagać w kopiowaniu oprogramowania między komputerami, występuje w wielu niezgodnych ze sobą wersjach, co czyni go bezużytecznym do wykonywania tego pierwotnego zadania. Pierwsza wersja polecenia s um znakomicie spełniała swoją funkcję i jej niewyszukany algo­ rytm był w zupełności wystarczający. Wniesione „poprawki" może i spowodowały, że program stał się lepszy, ale tylko niewiele lepszy i na pewno nie na tyle, aby warto było poświęcać zgod­ ność. Problem polega nie na dodaniu ulepszeń, lecz na tym, że niezgodne ze sobą wersje pro­ gramu mają takie same nazwy. Zmiany wywołały problem z wersjami, który będzie nas gnębił jeszcze wiele lat.

Utrzymuj zgodność z istniejącymi programami i danymi. Zwyczajem jest, że gdy nowa wer­ sja programu, takiego jak np. procesor tekstu, pojawia się w sprzedaży, to jest ona w stanie od­ czytywać także pliki utworzone przez starą wersję. Jedną rzecz można zaakceptować: gdy funk­ cjonalność programu jest rozszerzana o nieprzewidziane funkcje, jego format plików musi się zmienić. Ale czasami nowe wersje nie potrafią zapisywać plików w starym formacie. Użytkow­ nicy nowej wersji oprogramowania, nawet jeśli nie korzystają z najnowszych udogodnień, nie mogą udostępniać swoich plików użytkownikom korzystającym ze starszych wersji i w efekcie wszyscy muszą dokonać uaktualnienia. Nieważne, czy jest to spowodowane przeoczeniem in­ żynierów, czy przyjętą przez firmę strategią marketingową - takie projektowanie programów zasługuje na potępienie.

Zgodność wsteczna (ang. backwards compatibility) to spełnianie przez program warunków star­ szej wersji specyfikacji. Jeśli planujesz zmodyfikować program, uważaj, aby nie uszkodzić sta­ rych programów i danych, które od niego zależą. Dobrze udokumentuj wprowadzone zmiany i stwórz możliwość powrotu do pierwotnego sposobu działania. A przede wszystkim upewnij się, że zmiany, które zamierzasz wprowadzić, stanowią rzeczywiste ulepszenie w stosunku do trudności związanych z przenośnością, które może to spowodować.

8.8. Internacjonalizacja Mieszkając w Stanach Zjednoczonych, można łatwo zapomnieć, ż e język angielski nie jest je­ dynym językiem na świecie, zestaw znaków ASCII to nie jedyny taki zestaw, znak $ nie jest jedynym symbolem waluty, daty można zapisywać z numerem dnia na początku, czas można

216

8 . PRZENOŚNOŚĆ

odmierzać według zegara 24-godzinnego itd. Zatem kolejnym aspektem przenośnosc1 iest, ogólnie rzecz biorąc, przeniesienie programu poza granice językowe i kulturowe. Ponieważ jest to bardzo obszerny temat, ograniczymy się tylko do omówienia kilku podstawowych kwestii.

Internacjonalizacja (ang. internationalization) programu to umożliwienie jego używania bez ograniczeń kulturowych. Wiąże się z tym wiele problemów, od kwestii wyboru zestawu znaków po sposób interpretacji ikon w interfejsach użytkownika.

Nie zakładaj, że używane będą tylko znaki z zestawu ASCII. Zbiory znaków, z których ko­ rzysta się w większości części świata, są bogatsze od zestawu ASCII. W standardowych funk­ cjach do sprawdzania znaków z pliku nagłówkowego ctype.h zwykle różnice te są niewidoczne:

i f ( i sal pha (c) ) . . . Powyższa instrukcja działa niezależnie od zastosowanego kodowania znaków, zachowuje się poprawnie także w lokalizacjach, w których jest więcej lub mniej liter niż w alfabecie łaciń­ skim, jeśli tylko program zostanie w tych lokalizacjach skompilowany. Oczywiście nawet sama nazwa i sal pha wskazuje na jej pochodzenie; niektóre języki w ogóle nie mają alfabetu. Większość krajów europejskich rozszerzyła zestaw ASCII, który definiuje tylko Ox7 F (7 bi­ tów) znaków, o dodatkowe znaki reprezentujące litery innych alfabetów. Kodowanie o nazwie Latin- 1, powszechnie używane w Europie Zachodniej, stanowi nadzbiór zestawu ASCII, w któ­ rym bajty o wartościach od 80 do FF są wykorzystywane do reprezentacji symboli i znaków ak­ centowanych, np. bajt E7 reprezentuje akcentowaną literę f· Angielskie słowo boy w zestawie ASCII (a także Latin-1) reprezentują 3 bajty o szesnastkowych wartościach 62 6F 79, natomiast francuskie słowo garfon w zestawie Latin-I reprezentują bajty 67 6 1 72 E7 6 F 6E. Inne języki definiują inne symbole, ale nie wszystkie one mogą pomieścić się w zakresie 128 nieużywanych wartości zestawu ASCII. Dlatego powstało wiele niezgodnych ze sobą standardów reprezentacji znaków przypisanych do bajtów z zakresu od 80 do FF. Dla niektórych języków zakres 8 bitów jest w ogóle za mały. W najważniejszych językach azjatyckich występują tysiące znaków. W Chinach, Japonii i Korei używa się kodów, w których na jeden znak jest przeznaczonych 1 6-bitów. W efekcie odczytanie dokumentu napisanego w jednym języku na komputerze skonfigurowanym dla innego języka stanowi poważny pro­ blem. Zakładając, że znaki zostaną przesłane bez błędów, do odczytania chińskiego tekstu na amerykańskim komputerze potrzeba przynajmniej specjalnego oprogramowania i fontów. Jeśli ktoś chce jednocześnie używać języków chińskiego, angielskiego i rosyjskiego, to problemy, które napotka, będą ogromne. W celu poprawienia tego stanu rzeczy opracowano zestaw znaków Unicode, czyli jeden kod dla wszystkich języków świata. W standardzie Unicode, który jest zgodny z 16-bitowym pod­ zbiorem standardu ISO 1 0646, do reprezentacji pojedynczego znaku używanych jest 16 bitów, a wartości od OOFF w dół pokrywają się z zestawem Latin-I. Zatem słowo garfon w reprezentacji 16-bitowej wygląda tak: 0067 006 1 0072 OOE7 006 F 006E. Alfabet cyrylicy zajmuje wartości z przedziału od 0401 do 04 FF, natomiast dla alfabetów języków ideograficznych zarezerwowano duży przedział wartości zaczynający się od 3000. Wszystkie popularne i mniej znane języki mają swoją reprezentację w standardzie Unicode, dlatego należy go używać do przesyłania do­ kumentów między różnymi krajami i do zapisywania tekstu zawierającego fragmenty w róż­ nych językach. Unicode zyskuje coraz większą popularność w internecie, a niektóre systemy przyjęły go jako standardowy format. Na przykład w języku Java Unicode jest standardowym kodowaniem do reprezentacji znaków w łańcuchach. Systemy Plan 9 i Inferno korzystają w pełni z Unicodu, nawet w nazwach plików i użytkowników. System Microsoft Windows wprawdzie

217

8.8. INTERNACJONALIZACJA

też obsługuje Unicode, ale nie jest to zawsze pewne. Wciąż większość aplikacji działających w tym systemie najlepiej współpracuje z zestawem ASCII, ale zaległości są szybko nadrabiane. Niestety, Unicode również napotyka trudności. Ponieważ znaki nie mieszczą się w 1 bajcie, w tekstach zakodowanych w tym standardzie może dochodzić do mieszania kolejności bajtów. W celu uniknięcia tych problemów dokumenty Unicode przed przesłaniem między progra­ mami lub przez sieć najczęściej tłumaczy się na strumień bajtów w kodzie o nazwie UTF-8. Każdy 16-bitowy znak jest przed wysłaniem kodowany w postaci sekwencji 1, 2 lub 3 bajtów. Zestaw znaków ASCII wykorzystuje wartości od OO do 7 F, które mieszczą się w 1 bajcie, a więc UTF-8 jest zgodny z ASCII. Wartości z przedziału od 80 do ?FF są reprezentowane przy użyciu 2 bajtów, a wartości od 800 w górę 3. Słowo gari;on w UTF-8 reprezentuje ciąg bajtów 67 6 1 72 C 3 A ? 6 F 6E. Wartość Unicode E7, znak f, jest w UTF-8 reprezentowana w postaci 2 bajtów: -

C3 A?. Zgodność kodowania UTF-8 z ASCII jest największym dobrodziejstwem, ponieważ dzięki niej programy, które traktują tekst jako nieinterpretowany strumień bajtów, mogą pracować na tekście zakodowanym w standardzie Unicode napisanym w dowolnym języku. Wypróbowali­ śmy nasz algorytm Markowa, opisany w rozdziale 3., na tekstach zakodowanych w standardzie UTF-8 w językach: rosyjskim, greckim, japońskim i chińskim i nie stwierdziliśmy żadnych problemów. W przypadku języków europejskich, w których do rozdzielania słów stosuje się spację, tabulatory i znaki nowego wiersza z zestawu ASCII, otrzymaliśmy prawidłowo wyglą­ dający bezsensowny tekst. Jeśli chodzi o pozostałe języki, to aby otrzymać efekt zbliżony do zamierzonego, musielibyśmy zmienić zasady oddzielania słów. Języki c i c+ + obsługują tzw. „szerokie znaki'', które są 16-bitowyrni lub większymi licz­ bami całkowitymi, i kilka związanych z nimi funkcji, używanych do przetwarzania znaków Unicode lub z innych zestawów. Literały znakowe zawierające te szerokie znaki zapisuje się przy użyciu notacji L" ", lecz powodują one kolejne trudności z przenośnością: program, w którym użyto szerokich stałych znakowych, można zrozumieć tylko wówczas, gdy się go ogląda na ekranie używającym tego samego zestawu znaków. Ponieważ przenośne przesyłanie znaków między komputerami jest możliwe dopiero po ich konwersji na strumień bajtów, taki jak UTF-8, w języku C dostępne są funkcje służące do konwersj i szerokich znaków na bajty i odwrotnie. Ale jaką konwersję marny zastosować? Interpretacja zestawów znaków i definicja kodowania strumienia bajtów są ukryte głęboko w bibliotekach i trudno je stamtąd wydobyć. Sytuacja w najlepszym wypadku jest niezadowalająca. Niewykluczone, że w pięknej przyszłości wszyscy dojdą do porozumienia i zgodzą się na używanie jednego zestawu znaków, ale bardziej prawdopodobne jest wielkie zamieszanie podobne do problemów z kolejnością bajtów, które ciągle jeszcze dają nam się we znaki. . . •

Nie zakładaj, że wszyscy używają języka angielskiego. Twórcy interfejsów muszą pamiętać o tym, że ta sarna myśl wyrażona w różnych językach może wymagać innej liczby znaków, a więc trzeba przewidzieć wystarczająco dużo miejsca na ekranie i w tablicach. A jeśli chodzi o komunikaty o błędach? Powinny być przynajmniej wolne od żargonu i slangu zrozumiałych tylko przez wąskie grono osób. Dobrym pomysłem na początek jest stosowanie jak najprostszego języka. Często stosowaną techniką jest zgromadzenie tekstu wszystkich ko­ munikatów w jednym miejscu, aby można było je łatwo przetłumaczyć na inne języki. Jest wiele kwestii kulturowych, które trzeba rozwiązać, takich jak np. używany tylko w Ame­ ryce Północnej format daty, w którym numer miesiąca pisze się przed numerem dnia. Jeśli ist­ nieje choćby niewielkie prawdopodobieństwo, że program będzie używany w innych krajach, należy takiego rodzaju uzależnień unikać lub przynajmniej je minimalizować. Często ikony w graficznych interfejsach uŻytkownika są kulturowo zależne. Niektórych ikon nie mogą roz­ szyfrować nawet osoby, dla których są one przeznaczone, nie mówiąc już o ludziach pochodzą­ cych z innych kręgów kulturowych.

218

8 . PRZENOŚNOŚĆ

8.9. Podsumowanie Przenośny kod to ideał, do którego warto dążyć. Zbyt wiele czasu marnuje się na wprowadza­ nie zmian w programach, aby je przenieść do nowego systemu, lub na starania, by działały mimo ustawicznego rozwoju zarówno ich samych, jak i systemów, w których są używane. Przenośność ma jednak swoją cenę. Wymaga staranności przy implementacji i znajomości za­ gadnień związanych z przenośnością dotyczących wszystkich docelowych systemów. Przedstawiliśmy dwa podejścia do kwestii przenośności, które określiliśmy jako sumowa­ nie właściwości i zbiór wspólny właściwości. Pierwsze podejście polega na pisaniu wersji pro­ gramu działających we wszystkich docelowych systemach poprzez łączenie jak największej ilo­ ści kodu przy użyciu takich technik, jak kompilacja warunkowa. Metoda ta ma wiele wad: wymaga napisania znacznie większej ilości kodu, który najczęściej jest o wiele bardziej skom­ plikowany, trudno jest nadążać z aktualizacjami oraz przeprowadzać testy. Drugie podejście polega na napisaniu: jak największej ilości kodu działającego bez zmian we wszystkich systemach. Zależności systemowe, których nie da się uniknąć, zostają wyodręb­ nione w osobnych plikach służących jako interfejs między programem a danym systemem. To podejście również nie jest bez wad, ponieważ grozi pogorszeniem wydajności, a nawet redukcją funkcjonalności, ale na dłuższą metę korzyści przeważają nad wadami.

Lektura uzupełniająca Istnieje wiele opisów różnych języków programowania, ale tylko nieliczne są na tyle precyzyj­ ne, że mogą służyć jako wyczerpujące źródła informacji. Przyznajemy się, że mamy osobistą słabość do książki Język ANSI C Briana Kernighana i Dennisa M. Ritchiego (wyd. 7, WNT, 2002), ale nie zastępuje nam ona standardu. Dobre porady na temat pisania przenośnych pro­ gramów można znaleźć w książce C. A Reference Manuał Sama Harbisona i Guya Steele'a (Prentice Hall, 1994), wydanej ostatnio po raz czwarty. Oficjalne standardy języków C i C+ + można uzyskać w organizacji ISO. Najbliższa oficjalnej specyfikacji języka Java jest książka The Java Language Specification Jamesa Goslinga, Billa Joya i Guya Steele'a (Addison-Wesley, 1996). Znakomitym źródłem wiedzy na temat programowania w środowisku Unix jest książka Programowanie w środowisku systemu Unix Richa Stevensa (WNT, 2002). Znajduje się w niej szczegółowy opis kwestii dotyczących przenośności programów między różnymi wariantami Uniksa. POSIX (ang. Portable Operating System Inteiface) jest międzynarodowym standardem, który zawiera definicje poleceń i bibliotek opartych na systemie Unix. Opisuje on standardowe śro­ dowisko, standaryzuje pisanie przenośnego kodu dla programów użytkowych oraz definiuje jednolity interfejs do operacji wejścia-wyjścia, systemów plików oraz procesów. Jego opis znaj­ duje się w serii książek opublikowanych przez stowarzyszenie IEEE. Określenie „big-endian" ukuł Jonathan Swift w 1726 roku. Termin „endian" do nomenklatury komputerowej wprowadził Danny Cohen w pięknej bajce o kolejności bajtów pt. On Holy Wars and a Plea for Peace opublikowanej w czasopiśmie „IEEE Computer" w październiku 1981 roku. Twórcy systemu Plan 9, który powstał w Bell Labs, sprawę przenośności potraktowali prio­ rytetowo. System ten można skompilować bez żadnych zmian w kodzie źródłowym niezawie­ rającym żadnych dyrektyw #i fdef na wielu różnych procesorach i używa on w pełni zestawu znaków Unicode. Aktualne wersje edytora Sam (którego pierwszy opis ukazał się w artykule pt. The Text Editor Sam w czasopiśmie „Software - Practice and Experience" 1 987, R. 17, nr 1 1 , s. 813 - 845) używają zestawu Unicode i mogą działać w wielu systemach operacyjnych. Proble­ my dotyczące obsługi 16-bitowych zestawów znaków zostały opisane w artykule pt. Hello World

219

LEKTURA UZUPEŁNIAJĄCA

or Ka.AYfµi:pa KóaµE: or .: /v/.:: tj /;t tftf'f!. autorstwa Roba Pike'a i Kena Thompsona (Proceedings of the Winter 1 993 USENIX Conference, San Diego 1993, s. 43 50). W artykule tym pojawiła się pierwsza wzmianka o kodowaniu UTF-8. Można go pobrać na stronie internetowej systemu operacyjnego Plan 9 w serwisie Bell Labs, podobnie jak najnowszą wersję edytora Sam. System Inferno, który powstał na bazie doświadczeń zebranych podczas korzystania z sys­ temu Plan 9, jest pod pewnymi względami podobny do Javy. Definiuje wirtualną maszynę, którą można zaimplementować na dowolnym rzeczywistym komputerze, udostępnia język Limbo, którego kod jest tłumaczony na instrukcje dla tej wirtualnej maszyny, i używa kodo­ wania znaków w standardzie Unicode. Dodatkowo zawiera wirtualny system operacyjny udo­ stępniający przenośny interfejs do wielu komercyjnych systemów. Jego opis można znaleźć w pracy pt. The Inferno Operating System autorstwa Seana Dorwarda, Roba Pike'a, Davida Leo Presotta, Dennisa M. Ritchiego, Howarda W. Trickeya i Philipa Winterbottoma („Bell Labs Technical Journal", R. 2, nr 1, zima 1997). -

220

8. PRZENOŚNOŚĆ

Notacja

Ze WSZYstkich wytworów człowieka najbardziej zdumiewający jest język

Giles Lytton Strachey, Word and Poetry

Wybór odpowiedniego języka programowania może mieć kluczowe znaczenie w kwestii tego, czy pisanie programu przyjdzie nam z łatwością. Dlatego właśnie zawodowi programiści oprócz takich ogólnych języków, jak C i jemu podobne, znają cały szereg programowalnych powłok, języków skryptowych i rozmaitych języków specjalistycznych. Znaczenie dobrej notacji rozciąga się daleko poza tradycyjne programowanie i sięga także specjalnych dziedzin zastosowań. Za pomocą wyrażeń regularnych możemy pisać zwięzłe (choć czasami enigmatyczne) definicje klas łańcuchów. Język HTML umożliwia definiowanie roz­ mieszczenia elementów w interaktywnych dokumentach, w których często są osadzane pro­ gramy napisane w innych językach, np. JavaScript. PostScript pozwala zdefiniować całe dokumenty - np. tę książkę - jako stylizowane programy. Wiele arkuszy kalkulacyjnych i procesorów tekstu ma własne języki programowania, np. Visual Basic, służące do obliczania wartości wyra­ żeń, pobierania informacji czy określania rozmieszczenia elementów. Jeśli znajdziesz się w sytuacji, w której piszesz dużą ilość kodu tylko po to, aby rozwiązać jakieś przyziemne zadanie, albo masz problem z wyrażeniem procesów, to zastanów się, czy na pewno używasz właściwego języka. Jeżeli odpowiedni do danego zadania język jeszcze nie ist­ nieje, może warto byłoby go utworzyć. Tworzenie języka nie musi wcale oznaczać pracy nad następcą Javy. Wiele dotkliwych problemów można rozwiązać przez zastosowanie prostej zmiany w notacji. Jako przykład weźmy łańcuchy formatujące funkcji z rodziny pri ntf, których zwięzła i ekspresywna składnia pozwala precyzyjnie kontrolować drukowanie wartości. W tym rozdziale pokażemy, jak można rozwiązać różne problemy przy użyciu notacji, oraz zademonstrujemy kilka technik, których można użyć do implementacji własnego specjalnego języka. Zbadamy nawet możliwości pisania programów przez inne programy. Ten pozornie ekstremalny sposób wykorzystania notacji spotyka się znacznie częściej i jest on o wiele łatwiejszy do użycia, niż przypuszcza wielu programistów.

222

9. NOTACJA

9. 1 . Formatowanie danych Zawsze istnieje pewna rozbieżność między tym, co chcemy powiedzieć komputerowi („Roz­ wiąż mój problem"), a tym, co musimy powiedzieć, aby zmusić go do wykonania zadania. Im rozbieżności te są mniejsze, tym lepiej. Dobra notacja ułatwia wyrażenie tego, czego się chce, i pozostawia mniej możliwości popełnienia przy tym błędu. Czasami dobra notacja może podsunąć nowe spostrzeżenia, co pozwala rozwiązać problemy, które wydawały się zbyt trudne, a nawet doprowadzić do jakichś odkryć. Małe języki (ang. Little languages) to specjalne notacje wykorzystywane w wąskich dziedzinach zastosowań. Nie tylko stanowią dobry interfejs, lecz także pomagają w organizacji programu, który je implementuje. Dobrym tego przykładem są łańcuchy formatowania funkcji pri ntf:

pri ntf( "%d %6 . 2f % - 1 0 . lOs\n " , i , f , s ) ; Każdy znak % w łańcuchu formatowania stanowi sygnał do podstawienia w to miejsce war­ tości z następnego argumentu funkcji pri ntf. Po kilku opcjonalnych znacznikach i określni­ kach szerokości pól znajduje się końcowa litera określająca spodziewany rodzaj parametru. Ta notacja jest zwięzła, intuicyjna i łatwo się ją zapisuje, a jej implementacja nie jest trudna. Jej odpowiedniki w językach C + + (i ostream) i Java (j ava . i o) wydają się mniej zgrabne, ponie­ waż nie udostępniają specjalnej notacji, ale za to zostały rozszerzone na typy danych zdefinio­ wane przez użytkownika i oferują możliwość sprawdzania typów. Istnieją niestandardowe implementacje funkcji pri ntf pozwalające rozbudowywać stan­ dardowy zestaw opcji o własne konwersje. Jest to przydatne, gdy mamy inne typy danych, któ­ re wymagają konwersji przed wysłaniem na wyjście. Na przykład kompilator mógłby używać łańcucha %L do oznaczania numeru wiersza i nazwy pliku. System graficzny mógłby używać łańcucha %P do oznaczania punktów i %R do oznaczania prostokątów. Czymś w tym rodzaju był enigmatyczny łańcuch liczb i liter służący do pobierania informacji o akcjach, który pokazali­ śmy w rozdziale 4. - zwięzła notacja do składania danych o kursach akcji. Podobne przykłady możemy przedstawiać w językach C i C+ +. Załóżmy, że chcemy prze­ syłać między dwoma systemami pakiety składające się z różnych kombinacji typów danych. Jak pamiętamy z rozdziału 8., najlepszym rozwiązaniem w takiej sytuacji może być zastosowa­ nie konwersji na format tekstowy. Jednak w przypadku standardowego protokołu sieciowego bardziej uzasadnione jest użycie formatu binarnego ze względu na wydajność i rozmiar. Jak napisać kod do obsługi pakietów, który będzie przenośny, wydajny i łatwy w obsłudze? Aby sprowadzić dyskusję na konkretny grunt, wyobraźmy sobie, że chcemy przesyłać mię­ dzy systemami pakiety elementów o rozmiarach 8, I6 i 32 bitów. Standard ANSI języka C sta­ nowi, że w zmiennej typu char możemy zapisać przynajmniej 8 bitów, w zmiennej typu s hort I6, a w zmiennej typu l ong 32. W związku z tym do reprezentacji naszych wartości uży­ jemy tych właśnie typów danych. Typów pakietów będzie wiele. Na przykład pakiet typu 1 . może mieć I-bajtowy specyfikator typu, Z-bajtowy licznik, I-bajtową wartość i 4-bajtowy ele­ ment danych: -

-

OxOl

va 1

Pakiet typu 2. może zawierać jedno słowo typu s hort i dwa słowa typu l ong: Ox02

dwl,

dwl,

dwl,

dw23

9.1. FORMATOWANIE DANYCH

223

Jednym z możliwych podejść jest napisanie funkcji pakujących i rozpakowujących dla każ­ dego możliwego typu pakietu:

i nt pack typel (unsi gned char *buf, unsi gned s hort count , unsi gned char val , unsi gned l ong data) unsi gned char *bp ; bp = buf; *bp++ = OxOl ; *bp++ = count >> 8 ; *bp++ = count ; *bp++ = val ; *bp++ = data >> 24; *bp++ = data >> 16; *bp++ = data >> 8; *bp++ = data ; return bp - buf;

Dla realnego protokołu takich procedur byłyby dziesiątki i wszystkie stanowiłyby zmody­ fikowane wersje jednej procedury. Można by je uprościć przy użyciu makr lub funkcji do ob­ sługi podstawowych typów danych (s hort, l ong itp.), ale nawet wówczas w takim wielokrotnie powtarzającym się kodzie łatwo o błąd, a przy tym trudno się go czyta i utrzymuje. W sytuacji, gdy marny do czynienia z takim z natury powtarzalnym kodem, pomóc nam może użycie odpowiedniej notacji. Pożyczając pomysł z funkcji pri ntf, możemy zdefiniować niewielki język do opisu pakietów, w którym każdy pakiet opisywałby krótki łańcuch definiu­ jący jego układ. Kolejne elementy pakietu byłyby zakodowane przy użyciu liter: c dla 8-bitowego znaku, s dla 1 6-bitowej liczby typu s hort i l dla 32-bitowej liczby typu i nt. Tak więc pakiet typu 1. zbudowany przez nasz powyższy przykład, włącznie z początkowym bajtem określają­ cym typ, byłby opisywany przez łańcuch formatu csc l . Następnie moglibyśmy do tworzenia wszystkich rodzajów pakietów używać jednej funkcji np. o nazwie pack. Rozważany pakiet tworzyłoby następujące wywołanie:

pack (buf, "cscl " , OxO l , count , val , data) ; Ponieważ nasz łańcuch formatowania zawiera tylko definicje danych, nie ma potrzeby używania znaków %, których używa funkcja p ri ntf. W praktyce na początku pakietu można umieścić informację na temat sposobu dekodowa­ nia reszty pakietu, ale założymy, że pierwszy bajt pakietu posłuży do określania układu. Nadawca będzie kodował i wysyłał dane w tym formacie. Odbiorca będzie je odbierał, spraw­ dzał pierwszy bajt i na jego podstawie dekodował dalsze bajty. Poniżej znajduje się implementacja funkcji pack, która zapełnia bufor buf reprezentacją swoich argumentów zakodowaną zgodnie z określonym formatem. Używamy tylko wartości bez znaku, włącznie z tymi w buforze pakietów, aby uniknąć problemów z obsługą znaku liczby. Skorzystamy też z typowych instrukcji typedef, by skrócić deklaracje typów danych:

typedef unsi gned char uchar; typedef unsi gned short ushort ; typedef unsi gned l ong u l ong ;

224

9. NOTACJA

Podobnie jak w funkcjach spri ntf, st rcpy i innych tego rodzaju w funkcji pack będzie przyjęte założenie, że bufor jest wystarczająco duży, aby pomieścić w nim wynik. Zapewnienie tego jest obowiązkiem wywołującego. Nie ma też procedur wykrywaj ących niezgodności między formatem a listą argumentów.

#i ncl ude /*pack: pakuje dane wfonnacie binarnym do bufora buf i zwraca długość */

i nt pack (uchar *buf, char *fmt , . . . ) va l i st arg s ; char *p; uchar *bp ; ushort s ; u l ang l ; bp = buf; va start (args , fmt) ; for (p = fmt ; *p ! = ' \O ' ; p++) { swi tch (*p) { case ' c ' : /* Znak *I *bp++ = va_arg (args , i nt) ; break ; case ' s ' : /* Wartość typu short */ s = va_arg (args , i nt) ; *bp++ = s » 8 ; *bp++ = s ; brea k ; case ' l ' : /* Wartość typu long */ l va_arg ( args , ul ong) ; *bp++ = l >> 24; *bp++ = l >> 1 6 ; *bp++ = l » 8 ; *bp++ = l ; brea k ; defaul t : /* Niepoprawny znak określający typ */ va_end (args) ; return - 1 ; =

va_end (args) ; return bp - buf;

Procedura pack w większym stopniu korzysta z zawartości pliku nagłówkowego stdarg.h niż omówiona w rozdziale 4. funkcja epri nt f. Kolejne argumenty są pobierane przy użyciu makra va_ arg, którego pierwszym argumentem jest zmienna typu va_ l i st ustawiana przez funkcję va_start, a drugim typ argumentu (dlatego właśnie va_arg jest makrem, a nie funkcją). Po zakończeniu przetwarzania musi zostać wywołana funkcja v a_end. Mimo iż argumenty ' c ' i ' s ' reprezentują wartości typu char i s h o rt, muszą być pobierane jako typ i nt, ponieważ w języku C argumenty typu char i s hort, jeśli są reprezentowane na liście argumentów przez wielokropek, są zamieniane na typ i nt. Teraz procedura pac k_type będzie składała się z jednego wiersza zawierającego wywołanie funkcji pack szeregującej jej argumenty: -

9.1. FORMATOWANIE DANYCH

225

I* pack_typel: pakuje pakiety w formacie 1 *I

i nt pack_typel (uchar *buf, ushort coun t , uchar val , u l ong data) { return pack(buf, "cscl " , OxO l , count , val , data) ;

Rozpakowywanie możemy wykonać w podobny sposób : zamiast pisać osobny kod dla każ­ dego formam pakietu, wywołamy jedną funkcję unpack z łańcuchem formatowania jako argu­ mentem. Tak kod wykonujący konwersję zbierzemy w jednym miejscu: I* unpack: rozpakowuje dane spakowane z bufora buf, zwraca długość *I

i nt unpac k ( uchar *buf, char *fmt , . . . ) { va_l i st args ; char * p ; u c h a r *bp, *pe ; ushort *ps ; u l ong *pl ; bp = buf; va start (arg s , fmt ) ; for (p = fmt ; *p ! = ' \O ' ; p++) { swi tch (*p) { case ' c ' : /* Znak *I pe = va_arg (args , uchar* ) ; *pe = *bp++; brea k ; c a s e ' s ' : / * Wartość typu short *I ps = va_arg (args , ushort*) ; *ps = *bp++ << 8 ; * p s i = *bp++; break ; case ' l : /* Wartość typu long *I pl = va arg (args , u l ong*) ; *pl = *bp++ << 24; *pl i = *bp++ << 16; *pl i= *bp++ « 8 ; *pl i = *bp++ ; brea k ; defaul t : /* Niepoprawny znak określający typ *I va_end (args) ; return - 1 ; '

va_en d ( args ) ; return bp - buf;

Podobnie jak scanf funkcja unpack musi zwracać kilka wartości. Dlatego jej argumenty są wskaźnikami na zmienne, w których zostaną zapisane wyniki. Natomiast wartość zwrotna tej funkcji to liczba bajtów w pakiecie, którą można wykorzystać do sprawdzania, czy nie ma błędów. Dzięki temu, że używamy wartości bez znaku oraz nie przekraczamy rozmiarów typów do­ puszczanych przez standard ANSI języka C, ten kod bez trudu przesyła dane nawet między maszynami, w których typy short i 1 ong mają różne rozmiary. Zakładając, że program używający

226

9. NOTACJA

funkcji pack nie będzie próbował wysyłać jako np. l ong wartości, której nie da się zaprezento­ wać przy użyciu 32 bitów, przesył zostanie wykonany poprawnie. W istocie przesyłamy 32 niż­ sze bity wartości. Gdybyśmy chcieli przesyłać większe wartości, moglibyśmy zdefiniować do­ datkowy format. Procedury rozpakowujące przystosowane do poszczególnych typów, które wywołują funk­ cję unpack, są łatwe do napisania: /* unpack_type2: rozpakowuje i przetwarza pakiety typu 2. */

i nt unpack_type2 ( i nt n , uchar *buf) { uchar c ; ushort coun t ; u l ong dwl , dw2 ; i f ( unpack (buf, "csl l " , &c , &count , &dwl , &dw2) ! = n ) return - 1 ; assert (c == Ox02 } ; return proces s_type2 (count , dwl , dw2) ;

Przed wywołaniem funkcji unpack_ type2 musimy sprawdzić, czy mamy do czynienia z pa­ kietem typu 2. Do tego potrzebna nam jest poniższa pętla pobierania danych:

whi l e ( (n = readpacket (networ k , buf, BUFS I Z ) ) > O) { switch (buf [O] ) { defau l t : epr i n t f ( " N i eprawi dłowy typ paki etu Ox%x " , buf[O] ) ; break ; case 1 : unpack_typel (n , buf} ; break ; case 2 : unpack_type2 ( n , buf} ; break ;

Programowanie w taki sposób może się przedłużać. Bardziej zwięzły kod uzyskamy, jeśli zdefiniujemy tablicę wskaźników na funkcje, której elementami będą procedury rozpakowują­ ce indeksowane według typu pakietu:

i nt (*unpackfn [] ) (i nt , uchar *} unpack_typeO , unpack_typel , unpack_type2 , };

=

{

Każda funkcja w tej tablicy analizuje pakiet, sprawdza wynik i wznawia jego dalsze prze­ twarzanie. Tablica ta znacznie upraszcza zadanie odbiorcy:

9.1 . FORMATOWANIE DANYCH

227

I* receive: odbiera pakiety z sieci ije przetwarza */

voi d recei ve ( i nt network) { uchar type , buf [BUFSI Z] ; i nt n ; whi l e ( (n readpacket (network, buf, BUFS I Z ) ) > O ) { type = buf [O] ; i f (type >= NELEMS (unpackfn ) ) epri ntf ( " Ni eprawidłowy typ paki etu Ox%x " , type) ; i f ( (*unpac kfn [type] ) (n , buf) < O) epri ntf ( " Błąd protokołu , typ %x długość %d " , type , n) ; =

Kod obsługi każdego pakietu jest zwięzły i znajduje się w całości w jednym miejscu, dzięki czemu łatwo go utrzymywać. Odbiorca jest w dużym stopniu niezależny od protokołu. Kod jest klarowny i szybko działa. Omówiony tu przykład opiera się na rzeczywistym kodzie pewnego komercyjnego proto­ kołu sieciowego. Kiedy autor zdał sobie sprawę, że ta metoda może zadziałać, kilka tysięcy wierszy powtarzalnego i podatnego na błędy kodu skurczyło się do kilkuset łatwych w utrzy­ maniu linijek. Notacja zaprowadziła doskonały porządek.

Ćwiczenie 9.1. Zmodyfikuj funkcje pack i unpack tak, aby poprawnie przesyłały wartości ze znakiem, nawet między maszynami, w których typy s hort i l ang mają różne rozmiary. Jak trzeba zmodyfikować łańcuchy formatu, by móc za ich pomocą definiować dane ze znakiem? Jak można przetestować kod, aby dowiedzieć się, czy np. poprawnie przesyła wartość - 1 z kompute­ ra, w którym typ l ang ma 32 bhy, do komputera, w którym typ ten ma 64 bity?

Ćwiczenie 9.2. Rozszerz zakres działania funkcji pa c k i u n p a c k na obsługę łańcuchów. Jedną z możliwości rozwiązania tego zadania jest dodanie długości łańcucha do łańcucha formatu. Niech funkcje te do obsługi powtarzających się elementów używają licznika. Jaki ten dodatek będzie mieć wpływ na kodowanie łańcuchów?

Ćwiczenie 9.3. Tablica wskaźników na funkcje użyta w przedstawionym powyżej programie w języku C stanowi samo serce mechanizmu funkcji wirtualnych języka C+ + . Przepisz funk­ cje pack, unpack i recei ve w języku C+ + , wykorzystując to udogodnienie notacyjne. Ćwiczenie 9.4. Napisz wersję wiersza poleceń funkcji pri ntf drukującą swój drugi argument i następne w formacie określonym przez pierwszy argument. Niektóre powłoki mają standar­ dowo wbudowaną taką funkcję.

Ćwiczenie 9.5. Napisz funkcję implementującą specyfikacje formatów z arkuszy kalkulacyj­ nych albo z klasy Dec i mal Format języka Java, które wyświetlają liczby według wzorców okre­ ślających obowiązkowe i opcjonalne liczby, miejsce przecinka dziesiętnego itd. Na przykład poniższy format:

#11 . #110 , 00

228

9. NOTACJA

definiuje liczbę dziesiętną z dwoma miejscami po przecinku, przynajmniej jedną cyfrą przed przecinkiem, kropką za cyfrą oznaczającą tysiące i wypełnieniem pustych miejsc spacja­ mi do 10 tysięcy. W tym formacie liczba 1 2345 , 67 miałaby postać 12 . 345 , 67, a liczba 4 0 , 40 (znaki podkreślenia oznaczają spacje). Pełną specyfikację można znaleźć w definicji klasy Deci mal Format i w arkuszach kalkulacyjnych. .

__

9.2. Wyrażenia regularne Określniki formatu użyte w funkcjach pack i unpac k to przykład bardzo prostej notacji służą­ cej do definiowania rozmieszczenia danych w pakietach. Nasz następny temat to nieco bardziej skomplikowana, ale i bardziej ekspresywna notacja o nazwie wyrażenia regularne (ang. regular expressions) służąca do definiowania wzorców tekstowych. Wyrażeń regularnych używaliśmy wcześniej już kilka razy, ale jeszcze ich ściślej nie zdefiniowaliśmy. Są one na tyle łatwe do zro­ zumienia, że nie wyinagają zbyt wielu objaśnień. Podczas gdy w środowisku programistycznym systemu Unix są one wszechobecne, to w innych systemach nie są już tak często używane. Wo­ bec tego w tym podrozdziale pokażemy niektóre z ich wielkich zalet. Na wypadek gdybyś nie miał pod ręką żadnej biblioteki wyrażeń regularnych, przedstawimy też ich podstawową im­ plementację. Jest kilka rodzajów wyrażeń regularnych, ale wszystkie działają na tej samej zasadzie. Są wykorzystywane do definiowania wzorców literałów znakowych, a do tego służą w nich ozna­ czenia powtórzeń, alternatyw i skrócone formy przedstawiania klas znaków, takich jak cyfry czy litery. Wśród szeroko znanych przykładów można wymienić tzw. symbole wieloznaczne (ang. wildcards) używane w wierszach poleceń i powłokach do definiowania wzorców nazw pli­ ków. Zwyczajowo do tego celu używany jest znak *, który oznacza „dowolny łańcuch znaków". W związku z tym polecenie

C : \> del * . exe wybierze wszystkie pliki, których nazwa kończy się łańcuchem znaków .exe. Jednak jak to często bywa, między systemami, a nawet poszczególnymi programami występują różnice w szczegółach. Mimo iż - sądząc po różnicach występujących między poszczególnymi programami może się wydawać, że wyrażenia regularne to jakiś naprędce sklecony mechanizm, to w istocie są one językiem, który ma formalną gramatykę i w którym każda wypowiedź ma ściśle okre­ ślone znaczenie. Co więcej, jeśli zostaną dobrze zaimplementowane, to mogą działać bardzo szybko. Łącząc teorię inżynierii oprogramowania z praktyką, można uzyskać zadziwiająco ko­ rzystne efekty. Przykład zalet stosowania specjalnych algorytmów przedstawiliśmy w rozdziale 2. Wyrażenie regularne składa się z sekwencji znaków definiującej pewien zbiór łańcuchów tekstu. Większość znaków użyrych w wyrażeniu regularnym reprezentuje sama siebie, a więc wyrażenie abc będzie znajdowało wszystkie wystąpienia łańcucha abc. Oprócz tego istnieje kilka metaznaków (ang. metacharacters) służących do zaznaczania powtórzeń, grupowania oraz położenia znaków. W typowych wyrażeniach regularnych używanych w systemie Unix znak " oznacza początek łańcucha, a znak $ - koniec. W związku z tym wyrażenie regularne "x pa­ suje do litery x znajdującej się tylko na początku łańcucha, a x$ - na końcu. Wyrażenie "x$ pasuje wyłącznie do łańcucha składającego się tylko z jednej litery x, a "$ dopasowuje pusty łańcuch.

229

9.2. WYRAŻENIA REGULARNE

Znak . pasuje do dowolnego znaku, a więc wyrażenie x . y jest odpowiednie dla łańcuchów $ jest właściwe dla każdego poje­ dynczego znaku. Zbiór znaków w nawiasie kwadratowym pasuje do każdego znaku, który się w tym zbiorze znajduje, a więc wyrażenie [0123456789] nadaje się dla każdej występującej pojedynczo cyfry. Zapis ten można skrócić do postaci [0-9] . Do łączenia tych podstawowych elementów można używać nawiasów oznaczających gru­ powanie, znaków J oznaczających alternatywę, znaków * oznaczających zero lub więcej wystą­ pień, znaków + oznaczających jedno wystąpienie lub więcej oraz znaków ? oznaczających zero wystąpień lub jedno. W końcu znak \ służy jako przedrostek używany do wyłączania specjal­ nego znaczenia metaznaków, tzn. wyrażenie \* oznacza znak *, a \\ - znak ukośnika. Najbardziej znanym narzędziem pozwalającym korzystać z wyrażeń regularnych jest wspo­ mniany już kilka razy program grep. Stanowi on znakomity dowód na to, że notacja czyni cu­ da. Przepuszcza przez filtr wyrażeń regularnych każdy wiersz tekstu pobrany z pliku wejścio­ wego i zwraca na wyjściu te łańcuchy tekstu, które pasowały do jego wyrażeń. Ta specyfikacja w połączeniu z wielkimi możliwościami wyrażeń regularnych pozwala mu rozwiązywać wiele pospolitych problemów. W poniższych przykładach zwróć uwagę, że składnia wyrażeń regu­ larnych użytych jako argument programu grep różni się od użycia symbolu wieloznacznego do określania zbiorów nazw plików. Różnice te wynikają z odmiennych zastosowań. W których plikach źródłowych używana jest klasa Regexp?

xay, x2y itd., ale nie xy czy xaby. Natomiast wyrażenie

".

% grep Regexp * . j ava Który plik zawiera jej implementację?

% grep ' cl as s . *Regexp ' * . j ava Gdzie ja zapisałem ten e-mail od Bartka?

%

grep ' AFrom : . * bartek@ ' mai l /* Ile niepustych wierszy znajduje się w kodzie źródłowym tego programu?

%

grep ' . ' * . c++ I

we

Dzięki znacznikom pozwalającym włączyć opcję drukowania numerów dopasowanych wier­ szy oraz możliwości liczenia dopasowań, wyszukiwania z uwzględnieniem wielkości liter, od­ wracania sensu wyrażeń (tzn. wybór wierszy, które nie pasują do wzorca) i wykonywania rozmaitych operacji program grep zyskał tak dużą popularność, że stał się klasycznym przykładem pro­ gramowania narzędziowego. Niestety, nie każdy system zawiera program grep lub jego odpowiednik. Niektóre systemy posiadają bibliotekę wyrażeń regularnych, najczęściej o nazwie regex lub regexp, przy użyciu której można napisać własną wersję narzędzia grep. Jeśli żadna z tych możliwości nie wchodzi w rachubę, to można z łatwością zaimplementować własny w miarę funkcjonalny podzbiór ję­ zyka wyrażeń regularnych. Przedstawiamy implementację wyrażeń regularnych i programu grep. Dla uproszczenia użyjemy tylko następujących metaznaków: ", $, oraz *, przy czym * będzie oznaczać powtórzenie pojedynczej, znajdującej się przed tym metaznakiem kropki lub innego znaku. Implementacja tego podzbioru daje duże możliwości, a wymaga niewielkiego .

230

9. NOTACJA

wysiłku programistycznego w porównaniu z tym, gdybyśmy chcieli zaimplementować całe wy­ rażenia regularne. Zaczniemy od funkcji dopasowywania match. Jej zadaniem jest sprawdzenie, czy dany łań­ cuch tekstu pasuje do określonego wyrażenia regularnego: /* match: szuka wyrażenia regularnego w tekście */

i nt match (char *regex p , char *text) { i f (regexp [O] == ' " ' ) return matchhere (regexp+l , text ) ; /* Trzeba szukać nawet wówczas, gdy łmicuchjestpusty */ do { i f (matchhere (regexp , text ) ) return 1 ; whi l e {*text++ ! = ' \O ' ) ; return O ;

Jeśli wyrażenie regularne zaczyna się o d znaku ", to początek tekstu musi pasować do resz­ ty wyrażenia. W przeciwnym razie przeglądamy tekst i za pomocą .funkcji matchhere spraw­ dzamy, czy pasuje on na którejkolwiek pozycji. Gdy znajdziemy dopasowanie, kończymy pra­ cę. Zwróć uwagę na użycie pętli do-whi 1 e: wyrażenia mogą pasować do pustych łańcuchów (np. $ pasuje do pustego łańcucha na końcu wiersza, a . * - do dowolnej liczby znaków, także zera), a więc musimy wywoływać funkcję matchhere, nawet gdy tekst jest pusty. Rekursywna funkcja match here wykonuje większość pracy: /* matchhere: szuka wyrażenia regularnego na początku tekstu */

i nt matchhere (char *regexp , char *text) { ' \O ' ) i f (regexp[O] return l ; i f ( regexp [1] '*') return matchstar(regexp [O] , regexp+2 , text) ; i f (regexp [O] == ' $ ' && regexp [ l] == ' \O ' ) return *text == ' \O ' ; i f {*text ! = ' \0 ' && (regexp [O] == ' . ' I I regexp [O] ==*text) ) return matchhere ( regexp+ l , text+l) ; return O ;

Puste wyrażenie regularne oznacza, że doszliśmy do końca i znaleźliśmy dopasowanie. Jeśli na końcu wyrażenia znajduje się znak $, wyrażenie pasuje tylko wówczas, gdy tekst również się skończył. Jeżeli na początku wyrażenia znajduje się kropka, to pasuje ono do każdego znaku. W przeciwnym razie wyrażenie zaczyna się od zwykłego znaku, który pasuje tylko do samego siebie w tekście. Zatem znaki " i $, występujące w środku wyrażenia regularnego, są traktowane jako zwykłe znaki, a nie metaznaki. Zauważ, że funkcja matchhere po dopasowaniu jednego znaku wzorca i łańcucha tekstowego wywołuje sama siebie, dzięki czemu głębokość rekurencji może odpowiadać długości wzorca. Jedyny problem powstaje wówczas, gdy wyrażenie zaczyna się od znaku z gwiazdką, np. x*. Wtedy wywołujemy funkcję mat chstar, której jako pierwszy argument podajemy argument operacji gwiazdki, czyli tutaj znak x, a jako kolejne argumenty przekazujemy dalszą część wzorca za gwiazdką i tekst.

23 1

9.2. WYRAŻENIA REGULARNE

/* matchstar: szuka wyrażenia c *regexp na początku tekstu */

i nt matchstar ( i nt c , char *regexp , char *text) { do /* Wzorzec *pasuje do zera lub większej liczby wystąpień */ i f (matchhere (regexp , text) ) return 1 ; whi l e (*text ! ' \O ' && (*text++ c II c ' . ')); return O ; =

= =

W funkcji tej została użyta kolejna pętla do-whi l e, której wykonanie powoduje warunek, że wyrażenie regularne x* może pasować do zera znaków. Pętla sprawdza, czy tekst pasuje do po­ zostałej części wyrażenia regularnego, sprawdzając każdy znak teksm, jeśli pierwszy znak pa­ suje do argumentu gwiazdki. Jest to bez wątpienia niewyszukana implementacja, ale działa i zajmuje mniej niż 30 wier­ szy kodu, co stanowi dowód na to, że aby móc korzystać z wyrażeń regularnych, wcale nie trzeba zaprzęgać do pracy zaawansowanych technik. Wkrótce pokażemy kilka możliwości rozszerzenia tego kodu. Na razie jednak napiszemy wersję narzędzia grep, która używa funkcji matc h . Oto główna procedura: /* main: szuka wyrażeń regularnych w plikach */

i nt mai n ( i nt argc , char *argv [] ) { i nt i , nmatc h ; F I LE *f; setprogname ( " grep " ) ; i f (argc < 2) epri ntf ( " Sposób użyc i a : grep wyrażeni e_regul arne [pl i k . „ ] " ) ; nmatch O ; i f (argc 2) { i f (grep (argv [l] , stdi n , NULL) ) nmatch++ ; el se { for (i 2 ; i < argc; i ++) { f fopen (argv [ i ] , " r " ) ; i f (f NULL) { wepri ntf ( " N i e można otworzyć %s : " , argv [ i ] ) ; conti nue; =

==

=

=

==

if (grep ( argv [l] , f , argc>3 nmatch++; fcl ose (f) ; return nmatch

==

argv [ i ]

NULL) > O)

O;

Przyjęło się, że programy w języku C w razie powodzenia zwracają wartość O i inne wartości w przypadku różnych niepowodzeń. W naszym programie grep, podobnie jak w wersji unik­ sowej, powodzenie oznacza znalezienie pasującego wiersza, a więc nasz program zwraca O, gdy znajdzie jakieś dopasowania, 1, jeśli nic nie znajdzie, oraz 2 (za pośrednictwem funkcji epri ntf), jeżeli wystąpi błąd. Te wartości określające stan można sprawdzać za pomocą innych programów, takich jak powłoka:

232

9. NOTACJA

I* grep: szuka wyrażenia regularnego w pliku *I

i nt grep (char *regexp , F I LE *f, char *name) { i nt n, nmatc h ; char buf [BUFS I Z] ; nmatch = O ; whi l e ( fgets (buf, s i zeof b u f , f) ! = NULL) { n = strl en (buf) ; i f (n > O && buf[n-1] == ' \n ' ) buf[n-1] = ' \O ' ; i f (match (regexp , buf) ) nmatch++ ; i f (name ! = NULL) pri ntf( "%s : " , name) ; pri ntf( "%s\n " , buf) ; return nmatc h ;

Główna procedura nie kończy działania, jeśli nie zdoła otworzyć pliku. Zdecydowaliśmy się na takie rozwiązanie, ponieważ często można spotkać tego rodzaju polecenia:

%

grep herpol hode * . *

gdy okazuje się, że jednego z plików w katalogu nie da się odczytać. Lepiej jest, jeżeli pro­ gram zgłosi błąd i kontynuuje działanie, niż miałby się poddawać i zmuszać użytkownika do wpisania ręcznie listy plików z pominięciem tego, który sprawia problemy. Zauważ również, że funkcja grep drukuje nazwę pliku i numer dopasowanego wiersza, ale jeśli pobiera dane ze standardowego wejścia lub jednego pliku, to tego nie robi. Może się to wydawać dziwne, ale jest to idiomatyczny styl programowania, który został wypracowany na podstawie doświadcze­ nia. Gdy program ma podane na wejściu tylko jedno źródło danych, zazwyczaj jego zadaniem jest wybór, a w takim przypadku nazwa pliku tylko by zaśmiecała dane wyjściowe. Jeśli nato­ miast program ma przeszukać większą liczbę plików, zadanie zwykle polega na znalezieniu wszyst­ kich wystąpień jakiegoś łańcucha znaków i wówczas nazwy plików są przydatne. Porównajmy:

% stri ngs markov . exe I grep ' DOS made ' z

%

grep grammer chapter* . txt

Wszystkie takie drobnostki sprawiają, że grep jest tak bardzo popularny, oraz pokazują, iż notacja musi iść w parze z ludzką myślą inżynieryjną, aby mogło powstać naturalne i efektywne narzędzie. Funkcja match w naszej implementacji zwraca wartość, najszybciej jak tylko jest to możli­ we. Dla programu grep jest to bardzo dobre ustawienie domyślne. Jednak w implementacji operatora zastępowania (funkcja Znajdź i zamień) w edytorze tekstu bardziej odpowiednie jest najdłuższe dopasowanie z lewej. Na przykład w tekście aaaaa wzorzec a* znajdzie dopasowa­ nie do pustego łańcucha na początku, ale bardziej naturalne wydaje się dopasowanie wszystkich pięciu liter a. Aby zmusić funkcję match do znajdowania najdłuższego pasującego łańcucha

9.2. WYRAŻENIA REGULARNE

233

z lewej strony, trzeba ponownie napisać funkcję matchstar, tak aby była zachłanna. Funkcja ta zamiast badać każdy znak tekstu od lewej do prawej, powinna przeskakiwać najdłuższy łań­ cuch pasujący do argumentu operatora gwiazdki, a następnie wracać, jeśli reszta łańcucha nie pasuje do pozostałej części wzorca. Innymi słowy, powinna działać od prawej do lewej. Poniżej znajduje się druga wersja funkcji matchstar, która wyszukuje najdłuższe dopasowanie od lewej: I* matchstar: najdłuższe dopasowanie z lewej dla wyrażenia c*regexp *I

i nt matchstar ( i nt c , char *regexp , char *text) { char *t ; for (t do

text ; *t ! = ' \O ' && (*t == c I I c == ' . ' ) ; t++) /* Znak *pasuje do zera lub większej liczby znaków *I

i f (matchhere(regexp, t ) ) return 1 ; whi l e (t-- > text ) ; return O ;

Nie m a znaczenia, które dopasowanie znajdzie program, ponieważ szuka on jakiegokolwiek wystąpienia danego wzorca i drukuje cały wiersz. W związku z tym, ponieważ funkcja szukania najdłuższego dopasowania z lewej wykonuje więcej pracy, nie jest ona konieczna dla samego programu grep, ale jest niezbędna dla operatora zastępowania. Niezależnie od wyrażenia regularnego nasza implementacja narzędzia grep jest konkuren­ cyjna wobec wersji systemowych. Istnieją wprawdzie takie patologiczne wyrażenia, które mogą powodować wykładniczą złożoność obliczeniową, np. jeśli wzorzec a*a*a*a*a*b zastosuje się do przeszukania tekstu aaaaaaaaac, ale niektóre komercyjne implementacje również tak mają. Wersja programu grep o nazwie egrep, znajdująca się w systemie Unix, używa bardziej za­ awansowanego algorytmu dopasowywania gwarantującego liniową złożoność obliczeniową dzięki uniknięciu cofania, gdy częściowe dopasowanie się nie powiedzie. Jakie są możliwości rozszerzenia funkcji match, aby w pełni obsługiwała wyrażenia regu­ larne? Wymagałoby to dodania obsługi klasyfikacji znaków, takich jak wzorzec [a-zA-Z] pa­ sujący do każdego znaku alfabetu, możliwości cytowania metaznaków (aby np. można było po­ szukać kropki), stosowania nawiasów grupujących oraz definiowania alternatyw (abc lub def). Należałoby zacząć od sprowadzenia wzorca do takiej postaci, w której łatwiej go skanować. Analizowanie klasy znaków przy każdym porównywaniu jej z jakimś znakiem to mało wydajne rozwiązanie. Wydajność operacji klasyfikowania znaków można znacznie poprawić, stosując wcześniej obliczone reprezentacje utworzone na bazie wektorów bitów. Pełna implementacja wyrażeń regularnych, z nawiasami i alternatywami, wymagałaby zastosowania bardziej za­ awansowanych technik, ale do jej budowy można by też użyć niektórych technik, które omó­ wimy w dalszej części tego rozdziału.

Ćwiczenie 9.6. Jaka jest wydajność operacji przeszukiwania zwykłego tekstu funkcji match w po­ równaniu z funkcją strstr? Ćwiczenie 9.7. Napisz nierekursywną wersję funkcji matchhere i porównaj jej wydajność z wersją rekursywną.

Ćwiczenie 9.8. Dodaj kilka opcji do programu grep. Wśród najpopularniejszych można wy­ mienić opcję -v odwracającą sens wyrażenia, - i umożliwiającą wyszukiwanie znaków alfabetu

234

9. NOTACJA

bez rozróżniania małych i wielkich liter oraz -n drukującą numery wierszy w danych wyjścio­ wych. Jak powinny być drukowane numery wierszy? Czy powinny być drukowane w tym sa­ mym wierszu, co dopasowany tekst?

Ćwiczenie 9.9. Dodaj do funkcji match operatory + (jeden lub więcej) i ? (zero lub jeden). Wzorzec a+bb? dopasowuje jedną literę lub więcej liter a, za którymi znajduje się jedna litera lub więcej liter b. Ćwiczenie 9.10. Aktualna implementacja funkcji match traktuje znaki "' i $ jako zwykłe znaki, jeśli nie znajdują się na początku lub na końcu wyrażenia, oraz podobnie traktuje znak *, jeżeli nie znajduje się on bezpośrednio za literałem znakowym albo kropką. Jednak tradycyjnie do wyłączania specjalnego znaczenia znaków stosuje się znak ukośnika. Popraw funkcję match, aby jako zwykłe traktowała tylko te metaznaki, przed którymi znajduje się ukośnik.

Ćwiczenie 9.11. Dodaj do funkcji match obsługę klas znaków. Klasy znaków służą do definio­ wania wzorców pasujących do dowolnego znaku spośród wymienionych w nawiasach prosto­ kątnych. Korzystanie z nich byłoby znacznie bardziej wygodne, gdyby można było definiować zakresy, np. [a-z] dla dowolnej małej litery, oraz odwracać znaczenie wyrażenia, np. wzorzec ["'0-9] pasowałby do wszystkiego, co nie jest cyfrą. Ćwiczenie 9.12. Zmień funkcję match w taki sposób, aby używała wersji funkcji matchstar dopasowującej najdłuższy łańcuch z lewej oraz zwracała pozycje pierwszego i ostatniego znaku dopasowanego tekstu. Następnie przy użyciu tej funkcji napisz program gres, który będzie po­ dobny do programu grep, lecz będzie drukował każdy wiersz wejściowy, wstawiając w nim nowy tekst w miejsce tekstu pasującego do wzorca, tak jak w poniższym przykładzie: %

gres ' hornoi ous i an ' ' hornoou s i an ' rni s s i o n . strnt

Ćwiczenie 9.13. Zmodyfikuj funkcję match i program grep tak, aby działały na łańcuchach znaków Unicode zakodowanych w standardzie UTF-8. Ponieważ standardy UTF-8 i Unicode są nadzbiorami zestawu ASCII, ta zmiana nie będzie powodować problemów ze zgodnością. Wyrażenia regularne i przeszukiwany tekst również muszą poprawnie obsługiwać UTF-8. Jak powinny zostać zaimplementowane klasy znaków?

Ćwiczenie 9.14. Napisz automat testujący wyrażenia regularne, który tworzy wyrażenia testo­ we i łańcuchy do wyszukiwania. Jeśli masz taką możliwość, użyj istniejącej biblioteki jako im­ plementacji referencyjnej. Niewykluczone, że w niej również znajdziesz błędy.

9.3. Programowalne narzędzia Wiele narzędzi zbudowano wokół różnych specjalnych języków. Program grep jest jednym z ro­ dziny narzędzi, które wykorzystują wyrażenia regularne i inne języki do rozwiązywania pro­ blemów programistycznych. Jednym z pierwszych przykładów był interpreter poleceń lub język sterowania zadaniami. Bardzo szybko zauważono, że często występujące sekwencje poleceń można umieszczać w pli­ kach, które następnie można przekazać na wejściu do wykonania interpreterowi poleceń lub powłoce. Od tego była już krótka droga do dodania parametrów, instrukcji warunkowych, pętli, zmiennych i innych typowych konstrukcji programistycznych. Główna różnica polegała na

9.3. PROGRAMOWALNE NARZĘDZIA

235

tym, że był tylko jeden typ danych - łańcuchy - oraz operatory w powłokach często były całymi programami, które wykonywały ciekawe obliczenia. Mimo iż programowanie powłoki wyszło już z mody, ustępując pola nowym technikom, takim jak język Perl w środowiskach poleceń czy przyciski w graficznych interfejsach użytkownika, to nadal stanowi efektywny spo­ sób budowania złożonych operacji z prostszych składników. Innym programowalnym narzędziem jest Awk, niewielki język wyspecjalizowany do ope­ rowania na wzorcach, służący do wybierania i przekształcania strumieni wejściowych. Jak wi­ dzieliśmy w rozdziale 3„ Awk automatycznie wczytuje plik i każdy wiersz takiego pliku dzieli na pola, którym nadaje nazwy od $ 1 do $NF, przy czym NF oznacza liczbę pól w wierszu. Dzięki zdefiniowaniu domyślnego sposobu wykonania wielu pospolitych zadań Awk umożliwia pisa­ nie przydatnych jednowierszowych programów. Na przykład poniższy kompletny program na­ pisany w Awku # split.awk: dzieli dane wejściowe na słowa, które umieszcza w osobnych wierszach

{ for ( i = l ; i <= N F ; i ++) pri nt $ i )

drukuje słowa każdego wiersza wejściowego po jednym w wierszu. Można też napisać pro­ gram działający odwrotnie. Poniżej znajduje się implementacja programu fmt, która zapełnia każdy wiersz wyjściowy słowami, ale wstawia najwyżej 60 znaków. Pusty wiersz powoduje utworzenie nowego akapitu. #fint.awk:formatuje dane w postaci wierszy o maksymalnej długości 60 znaków

/ . / { for ( i = l ; i <= N F ; i ++) addword ($i ) } # Niepusty wiersz # Pusty wiersz /"$/ { pri nt l i ne ( ) ; pri nt " " } END { pri ntl i ne ( ) } funct i on addword (w) { i f ( l ength ( l i ne) + 1 + l ength (w) > 60) pri ntl i ne ( ) i f (l ength (l i ne) == O) l i ne= w el se w l i ne = l i ne funct i on pri ntl i ne ( ) { i f ( l ength ( l i ne) > O) pri nt l i ne l i ne = 11 11

Programu fmt często używamy do zmiany układu wiadomości e-mail i innych krótkich dokumentów. Użyliśmy go także w rozdziale 3. do formatowania danych zwracanych przez programy implementujące algorytm Markowa. Wiele programowalnych narzędzi powstaje na bazie małych języków, które zostały zapro­ jektowane do rozwiązywania w naturalny sposób problemów w jakiejś wąskiej dziedzinie. Do­ brym tego przykładem jest program eqn używany w systemie Unix do zapisywania wzorów ma­ tematycznych. Jego język wejściowy jest podobny do języka, jakim posłużyłby się matematyk czytający na głos równania, np. rt/2 pisze się pi over 2. Podobnie jest w języku TEX ten sam ułamek zapisalibyśmy w nim jako \pi \over 2. Jeśli dla problemu, nad którym pracujesz, istnieje naturalna lub dobrze znana notacja, to użyj jej albo przystosuj ją do własnych potrzeb. Nie zaczynaj wszystkiego od początku. -

236

9. NOTACJA

Twórcę języka Awk zainspirował program, w którym używano wyrażeń regularnych do rozpoznawania nieprawidłowych rekordów w danych telekomunikacyjnych. Ale Awk jest prawdziwym językiem programowania, ponieważ zawiera zmienne, wyrażenia, pętle itp. Języki Perl i Tel od samego początku projektowano z myślą o połączeniu wygody i ekspresywności małych języków z potęgą dużych. Mimo iż są to prawdziwe języki ogólnego przeznaczenia, to najczęściej używa się ich do przetwarzania tekstu. Takie narzędzia określa się ogólnym mianem języków skryptowych, ponieważ wywodzą się z wczesnych interpreterów poleceń, których funkcjonalność była ograniczona do wykony­ wania przygotowanych przez programistę skryptów programów. Wykorzystanie wyrażeń re­ gularnych w językach skryptowych nie ogranicza się tylko do wyszukiwania wzorców sprawdzania, czy w tekście występuje określony wzorcem tekst - ponieważ mogą one służyć również do identyfikowania fragmentów tekstu, które mają zostać przekształcone. Do tego celu zostały użyte dwa polecenia reg sub (zamiana wyrażenia regularnego) w poniższym programie w języku Tel. Jest to nieco uogólniona wersja programu pobierającego informacje o akcjach, który przedstawiliśmy w rozdziale 4. Ten program pobiera adres URL przekazany jako pierw­ szy argument. Pierwsza operacja zastępowania usuwa łańcuch znaków http : //, jeśli łańcuch ten istnieje. Druga operacja zamienia pierwszy znak / na spację, w efekcie dzieląc argument na dwa pola. Polecenie l i ndex pobiera pola z łańcucha (zaczynając .od indeksu o numerze O). Tekst znajdujący się w nawiasie [] jest w Tel wykonywany jako polecenie i zastępowany wynikiem. Wyrażenie $x zostanie zastąpione wartością zmiennej x. # geturl.tc/: pobiera dokument spodpodanego adresu URL # Dane sąpobierane w następującej postaci: [http://]abc.defcom[/cokolwiek.„] ; # Usuwa la1icuch http:!!, jeślijest regsub " http : // " $argv 11 11 argv regsub " / " $argv " " argv ; # Zamienia pie1wszy znak I na spację

set so [soc ket [l i ndex $argv O] 80] set q 11 / [l i ndex $argv 1] "

; # Tworzy połączenie sieciowe

puts $so " G ET $q HTTP/ 1 . 0\n\n" ; # Wysyła żądanie fl ush $so whi l e { [gets $so l i ne] >= O && $ l i ne ! = 11 11 ) { } ; # Pomija nagłówek ; # Odczytuje i drukuje całą odpowiedź puts [read $so] Ten skrypt zwykle zwraca ogromne ilości danych, których lwią część stanowią znaczniki HTML ujęte w nawiasy < i >. Ponieważ Perl bardzo dobrze nadaje się do zamiany tekstu, uży­ jemy teraz skryptu w tym języku, aby za pomocą wyrażeń regularnych pozbyć się wspomnia­ nych elementów HTML-a: #unhtml.pl: usuwa znaczniki HTML # Gromadzi wszystkie dane wejściowe w jednym laiicuchu # W tym celu łączy wiersze wejściowe

wh i 1 e { <>) { $str . = $_; } $str =- s/< [A>] *>//g ; $str s/  ; / /g ; $str =- s/\s+/\n/g ; pri nt $str; =-

# Usuwa < „ . > # Zamienia lai/cuchy   na spacje # Likwiduje nadmiarowe spacje

Dla osób, które nie posługują się biegle językiem Perl, ten kod jest mało zrozumiały. Konstrukcja

9.4. INTERPRETERY, KOMPILATORY I MASZYNY WIRTUALNE

237

$str =- s/regexp/repl /g zastępuje łańcuch repl pobranym z łańcucha str fragmentem tekstu pasującym (najdłuż­ sze dopasowanie z lewej) do wyrażenia regularnego regexp. Znajdująca się na końcu litera g (od ang. global - globalnie) oznacza, że operacja ma zostać wykonana dla wszystkich dopaso­ wań w łańcuchu, a nie tylko dla pierwszego. Metaznak s \ to skrócony zapis oznaczający do­ wolny biały znak (spację, tabulator, znak nowego wiersza itp.). Znak \n oznacza nowy wiersz. Łańcuch &nb s p ; to specjalny sposób zapisu znaku w języku HTML - jak w rozdziale 2. określający spację niełamliwą. Zbierając to wszystko razem, poniżej przedstawiamy mało rozgarniętą, ale funkcjonalną przeglądarkę internetową zaimplementowaną za pomocą jednego wiersza kodu:

-

# web: pobiera stronę internetową iformatuje jej tekst, ignorując kod HTA1L

geturl . tcl $ 1 / unhtml . pl I fmt . awk Program ten pobiera stronę internetową, odrzuca wszystkie znaki sterujące i informacje o formatowaniu, a następnie formatuje tekst według własnych zasad. W ten sposób można szybko pobrać tekst ze strony internetowej. Zwróć uwagę na różnorodność języków, których użyliśmy. Każdy z nich jest przystosowa­ ny do wykonywania określonego rodzaju zadań: Tel, Perl, Awk i dodatkowo wyrażenia regu­ larne. Największą zaletą notacji jest to, że można wybrać dobrą notację do każdego rodzaju za­ dań. Język Tel najlepiej nadaje się do pobierania tekstu przez sieć. Języki Perl i Awk doskonale sprawdzają się w przetwarzaniu i formatowaniu tekstu. Natomiast wyrażenia regularne są naj­ lepsze do określania fragmentów tekstu, które trzeba znaleźć i zmodyfikować. Połączenie tych wszystkich języków daje znacznie większe możliwości niż użycie któregokolwiek z nich w izo­ lacji. Warto podzielić pracę na kilka części, jeśli pozwala to skorzystać z dobrodziejstw użycia odpowiedniej notacji.

9.4. Interpretery, kompilatory i maszyny wirtualne Jak kod źródłowy programu staje się wykonywalnym programem? Jeśli użyty do jego budowy język jest w miarę prosty, tak jak np. funkcja pri nt f albo nasze najprostsze wyrażenia regular­ ne, to możemy wykonać bezpośrednio kod źródłowy. Jest to łatwy i szybki sposób. Między czasem przygotowywania programu do użytku a szybkością jego wykonywania ist­ nieje pewna zależność. Jeśli język programowania jest skomplikowany, to z reguły lepiej jest przekonwertować kod źródłowy na wydajną wewnętrzną reprezentację. Czas poświęcony na przetworzenie kodu źródłowego można odzyskać dzięki szybszemu działaniu programu. Pro­ gramy, które mają funkcję zarówno przekształcania, jak i wykonywania wczytanego kodu źró­ dłowego, nazywają się interpreterami. Do tej licznej grupy należą języki Awk i Perl oraz wiele innych języków skryptowych i specjalnych. Trzecia możliwość to wygenerowanie instrukcji przeznaczonych dla konkretnego rodzaju komputera, na którym mają być wykonywane. Do tego służą kompilatory. To podejście wyma­ ga najwięcej wysiłku i czasu na początku, ale daje możliwość najszybszego wykonywania pro­ gramów. Istnieją też inne techniki. Jedną z nich - zajmiemy się nią w tym podrozdziale - jest kompilacja programów do postaci instrukcji przeznaczonych dla sztucznego komputera (ma­ szyny wirtualnej), który można zaimplementować w dowolnym prawdziwym komputerze. Ma­ szyna wirtualna łączy w sobie wiele zalet typowej interpretacji i kompilacji.

238

9. NOTACJA

Jeśli język programowania jest prosty, to analiza struktury napisanego w nim programu i jej konwersja na wewnętrzną postać nie wymagają wiele pracy. Jeżeli natomiast mamy do czynienia z bardziej złożonym językiem - zawierającym deklaracje, zagnieżdżone struktury, instrukcje i wyrażenia rekursywne, operatory o określonej kolejności wykonywania itd. - to analiza składni jego kodu w celu poznania struktury programu jest bardziej skomplikowana. Analizatory składni często pisze się, korzystając z pomocy automatycznego generatora, cza­ sami nazywanego kompilatorem kompilatorów, jak np. yacc lub bison. Programy takie prze­ kształcają opis języka, zwany gramatyką, w (najczęściej) program w języku c lub c + + , który po skompilowaniu będzie tłumaczył instrukcje napisane w tym języku na wewnętrzną repre­ zentację. Oczywiście utworzenie analizatora składni bezpośrednio z gramatyki stanowi kolejny przykład tego, jak dużo daje dobra notacja. Reprezentacja tworzona przez analizator składni ma najczęściej postać drzewa, którego wewnętrzne węzły zawierają operatory, a liście - argumenty operacji. Dla poniższej instrukcji

a = max ( b , c/2) ; może zostać utworzone następujące drzewo rozbioru (składni):

max

a

b

/ �

I

/ �

c

2

Do tworzenia i przetwarzania drzew rozbioru można by użyć wielu z algorytmów drzew opisanych w rozdziale 2. Po utworzeniu drzewa mamy kilka możliwości dalszego postępowania. Najprościej, tak jak to zrobiono w języku Awk, jest przeglądać drzewo, bezpośrednio obliczając wartości w napoty­ kanych węzłach. Uproszczona wersja takiej procedury dla języka wyrażeń używającego wartości całkowitych mogłaby poruszać się po drzewie metodą przeszukiwania wstecznego (ang. post-order traversal):

typedef struct Symbo l Symbol ; typedef struct Tree Tree; struct Symbol { i nt val ue; char *name; }; struct Tree op; i nt val ue; i nt Symbol *symbol ; *l eft ; Tree Tree *ri ght;

I* Kod operacji */ /* Wartość, jeśli liczba */ /* Symbol, jeśli zmienna */

9.4. INTERPRETERY, KOMPILATORY I MASZYNY WIRTUALNE

239

}; /* eval: wersja 1

-

obliczanie wartości wyrażenia przedstawionegojako drzewo *I

i nt eval (Tree *t) { i nt l eft , right; switch (t->op) { case NUMBER: return t->val ue; case VARIABLE : return t->symbo l ->val ue; case ADD : return eval (t->l eft) + eval (t->ri ght ) ; case DIVIDE: l eft = eval (t->l eft) ; ri ght = eval (t->ri ght) ; i f (ri ght == D) epri ntf ( " Dz i e l en i e warto!ci %d przez zero " , l eft) ; return l eft / ri gh t ; case MAX : l eft = eval (t->l eft) ; right = eval (t->ri ght ) ; return l ef>ri ght ? l eft : ri ght ; case ASS I G N : t->l eft->symbol ->val ue = eval (t->ri ght) ; return t->l eft->symbol ->val ue; I * ... *I

}

Kilka pierwszych klauzul case oblicza proste wyrażenia, takie jak stałe i wartości. Dalsze klauzule dotyczą obliczania wartości wyrażeń arytmetycznych, a pozostałe mogą obsługiwać specjalne przypadki przetwarzania, warunki i pętle. Aby możliwa była implementacja struktur sterujących, w drzewie są potrzebne dodatkowe informacje (niepokazane) dotyczące przepływu sterowania. Podobnie jak w funkcjach pack i unpac k instrukcję swi tch możemy zamienić na tablicę wskaźników na funkcje. Poszczególne operatory pozostaną w dużym stopniu takie same, jak w instrukcji swi tch: I * addop: zwraca sumę dwóch wyraże1i przedstawionych w postaci drzewa *I

i nt addop (Tree *t) { return eval (t->l eft) + eval (t->ri ght) ;

Tabela wskaźników na funkcje wiąże operatory z funkcjami, które wykonują właściwe im operacje:

en urn { /* Kody operacji, Tree.op itd. *I NUMBER, VARIABLE, ADD , DIVIDE, I * ... *I

240

9. NOTACJA

}; I* optab: tablicafimkcji realizujących działanie operatorów *I

i nt {*optab [] ) (Tree *) { pushop , /* NUMBER *I pushsymop, /* VARIABLE *I addop, I* ADD *I I* DIVIDE *I d i vop , =

I*

„.

*I

}; Przy obliczaniu wartości wyrażenia wybieramy odpowiednie funkcje z tablicy wskaźników, posługując się indeksami w postaci odpowiadających im operatorów. Ta wersja funkcji eval wywołuje inne funkcje rekursywnie. I* eval: wersja 2

-

oblicza drzewo przy użyciu tablicy operatorów *I

i nt eva l (Tree *t) return {*optab [t->op] ) (t ) ;

Obie wersje funkcji eval są rekursywne. Są sposoby na wyeliminowanie rekurencji, wśród których znajduje się sprytna technika zwana kodem nizanym (ang. threaded code) pozwalająca całkowicie spłaszczyć stos wywołań. Najlepiej całkowicie pozbyć się rekurencji, przechowując funkcje w tablicy, której zawartość jest sekwencyjnie przeglądana w trakcie wykonywania pro­ gramu. Tablica ta staje się sekwencją instrukcji do wykonania przez niewielką, specjalnie przy­ stosowaną do tego celu maszynę. Wciąż jednak potrzebujemy stosu do reprezentacji częściowych wyników obliczeń, w związku z czym zmianie ulegnie forma funkcji, ale łatwo te zmiany zauważyć. W efekcie wynaleźliśmy maszynę stosową, w której instrukcjami są małe funkcje, a argumenty są przechowywane w osobnym stosie argumentów. Nie jest to prawdziwa maszyna, ale możemy ją zaprogramować jak prawdziwą oraz z łatwością zaimplementować jako interpreter. Zamiast przemierzać drzewo w celu obliczenia wartości reprezentowanego przez nie wyra­ żenia, przemierzamy je, aby utworzyć tablicę funkcji, która będzie służyć do wykonania pro­ gramu. Tablica ta będzie także zawierała wartości, takie jak stałe i zmienne (symbole), używane przez instrukcje, a więc typem jej elementów powinna być unia:

typedef uni on Code Code; uni on Code { voi d {*op) (voi d) ; I* Funkcja, jeśli operator *I i nt val ue; l* Wartość, jeśli liczba *I Symbol *symbol ; I* Symbol, jeśli zmienna *I }; Poniżej znajduje się kod źródłowy procedury, która tworzy wskaźniki na funkcje i zapisuje je w tablicy o nazwie code. Funkcja generate nie zwraca wartości wyrażenia (ta zostanie obli­ czona po wykonaniu wygenerowanego kodu), lecz indeks w tablicy code następnej operacji, która ma zostać wygenerowana: I* generale: genentje instrukcje, przemierzając drzewo *I

i nt generat e ( i nt codep , Tree *t) {

9.4. INTERPRETERY, KOMPILATORY I MASZYNY WIRTUALNE

241

swi tch (t->op} ( case NUMBER: code[codep++] . op = pushop; cod e [codep++] . val ue = t->val ue; return codep ; case VAR I ABLE : code[codep++] . op = pushsymop ; code [codep++] . symbol = t->symbol ; return codep ; case ADD : codep = generat e ( codep , t->l eft ) ; codep = generate(codep , t->ri ght) ; code [codep++] . op = addop ; return codep ; case D I V I D E : codep = generate (codep , t->l eft ) ; codep = generate(codep , t->ri ght} ; code [codep++] . op = di vop ; return codep ; case MAX : /* ... *I

Dla instrukcji a

max ( b , c/2) zostałby wygenerowany następujący kod:

pushsymop b pushsymop

c

pushop 2 di vop maxop storesymop a Funkcje odpowiadające poszczególnym operatorom działają na stosie, zdejmując z niego argumenty i układając na nim wyniki. Interpreterem jest pętla, która przegląda tablicę wskaźników na funkcje, używając do tego celu licznika programu:

Code code [NCODE] ; i nt stack [NSTACK] ; i nt stackp; i nt pe; /* Licznikprogramu */ /* eval: wersja 3

-

oblicza wartości wyrażeń z wygenerowanego kodu */

i nt eval (Tree *t} { pe = generate (O , t } ; code [pc] . op = NULL; stackp

=

O;

242

9. NOTACJA pe = O ; whi l e (code [pc] . op ! = NULL) {*code [pc++] . op ) () ; return stack [O] ;

Ta pętla symuluje programowo na naszej maszynie stosowej to, co dzieje się w sprzęcie prawdziwego komputera. Oto kilka reprezentatywnych operatorów: /* pushop: kładzie liczbę na stos; wartośćjest następnym słowem w stn1mieniu tablicy code */

v o i d pushop (voi d) { stack [stackp++] = code [pc++] . val ue; /* divop: oblicza iloraz dwóch wyrażeń */

v o i d d i vop {voi d) { i nt l eft , right; right = stack [--stac kp] ; l eft = stack [--stackp] ; i f {ri ght == O) epri n t f ( " Dz i el en i e l i czby %d przez zero\n " , l eft ) ; stack [stac kp++] = l eft / ri gh t ;

Zauważ, że konstrukcja sprawdzająca, czy nie nastąpi dzielenie przez zero, znajduje się w funkcji di vop, a nie generate. Instrukcje warunkowe, rozgałęzienia i pętle zmieniają wartość licznika programu znajdują­ cego się w funkcji odpowiadającej operatorowi, powodując w ten sposób przejście do innego miejsca w tablicy funkcji. Na przykład operator goto zawsze ustawia wartość zmiennej pe, podczas gdy rozgałęzienie warunkowe ustawia ją tylko wówczas, gdy jest spełniony warunek. Tablica code stanowi oczywiście wewnętrzną strukturę interpretera, ale wyobraźmy sobie, że chcemy zapisać wygenerowany program w pliku. Gdybyśmy zapisali adresy funkcji, otrzy­ malibyśmy nieprzenośny i podatny na awarie produkt. W związku z tym zamiast tego mogliby­ śmy zapisać stałe reprezentujące funkcje, np. 1000 dla addop, 1001 dla pus hop itd„ i przemie­ niać je z powrotem we wskaźniki na funkcje podczas wczytywania programu do interpretacji. Jeśli przejrzymy zawartość pliku tworzonego przez tę procedurę, to zobaczymy coś, co wy­ gląda jak strumień rozkazów dla maszyny wirtualnej, której rozkazy implementują podstawowe operatory naszego małego języka, a funkcja generate jest w istocie kompilatorem tłumaczącym ten język na język maszyny wirtualnej. Maszyny wirtualne to wspaniały stary wynalazek, który ostatnio przeżywa swoją drugą młodość dzięki językowi Java i jego maszynie wirtualnej JVM (ang. Java Virtual Machine). Dzięki nim można łatwo tworzyć przenośny, wydajny kod pro­ gramów w języku wysokiego poziomu.

9.5. Programy, które piszą programy Bodaj najciekawszą cechą funkcji generate jest to, że jest ona programem, który pisze progra­ my: jej wynik jest wykonywalnym strumieniem rozkazów dla innej (wirtualnej) maszyny.

9.5. PROGRAMY, KTÓRE PISZĄ PROGRAMY

243

Kompilatory robią to cały czas - tłumaczą kod źródłowy na rozkazy maszynowe, a więc na pewno nie jest to żadna nowość. W istocie programy piszące programy można spotkać w wielu postaciach. Typowym przykładem jest dynamiczne generowanie internetowych stron w j ęzyku HTML. Mimo pewnych ograniczeń jest to prawdziwy język, w którym ponadto możliwe jest stosowanie dodatkowego kodu np. w języku JavaScript. Strony internetowe często generuje się w locie za pomocą programów napisanych w językach Perl albo C, a ich zawartość (np. wyniki wyszukiwania i reklamy) jest uzależniona od treści otrzymanego żądania. My użyliśmy specjalnych języków do wygenerowania wykresów, rysunków, tabel, działań matematycznych i indeksu zamieszczonych w tej książce. Innym przykładem jest język programowania PostScript, w któ­ rym kod generują procesory tekstu, programy do rysowania i wiele innych aplikacji. W osta­ tecznej formie ta książka ma postać składającego się z 57 tysięcy wierszy programu napisanego w języku PostScript. Dokument jest statycznym programem, ale pomysł użycia języka programowania w roli no­ tacji służącej do rozwiązywania dowolnego rodzaju problemów jest godny uwagi. Wiele lat te­ mu programiści marzyli o komputerach, które pisałyby wszystkie programy za nich. Zapewne marzenie to nigdy się nie ziści, ale dzisiejsze komputery cały czas piszą za nas programy, często do reprezentowania takich rzeczy, których nigdy wcześniej nie wyobrazilibyśmy sobie jako programów. Do najpospolitszych programów piszących programy zaliczają się kompilatory, które tłu­ maczą kod napisany w języku wysokiego poziomu na kod maszynowy. Często jednak przydat­ ne jest przetłumaczenie kodu na język programowania głównego nurtu. W poprzednim pod­ rozdziale napisaliśmy, że generatory analizatorów składni przekształcają definicję gramatyki języka w program w języku C, który analizuje kod w danym języku. Język C jest często wyko­ rzystywany w ten sposób jako pewien rodzaj „języka asemblera wysokiego poziomu". Pierwsze kompilatory ogólnych języków C+ + i Modula-3 najpierw tworzyły kod w języku C, który na­ stępnie był kompilowany przez standardowy kompilator języka C. Wśród zalet takiego podej­ ścia można wyliczyć m.in. wydajność (ponieważ takie programy mogą z zasady działać tak sa­ mo szybko, jak programy napisane w języku C) oraz przenośność (ponieważ kompilatory można przenieść do każdego systemu, w którym jest kompilator języka C). To znacznie pomo­ gło w początkowym rozpowszechnianiu tych języków. Kolejnym przykładem jest interfejs graficzny języka Visual Basic generujący instrukcje przypisania w tym języku do inicjalizacji obiektów, które użytkownik wybrał z menu i umie­ ścił na ekranie za pomocą myszy. Wiele innych języków ma „wizualne" systemy i kreatory tworzące kod interfejsu użyrkownika, którego elementy rozmieszcza się za pomocą myszy. Jednak mimo dużych możliwości oferowanych przez generatory programów oraz dostępno­ ści wielu dobrych przykładów pomysł ten nie cieszy się zainteresowaniem, na jakie zasługuje, i niewielu programistów z niego korzysta. Ale istnieje cała masa okazji do utworzenia własnego kodu przez program, a więc każdy może z tego skorzystać. Oto kilka przykładów generowania kodu w językach c i c+ + . System operacyjny Plan 9 generuje komunikaty o błędach przy użyciu pliku nagłówkowego zawierającego nazwy i komentarze. Komentarze są automatycznie konwertowane na łańcuchy w cudzysłowach i umieszczane w tablicy, którą można indeksować wartościami z wyliczenia. Poniżej widać strukturę tego pliku nagłówkowego: /* errors.h: standardowe komunikaty o błędach */

enum { Eperm, Eio, Efi l e ,

I* Permission denied */ /* 110 error */ /* File does not exist */

244

};

9. NOTACJA Emem, Espace, Egreg

/* Memory limit reached */ /* Out offile space */ /* Jt 's all Greg'sfault */

Z takich danych wejściowych prosty program może utworzyć następujący zbiór deklaracji komunikatów o błędach: /* Generowane maszynowo, nie zmieniać *I

char *errs [] { " Permi s s i on den i ed " , /* Eperm */ " I/O error" , I* Eio */ " Fi 1 e does not ex i s t " , /* Efile */ "Memory 1 i mi t reached " , /* Emem */ "Out of fi 1 e space" , /* Espace */ " It ' s al l Greg ' s faul t " , /* Egreg *I }; =

Podejście to ma kilka zalet. Po pierwsze relacje między wartościami wyliczenia i reprezen­ towanymi przez nie łańcuchami są oczywiste i łatwo je uniezależnić od języka naturalnego. Ponadto informacja występuje tylko raz, jako „pojedynczy punkt prawdy", na podstawie które­ go jest generowany pozostały kod. Dzięki temu informacje trzeba aktualizować tylko w jednym miejscu. Gdyby takich miejsc było więcej, to wcześniej czy później zawarte w nich informacje zaczęłyby się różnić. W końcu bardzo łatwo można sprawić, aby plik . c był tworzony i kompi­ lowany od nowa za każdym razem, gdy zmieni się plik nagłówkowy. Gdy trzeba zmienić któryś komunikat o błędzie, to wystarczy zmodyfikować plik nagłówkowy i skompilować system ope­ racyjny. Komunikaty zostaną zaktualizowane automatycznie. Program generujący można napisać w dowolnym języku, np. w Perlu, w którym łatwo prze­ twarza się łańcuchy znaków: # enum.pl: generuje komunikaty o błędach z wartości wyliczenia i komentarzy

pri nt " /* Generowane maszynowo , n i e zmi eni ać . */\n\n " ; pri nt " char *errs [] {\n" ; =

wh i l e ( <>) { chop ; i f (/A\s* ( E [a-z0-9] +) , ?/) $name $ 1 ; s/. *\/\* *// ; s/ *\*\/// ; pri nt "\t\ "$_\ " , /* $name =

# Usuwa znaki nowego wiersza # Pierwsze słowo zaczyna się od litery E # Zapisanie nazwy # Usuwa wszystko do /* # Usuwa */

*/\n " ;

pri nt " } ; \n " ; Znowu użyliśmy wyrażeń regularnych. Z ich pomocą wybieramy wiersze, których pierwsze pola wyglądają jak identyfikatory z przecinkiem. Pierwsza operacja zastępowania usuwa wszystko, co znajduje się przed pierwszym niebiałym znakiem komentarza, natomiast druga usuwa znak zakończenia komentarza i wszystkie znajdujące się przed nim białe znaki.

9.5. PROGRAMY, KTÓRE PISZĄ PROGRAMY

245

Podczas testowania kompilatora Andy Koenig opracował wygodną technikę pisania kodu C + + sprawdzającego, czy kompilator znajduje błędy w kodzie programów. Fragmenty kodu, które powinny powodować uruchomienie mechanizmów diagnostycznych kompilatora, zostały opatrzone magicznymi komentarzami opisującymi spodziewane komunikaty. Każdemu wier­ szowi przypisano komentarz zaczynający się od znaków /// (aby odróżniał się od zwykłych komentarzy) i zawierający wyrażenie regularne pasujące do komunikatu zwracanego przez kompilator dla danego wiersza. Zatem dwa poniższe fragmenty kodu powinny generować dane diagnostyczne:

i nt f ( ) { ) lllwarning. * non-voidfanction . * shou/d return a va/ue

voi d g () { return l ; }

Ili error. * voidfunction may not return a va/ue

Jeśli drugi z testów przepuścimy przez nasz kompilator języka c+ +, zostanie wydrukowany oczekiwany komunikat, który pasuje do wyrażenia regularnego:

% CC x . c " x . c " , l i ne 1 : error(32 1 ) : voi d functi on may not return a val ue Każdy taki fragment kodu podaje się kompilatorowi, a następnie porównuje się wynik z ocze­ kiwanymi danymi. Proces ten można zautomatyzować z pomocą programów powłoki i w języku Awk. Niepowodzenie oznacza, że kompilator zwrócił informacje inne niż oczekiwane. Ponie­ waż komentarze są wyrażeniami regularnymi, w danych wyjściowych można dopuścić pewien zakres swobody, który w zależności od potrzeb można poszerzać lub zwężać. Pomysł semantycznego wykorzystania komentarzy nie jest nowy. W j ęzyku PostScript zwykłe komentarze zaczynają się od znaku %. Natomiast komentarze zaczynające się od znaków %% mogą zawierać dodatkowe informacje o liczbie stron, prostokątnych ramkach otaczających, nazwach fontów itp.:

%%PageBoundi ngBox : 126 307 492 768 %%Pages : 14 %%DocumentFonts : Hel vet i ca Times - Ital i c Times-Roman Luci daSans-Typewri ter W języku Java znane są komentarze oznaczane za pomocą ciągów znaków /** i */, służące do dokumentowania klasy, której definicja znajduje się za nimi. Zakrojoną na większą skalę techniką pisania kodu przeplatanego z dokumentacją jest metoda zwana programowaniem pi­ śmiennym (ang. literate programming). W metodzie tej kod źródłowy programu jest połączony z dokumentacją w taki sposób, że jeden proces może wydrukować program w kolejności odpo­ wiedniej do czytania przez człowieka, a inny w kolejności właściwej do jego skompilowania. We wszystkich przedstawionych przykładach należy zwrócić uwagę na rolę, jaką odgrywa w nich notacja, połączenie różnych języków oraz sposób użycia narzędzi. Możliwości poszcze­ gólnych składników dzięki połączeniu zostały zwiększone.

Ćwiczenie 9.15. Jednym z najstarszych dowcipów programistycznych jest napisanie programu, którego działanie polega na utworzeniu wiernej kopii swojego kodu źródłowego. Jest to ciekawy specjalny przypadek programu pisanego przez program. Spróbuj napisać taki program w kilku swoich ulubionych językach.

246

9. NOTACJA

9 6 Generowanie kodu za pomocą makr .

.

Schodząc o kilka poziomów niżej, możliwe jest generowanie kodu w czasie kompilacji za po­ mocą makr. Do tej pory przestrzegaliśmy przed używaniem makr i kompilacji warunkowej, ponieważ techniki te mogą powodować wiele problemów. Ale mają one swoją niszę. Czasami podstawienie tekstowe jest idealnym rozwiązaniem problemu. Jednym z przykładów jest uży­ cie preprocesora makr języków c i c+ + do łączenia części programu zawierających powtarza­ jące się fragmenty. Na przykład omówiony w rozdziale 7. program sprawdzający szybkość podstawowych kon­ strukcji językowych używał preprocesora do składania testów, które opakowywał w szablono­ wy kod. Test polegał na umieszczeniu kodu w pętli uruchamiającej zegar, wykonaniu go okre­ śloną liczbę razy, zatrzymaniu zegara i przedstawieniu wyniku. Całość powtarzającego się kodu została wyrażona w kilku makrach, a kod, którego czas wykonywania miał być mierzony, był przekazywany jako argument. Podstawowe makro ma następującą postać:

#defi ne LOOP (CODE) { to = cl ock ( ) ; for (i = O ; i < n; i ++) CODE; pri ntf ( "%7d c l o c k ( ) - tO) ; " ,

\ \ \ \

Znaki ukośnika służą do podziału treści makra na kilka wierszy. To makro jest używane w „instrukcjach", które zazwyczaj wyglądają tak:

LOOP ( f1 f2) LOOP (fl f2 + f3) LOOP (fl = f2 - f3) =

=

Czasami występują jeszcze inne instrukcje służące do inicjalizacji, ale podstawowa część dotycząca mierzenia czasu znajduje się w tych jednoargumentowych fragmentach, które są rozwijane do pokaźnej ilości kodu. Makr można także używać do generowania kodu produkcyjnego. Bart Locanthi napisał kiedyś wydajną wersję operatora grafiki dwuwymiarowej. Operator ten, zwany bi tbl t lub ra­ sterop, trudno wydajnie zaimplementować, ponieważ ma wiele argumentów, które łączą się ze sobą w skomplikowany sposób. Przeprowadzając drobiazgową analizę przypadków, Locanthi zdołał zredukować kombinacje do pojedynczych pętli, które można było indywidualnie zop­ tymalizować. Następnie każdy przypadek był konstruowany poprzez podstawienie za pomocą makra, analogicznie do przykładu testowania wydajności, a wszystkie warianty były wymienia­ ne w jednej dużej instrukcji swi t c h . Oryginalny kod źródłowy składał się z kilkuset wierszy, a w wyniku przetworzenia za pomocą makra rozrastał się do kilku tysięcy. Kod rozwijany przez makro nie był optymalny, ale uwzględniając skalę trudności problemu, był b ardzo praktyczny i łatwy do wygenerowania. Ponadto był bardzo wydajny jak na wysoce zoptymalizowany kod.

Ćwiczenie 9.16. W ćwiczeniu 7.7 trzeba było napisać program szacujący czas wykonywania różnych operacji w języku C + + . Napisz nową wersję tego programu, stosując techniki opisane w tym rozdziale.

Ćwiczenie 9.17. W ćwiczeniu 7.8 należało wykonać model kosztów dla języka Java, w którym nie ma możliwości używania makr. Rozwiąż ten problem poprzez napisanie nowego programu w dowolnym języku (lub językach), który pisze wersję w Javie i automatyzuje wykonywanie pomiarów czasu.

9.7. KOMPILACJA W LOCIE

247

9.7. Kompilacja w locie W poprzednim podrozdziale omawialiśmy programy, które piszą programy. W każdym z przedsta­ wionych przykładów generowany program miał postać kodu źródłowego. W celu uruchomienia trzeba go było poddać kompilacji lub interpretacji. Lecz możliwe jest też wygenerowanie kodu, który jest gotowy do natychmiastowego wykonania, jeśli zamiast kodu źródłowego wygeneruje się rozkazy maszynowe. Nazywa się to kompilacją w locie (ang. on the fly compilation) lub kom­ pilacją na czas (ang. just in time compilation). Pierwszy termin jest starszy, ale popularniejszy jest drugi, zwłaszcza w formie akronimu JIT. Chociaż skompilowany kod nie może być przenośny (działa tylko w jednym rodzaju proce­ sora), to może być bardzo szybki. Weźmy na przykład poniższe wyrażenie:

max { b , c/2) Program musi obliczyć wartość c, podzielić ją przez dwa, wynik porównać z b i wybrać większą z dwóch wartości. Gdybyśmy wartość tego wyrażenia obliczali przy użyciu opisanej wcześniej wirtualnej maszyny, to moglibyśmy pominąć sprawdzanie dzielenia przez zero w funkcji di vop. Sprawdzanie to jest tu bezcelowe, ponieważ liczba dwa nigdy nie będzie zerem. Lecz w maszy­ nie wirtualnej zaprojektowanej zgodnie z zasadami, które przedstawiliśmy, nie ma możliwości wyeliminowania tej operacji sprawdzania. Każda implementacja operacji dzielenia sprawdza, czy dzielnik nie jest zerem. Tu może nam pomóc dynamiczne generowanie kodu. Jeśli kod wyrażeń będziemy budować bezpośrednio, zamiast tworzyć łańcuch zdefiniowanych wcześniej operacji, możemy uniknąć sprawdzania w tych przypadkach, gdy wiadomo, że dzielnik ma wartość różną od zera. W isto­ cie możemy posunąć się nawet jeszcze dalej. Jeżeli całe wyrażenie ma wartość stałą, np. max (3*3 , 4/2 ) , to jesteśmy w stanie obliczyć je raz podczas generowania kodu i zastąpić stałą wartością 9. Gdyby takie wyrażenie występowało w pętli, to oszczędzalibyśmy czas w każdym cyklu. Jeśli pętla ta wykonywałaby bardzo dużo powtórzeń, odzyskalibyśmy czas poświęcony na analizę wyrażenia i generowanie dla niego kodu. Głównie chodzi o to, że notacja umożliwia nam wyrażenie problemu w ogólny sposób, a kom­ pilator dla tej notacji może zoptymalizować kod dla szczegółów konkremych obliczeń. Na przykład w maszynie wirtualnej dla wyrażeń regularnych zapewne używalibyśmy operatora dopasowują­ cego literały znakowe:

i nt matchchar ( i nt l i teral , char *text) { return *text l i teral ; ==

Kiedy jednak generowany jest kod dla konkremego wzorca, wartość danego argumentu 1 i tera 1 jest stała, np. znak x, w związku z tym moglibyśmy użyć następującego kodu operatora:

i nt matchx (char *text) { return *text == ' x ' ;

Zamiast definiować specjalny operator dla każdego możliwego znaku, ułatwiliśmy sobie życie przez generowanie kodu operatorów, których rzeczywiście potrzebujemy w danym wyra­ żeniu. Uogólniając ten pomysł na kompletny zestaw operacji, możemy napisać kompilator

248

9. NOTACJA

działający w locie, tłumaczący bieżące wyrażenia regularne na specjalny kod zoptymalizowany dla tych wyrażeń. Dokładnie tak postąpił Ken Thompson, implementując wyrażenia regularne w komputerze IBM 7094 w 1967 roku. Jego wersja generowała niewielkie bloki rozkazów procesora 7094 w postaci binarnej dla różnych operacji w wyrażeniu, wiązała je razem, a następnie wykony­ wała tak powstały program, wywołując go jak zwykłą funkcję. Podobne techniki można zasto­ sować do tworzenia specyficznych sekwencji instrukcji dla operacji aktualizowania ekranu w syste­ mach graficznych. Jest w nich tyle specjalnych przypadków, że lepiej tworzyć dynamiczny kod dla każdego z nich, gdy się pojawi, niż pisać je wszystkie samodzielnie albo dodawać testy wa­ runkowe do bardziej ogólnego kodu. Aby pokazać, jak się tworzy prawdziwy kompilator działający w locie, trzeba by było zagłę­ bić się w szczegóły konkretnego zbioru rozkazów. Nie możemy tego zrobić, ale możemy przy­ najmniej poznać ogólne zasady działania takiego systemu. Pozostała część tego rozdziału za­ wiera tylko omówienie ogólnej koncepcji. Nie należy tego traktować jako szczegółowego opisu sposobu implementacji. Przypomnijmy, że pracę nad naszą maszyną wirtualną zakończyliśmy, mając następującą strukturę:

Code eode [NCODE] ; i nt staek [NSTACK] ; i nt staekp ; i nt p e ; /* Licznik programu */ Tree *t ; t = parse ( ) ; pe = generate (O, t ) ; eode [pe] . op = NULL; staekp = O ; pe = O; whi l e (eode [pc] . op ! = NULL) (*eode [pe++] . op) ( ) ; return staek [O] ; Aby przystosować ten kod do kompilacji w locie, musimy w nim wprowadzić pewne zmiany. Po pierwsze tablica code nie jest już tablicą wskaźników na funkcje, lecz tablicą wykonywal­ nych rozkazów. To, czy rozkazy będą typu char, i nt czy 1 ong, zależy od procesora, dla którego będziemy kompilować kod. My użyjemy typu i nt. Gdy kod zostanie wygenerowany, wywoła­ my go jako funkcję. Nie będzie żadnego wirtualnego licznika programu, ponieważ kod będzie wykonywany przez procesor zgodnie z jego własnym cyklem. Po wykonaniu obliczenia nastąpi zwrócenie wartości, tak jak w przypadku zwykłej funkcji. Argumenty operacji możemy prze­ chowywać na osobnym stosie albo wykorzystać do tego celu stos procesora. Każde z tych roz­ wiązań ma swoje zalety, lecz my zdecydowaliśmy się na pozostanie przy osobnym stosie, aby móc skupić się na szczegółach samego kodu. Teraz nasza implementacja wygląda tak:

typedef i nt Code; Code eode [NCODE] ; i nt eodep ; i nt stack [NSTACK] ; i nt staekp ;

9.7. KOMPILACJA W LOCIE

249

Tree * t ; v o i d (*fn) (voi d ) ; i nt p e ; t = parse ( ) ; pe = generate (O , t ) ; gen return (pe) ; staekp = O ; f1 usheaehes ( ) ; fn = (voi d (*} (voi d) ) (*fn} ( ) ; return stack [O] ;

/* Generuje sekwencję powrotu zfunkcji */ /* Synchronizacja pamięci z procesorem *I eode; /* Rzutowanie tablicy na wskaźnik na funkcję */ /* Wywolaniejimkcji */

Po zakończeniu działania funkcji generate funkcja genreturn ustawia rozkazy, które zmu­ szają wygenerowany kod do oddania sterowania funkcji ev a 1 . Funkcja f1 ushcaches przygotowuje procesor do wykonywania świeżo wygenerowanego kodu. Nowoczesne maszyny są szybkie po części dlatego, że mają pamięci podręczne, w któ­ rych przechowują instrukcje i dane, oraz wewnętrzne potoki pozwalające na równoczesne wy­ konywanie kolejnych instrukcji. Te pamięci podręczne i potoki wymagają, aby strumień in­ strukcji był statyczny. Jeśli wygenerujemy kod bezpośrednio przed wykonaniem, to możemy wprowadzić w błąd procesor. Aby procesor mógł wykonać nowe instrukcje, konieczne jest uprzednie wyczyszczenie jego potoku i pamięci podręcznych. Są to operacje ściśle uzależnione od maszyny. Implementacja funkcji f1 u s h caches w każdym rodzaju komputera będzie inna. Wyrażenie ( vo i d {*) (voi d) ) code wykonuje konwersję adresu tablicy zawierającej wyge­ nerowane instrukcje na wskaźnik na funkcję, który pozwala wywołać code jako funkcję. Technicznie samo wygenerowanie kodu nie jest trudne, ale aby to było wydajne, trzeba w to włożyć nieco wysiłku. Zaczniemy od kilku podstawowych składników budulcowych. Tak jak poprzednio tablica code i indeks do niej są obsługiwane podczas kompilacji. Dla uproszczenia zdefiniujemy je globalnie, tak jak wcześniej . Następnie możemy przejść do pisania funkcji układającej rozkazy: /* emit: dodaje rozkaz do strumienia kodu */

v o i d emi t (Code i nst) { eode [codep++] = i ns t ;

Same rozkazy można zdefiniować przez makra zależne o d procesora lub niewielkie funkcje, które składają rozkazy, wypełniając pola w słowach rozkazów. Hipotetycznie moglibyśmy utworzyć funkcję o nazwie popreg, generującą kod pobierający wartość ze stosu i zapisujący ją w rejestrze procesora, i drugą funkcję o nazwie pus hreg, która generowałaby kod pobierający wartość zapisaną w rejestrze i wstawiałaby ją na stos. Nasza zmodyfikowana funkcja addop wy­ korzystywałaby je w ten sposób, mając kilka zdefiniowanych stałych opisujących rozkazy (jak ADDI NST) i ich układ (różne pozycje SHI FT, które definiują format): /* addop: generuje rozkaz ADD */

v o i d addop (voi d) { Code i ns t ; popreg (2} ; popreg ( 1 ) ;

/* Zdejmuje element ze stosu i wstawia go do rejestru 2 */ /* Zdejmuje element ze stosu i wstawia go do rejestru I */

250

9. NOTACJA

i nst ADDI NST << I NSTS H I FT ; i nst I = (Rl) « OP!SHI FT ; i nst I = ( R2) « OP2SHI FT ; emi t ( i nst) ; /* Wysyła rozkaz ADD Rl, R2 */ I* Umieszcza wartość rejestru 2 na stosie */ pushreg (2) ; =

To dopiero początek. Gdybyśmy chcieli napisać prawdziwy kompilator działający w locie, zastosowalibyśmy optymalizację. Jeśli dodajemy stałą, to nie musimy jej umieszczać na stosie, zdejmować ze stosu i dopiero dodawać. Możemy to działanie wykonać bezpośrednio. Myśląc w ten sposób, można wyeliminować dużo narzutu. Ale nawet w tej postaci funkcja addop bę­ dzie działała znacznie szybciej od swoich wcześniejszych wersji, ponieważ różne operatory nie są wiązane razem przez wywołania funkcji. W zamian kod, który je wykonuje, jest umieszczo­ ny w pamięci w formie pojedynczego bloku rozkazów, a wiązanie wykonuje za nas rzeczywisty licznik programu procesora. Funkcja generate pozostaje prawie taka sarna, jak w wersji dla maszyny wirtualnej. Jedyna różnica polega na tym, że zamiast wskaźników na wcześniej zdefiniowane funkcje układa prawdziwe rozkazy. Aby tworzyła wydajny kod, powinna wyszukiwać i eliminować stałe oraz wykonywać pewne inne działania optymalizacyjne. W naszym pobieżnym przeglądzie technik generowania kodu niektóre zagadnienia poka­ zaliśmy tylko w zarysie, a wiele pominęliśmy całkowicie. Pominęliśmy też złożone kwestie do­ tyczące programowania nowoczesnych procesorów. Ale na tym przykładzie udało nam się po­ kazać, jak program może przeanalizować opis problemu w celu utworzenia specjalnego kodu do jego rozwiązania w wydajny sposób. Korzystając z tej wiedzy, możesz utworzyć niezwykle szybką implementację programu grep, zaimplementować mały język, zaprojektować i zbudo­ wać wirtualną maszynę przeznaczoną do wykonywania specjalnych obliczeń, a nawet z odrobiną pomocy napisać kompilator dla jakiegoś interesującego języka. Wyrażenia regularne mają niewiele wspólnego z językiem C+ +, lecz zarówno wyrażenia, jak i język są notacją służącą do rozwiązywania problemów. Dzięki odpowiedniej notacji roz­ wiązanie wielu problemów jest znacznie łatwiejsze. A projektowanie i implementowanie notacji może dostarczyć nam sporo rozrywki.

Ćwiczenie 9.18. Kompilator działający w locie generowałby szybszy kod, gdyby w miejsce wy­ rażeń zawierających tylko stałe, np. max (3*3 , 4/2 ) , wstawiał gotowe wartości. Jak kompilator powinien obliczyć takie wyrażenie po rozpoznaniu go? Ćwiczenie 9.19. Jak przetestujesz kompilator działający w locie?

Lektura uzupełniająca Książka The Unix Programming Environment Briana Kernighana i Raba Pike'a (Prentice Hall, 1984) zawiera bardziej szczegółowe omówienie technik programowania w systemie Unix przy użyciu różnych narzędzi. W rozdziale 8. tej książki przedstawiona jest kompletna implementa­ cja prostego języka programowania, od gramatyki yacc po kod wykonywalny. W książce TEX. The Program (Addison-Wesley, 1986) Donald Knuth opisuje skompliko­ wany forrnater dokumentów, przedstawiając cały program składający się z około 13 tysięcy wierszy kodu w języku Pascal. Kod ten został napisany z zastosowaniem metody „programo­ wania piśmiennego", stylu polegającego na złączeniu w jedno dokumentacji i kodu źródłowego

LEKTURA UZUPEŁNIAJĄCA

25 1

oraz użyciu programów do formatowania dokumentacji i wyodrębniania kodu przeznaczonego do kompilacji. W książce A Retargetable C Compiler. Design and Implementation Chrisa Frasera i Davida Hansona (Addison-Wesley, 1995) znajdziemy podobny opis dla kompilatora języka ANSI C. Opis maszyny wirtualnej Javy można znaleźć w książce The Java Virtual Machine Specifica­ tion. Second Edition autorstwa Tima Lindholma i Franka Yellina (Addison-Wesley, 1999). Algorytm Kena Thompsona (jeden z pierwszych patentów na oprogramowanie) został opi­ sany w artykule Regular Expression Search Algorithm, który ukazał się w magazynie „Communi­ cations of the ACM" 1968, R. Il, nr 6, s. 419 - 422. Szczegółowe omówienie wyrażeń regular­ nych można znaleźć w książce pt. Mastering Regular Expressions, której autorem jest Jeffrey E.F. Friedl (O'Reilly, 1997). Kompilator działający w locie dla operacji grafiki dwuwymiarowej jest opisany w artykule autorstwa Roba Pike'a, Barta Locanthiego i Johna Reisera pt. Hardware/Software Tradeoffs for Bitmap Graphics on the Blit, który ukazał się w magazynie „Software - Practice and Experience" 1985, R. 15 nr 2, s. 1 3 1 - 1 52.

252

9. NOTACJA

Epilog

Gdyby ludzie mogli UCZYĆ się o d historii, t o czegóż ona by

nas

nie naucZYla!

Ale namiętności i towarZYstwo oślepiają nas, przez co wiedza, którą zdobywamy dzięki doświadczeniu, jest jak lampa na rufie oświetlająca fale pozostające za nami.

Samuel Taylor Coleridge, Recollections

Świat komputerów stale się powiększa, a tempo tej ekspansji wydaje się rosnąć. Programiści muszą sobie radzić z coraz to nowszymi językami, narzędziami, systemami i oczywiście zmia­ nami burzącymi zgodność starszych wersji z nowymi. Programy są coraz większe, interfejsy coraz bardziej skomplikowane, a terminy coraz krótsze. Niektóre rzeczy są jednak niezmienne, istnieją pewne stabilne punkty, w których nauki i wnioski wyciągnięte z przeszłości mogą pomóc w przyszłości. Tematy omawiane w tej książce są oparte na takich niezmiennych koncepcjach.

Prostota i klarowność są pierwsze i najważniejsze, ponieważ prawie wszystko się na nich opie­ ra. Zrób najprostszą działającą rzecz. Wybierz najprostszy algorytm, który powinien działać wystarczająco szybko, i najprostszą strukturę danych, która wystarczy do wykonania zadania. Połącz je za pomocą czystego i klarownego kodu. Nie komplikuj ich niepotrzebnie, chyba że z pomiarów wydajności wyniknie, iż konieczne są poprawki. Jeśli nie ma dobrych powodów, aby to zmieniać, interfejsy powinny być minimalne i skromne.

Ogólność często idzie w parze z prostotą, ponieważ może umożliwić rozwiązanie problemu raz na zawsze zamiast powtarzania tych samych czynności w nieskończoność dla każdego przy­ padku. Jest to też często właściwe podejście, jeśli chce się napisać przenośny kod: znajdź jedno ogólne rozwiązanie, które działa w każdym systemie, zamiast potęgować różnice między systemami. Rozwój to kolejna ważna kwestia. Niemożliwe jest utworzenie idealnego programu już w pierw­ szym podejściu. Gruntowną wiedzę potrzebną do znalezienia prawidłowego rozwiązania można zdobyć tylko poprzez przemyślenia i doświadczenia. Ani sama dogłębna analiza, ani żadne sztuczki nie wystarczą. Najbardziej efektywny sposób pracy to utworzenie prototypu, ekspery­ mentowanie, skorzystanie z komentarzy użytkowników oraz dalsze udoskonalanie. Programy, które tworzymy na własny uŻytek, zwykle są za mało rozwinięte. Duże programy, kupowane od kogoś innego, często zbyt szybko się zmieniają, niekoniecznie na lepsze.

254

EPILOG

Interfejsy stanowią dużą część dziedziny programowania, a więc kwestie z nimi związane po­ jawiają się w wielu miejscach. Najbardziej oczywiste przypadki znajdują się w bibliotekach, ale interfejsy można spotkać także między programami oraz między programami a użytkownika­ mi. Zasady dotyczące prostoty i ogólności mają szczególne zastosowanie w projektowaniu in­ terfejsów. Twórz spójne interfejsy, których obsługi łatwo można się nauczyć. Ściśle się ich trzymaj. Abstrakcja to bardzo efektywna technika: wyobraź sobie idealny komponent, program albo perfekcyjną bibliotekę, utwórz interfejs jak najlepiej odpowiadający temu ideałowi, a na­ stępnie ukryj szczegóły implementacyjne poza interfejsem, aby nie szkodziły.

Automatyzacja jest niedoceniana. Można pracować o wiele wydajniej, jeśli do wykonywania różnych zadań zaprzęgnie się komputer. Pokazywaliśmy przykłady testowania, usuwania błę­ dów, analizowania wydajności i pisania kodu oraz programy mogące tworzyć programy, których napisanie ludziom sprawiałoby duże trudności. Notacja również jest niedoceniana, i to nie tylko jako sposób mówienia komputerom, co mają robić. Notacja organizuje ramy do implementacji wielu narzędzi oraz określa strukturę pro­ gramów, które piszą programy. Wszyscy dobrze posługujemy się dużymi językami ogólnego przeznaczenia, używanymi do wykonywania większości zadań. Lecz gdy otrzymujemy zadania tak skoncentrowane i dobrze poznane, że ich wykonywanie zdaje się wręcz mechaniczne, może to być czas na utworzenie notacji, która pozwoli naturalnie wyrazić te zadania i język używany do ich implementacji. Do naszych ulubionych przykładów należą wyrażenia regularne, ale ist­ nieje nieskończona liczba okazji do utworzenia małych języków służących do specjalnych za­ stosowań. Nie muszą one być wcale finezyjne, aby można było odnieść korzyści z ich używania. Jako programiści możemy łatwo ulec złudzeniu, że jesteśmy tylko małymi trybami w wielkiej maszynie, zmuszeni do używania języków, systemów i narzędzi, które nam narzucono, i wyko­ nywania zadań, które powinny być za nas wykonywane. Ale na dłuższą metę liczy się to, jak dobrze sobie radzimy, używając dostępnych nam środków. Przyjmując niektóre z koncepcji przedstawionych w tej książce, spostrzeżesz, że piszesz kod, z którym łatwiej się pracuje, Twoje sesje diagnostyczne są mniej skomplikowane oraz programujesz pewniej niż do tej pory. Mamy nadzieję, iż dzięki lekturze tej książki Twoja praca stanie się bardziej produktywna i przyjem­ niejsza.

Zebrane zasady

. . . używając każdej prawdy, jaką znalazłem, za prawidło, które mi służyło potem do znalezienia innych . . .

Rene Descartes, Rozprawa o metodzie (przeł. Boy, Warszawa, Gobethner i Wolff 192 1)

Treść niektórych rozdziałów można by streścić, formułując kilka zasad i wskazówek podsumo­ wujących ich treść. Wszystkie te zasady zebraliśmy w tym dodatku, aby można je było łatwo znaleźć. Pamiętaj, że każda z nich została przedstawiona w odpowiednim kontekście, w którym ma sens i jej stosowanie jest uzasadnione.

Styl Zmiennym globalnym nadawaj opisowe nazwy, a lokalnym - krótkie. Konsekwentnie trzymaj się jednego stylu. Używaj czasowników do nazywania funkcji. Bądź dokładny. Stosuj wcięcia, aby uwidocznić strukturę. Stosuj naturalną formę wyrażeń. Używaj nawiasów, aby nie pozostawiać niejednoznacznych przypadków. Skomplikowane wyrażenia dziel na mniejsze części. Pisz klarownie. Uważaj na efekty uboczne. Zawsze tak samo rozmieszczaj wcięcia i nawiasy. Używaj idiomów, aby utrzymać spójność tekstu programu. Do programowania instrukcji wielokrotnego wyboru używaj instrukcji i f-el se. Unikaj używania makr w roli funkcji. Treść i argumenty makr umieszczaj w nawiasach. Nadawaj nazwy magicznym liczbom. Liczby definiuj jako stałe, a nie makra. Używaj stałych znakowych, a nie liczb całkowitych. Rozmiar obiektów obliczaj za pomocą konstrukcji językowych. Nie roztrząsaj rzeczy oczywistych.

256

ZEBRANE ZASADY

Opisuj w komentarzach funkcje i dane globalne. Nie komentuj złego kodu, lecz go poprawiaj. Pisz komentarze zgodne z kodem, którego dotyczą. Objaśniaj, zamiast utrudniać zrozumienie.

Interfejsy Ukrywaj szczegóły implementacyjne. Wybierz niewielki ortogonalny zestaw operacji podstawowych. Nie działaj za plecami użytkownika. Daną czynność zawsze wykonuj tak samo. Zwalniaj zasoby na tym samym poziomie, na którym zostały zajęte. Wykrywaj błędy na niskim poziomie, a obsługuj je na wysokim. Używaj wyjątków tylko w szczególnych sytuacjach.

Debugowanie Szukaj znajomych znaków. Przeanalizuj ostatnią zmianę w programie. Nie popełniaj dwa razy tego samego błędu. Nie odkładaj poprawiania błędów na później. Sprawdź zawartość stosu wywołań. Najpierw przeczytaj, potem pisz. Objaśnij swój kod komuś innemu. Spraw, aby błąd dało się powtórzyć. Dziel i rządź. Przeanalizuj liczby związane z awariami. Pomóż sobie znaleźć miejsce usterki przez wyświetlenie dodatkowych danych. Pisz samosprawdzający się kod. Utwórz plik dziennika. Narysuj obrazek. Używaj narzędzi. Prowadź zapiski.

Testowanie Testuj warunki brzegowe kodu. Testuj warunki wstępne i końcowe. Używaj asercji. Programuj defensywnie. Sprawdzaj, czy funkcja nie zakończyła działania z powodu błędu. Testuj stopniowo. Najpierw testuj najprostsze części. Dowiedz się, jakich wyników należy się spodziewać. Sprawdzaj, czy właściwości zostały zachowane. Porównuj niezależne od siebie implementacje. Sprawdzaj stopień pokrycia kodu testami. Zautomatyzuj testowanie regresywne. Twórz samodzielne testy.

ZEBRANE ZASADY

Wydajność Zautomatyzuj proces mierzenia czasu wykonywania. Używaj programu profilującego. Skoncentruj się na gorących punktach. Narysuj obrazek. Użyj lepszego algorytmu lub lepszej struktury danych. Włącz opcje optymalizacji kodu w kompilatorze. Wyreguluj kod. Nie optymalizuj tego, co nie ma znaczenia. Gromadź wspólne podwyrażenia. Zastępuj czasochłonne operacje lżejszymi. Rozwijaj lub całkiem eliminuj pętle. Zapisuj w pamięci podręcznej często używane wartości. Napisz specjalną funkcję alokującą pamięć. Buforuj dane wejściowe i wyjściowe. Obsługuj specjalne przypadki osobno. Obliczaj wyniki wcześniej. Używaj wyników przybliżonych. Przepisz kod w języku niższego poziomu. Oszczędzaj pamięć, używając jak najmniejszych struktur danych. Nie przechowuj tego, co możesz łatwo obliczyć.

Przenośność Trzymaj się standardu. Używaj głównego nurtu języka. Wystrzegaj się kłopotliwych elementów języka. Wypróbuj kilka kompilatorów. Używaj standardowych bibliotek. Używaj tylko tych konstrukcji, które są dostępne wszędzie. Unikaj kompilacji warunkowej. Kod zależny od konkretnego systemu zapisz w osobnym pliku. Ukrywaj kod zależny od konkretnego systemu za interfejsem. Do wymiany danych używaj formatu tekstowego. Do wymiany danych używaj stałej kolejności bajtów. Zmień nazwę, jeśli zmieniasz specyfikację. Zachowaj zgodność z istniejącymi programami i danymi. Nie zakładaj, że używane znaki należą do zestawu ASCII. Nie zakładaj, że używany będzie język angielski.

257

258

ZEBRANE ZASADY

Skorowidz

Kobieta: Czy jest tu moja ciotka Minnie? Driftwood: Cóż, możesz wejść i poszukać, jeżeli chcesz. Jeśli jej tu nie ma, to zapewne możesz znaleźć kogoś równie dobrego.

Bracia Marx, Noc w operze

#define, 3 1

przyspieszanie, 1 8 1

#ifdef, 207

rola, 3 9

%f, 1 28

sortowania, 4 2 , 47

%lf, 1 28

tworzenia,

&, 1 7

łańcuchów elementów, 166

.length, 3 2

tekstu, 85

?, 12, 18

1.

usuwania nieużytków, 1 16

17

wybór, 68, 182

+ + , 19, 22

wymagania pamięciowe, 50

+ = , 109

wyszukiwania binarnego, 42

< = , 24 = = , 17

zakończenie, 77 złożoność,

0, 3 1

oczekiwana, 50 pesymistyczna, 50

A abstrakcja, 1 12, 208

alokacja, 1 16 pamięci, 24, 166, 186, 192 analiza

addfront, 55

projektu, 8

aktualizacja komentarza, 35

składniowa drzewa, 63

algorytm, 8, 193 czas dzialania, 50 dane wejściowe, 44 jasny, 86 Markowa, 70, 72, 79, 90 test, 168

ANSI, 202

c, 46, 53, 202, 204 standard, 24 API, 1 13, 204 application programming interface, 1 13 argumenty makra, 29

podstawowy, 39, 83

Ariane 5 , 165

porównywanie czasu działania, 50

arytmetyczne

przeszukiwania,

przesunięcie, 200

binarnego, 4 1

asembler, 188

sekwencyjnego, 40

asercja, 150

260

SKOROWIDZ

asocjacyjna

usuwanie, 1 25, 147 uważne przeczytanie kodu, 1 3 1

tablica, 86

wykres, 134

associative array, 86 atexit, 1 16

wykrywanie, 9

automatyzacja, 7, 254

wymuszanie powtarzalności, 1 3 1 zasada obsługi, 1 1 9

testów, 157 Awk, 9, 86, 87, 90, 158, 180, 193, 235, 237, 245

znajdowanie, 1 47 znany, 144

B backwards compatibility, 2 1 5 bajty kolejność, 201 porządek, 2 1 1 balanced tree, 6 1 B-drzewo, 63 Beta wersja, 168 bezwzględna wartość, 49 biala skrzynka, 167 biblioteka, 202 big-endian, 2 1 8

boundary condition resting, 148 Bourne, 166 break, 27 Brooks, 69, 95 bsearch, 46 bucket, 64 bufor błąd przepełnienia, 164 danych, wejściowych, 187 wyjściowych, 187 rozmiar, 76 bug, 125 build, 76

binarne

c

przeszukiwanie, 46 drzewo poszukiwań, 59, 60 bitowy operator, 1 7 pole, 201 błąd asercja, 150 błędne przekonanie, 136 cechy usterki, 13 2 diagnostyka, 12 7

C, 9, 10, 1 7, 19, 22, 24, 27, 28, 3 1 , 3 2 , 40, 44, 48, 53, 54, 64, 66, 73, 8 1 , 83, 89, 96, 103, 107, 1 14, 1 16, 121, 134, 139, 160, 1 7 7 , 182, 184, 188, 189, 1 9 1 , 196, 1 9 7 , 199, 201, 202, 203, 2 1 3 , 2 1 7 , 23 1 , 243 wada, 79 zaleta, 79

c + + , 9, 14, 1 7 , 19, 22, 24, 21, 28, 29, 3 1 , 32, 40, 44, 47, 5 1 , 53, 54, 59, 64, 66, 83, 89, 108, 1 10, 1 1 1 ,

dodanie instrukcji wyświetlających informacje, 132

1 13, 1 15, 1 16, 134, 139, 160, 163, 177, 182, 184, 188,

dziennik, 134

189, 1 9 1 , 196, 198, 199, 201, 202, 2 1 3 , 2 1 7 , 243

informacja, 1 5 1

case, 26

innych programistów, 143

cel testowania, 167

kompilatora, 143

cerr, 134

komunikat, 1 18

Chain, 80

minimalny zestaw danych wejściowych, 132

char, 200

na żądanie, 1 3 1

char **array, 40

nieregularny, 1 3 8

dock, 1 7 7

nowy, 1 2 9

Cohen, 2 1 8

obsługa, 9 9 , 1 0 1 , 1 1 7

comma-separated values, 94

p o zmianie, 1 2 9

Comparable, 47

porównywanie plików, 135

const, 3 1

powielenie, 129

cost model, 1 9 1

przepełnienia bufora, 164

cross-referencer, 143

roku 2000, 188

csv, 94, 95, 96, 108, 1 1 2

rozmowa z pluszowym misiem, 1 3 1

csvgetline, 96

rzeczywiste działanie programu, 13 7

ctime, 36, 153

składni, 2 1

ctype, 28

skutki lekceważenia, 130

cydic redundancy check, 67

sprzętu, 138

cykliczna kontrola nadmiarowa, 67

strumień, 134

czarna skrzynka, 167

u jednej osoby, 140

26 1

SKOROWIDZ

czas

do-while, 23

działania algorytmu, 50

drukowanie elementów listy, 56

mierzenie, 172, 177

drzewo, 59

pracy procesora, 178

analiza składniowa, 63

użycia procesora, 1 77

korzeń, 59

wykonywania programu, 177

niezrównoważone, 6 1

czytelne formatowanie, 16

poszukiwań binarne, 59, 60 przeglądanie poprzeczne, 62

D dane, 64, 155 globalne, 34 na wyjściu, 155

najmniejszy typ, 189 oznaczanie końca, 77

zrównoważone, 6 1 dublowanie elementów, 6 1 dwuznaczności unikanie, 1 6 dzieci węzeł, 60 dzielenie, 59 dziennik błąd, 134

statyczne, 54 struktura, 8, 39, 59

E

szkodliwe, 164

typ źle dobrany, 128

efekty uboczne, 1 9

wejściowe, 18 7

efektywność wykorzystania pamięci, 190

wybór struktur, 89

elastyczność, 108

wyjściowe, 187

element

wymiana, 209, 212

dostęp swobodny, 59

Date, 1 78

dublowanie, 61

debugging, 125

grupowanie, 16

debugowanie, 126, 256

liczenie, 57

decyzje

o zmiennym rozmiarze, 59

wielokierunkowe, 25 defensive programming, 1 22 defensywne programowanie, 122, 1 5 1 definicja,

powiązany, 14, 64 przesuwanie, 53 wstawianie, 59 ełse, 25, 26

pakietów, 202

else-if, 25, 26

pola, 99

Ellis, 89

dekrementacja, 1 9

endian, 218

deque, 84

endprintf, 1 1 7

design pattems, 9 1

enum, 3 1

deskryptywna

EOF, 200

nazwa, 13

estrdup, 1 1 8

destruktor, 1 16

ewaluacja, 1 9, 29

diagnostyka

exception, 1 20

błędów, 127 instrukcji, 127

F

kodu, 9 programu, 126, 140 diff, 135 Dijkstra, 147 długość słów, 85 dobry

fall-through, 26 fclose, 1 5 1 fflush, 134 fgets, 24, 148 filtr spamu, 176

inteńejs, 1 12

fina!, 3 1

kod, 37

find , 40

technika sortowania, 63

Flandren, 194

zestaw testów, 161

float, 187

·

domyślny rozmiar tablicy, 7 3

flush, 134

doświadczenia, 253

flushcaches, 249

double, 187

fopen, 1 5 1 for, 22, 23

262

SKOROWIDZ

format

I

CSV, 94, 95, 96 pętla, 22

IBM 7094, 248

formatowanie

idealny komentarz, 33

czytelne, 16

idiom, 22, 24 idiomatyczny kod, 3 6

wyrażenia, 16

if, 2 0 , 2 1 , 2 5

fprintf, 1 5 1 fragment niejasny, 1 1

if... else, 1 9 , 2 5

fread, 1 5 1

implementacja, niezależne wyniki, 156

free, 192

programu, 8

funkcja

indeksowania operator, 85

generująca, 8 1

indexOf, 40

komentarz, 34

Inferno, 187

logiczna, 14

informacja

łańcuchowa, 1 14 mieszająca, 64, 67, 74, 75 nazwa, 13, 14

o błędzie, 151 ukrywanie, 99, 100, 1 1 2 inicjalizacja, 1 14

sortująca, 44

statyczna, 1 1 5

fwrite, 1 5 1

tablica, 167

G

zmienna, 167 inkrementacja, 16, 19 in-order traversal, 62

garbage collection, 1 16

insert, 62

generate, 242

instrukcja, 16

generator

diagnostyczna, 127

liczb losowych, 49

sprawdzająca, 26

odsyłaczy, 143

lnteger, 48

tekstu, 77

interaktywnego programu test, 168

getchar, 23, 28

interfejs, 8, 47, 96, 99, 1 1 2, 208, 254, 256

gets, 24, 164

CSV, 1 1 2

getTime, 1 7 8

d o tablic rozproszonych, 64

GIF, 190

dobry, 1 1 2

globalne

duży, 1 13

dane, 34

łatwy w użyciu, 123

optymalizator, 182

poprawny, 150

zmiennne, 1 1 2

programistyczny, 1 13

glowa, 54

publiczny, 80, 108

główny nurt języka, 197

użytkownika, 9, 1 2 1

gorący punkt, 178, 184, 186

zasady tworzenia, 1 1 2 zwięzły, 1 13

graficzne operacje, 188 gramatyka, 238

internacjonalizacja, 2 1 6

granice tabeli, 166

internationalization, 2 1 6

grep, 143, 1 72, 229, 234

internetowy robak, 165

grupowanie elementów, 16

interpreter, 23 7

H

poleceń, 234 isspam, 179 isupper, 28

Hashtable, 79, 83

J

head, 54 hermetyzacja, 1 1 2 hierarchiczna struktura danych, 59 Hoare, 42, 47

jasny algorytm, 86 Java, 9, 14, 1 7, 22, 24, 27, 28, 3 1 , 40, 47, 48, 5 1 , 54, 58, 64, 79, 83, 89, 1 13 , 1 15, 1 1 6, 1 2 1 , 134, 178, 188, 199, 213 Java Virtual Machine, 242 jednokierunkowa lista, 54

263

SKOROWIDZ jednolitość, 1 23

funkcja, 34

język

idealny, 33

mały, 222

niejasny, 3 7

niskiego poziomu, 9, 188 nurt główny, 197

kompilacja na czas, 247

programowania, 9

w locie, 247

skryptowy, 236

warunkowa, 205

standard, 196

kompilator, 166, 182, 184, 195, 197, 243, 250

wybór, 221

błąd, 143

wysokiego poziomu, 9

optymalizacji kodu, 182

JIT, 247

testowanie, 155, 201

just in time compilation, 247

komputer zasady korzystania, 7

JVM, 242

komunikat, 2 1 7 o błędzie, 1 18

K klamry, 27 klarowność, 26, 253 klasa, 201 globalna, 13 kontenerowa, 79 klucze, 64 Knuth, 167, 1 78, 194 kod diagnostyka, 9

konflikt nazw, 1 1 3 konsrruktor, 1 15 , 1 1 6 kontener, 83 konwencje, 1 2 konwersji współczynnik, 29 końcowy warunek, 149 kopiowanie, 59, 1 14 korzeń drzewa, 59 kosztów model, 1 9 1 krotka, 1 2 0 kubełek, 64

dobry, 3 7 generowanie za pomocą makr, 246

L

idiomatyczny, 36 klarowny, 19, 36

last-in-first-out, 59

łatwość czytania, 12

liczba, 29, 3 1

nizany, 240

0, 3 1

optymalizacja, 182

całkowita, 45, 191

pokrycie testami, 156

double, 128

przejrzysty, 18

losowa, 49

regulacja, 183

zmiennoprzecinkowa, 191

samosprawdzający, 133

liczenie elementów, 5 7

spójny, 12

licznik odniesień, 1 1 6

sprytny, 18

LIFO, 59

struktura, 1 6 uwypuklenie, 2 0

liniowe przeszukiwanie, 40 lista, 54, 83

testowanie w czasie pisania, 151

drukowanie elementów, 56

wolny od błędów, 147

jednokierunkowa, 54

wyższej jakości, 151

modyfikacja, 55

zależny od maszyny, 188

pamięć wolna, 186

zwięzły, 19, 86

tworzenie, 55

źródłowy, 12

usuwanie, 5 7 , 58

Koenig, 245

liść, 6 1

kolejka, 14

literate programming, 245

dwukierunkowa, 84 kolejność, bajtów, 201 wykonywania obliczeń, 199 kolizja, 67 komentarz, 33, 34 aktualizacja, 35 cel stosowania, 3 7

little languages, 222

Iocali ty, 186

Locanthi, 246 logiczne przesunięcie, 200 lokalności zasada, 186 lookup, 62 losowa liczba, 49

264

SKOROWIDZ

Ł

funkcja, 14 logiczna, 14 klasa globalna, 1 3

łańcuch algorytm tworzenia, 166

konflikt, 1 1 3

nazwa, 13

łańcuch, 1 3

Markowa , 70, 79

niespójna, 14 prywatna, 1 13

łańcuchowa funkcja, 1 14 łatwy w użyciu interfejs, 123

stała, 1 3 struktura globalna, 1 3

M

wskaźnik, 1 3 zmienna, globalna, 1 3

mainstream, 197

lokalna, 13

makro, 28, 31, 32

pętlowa, 13

argumenty, 29 generowanie kodu, 246 problem, 28

negacja, 35 new, 129 niedorzeczne wartości, 1 28

malloc, 24, 129, 192

niejasny

małe języki, 222

fragment, 1 1

map, 79, 84, 85

komentarz, 3 7

markov, 70, 9 1 , 163, 1 70

niepoprawne dane wejściowe, 122

maszyna,

nieprzezroczysty typ, 1 1 2

stosowa, 240

niesłychanie duża wartość, 128

wirtualna, 237

niespójna nazwa, 14

Math.abs, 49 mechanizm wyjątków, 120 memcmp, 1 79, 183

nietypowe sytuacje, 120 niezależne implementacje, 156 niezamykanie plików, 138

memcopy, 53

niezrównoważone drzewo, 61

memcpy, 1 13

niskopoziomowy język, 9

memmove, 53, 1 13, 188

nizany kod, 240

memset, 1 6 1 , 188

not a number, 120

metacharacters, 228

notacja, 22 1 , 254

metaznaki, 228 Microsoft Visual C+ + 5.0, 163 mierzenie czasu, 1 72, 1 7 7

0, 50 programowanie, 9 nowy węzeł, 6 1

mieszająca funkcja, 74

null, 3 2

Mitchell, 89

numerycznego programu test, 1 5 5

mocy zmniejszenie, 184

nurt główny języka, 1 9 7

model,

nvcmp, 4 6

kosztów, 191 statystyczny tekstu, 70 Modula-3, 243

o

modularyzacja, 1 1 2 obciążeniowe testy, 9

N nadmiarowa kontrola cykliczna, 67

obiektu rozmiar, 3 2 Object, 4 7 , 48 obliczenia

najmniejsze typy danych, 189

kolejność wykonywania, 199

najprostsza struktura danych, 53

zawczasu, 187

najwspanialsze osiągnięcie informatyki, 64 Nameval, 5 1

obsługa blędów, 99, 101, 1 1 7 zasada, 1 1 9

NaN, 1 20

oczekiwana złożoność algorytmu, 50

nawiasy, 1 6

odsyłaczy generator, 143

klamrowe, 20 nazwa, 13 deskryptywna, 1 3 elementy powiązane, 1 4

odzyskiwanie zasobów, 1 16 ogonowa rekurencja, 62 ogólność, 253 programowania, 7

265

SKOROWIDZ

on the f!y compilation, 24 7 0-notation, 50

pomiary, 193 wykonywanie, 172

operacja

poprawa wydajności, 17 5

graficzna, 188

poprawność interfejsu, 150

wejścia, 19

porównywanie

czasu działania algorytmów, 5 O

wyjścia, 19

liczb całkowitych, 45

operator, 16 bitowy, 17

portability, 195

indeksowania, 85

Portable Operating System Interface, 2 1 8

logiczny, 1 7

porządek bajtów, 2 1 1

priorytet, 17

POSIX, 204, 2 1 8

przeciążanie, 189

post-order traversal, 63

przypisania, 17

PostScript, 245

relacji, 17, 24

potok, 249

opóźnienia w dostarczaniu poczty, 1 72

potomek, 60, 61

optymalizacja, 184, 193

powiązane elementy, 64

gospodarowania pamięcią, 189

pozycja znaku, 29

kodu kompilatora, 182

PPM, 190

wykorzystania zasobów, 9

praktyka programowania, 7, 1 2

zasada, 1 7 1

Prefix, 8 1 , 82

optymalizator globalny, 1 8 2

pre-order traversal, 63

oszczędzanie pamięci, 190

printf, 97, 128, 222

oznaczanie końca danych, 77

priorytetu operator, 17 problemu rozmiar, 50

p pair, 120 pakietów definicja, 202 pamięć, 1 14 alokowanie, 24, 166, 186, 192 efektywność wykorzystania, 190 optymalne gospodarowanie, 189 oszczędzanie, 190 podręczna, 186 wolna, 186 wyciek, 138 zwalnianie, 192 Pathfinder, 130 Perl, 9, 86, 87, 90, 237 pesymistyczna złożoność algorytmu, 50 pętla, 16, 2 1 , 22, 23, 24, 148 eliminacja, 185 format, 22 pierwsze wystąpienie znaku, 40 pisanie kodu, 1 5 1 piśmienne programowanie, 245 plik dziennika, 134 nagłówkowy, 202 niezamykanie, 138 poczty opóźnienia w dostarczaniu, 172 podręczna pamięć, 186 podstawowe algorytmy, 39, 83 pole bitowe, 201 definicja, 99

procedura przeszukująca, 40 procesor, 195 prof, 178 profil, 172, 1 73 , 178 program diagnostyczny, 126, 140 wady, 127 zalety, 1 26 do powszechnego użytku, 90 generujący tekst, 69 graficzny, 155 implementacja, 8 interaktywny, 168 jak napisać, 12 numeryczny, 155 odporny na niepoprawne dane wejściowe, 122 pisze programy, 242 profilujący, 172, 173, 178 prototyp, 98 przekazanie do użytku, 166 przenośny, 9, 195 przyspieszanie działania, 183 rzeczywiste działanie, 13 7 spowolnienie, 189 struktura, 143 włamanie, 164 wydajność, 88, 188 złożoność obliczeniowa, 181 programowanie defensywne, 122, 1 5 1 notacja, 9 ogólność, 7

266

SKOROWIDZ

programowanie

R

piśmienne, 245 praktyka, 7, 1 2

rama testowa, 154, 159, 162, 193

prostota, 7

rand, 49

przejrzystość, 7

RCS, 135

styl, 8, 38

real, 177 realloc, 1 29

zasady, 1 2 projektu analiza, 8

reduction in strength, 184

prostota programowania, 7, 253

reentrant, 1 16 reference count, 1 16

prototyp, 197

referencja, 1 1 5

programu, 98

regression testing, 157

prywatna nazwa, 1 13 przechowywanie elementów o zmiennym rozmiarze, 59 przeciążanie operatorów, 189 przeglądanie

regresywne testowanie, 157, 180, 184 regulacja kodu, 183 regular expressions, 228 regularne wyrażenia, 228

poprzeczne, 62

rekurencja, 4 7

wsteczne, 63

ogonowa, 62

wzdlużne, 63

relacji operator, 1 7 , 24

przejrzystość, 1 3

reputacji utrata, 143

programowanie, 7 przekazanie programu do użytku, 166 przenośność programów, 9, 142, 195, 2 1 4, 257 przepełnienie, 46

rgen, 49 robak internetowy, 165 rozmiar bufora, 76

bufora, 164

obiektu, 32

przesunięcie

problemu, 50

arytmetyczne, 200

tablicy, 29, 33, 66, 104

elementu, 53

typów danych, 198

logiczne, 200

rozszerzalna tablica, 51

przeszukiwanie

rozwój, 253

binarne, 4 1 , 46

rzutowanie, 53

liniowe, 40 procedura, 40

s

sekwencyjne, 40 tablicy, 154

samodzielne testy, 158

tekstu, 143 przydzielanie pamięci, 1 14 przypisanie, 1 6

samosprawdzający się kod, 133 scalanie, 59 scanf, 96, 1 28, 1 5 1

operator, 1 7 wstawianie do warunku pętli, 23 przyspieszanie

scmp, 45 sekwencyjne wyszukiwanie, 40 sentinel, 7 7

algorytmu, 181 działania programu, 174, 183 struktury danych, 181 publiczny interfejs, 80, 108 pułapki językowe, 198

shaney, 9 1 sizeof, 32 składni błędy, 21 skrócenie czasu usuwania usterek, 125 skrypt testowy, 158

punkt gorący, 184, 186

skryptowy język, 236

putchar, 23

słowa, 73, 85 słownik, 84, 87

Q qsort, 44, 45, 46

struktura danych, 79 sort, 47, 49 sortowanie

queue, 14

algorytm, 42, 47

quicksort, 42, 49

dobra technika, 63 funkcja, 44 szybkie, 42 tablic łańcuchów, 45

267

SKOROWIDZ

spam, 1 7 2 filtr, 1 76 specyfikacja, 101 zawartość, 1 O 1 split, 1 0 3 , 105, 109 sposoby doboru testów, 154 spójność, 20, 22, 1 1 4 kodu, 1 2 zewnętrzna, 1 14

symbole, tablica, 64 wieloznaczne, 228 SYS, 1 7 7 system zależności, 208 operacyjny, 195 System.err, 134 systematyczne testowanie niewielkich przypadków, 154

sprzętu bląd, 138

sytuacje nietypowe, 120

stała, 19, 3 1

szkodliwe dane wejściowe, 164

całkowitoliczbowa, 3 1

szybkie sortowanie, 42

nazwa, 13 znakowa, 3 1

T

stanu utrzymywanie, 1 1 4 standard, 197, 202 ANSI C, 24, 202, 222, 225 ANSI/ISO języka C, 196 ISO języka C + +, 196 języka, 196 Standard Template Library, 83 State, 73 statyczna inicjalizacja, 1 1 5 statyczne dane, 54 stderr, 134 stdout, 1 1 3 STL, 59, 8 3 , 90, 120, 163 stos, 59, 186 wywołań, 126, 130 strchr, 40, 179 strcmp, 36, 45 strcpy, 24 strdup, 24 StreamTokenizer, 80 strerror, 1 20 String, 40, 48 strings, 140 strlen, 24, 1 7 9 strncmp, 1 79 stronicowanie, 189 strstr, 40, 173, 176, 179 strtok, 96, 105, 1 1 3 struktura danych, 8, 39, 201 najprostsza, 53 słownik, 79 globalna nazwa, 13 kodu, 16 programu, 143 strumienie błędów, 134 styl, 1 2, 255 funkcja, 12 programowania, 8, 38 swap, 49 Swift, 218 swobodny dostęp do elementów, 59

tabela granice, 166 tablica, 40, 53 asocjacyjna, 86 domyślny rozmiar, 7 3 inicjalizacja, 167 lańcuchów, 45 mieszająca, 5 1 , 64, 80 funkcja tworząca, 7 5 przeszukanie, 154 rozmiar, 29, 33, 66, 104 rozproszona, 64 rozszerzalna, 5 1 słowa, 73 symboli, 64 znaków, 108 tai! recursion, 62 Tcl(Tk, 9 technika usuwania błędów, 1 25 tekst algorytm tworzenia, 85 generowanie, 77 model statystyczny, 70 przeszukiwanie, 143 test, 9, 147, 153, 193, 256 algorytm Markowa, 168 automatyzacja, 157 białej skrzynki, 167 cel, 167 czarnej skrzynki, 167 dobry zestaw, 161 duża ilości danych, 163 kompilator, 155 obciążeniowy, 9 pokrycia kodu, 156 programu, graficznego, 155 interaktywnego, 168 numerycznego, 155 przeciążeniowy, 163 rama, 154, 159, 162

268

SKOROWIDZ

test

w

regresywny, 157, 180, 184 samodzielny, 158

wartości

sposoby doboru, 154

bezwzględne, 49

stopniowy, 153

brzegowych testowanie, 9

systematyczny, 153

niedorzeczne, 128

testu, 168

niesłychanie duże, 128

ustawienia parametrów wejściowych, 167

oddzielane przecinkami, 94

w czasie pisania kodu, 1 5 1

początkowych ustawianie, 1 15

wartości brzegowych, 9 , 148 rozszerzenie metody, 154 wzorcowy, 194

zmiennej modyfikacja, 19 wartownik, 77 warunek, 25

zautomatyzowanie, 154

brzegowy, 148

zestaw, 153, 167, 174

końcowy, 149

TEX, 1 67

pętli, 23

Thompson, 194, 248

wstępny, 149

threaded code, 240

warunkowa,

time, 1 7 7

kompilacja, 205

tupie, 120

wyrażenie, 19

tworzenie listy, 5 5

wcięcia, 16, 20, 21

typ danych

wczytywanie liczb typu double, 128

najmniejszych, 189

wejście, 19

nieprzezroczysty, 1 12

wektor, 83

rozmiar, 198

weprintf, 61, 1 1 7

źle dobrany, 128

wersja beta, 168 węzeł

u ukrywanie informacji, 99, 100, 1 1 2 unia, 201 unikanie dwuznaczność, 1 6 unquote, 9 6

wielowejściowy program, 1 1 6 wiszący wskaźnik, 139 włamanie do programu, 164 właściwości danych wejściowych, 155

unsigned char, 66 ustawianie wartości początkowych, 1 1 5 usterki czas usuwania, 1 25 usuwanie

wprintf, 203 wskaźnik brakującego potomka, 60 nazwy, 13

błędów, 147

wiszący, 13 9

listy, 57, 58

współczynnik konwersji, 29

usterek, 125

współdzielenie, 1 14

UTF-8, 2 1 7

wstawianie elementu, 59

utrata reputacji, 143

wsteczna zgodność, 2 1 5

utrzymywanie stanu, 1 14 użytkownika interfejs, 9, 1 2 1

V

void*, 44, 53

wielokierunkowe decyzje, 25 wildcards, 228

Unicode, 216

Vector, 79, 83, 84, 108

nowy, 6 1 while, 23, 26

uboczne efekty, 1 9

Visual Basic, 9, 243

dzieci, 60

wstępny warunek, 149 wybór algorytmu, 68, 182 języka, 9, 221 struktur danych, 89 wycieki pamięci, 138 wydajność, 1 7 1 , 257 analiza graficzna, 180 poprawa, 1 7 5 program, 88, 188 wyjątek, 1 20 wyjście, 1 9

269

SKOROWIDZ

wykładnicza złożoność obliczeniowa, 5 1 wykonywanie pomiarów, 172 wykorzystania zasobów optymalizacja, 9

zasoby odzyskiwanie, 1 16

zarządzanie, 58, 99, 1 OO, 1 14

wykres błędów, 134

zautomatyzowanie testowania, 154

wykrywanie błędów, 9

zbiór, 83

wymagania pamięciowe algorytmu, 50

klas kontenerowych, 79

wymiana danych, 209, 2 1 2

zero, 31

wyniki niezależnych implementacji, 156

zestaw

wyrażenia, 16

testów, 153, 167, 174

formatowanie, 16

maków, 2 1 6

regularne, 228

zewnętrzna spójność, 1 14

skomplikowane, 17

zgodność wsteczna, 2 1 5

warunkowe, 19

złożoność obliczeniowa, 5 0 , 5 6 , 181

wysokiego poziomu język, 9 wyszukiwanie

wykładnicza, 51 zmienna, 103

binarne, 42

globalna, 13, 1 1 2

sekwencyjne, 40

inicjalizacja, 167

wywołanie

lokalna, 13

stos, 126, 130

modyfikacja wartości, 19

wzorzec projektowy, 91

nazwa, 13 pętlowa, 13

y

wewnętrzna, 103 zmniejszenie mocy, 184 znak

Yorktown, 150, 1 5 1

pierwsze wystąpienie, 40

z zależności systemowe, 208 zarządzanie zasobami, 58, 99, 100, 1 14 zasada korzystania z komputera, 7 lokalności, 186 obsługi błędów, 1 1 9 optymalizacji, 1 7 1 programowania, 12

pozycja, 29 tablica, 108 zapytania, 12 zestaw, 216 zrównoważone drzewo, 61 zwalnianie pamieci, 1 14, 192 zwiększenie wydajności programu, 188 zwięzłość, 13 kodu, 86

KANON INFORMATYKI

Jeśli tak, w przyszłości na pewno chciałbyś tego uniknąć! Takie problemy dla zbyt wielu r>rogramistów są niestety chlebem powszednim. Dzieje się tak między innymi dlatego, że testowanie, diagnostyka, przenośność, wydajnośc czy styl programowania są często traktowane po macoszemu przez osoby tworzące oprogramowanie. A świat rządzony przez olbrzymie interfejsy, wciąż zmieniające się narzędzia, języki czy systemy nie sprzyja podstawowym zasadom tworzenia

dobrego kodu - prostocie,

ogólności i przejrzystości.

Programowanie to coś więcej

niż samo pisanie

kodu.

W książce .Lekcja programowania. Najlepsze praktyki" znaj­ dziesz opis wszystkich zagadnień, z którymi styka się pro­ gramista - od projektowania, poprzez usuwanie usterek, testowanie kodu czy poprawę jego wydajności, po proble­ my związane z poprawianiem oprogramowania napisanego przez innych. Wszystko zostało oparte na zaczerpniętych z realnych projektów przykładach, napisanych w językach C, C++, Java i innych.

Brian

W.

Kernighan

i

Rob Pike

pracują w Computing

Science Research Center w Bell Laboratories, Lucent Tech­ nologies. Brian Kernighan pracuje także dla wydawnictwa Addison-Wesley jako konsultant serii książek .Professional Computing"; napisał też wraz z Dennisem Ritchie książkę Język ANSI C".

Rob Pike

jest głównym architektem i programistą syste­

mów operacyjnych Plan 9 oraz Inferno. W swojej pracy

badawczej interesuje się tworzeniem oprogramowania, które pomaga ludziom pisać ich własne programy.

Iii � Księgarnia internetowa: � http ://hel ion .pl

Helion

f) http://helion.pl/promocje Książki najctiętniej czytane: f) http://hellon.pl/bestsellery f) http://helion.pl/nowosci