IDZ DO
IDZ DO
PRZYKŁADOWY ROZDZIAŁ
PRZYKŁADOWY ROZDZIAŁ
STL w praktyce. 50 sposobów
SPIS TRE CI
SPIS TRE CI
efektywnego wykorzystania
KATALOG KSIĄŻEK
KATALOG KSIĄŻEK
Autor: Scott Meyers
Tłumaczenie: Adam Majczak (rozdz. 1-5),
KATALOG ONLINE
KATALOG ONLINE
Wojciech Moch (rozdz. 6, 7, dod. A-C)
ISBN: 83-7361-373-0
Tytuł oryginału: Effective STL 50 Specific Ways
ZAMÓW DRUKOWANY KATALOG
ZAMÓW DRUKOWANY KATALOG
to Improve Your Use of the Standard Template Library
Format: B5, stron: 282
TWÓJ KOSZYK
TWÓJ KOSZYK
Standard Template Library to jedno z najpotężniejszych narzędzi programistycznych
DODAJ DO KOSZYKA
DODAJ DO KOSZYKA
charakteryzujące się złożono cią i wysokim stopniem komplikacji. W książce
 STL w praktyce. 50 sposobów efektywnego wykorzystania  przeznaczonej dla
zaawansowanych i rednio zaawansowanych programistów C++  znany ekspert Scott
Meyers prezentuje najważniejsze techniki stosowania tego narzędzia. Poza listą zaleceń,
CENNIK I INFORMACJE
CENNIK I INFORMACJE
jak postępować należy, a jak postępować się nie powinno, Meyers przedstawia wiele
poważniejszych aspektów STL pozwalających zrozumieć, dlaczego pewne rozwiązania
ZAMÓW INFORMACJE
ZAMÓW INFORMACJE
są poprawne, a innych należy unikać. Do każdej wskazówki dołączony jest kod
O NOWO CIACH
O NOWO CIACH
ródłowy i dokładne obja nienia, które powinny zainteresować zaawansowanych
programistów.
ZAMÓW CENNIK
ZAMÓW CENNIK
Jeżeli Twoja wiedza ogranicza się do informacji dostępnych w dokumentacji STL,
ta książka uzupełni ją o bezcenne wskazówki, które pozwolą Ci wykorzystać STL
CZYTELNIA
CZYTELNIA w praktyce.
Książka przedstawia:
FRAGMENTY KSIĄŻEK ONLINE
FRAGMENTY KSIĄŻEK ONLINE
" Podstawowe informacje o bibliotece STL i jej zgodno ci z innymi standardami
" Wskazówki dotyczące poprawnego doboru i używania pojemników
" Opis pojemników typu vector i string
" Omówienie pojemników asocjatywnych
" Metody wła ciwego korzystania z iteratorów
" Algorytmy wchodzące w skład STL
" Funktory, klasy-funktory i funkcje
" Programowanie za pomocą biblioteki STL
Książkę uzupełniają dodatki, w których znajdziesz między innymi obszerną bibliografię
na temat STL oraz cenne wskazówki dla programistów używających kompilatorów
firmy Microsoft.
Wydawnictwo Helion
 STL w praktyce. 50 sposobów efektywnego wykorzystania to nieocenione ródło
ul. Chopina 6
wiedzy na temat jednego z najważniejszych aspektów programowania w C++.
44-100 Gliwice
Jeżeli chcesz w praktyce wykorzystać STL, nie obędziesz się bez informacji
tel. [phone]
e-mail: [e-mail] zawartych w tej książce.
Spis treści
Podziękowania...................................................................................9
Przedmowa......................................................................................13
Wprowadzenie .................................................................................17
Rozdział 1. Kontenery........................................................................................29
Zagadnienie 1. Uważnie dobierajmy kontenery................................................................30
Zagadnienie 2. Nie dajmy sią zwieść iluzji o istnieniu kodów niezależnych
do zastosowanego kontenera........................................................................................35
Zagadnienie 3. Kopiowanie obiektów w kontenerach powinno być  tanie ,
łatwe i poprawne ..........................................................................................................40
Zagadnienie 4. Stosujmy metodą empty(), zamiast przyrównywać
rozmiar size() do zera...................................................................................................43
Zagadnienie 5. Preferujmy metody operujące na całych zakresach (podzbiorach),
bo są bardziej efektywne niż ich odpowiedniki operujące pojedynczymi elementami...45
Zagadnienie 6. Bądz
my wyczuleni i przygotowani na najbardziej
kłopotliwą interpretacją kompilatora C++ ...................................................................56
Zagadnienie 7. Gdy stosujemy kontenery zawierające wskaz
niki zainicjowane
za pomocą operatora new, pamiątajmy o zwolnieniu dynamicznej pamiąci
operatorem delete, zanim zawierający je obiekt-kontener sam zostanie usuniąty.......59
Zagadnienie 8. Nigdy nie twórzmy kontenerów zawierających wskaz
niki
kategorii auto_ptr .........................................................................................................64
Zagadnienie 9. Uważnie dobierajmy opcje do operacji kasowania ..................................67
Zagadnienie 10. Uważajmy na konwencje dynamicznej alokacji pamiąci
i stosowne ograniczenia ...............................................................................................73
Zagadnienie 11. Zrozumienie uprawnionych zastosowań alokatorów pamiąci
tworzonych przez użytkownika....................................................................................80
Zagadnienie 12. Miejmy umiarkowane i realistyczne oczekiwania odnośnie
poziomu bezpieczeństwa wielu wątków obsługiwanych przez kontenery STL ..........84
6 Spis treści
Rozdział 2. Kontenery typu vector oraz string.....................................................89
Zagadnienie 13. Lepiej stosować kontenery vector oraz string niż dynamicznie
przydzielać pamiąć tablicom........................................................................................90
Zagadnienie 14. Stosujmy metodą reserve, by uniknąć zbądnego przemieszczania
elementów w pamiąci...................................................................................................93
Zagadnienie 15. Bądz
my ostrożni i wyczuleni na zróżnicowanie implementacji
kontenerów typu string.................................................................................................96
Zagadnienie 16. Powinieneś wiedzieć, jak przesyłać dane z kontenerów vector
i string do klasycznego interfejsu zgodnego z C........................................................102
Zagadnienie 17. Sztuczka programistyczna  swap trick pozwalająca
na obciącie nadmiarowej pojemności ........................................................................106
Zagadnienie 18. Unikajmy stosowania wektora typu vector...............................108
Rozdział 3. Kontenery asocjacyjne...................................................................111
Zagadnienie 19. Ten sam czy taki sam  zrozumienie różnicy pomiądzy
relacjami równości a równoważności ........................................................................112
Zagadnienie 20. Określajmy typy porównawcze dla kontenerów asocjacyjnych
zawierających wskaz
niki............................................................................................117
Zagadnienie 21. Funkcje porównujące powinny dla dwóch dokładnie równych
wartości zawsze zwracać wartość false......................................................................122
Zagadnienie 22. Unikajmy bezpośredniego modyfikowania klucza w kontenerach
typu set i multiset .......................................................................................................126
Zagadnienie 23. Rozważmy zastąpienie kontenerów asocjacyjnych
posortowanymi wektorami.........................................................................................133
Zagadnienie 24. Gdy efektywność działania jest szczególnie istotna, należy bardzo
uważnie dokonywać wyboru pomiądzy map::operator[]() a map::insert()................140
Zagadnienie 25. Zapoznaj sią z niestandardowymi kontenerami mieszanymi ...............146
Rozdział 4. Iteratory........................................................................................151
Zagadnienie 26. Lepiej wybrać iterator niż const_iterator, reverse_iterator
czy const_reverse_iterator..........................................................................................151
Zagadnienie 27. Stosujmy funkcje distance() i advance(), by przekształcić
typ const_iterator na typ iterator ................................................................................155
Zagadnienie 28. Jak stosować metodą base() należącą do klasy reverse_iterator
w celu uzyskania typu iterator?..................................................................................159
Zagadnienie 29. Rozważ zastosowanie iteratorów typu istreambuf_iterator
do wczytywania danych znak po znaku.....................................................................163
Rozdział 5. Algorytmy......................................................................................165
Zagadnienie 30. Upewnijmy sią, że docelowe zakresy są wystarczająco obszerne .......166
Zagadnienie 31. Pamiątajmy o dostąpnych i stosowanych opcjach sortowania.............171
Zagadnienie 32. Stosujmy metodą erase() w ślad za algorytmami kategorii remove(),
jeśli naprawdą chcemy coś skutecznie usunąć z kontenera .......................................177
Zagadnienie 33. Przezornie i ostrożnie stosujmy algorytmy kategorii remove()
wobec kontenerów zawierających wskaz
niki ............................................................182
Zagadnienie 34. Zwracajmy uwagą, które z algorytmów oczekują
posortowanych zakresów ...........................................................................................186
Spis treści 7
Zagadnienie 35. Implementujmy zwykłe porównywanie łańcuchów znaków bez
rozróżniania wielkości liter za pomocą mismatch() lub lexicographical_compare()....190
Zagadnienie 36. Zrozum prawidłową implementacją algorytmu copy_if()....................196
Zagadnienie 37. Stosujmy accumulate() lub for_each() do operacji grupowych
na zakresach ...............................................................................................................198
Rozdział 6. Funktory, klasy-funktory, funkcje i inne...........................................205
Zagadnienie 38. Projektowanie klas-funktorów do przekazywania przez wartość ........205
Zagadnienie 39. Predykaty powinny być funkcjami czystymi .......................................208
Zagadnienie 40. Klasy-funktory powinny być adaptowalne...........................................212
Zagadnienie 41. Po co stosować funkcje ptr_fun, mem_fun i mem_fun_ref?................215
Zagadnienie 42. Upewnij sią, że less() oznacza operator<().....................................219
Rozdział 7. Programowanie za pomocą biblioteki STL .......................................223
Zagadnienie 43. Używaj algorytmów, zamiast pisać pątle .............................................223
Zagadnienie 44. Zamiast algorytmów stosujmy metody o takich samych nazwach ......231
Zagadnienie 45. Rozróżnianie funkcji count(), find(), binary_search(),
lower_bound(), upper_bound() i equal_range().........................................................233
Zagadnienie 46. Jako parametry algorytmów stosuj funktory, a nie funkcje .................241
Zagadnienie 47. Unikaj tworzenia kodu  tylko do zapisu ............................................245
Zagadnienie 48. Zawsze dołączaj właściwe pliki nagłówkowe......................................248
Zagadnienie 49. Naucz sią odczytywać komunikaty kompilatora związane
z biblioteką STL.........................................................................................................249
Zagadnienie 50. Poznaj strony WWW związane z biblioteką STL ................................256
Dodatek A Bibliografia....................................................................................263
Książki napisane przeze mnie .........................................................................................263
Książki, które nie ja napisałem (choć chciałbym)...........................................................264
Dodatek B Porównywanie ciągów znaków bez uwzględniania wielkości liter .....267
Jak wykonywać porównywanie ciągów znaków bez uwzglądniania wielkości liter
 artykuł autorstwa Matta Austerna .........................................................................267
Dodatek C Uwagi na temat platformy STL Microsoftu ......................................277
Szablony metod w STL...................................................................................................277
MSVC wersje 4 do 6 .......................................................................................................278
Rozwiązania dla kompilatorów MSVC w wersji 4 do 5.................................................279
Dodatkowe rozwiązanie dla kompilatora MSVC w wersji 6..........................................280
Skorowidz......................................................................................283
Rozdział 6.
Funktory, klasy-funktory,
funkcje i inne
Czy nam sią to podoba czy nie, funkcje i podobne do funkcji obiekty  funktory  są
cząścią STL. Kontenery asocjacyjne stosują je do porządkowania swoich elemen-
tów, w algorytmach typu wykorzystywane są do kontroli zachowań tych al-
gorytmów. Algorytmy takie jak i są bez funktorów zupełnie
nieprzydatne, natomiast adaptory typu i służą do tworzenia funktorów.
Wsządzie gdzie spojrzeć, można w STL znalez
ć funktory i klasy-funktory. Znajdą sią
one również w Twoich kodach z
ródłowych. Efektywne zastosowanie STL bez umiejąt-
ności tworzenia dobrych funktorów jest po prostu niemożliwe. Z tego powodu wiąksza
cząść tego rozdziału bądzie opisywać sposoby takiego tworzenia funktorów, aby zacho-
wywały sią one zgodnie z wymaganiami STL. Jednak jedno z zagadnień opisuje zupeł-
nie inny temat. Ten podrozdział spodoba sią osobom, które zastanawiały sią, dlaczego
konieczne jest zaśmiecanie kodu programu wywołaniami funkcji ,
i . Oczywiście można zacząć lekturą od tego właśnie podrozdziału,  Za-
gadnienie 41. , ale proszą nie poprzestawać na nim. Po poznaniu przedstawionych tam
funkcji konieczne bądzie zapoznanie sią z informacjami z pozostałych, dziąki czemu
Twoje funkcje bądą prawidłowo działały zarówno z tymi funkcjami, jak i z resztą STL.
Zagadnienie 38.
Projektowanie klas-funktorów
do przekazywania przez wartość
Zagadnienie 38. Projektowanie klas-funktorów do przekazywania przez wartość
Jązyki C i C++ nie pozwalają na przekazywanie funkcji w parametrach innych funkcji.
Konieczne jest przekazywanie wskaz
ników na te funkcje. Na przykład poniżej znajduje
sią deklaracja funkcji z biblioteki standardowej.
206 Rozdział 6. f& Funktory, klasy-funktory, funkcje i inne


 Zagadnienie 46. wyjaśnia, dlaczego algorytm jest zazwyczaj lepszym wy-
borem od funkcji . Teraz omówimy sposób deklarowania parametru
w funkcji . Po dokładniejszym przyjrzeniu sią wszystkim gwiazdkom okazuje
sią, że argument , który jest wskaz
nikiem na funkcją, jest kopiowany (czyli prze-
kazywany przez wartość) z miejsca wywołania do funkcji . Jest to typowy przy-
kład zasady stosowanej w bibliotekach standardowych jązyków C i C++, czyli prze-
kazywania przez wartość wskaz
ników na funkcje.
W STL obiekty funkcyjne modelowane są podobnie do wskaz
ników na funkcje, wobec
czego w STL obiekty funkcyjne są również przekazywane do i z funkcji przez war-
tość. Najlepszym przykładem może być deklaracja funkcji algorytmu po-
bierającego i zwracającego przez wartość funktory.






Tak na prawdą przekazywanie przez wartość nie jest absolutnie wymagane, ponie-
waż w wywołaniu funkcji można wyraz
nie zaznaczyć typy parametrów.
Na przykład w poniższym kodzie funkcja pobiera i zwraca funktory przez
referencją.

















Użytkownicy STL prawie nigdy nie przeprowadzają tego typu operacji, co wiącej,
pewne implementacje niektórych algorytmów STL nie skompilują sią w przypadku
przekazywania funktorów przez referencją. W pozostałej cząści tego sposobu bądą za-
kładał, że funktory można przekazywać wyłącznie przez wartość, co w praktyce jest
niemal zawsze prawdą.
Funktory muszą być przekazywane przez wartość, dlatego to na Tobie spoczywa ciążar
sprawdzenia, czy Twoje funktory przekazywane w ten sposób zachowują sią prawidło-
wo. Implikuje to dwie rzeczy. Po pierwsze, muszą one być małe, bo kopiowanie dużych
Zagadnienie 38. Projektowanie klas-funktorów do przekazywania przez wartość 207
obiektów jest bardzo kosztowne. Po drugie, Twoje funktory nie mogą być polimor-
ficzne (muszą być monomorficzne), co oznacza, że nie mogą używać funkcji wirtual-
nych. Wynika to z faktu, że obiekt klasy pochodnej przekazywany w parametrze typu
klasy bazowej zostaje obciąty, czyli w czasie kopiowania usuniąte bądą z niego
odziedziczone elementy. W podrozdziale  Zagadnienie 3. opisano inny problem, jaki
rozczłonkowanie (ang. slicing) tworzy w czasie stosowania biblioteki STL.
Unikanie rozczłonkowania obiektów i uzyskiwanie dobrej wydajności są oczywiście
bardzo ważne, ale trzeba pamiątać, że nie wszystkie funkcje mogą być małe i nie wszy-
stkie obiekty mogą być monomorficzne. Jedną z zalet funktorów w porównaniu ze
zwykłymi funkcjami jest fakt, że mogą one przechowywać informacją o swoim stanie.
Niektóre funktory muszą być duże, dlatego tak ważna jest możliwość przekazywania
takich obiektów do algorytmów STL z równą łatwością jak obiektów niewielkich.
Zakaz używania funktorów polimorficznych jest równie nierealistyczny. Jązyk C++
pozwala na tworzenie hierarchii dziedziczenia i dynamicznego wiązania. Te możli-
wości są tak samo użyteczne w czasie tworzenia klas-funktorów, jak i w innych miej-
scach. Klasy-funktory bez dziedziczenia byłyby jak C++ bez  ++ . Oczywiście ist-
nieje sposób umożliwiający tworzenie dużych i polimorficznych obiektów funkcyjnych,
a jednocześnie umożliwiający przekazywanie ich przez wartość, zgodnie z konwencją
przyjątą w STL.
Ten sposób wymaga przeniesienia wszystkich danych i funkcji polimorficznych do in-
nej klasy, a nastąpnie w klasie-funktorze umieszczenie wskaz
nika na tą nową klasą.
Na przykład utworzenie klasy polimorficznej zawierającej duże ilości danych:

















wymaga utworzenia małej monomorficznej klasy zawierającej wskaz
nik na klasą
implementacji i umieszczenie w klasie implementacji wszystkich danych i funkcji
wirtualnych:






208 Rozdział 6. f& Funktory, klasy-funktory, funkcje i inne


















Funkcja w klasie przedstawia sposób implementacji wszystkich
niemal wirtualnych funkcji w tej klasie. Wywołują one swoje wirtualne odpowiedniki
z klasy . W efekcie otrzymujemy małą i monomorficzną klasą , która ma
dostąp do dużej ilości danych i zachowuje sią jak klasa polimorficzna.
Pomijam tutaj pewne szczegóły, ponieważ podstawa naszkicowanej tu techniki jest do-
brze znana programistom C++. Opisywana jest ona w książce Effective C++ w roz-
dziale 34. W książce Design Patterns [6] nazywana jest Bridge Pattern, natomiast Sut-
ter w swojej książce Exceptional C++ [8] nazywa ją Idiomem Pimpl.
Z punktu widzenia STL podstawową rzeczą, o której należy pamiątać, jest fakt, że klasy
stosujące tą techniką muszą rozsądnie obsługiwać kopiowanie. Autor opisywanej wyżej
klasy musiałby odpowiednio zaprojektować jej konstruktor kopiujący, tak aby pra-
widłowo obsługiwał wskazywany przez klasą obiekt . Najprawdopodobniej
najprostszym sposobem bądzie zliczanie referencji do niego, podobnie jak w przypadku
szablonu , o którym można przeczytać w podrozdziale  Zagadnienie 50. .
Tak naprawdą, na potrzeby tego podrozdziału należy jedynie zadbać o właściwe zacho-
wanie konstruktora kopiującego. W końcu funktory są zawsze kopiowane (czyli prze-
kazywane przez wartość) w momencie przekazywania ich do i z funkcji, a to oznacza
dwie rzeczy: muszą być małe i monomorficzne.
Zagadnienie 39.
Predykaty powinny być
funkcjami czystymi
Zagadnienie 39. Predykaty powinny być funkcjami czystymi
Obawiam sią, że bądziemy musieli zacząć od zdefiniowania pewnych pojąć.
Zagadnienie 39. Predykaty powinny być funkcjami czystymi 209
Predykat to funkcja zwracająca wartość typu (lub inną dającą sią łatwo
przełożyć na ). Predykaty są funkcjami cząsto wykorzystywanymi
w STL. Są to, na przykład, funkcje porównujące w standardowych
kontenerach asocjacyjnych; wykorzystują je również (pobierają jako
parametry) różnego rodzaju algorytmy sortujące, a także algorytmy typu
. Opis algorytmów sortujących znajduje sią w podrozdziale
 Zagadnienie 31. .
Funkcje czyste to funkcje, których wartość zwracana zależy wyłącznie
od wartości jej parametrów. Jeżeli jest funkcją czystą, a i są obiektami,
to wartość zwracana przez tą funkcją może zmienić sią wyłącznie
w przypadku zmiany w obiekcie lub .
W jązyku C++ dane, których używa funkcja czysta, są albo przekazywane
jako parametry albo pozostają niezmienne w czasie życia funkcji (oznacza
to, że muszą być zadeklarowane jako ). Jeżeli funkcja czysta
wykorzystywałaby dane zmieniające sią miądzy poszczególnymi jej
wywołaniami, wtedy kolejne wywołania z tymi samymi parametrami mogłyby
zwracać różne wartości, a to byłoby niezgodne z definicją funkcji czystej.
Powinno to wystarczyć do wyjaśnienia dlaczego predykaty powinny być funkcjami
czystymi. Teraz muszą jedynie Cią przekonać, że ta rada ma solidne podstawy. W zwią-
zku z tym bądą musiał wyjaśnić jeszcze jedno pojącie.
Klasa-predykat jest klasą-funktorem, w której funkcja jest
predykatem, co znaczy, że zwraca wartości lub albo wartość,
którą można bezpośrednio przekształcić na wartość logiczną. Jak można
sią domyślić, w miejscach, w których STL oczekuje podania predykatu,
można podać albo rzeczywisty predykat albo obiekt-predykat.
To wszystko. Teraz mogą zacząć udowadniać, że naprawdą warto przestrzegać porad
przedstawionych w tym podrozdziale.
W podrozdziale  Zagadnienie 38. wyjaśniłem, że funktory przekazywane są przez wa-
rtość, dlatego należy tak je budować, aby można je było łatwo kopiować. W przypadku
funktorów bądących predykatami istnieje jeszcze jeden powód takiego projektowania.
Algorytmy mogą pobierać kopie funktorów i przechowywać je przez pewien czas, za-
nim ich użyją. Jak można sią spodziewać, implementacje niektórych algorytmów oczy-
wiście korzystają z tej możliwości. Efektem takiego stanu rzeczy jest fakt, że funkcje
predykatów muszą być funkcjami czystymi.
Aby móc udowodnić te twierdzenia, załóżmy, że budując klasą nie zastosujemy sią do
nich. Przyjrzyjmy sią poniższej (z
le zaprojektowanej) klasie-predykatowi. Niezależnie
od przekazywanych jej parametrów zwraca ona wartość tylko raz  przy trze-
cim wywołaniu. W pozostałych przypadkach zwraca wartość .






210 Rozdział 6. f& Funktory, klasy-funktory, funkcje i inne






Przypuśćmy, że chcielibyśmy użyć tej klasy do usuniącia trzeciego elementu wektora
:








Powyższy kod wygląda zupełnie przyzwoicie, jednak w wielu implementacjach STL
usunie on nie tylko trzeci, ale i szósty element wektora.
Aby zrozumieć, jak jest to możliwe, dobrze jest poznać cząsty sposób implementacji
funkcji . Należy pamiątać, że funkcja nie musi być implemen-
towana w ten sposób:










Szczegóły podanego kodu nie są istotne, jednak należy zwrócić uwagą, że predykat
jest przekazywany najpierw do funkcji , a nastąpnie do funkcji
. W obu przypadkach jest przekazywany do tych algorytmów przez wartość
(czyli kopiowany). Teoretycznie nie musi to być prawdą, jednak w praktyce najcząściej
jest. Wiącej informacji na ten temat znajdziesz w podrozdziale  Zagadnienie 38. .
Początkowe wywołanie funkcji (w kodzie klienta, związane z próbą usu-
niącia trzeciego elementu wektora ) tworzy anonimowy obiekt klasy
zawierający wewnątrzną składową inicjowaną wartością zero. Ten obiekt
(wewnątrz funkcji nazywa sią ) jest kopiowany do funkcji ,
w związku z czym ona również otrzymuje obiekt klasy z wyzerowaną
zmienną . Funkcja  wywołuje ten obiekt tak długo, aż zwróci
wartość , czyli trzykrotnie, a nastąpnie przekazuje sterowanie do funkcji
. Funkcja wznawia swoje działanie i w końcu wywołuje funkcją
, przekazując jej kolejną kopią predykatu . Jednak wartość
zmiennej w obiekcie ma nadal wartość zero. Funkcja nigdy
Zagadnienie 39. Predykaty powinny być funkcjami czystymi 211
nie wywoływała obiektu , a jedynie jego kopię. W efekcie trzecie wywołanie przez
funkcją podanego jej predykatu również zwróci wartość . Oto
dlaczego funkcja usunie z wektora dwa elementy zamiast jednego.
Najprostszym sposobem na unikniącie tego rodzaju problemów jest deklarowanie
w klasach-predykatach funkcji jako . W tak zadeklarowanych funk-
cjach kompilator nie pozwoli zmienić wartości składników klasy:









Ze wzglądu na to, że opisany problem można rozwiązać w tak prosty sposób, byłem
bliski nazwania tego zagadnienia  W klasach-predykatach stosujmy
typu  . Niestety, takie rozwiązanie nie jest wystarczające. Nawet funkcje skła-
dowe oznaczone jako mogą używać zmiennych pól klasy, niestałych lokal-
nych obiektów statycznych, niestałych statycznych obiektów klas, niestałych
obiektów w zakresie przestrzeni nazw i niestałych obiektów globalnych. Dobrze za-
projektowana klasa-predykat gwarantuje, że funkcje jej operatora są nie-
zależne od tego rodzaju obiektów. Zadeklarowanie jako jest ko-
nieczne dla uzyskania właściwego zachowania klasy, jednak nie jest wystarczające.
Co prawda wystarczyłoby tak zmodyfikować składowe, żeby nie wpływały na wynik
predykatu, jednak dobrze zaprojektowany wymaga czegoś wiącej 
musi być funkcją czystą.
Zaznaczyłem już, że w miejscach, w których STL oczekuje funkcji predykatu, za-
akceptowany zostanie również obiekt klasy-predykatu. Ta zasada obowiązuje również
w przeciwnym kierunku. W miejscach, w których STL oczekuje obiektu klasy-
predykatu, zaakceptowana zostanie również funkcja-predykat (prawdopodobnie zmody-
fikowana przez funkcją  zobacz  Zagadnienie 41. ). Zostało już udowod-
nione, że funkcje w klasach-predykatach muszą być funkcjami czysty-
mi, co w połączeniu z powyższymi stwierdzeniami oznacza, że funkcje-predykaty
również muszą być funkcjami czystymi. Poniższa funkcja nie jest aż tak złym predy-
katem jak obiekty tworzone na podstawie klasy , ponieważ jej zastoso-
wanie wiąże sią z istnieniem tylko jednej kopii zmiennej stanu, jednak i ona narusza
zasady tworzenia predykatów:





Niezależnie od tego, w jaki sposób tworzysz swoje predykaty, powinny one zawsze być
funkcjami czystymi.
212 Rozdział 6. f& Funktory, klasy-funktory, funkcje i inne
Zagadnienie 4O.
Klasy-funktory powinny być adaptowalne
Zagadnienie 40. Klasy-funktory powinny być adaptowalne
Przypuśćmy, że mamy listą wskaz
ników i funkcją określającą, czy dany wskaz
nik
identyfikuje interesujący nas element.


Jeżeli chcielibyśmy znalez
ć pierwszy wskaz
nik na interesujący nas element, można by
to zrobić w prosty sposób:





Jeżeli jednak bądziemy chcieli uzyskać pierwszy wskaz
nik na element nas nieinteresu-
jący, ten najbardziej oczywisty sposób nawet sią nie skompiluje.



W takim przypadku należy funkcją przekazać najpierw do funkcji
, a dopiero potem do adaptora .






Tutaj rodzi sią kilka pytań. Dlaczego konieczne jest zastosowanie funkcji na
funkcji przed przekazaniem jej do ? Co i jak robi funkcja
, że umożliwia skompilowanie powyższego kodu?
Odpowiedz
na te pytania jest nieco zaskakująca. Funkcja udostąpnia jedynie
kilka deklaracji . To wszystko. Są to deklaracje wymagane przez adaptor
i z tego powodu bezpośrednie przekazanie funkcji do nie bą-
dzie działać. Symbol jest jedynie prostym wskaz
nikiem na funkcją,
dlatego brakuje mu deklaracji wymaganych przez adaptor .
W STL znajduje sią wiele innych komponentów tworzących podobne wymagania. Każ-
dy z czterech podstawowych adaptorów funkcji ( , , i )
wymaga istnienia odpowiednich deklaracji , tak jak i wszystkie inne niestan-
dardowe, ale zgodne z STL adaptory tworzone przez różne osoby (na przykład te two-
rzone przez firmy SGI lub Boost  zobacz  Zagadnienie 50. ). Funktory zawierające
te wymagane deklaracje nazywane są adaptowalnymi, natomiast funkcje ich
Zagadnienie 40. Klasy-funktory powinny być adaptowalne 213
nieposiadające nazywane są nieadaptowalnymi. Adaptowalnych funktorów można
używać w znacznie wiąkszej ilości kontekstów niż nieadaptowalnych, dlatego, gdy
tylko to możliwe, należałoby budować funktory adaptowalne. Taka operacja nie kosz-
tuje wiele, a może znacznie ułatwić pracą użytkownikom Twoich klas-funktorów.
Zapewne już sią denerwujesz, że cały czas mówią o  odpowiednich deklaracjach
 , ale nigdy nie określam, jakie to deklaracje. Są to deklaracje: ,
, i . Niestety, życie nie jest
całkiem proste, ponieważ w zależności od rodzaju klasy-funktory powinny udostąp-
niać różne zestawy tych nazw. Tak naprawdą, jeżeli nie tworzysz własnych adapto-
rów (a tego w tej książce nie bądziemy opisywać), nie musisz znać tych deklaracji.
Wynika to z faktu, że najprostszym sposobem udostąpnienia tych deklaracji jest
odziedziczenie ich po klasie bazowej, a właściwie po bazowej strukturze. Klasy-
funktory, w których przyjmuje jeden argument, powinny być wywo-
dzone z , natomiast klasy-funktory, w których
przyjmuje dwa argumenty, powinny być wywodzone z .
Należy pamiątać, że i to szablony, dlatego nie moż-
na bezpośrednio po nich dziedziczyć, ale dziedziczyć po wygenerowanych przez nie
strukturach, a to wymaga określenia typów argumentów. W przypadku
musisz określić typ parametru pobieranego przez Twojej klasy funkto-
ra, a także typ jego wartości zwracanej. W przypadku konieczne jest
określenie trzech typów: pierwszego i drugiego parametru oraz zwraca-
nej przez niego wartości.
Poniżej podają kilka przykładów:













Proszą zauważyć, że w obydwu przypadkach typy przekazywane do
i są identyczne z typami pobieranymi i zwracanymi przez
danej klasy funktora. Troszką dziwny jest tylko sposób przekazania typu warto-
ści zwracanej przez operator jako ostatniego parametru szablonów
lub .
Zapewne nie uszło Twojej uwadze, że jest klasą, a
jest strukturą. Wynika to z faktu, że ma składowe opisujące jej
wewnątrzny stan (pole ), dlatego naturalną rzeczą jest zastosowanie w takiej
sytuacji klasy. Z kolei nie przechowuje informacji o stanie, dlatego
214 Rozdział 6. f& Funktory, klasy-funktory, funkcje i inne
nie ma potrzeby ukrywania w niej jakichkolwiek danych. Autorzy klas, w których nie
ma elementów prywatnych, cząsto deklarują takie klasy jako struktury. Prawdopo-
dobnie chodzi o możliwość unikniącia wpisywania w takiej klasie słowa kluczowego
. Wybór deklaracji takich klas jako klasy lub struktury zależy wyłącznie od prefe-
rencji programisty. Jeżeli cały czas próbujesz wykuć własny styl, a chciałbyś naślado-
wać zawodowców, zauważ, że w bibliotece STL wszystkie klasy nieposiadające stanu
(na przykład , itd.) deklarowane są jako struktury.
Przyjrzyjmy sią jeszcze raz strukturze :




Typ przekazywany do szablonu to , mimo że
pobiera argumenty typu . Zazwyczaj niebądące wskaz
nikami typy prze-
kazywane do szablonu lub odzierane są ze znaczni-
ków i referencji. (Nie pytaj dlaczego. Powód nie jest ani dobry, ani interesują-
cy. Jeżeli jednak nadal bardzo chcesz wiedzieć, napisz program testowy i nie usuwaj
w nim tych znaczników, a nastąpnie przeanalizuj wynik działania kompilatora. Jeżeli
po tym wszystkim nadal bądziesz zainteresowany tematem, zajrzyj na stroną boost.org
(zobacz  Zagadnienie 50. ) i przejrzyj na niej teksty dotyczące adaptorów funktorów
i cech wywołań).
W przypadku gdy pobiera wskaz
niki jako parametry, opisane wyżej za-
sady ulegają zmianie. Poniżej podają strukturą podobną do , która
posługuje sią wskaz
nikami :




W tym przypadku typy przekazywane do są identyczne z typami
pobieranymi przez . Wszystkie klasy-funktory pobierające lub zwracające
wskaz
niki obowiązuje zasada nakazująca przekazywanie do lub
dokładnie takich samych typów, jakie pobiera lub zwraca .
Nie możemy zapomnieć, z jakiego powodu snujemy te opowieści o klasach bazowych
i  dostarczają one deklaracji wymaga-
nych przez adaptory funktorów, dlatego dziedziczenie po tych klasach pozwala two-
rzyć funktory adaptowalne. To z kolei pozwala na pisanie tego rodzaju rzeczy:









Zagadnienie 41. Po co stosować funkcje ptr_fun, mem_fun i mem_fun_ref? 215



Gdyby nasze klasy-funktory nie zostały wywiedzione z klasy lub
, powyższe przykłady nawet by sią nie skompilowały, ponieważ funkcje
i działają tylko z funktorami adaptowalnymi.
W STL funktory modelowane są podobnie do funkcji w jązyku C++, które mają tylko
jeden zestaw typów parametrów i jedną wartość zwracaną. W efekcie przyjmuje sią,
że każda klasa-funktor ma tylko jedną funkcją , której parametry i wartość
zwracana powinny zostać przekazane do klas lub
(wynika to z omówionych właśnie zasad dla typów wskaz
nikowych i referencyjnych).
A z tego wynika z kolei, że nie powinno sią łączyć funkcjonalności struktur
i przez utworzenie jednej klasy mającej dwie
funkcje . Jeżeli utworzysz taką klasą, bądzie ona adaptowalna tylko w
jednej wersji (tej zgodnej z parametrami przekazywanymi do ). Jak
można sią domyślać, funktor adaptowalny tylko w połowie równie dobrze mógłby nie
być adaptowalny w ogóle.
W niektórych przypadkach utworzenie możliwości wywołania funktora w wielu for-
mach (a tym samym rezygnacja z adaptowalności) ma sens, co opisano w zagadnie-
niach: 7., 20., 23. i 25. Należy jednak pamiątać, że tego rodzaju funktory są jedynie
wyjątkami od zasady. Adaptowalność to cecha, do której należy dążyć w czasie two-
rzenia klas-funktorów.
Zagadnienie 41.
Po co stosować funkcje ptr_fun,
mem_fun i mem_fun_ref?
Zagadnienie 41. Po co stosować funkcje ptr_fun, mem_fun i mem_fun_ref?
O co chodzi z tymi funkcjami? Czasami trzeba ich używać, czasami nie. Co one wła-
ściwie robią? Wygląda na to, że czepiają sią nazw funkcji jak rzep psiego ogona. Nie-
łatwo je wpisać, denerwują w czasie czytania i trudno je zrozumieć. Czy są to artefakty
podobne do przedstawionych w podrozdziałach  Zagadnienie 10. i  Zagadnienie
18. , czy może członkowie komitetu standaryzacyjnego wyciąli nam niemiły dowcip?
Spokojnie, te funkcje mają do spełnienia naprawdą ważne zadania i z całą pewno-
ścią nie są dziwacznymi żartami. Jednym z ich podstawowych zadań jest zamaskowanie
pewnych niekonsekwencji syntaktycznych jązyka C++.
Jeżeli, posiadając funkcją i obiekt , chcielibyśmy wywołać na rzecz i jeste-
śmy poza funkcjami składowymi obiektu , jązyk C++ pozwala na zastosowanie
trzech różnych składni takiego wywołania.



216 Rozdział 6. f& Funktory, klasy-funktory, funkcje i inne






Teraz załóżmy, że mamy funkcją sprawdzającą elementy:



i kontener przechowujący te elementy:

Jeżeli chcielibyśmy sprawdzić wszystkie elementy w , moglibyśmy w prosty sposób
wykorzystać funkcją :

Wyobraz
my sobie, że nie jest zwyczajną funkcją, ale funkcją składową klasy
, co oznacza, że obiekty tej klasy mogą same sią sprawdzać:






W świecie doskonałym moglibyśmy zastosować funkcją , aby wywołać
funkcją dla każdego obiektu wektora :


Jeżeli świat byłby naprawdą doskonały, moglibyśmy również zastosować funkcją
, żeby wywołać funkcją w elementach kontenera prze-
chowującego wskaz
niki :




Pomyślmy jednak, co by sią działo w tym świecie doskonałym. W przypadku wywoła-
nia nr 1 wewnątrz funkcji wywoływalibyśmy zwykłą funkcją, przekazując
jej obiekt, czyli konieczne byłoby zastosowanie składni nr 1. W przypadku wywoła-
nia nr 2 wewnątrz funkcji wywoływalibyśmy metodą pewnego obiektu,
czyli konieczne byłoby zastosowanie składni nr 2. Natomiast w przypadku wywołania
nr 3 wewnątrz funkcji wywoływalibyśmy metodą obiektu, do którego od-
wołujemy sią poprzez wskaz
nik, czyli konieczne byłoby zastosowanie składni nr 3. To
wszystko oznacza, że musiałyby istnieć trzy różne wersje funkcji , a świat
nie byłby już tak doskonały.
Zagadnienie 41. Po co stosować funkcje ptr_fun, mem_fun i mem_fun_ref? 217
W świecie rzeczywistym istnieje tylko jedna wersja funkcji . Zapewne nie-
trudno sią domyślić, jak wygląda jej implementacja:





Proszą zauważyć, że funkcja wykorzystuje do wywoływania funkcji
składnią nr 1. Jest to ogólnie przyjąta w STL konwencja, funkcje i funktory są wywo-
ływane za pomocą składni stosowanej dla zwykłych funkcji. To wyjaśnia, dlaczego
można skompilować składnią nr 1, ale składni nr 2 i 3 już nie. Wszystkie algorytmy STL
(w tym również ) wykorzystują składnią nr 1, wobec czego jedynie wywoła-
nie nr 1 jest z nią zgodne.
Teraz powinno być już jasne, dlaczego istnieją funkcje i .
Sprawiają one, że funkcje składowe (które powinny być wywoływane za pomocą
składni nr 2 lub 3) są wywoływane za pomocą składni nr 1.
Funkcje i wykonują swoje zadania w bardzo prosty sposób,
spojrzenie na deklaracją jednej z nich powinno całkowicie wyjaśnić zagadką. Tak na-
prawdą są to szablony funkcji, istnieje ich kilka wersji różniących sią ilością parame-
trów i tym, czy przystosowywana funkcja jest oznaczona jako czy nie. Aby po-
znać sposób działania tych funkcji, wystarczy zobaczyć kod jednej z nich:






Funkcja pobiera wskaz
nik na metodą ( ) i zwraca obiekt typu .
Jest to klasa-funktor przechowująca wskaz
nik na metodą i udostąpniająca
wywołujący tą metodą na rzecz obiektu podanego jako parametr tego opera-
tora. Na przykład w kodzie:




funkcja otrzymuje obiekt typu przechowujący wskaz
nik na funk-
cją . Dla każdego wskaz
nika z za pomocą składni nr 1 wy-
woływany jest obiekt , a ten natychmiast wywołuje funkcją
zgodnie ze składnią nr 3.
Ogólnie, funkcja przystosowuje składnią nr 3 wymaganą przy wywołaniach
funkcji za pomocą wskaz
nika na składnią nr 1 stosowaną przez
funkcją , wobec czego nie powinno dziwić, że klasy w rodzaju
nazywane są adaptorami obiektów funkcyjnych. W podobny sposób funkcja
przystosowuje składnią nr 2, generując obiekty-adaptory typu .
218 Rozdział 6. f& Funktory, klasy-funktory, funkcje i inne
Obiekty tworzone przez funkcje i pozwalają nie tylko zakła-
dać, że wszystkie funkcje wywoływane są za pomocą tej samej składni, ale również,
podobnie jak obiekty generowanie przez funkcją , udostąpniają odpowiednie
deklaracje . Na temat tych deklaracji była mowa w podrozdziale  Zagadnienie
40. . Dziąki tym wyjaśnieniom powinno być już jasne, dlaczego ten kod sią skompiluje:

a te nie:




Wywołanie nr 1 przekazuje w parametrze funkcją, dlatego nie ma konieczności dosto-
sowania składni do wymagań funkcji . Algorytm wywoła otrzymaną funk-
cją za pomocą właściwej składni. Co wiącej, funkcja nie używa żadnej
z deklaracji udostąpnianej przez funkcją , wiąc nie ma potrzeby
przekazywania funkcji za pośrednictwem tej funkcji. Z drugiej strony, udo-
stąpnienie tych deklaracji na nic nie wpłynie, wiąc poniższy kod zadziała tak samo
jak ten podany wyżej.


Jeżeli teraz już nie wiesz, kiedy stosować funkcją , a kiedy nie  możesz
używać jej przy każdym przekazywaniu funkcji do komponentu STL. Bibliotece nie
zrobi to żadnej różnicy, nie wpłynie też na wydajność programu. Najgorsze, co może
Ci sią zdarzyć, to zdziwienie na twarzy osoby czytającej Twój kod pojawiające sią
w momencie napotkania nadmiarowego wywołania funkcji . Na ile bądzie
Ci to przeszkadzać? Chyba zależy to od Twojej wrażliwości na zdziwione twarze.
Inną strategią dotyczącą stosowania funkcji jest stosowanie jej tylko w przy-
padku, gdy zostaniemy do tego zmuszeni. Oznacza to, że w przypadkach, w których
konieczna bądzie obecność deklaracji , kompilacja programu zostanie wstrzy-
mana. Wtedy bądzie trzeba uzupełnić kod o wywołanie funkcji .
W przypadku funkcji i mamy zupełnie inną sytuacją. Ich
wywołanie jest konieczne przy każdym przekazywaniu metody do komponentu STL,
ponieważ poza udostąpnianiem potrzebnych deklaracji dostosowują one
składnią stosowaną przy wywoływaniu metod do składni stosowanej w całej bibliote-
ce STL. Brak odpowiedniej funkcji przy przekazywaniu wskaz
ników na metody unie-
możliwi poprawną kompilacją programu.
Pozostało nam omówić nazwy adaptorów metod. Okazuje sią, że natkniemy sią tutaj
na historyczny już artefakt. Gdy okazało sią, że potrzebne są takie adaptory, twórcy
biblioteki STL skupili sią na kontenerach wskaz
ników (W świetle ograniczeń, jakimi
obarczone są te kontenery  opisano je w zagadnieniach 7., 20. i 33.  pewnym
zaskoczeniem może być fakt, że to właśnie kontenery wskaz
ników obsługują klasy poli-
morficzne, podczas gdy kontenery obiektów ich nie obsługują). Zbudowano adaptor
dla metod i nazwano go . Póz
niej okazało sią, że potrzebny jest jeszcze adaptor
Zagadnienie 42. Upewnij się, że less() oznacza operator<() 219
dla kontenerów obiektów, wiąc nową funkcją nazwano . Nie jest to zbyt
eleganckie, ale takie rzeczy sią zdarzają. Pewnie każdemu zdarzyło sią nadać kompo-
nentowi nazwą, którą póz
niej trudno było dostosować do nowych warunków.
Zagadnienie 42.
Upewnij się, że less()
oznacza operator<()
Zagadnienie 42. Upewnij się, że less() oznacza operator<()
Jak wszyscy dobrze wiemy,  widgety mają swoją masą i maksymalną prądkość:







Oczywiście naturalnym sposobem sortowania widgetów jest sortowanie ich według ma-
sy, dlatego operator mniejszości ( ) w tym przypadku powinien wyglądać nastąpująco:




Przypuśćmy jednak, że chcielibyśmy utworzyć kontener typu , w któ-
rym widgety sortowane byłyby według ich prądkości maksymalnej. Wiemy już, że
domyślną funkcją porównującą kontenera jest .
Wiemy też, że domyślnie funkcja ta tylko wywołuje operator mniejszości ( ). Wyglą-
da na to, że jedynym sposobem na posortowanie kontenera według
prądkości maksymalnej jego elementów jest zniszczenie połączenia miądzy funkcją
a operatorem mniejszości ( ). Można to zrobić, nakazując funkcji
kontrolą jedynie prądkości maksymalnej podawanych jej widgetów:











Nie wygląda to na zbyt dobrą radą i taką nie jest, chyba jednak nie z powodu, o którym
myślisz. Czyż nie jest zaskakujące, że ten kod w ogóle sią kompiluje? Wielu programi-
stów zauważy, że nie jest on tylko zwykłą specjalizacją szablonu, ale jest specjalizacją
220 Rozdział 6. f& Funktory, klasy-funktory, funkcje i inne
szablonu w przestrzeni nazw . Bądą oni pytać:  Czy przestrzeń nie powinna być
świąta? Dostąpna tylko dla twórców biblioteki i bądąca poza zasiągiem zwykłych
programistów? Czy kompilatory nie powinny zakazywać grzebania w pracach twór-
ców C++? .
Zazwyczaj próby modyfikacji komponentów w przestrzeni są rzeczywiście za-
bronione, a próby ich wykonania kończą sią niezdefiniowanym zachowaniem aplika-
cji. Jednak w niektórych przypadkach takie prowizorki są dopuszczalne. W szczegól-
ności możliwe jest specjalizowanie szablonów do obsługi typów zdefiniowanych przez
użytkownika. Niemal zawsze są inne, lepsze wyjścia niż zabawa z szablonami z prze-
strzeni , jednak czasami wiele argumentów przemawia właśnie za taką opcją. Na
przykład autorzy klas inteligentnych wskaz
ników chcieliby, aby ich klasy zachowy-
wały sią jak zwyczajne wskaz
niki, dlatego w takich klasach cząsto spotyka sią spe-
cjalizacje funkcji . Poniższy kod jest cząścią klasy z biblioteki
Boost. Jest to właśnie inteligentny wskaz
nik, o którym można przeczytać w podroz-
działach  Zagadnienie 7. i  Zagadnienie 50. .















Powyższa implementacja nie jest pozbawiona sensu  z cała pewnością nie tworzy
żadnych niespodzianek, ponieważ taka specjalizacja zapewnia jedynie, że sortowanie
zwykłych wskaz
ników i wskaz
ników inteligentnych odbywa sią w ten sam sposób.
Niestety, nasza specjalizacja funkcji w klasie może przysporzyć kilku
niemiłych niespodzianek.
Programistom C++ można wybaczyć, że pewne rzeczy uznają za oczywiste. Na przy-
kład zakładają oni, że konstruktory kopiujące rzeczywiście kopiują obiekty (jak wy-
kazano w podrozdziale  Zagadnienie 8. , niedopełnienie tej konwencji może prowa-
dzić do zadziwiających zachowań programu). Zakładają też, że pobierając adres
obiektu, otrzymają wskaz
nik na ten obiekt (w podrozdziale  Zagadnienie 18. opisano
problemy, jakie powstają, gdy nie jest to prawdą). Przyjmują za oczywiste, że adapto-
ry takie jak i można stosować z funktorami (podrozdział  Zagad-
nienie 40. opisuje problemy wynikające z niespełnienia tego założenia). Zakładają
również, że operator dodawania ( ) dodaje (za wyjątkiem ciągów znaków, ale opera-
tor ten jest już od dawna używany do łączenia ciągów), operator odejmowania ( )
odejmuje, a operator porównania ( ) porównuje obiekty. W końcu przyjmują za oczy-
wiste, że zastosowanie funkcji jest równoznaczne z zastosowaniem operatora
mniejszości ( ).
Zagadnienie 42. Upewnij się, że less() oznacza operator<() 221
Operator mniejszości jest nie tylko domyślną implementacją funkcji , ale we-
dług założeń programistów definiuje on sposób działania tej funkcji. Jeżeli funkcji
nakażemy robić coś innego niż wywołanie operatora mniejszości ( ), pogwałci-
my w ten sposób oczekiwania programistów. To całkowicie zaprzecza  zasadzie
najmniejszego zaskoczenia  takie działanie jest nieprzyzwoite, bezduszne i złe. Tak
robić nie wolno.
Nie wolno tego robić, szczególnie dlatego, że nie ma ku temu powodów. W bibliotece
STL nie ma miejsca, w którym nie można by zastąpić funkcji innym rodzajem
porównania. Wracając do naszego początkowego przykładu (czyli kontenera
sortowanego według prądkości maksymalnej), aby osiągnąć zamierzony
cel, musimy jedynie utworzyć klasą-funktor wykonującą potrzebne nam porównanie.
Można ją nazwać prawie dowolnie, jednak na pewno nie można zastosować nazwy
. Oto przykład takiej klasy:







Tworząc nasz kontener, jako funkcją porównującą wykorzystamy klasą
i w ten sposób unikniemy wykorzystania domyślnej funkcji porównującej, czyli
.

Powyższy kod wykonuje dokładnie te operacje. Tworzy on kontener typu
elementów posortowanych zgodnie z definicją zawartą w klasie .
Porównajmy to z kodem:

Tworzy on kontener typu elementów posortowanych w sposób
domyślny. Oznacza to, że do porównań wykorzystywana bądzie funkcja ,
jednak każdy programista założy w tym miejscu, że odpowiadać za to bądzie operator
mniejszości ( ).
Nie utrudniajmy życia innym, zmieniając domyślną definicją funkcji . Niech
każde zastosowanie funkcji (bezpośrednie lub pośrednie) wiąże sią z wykorzy-
staniem operatora mniejszości. Jeżeli chcesz posortować obiekty za pomocą innego
kryterium, zbuduj do tego specjalną klasą-funktor i nie nazywaj jej . To prze-
cież takie proste.