Język C++. Gotowe rozwiązania dla programistów

Język C++. Gotowe rozwiązania dla programistów

• 1.
  IDZ DO PRZYK£ADOWY ROZDZIA£ SPIS TRE CI Jêzyk C++. Gotowe rozwi¹zania dla programistów KATALOG KSI¥¯EK Autor: Matthew Wilson T³umaczenie: Zbigniew Banach, KATALOG ONLINE Micha³ Dadan, Tomasz Walczak ISBN: 83-7361-841-4 ZAMÓW DRUKOWANY KATALOG Tytu³ orygina³u: Imperfect C++: Practical Solutions for Real-Life Programming Format: B5, stron: 696 TWÓJ KOSZYK DODAJ DO KOSZYKA C++ to popularny i uniwersalny jêzyk programowania. Jednak po d³u¿szym stosowaniu programi ci zaczynaj¹ zauwa¿aæ pewne jego niedoskona³o ci i ograniczenia. System typów, sposób dzia³ania niektórych kompilatorów, zwi¹zki pomiêdzy wska nikami CENNIK I INFORMACJE i tablicami, nieprzewidziane w standardzie zachowania obiektów statycznych i bibliotek dynamicznych to tylko niektóre z nich. Aby je obej æ, nale¿y wykorzystywaæ wiele ZAMÓW INFORMACJE bardzo zaawansowanych i nieznanych wielu programistom metod. O NOWO CIACH Ksi¹¿ka „Jêzyk C++. Gotowe rozwi¹zania dla programistów” to podrêcznik dla tych programistów C++, którzy zaczêli ju¿ dostrzegaæ ograniczenia tego jêzyka ZAMÓW CENNIK i zastanawiaj¹ siê, jak sobie z nimi poradziæ. Autor pokazuje sposoby ujarzmienia z³o¿ono ci jêzyka i uzyskania pe³nej kontroli nad kodem. Przedstawia najpowa¿niejsze wady C++ i sposoby rozwi¹zywania powodowanych przez nie problemów. Opisuje CZYTELNIA równie¿ metody tworzenia stabilniejszego, bardziej uniwersalnego, wydajniejszego i ³atwiejszego w pielêgnacji kodu. FRAGMENTY KSI¥¯EK ONLINE • Wymuszanie za³o¿eñ projektowych • Cykl ¿ycia obiektów • Hermetyzacja zasobów, danych i typów • Modele dostêpu do obiektów • Obs³uga w¹tków • Korzystanie z obiektów statycznych • Konwersja danych i typów • Zarz¹dzanie pamiêci¹ • Sterowanie dzia³aniem kompilatora Wszyscy programi ci, niezale¿nie od stopnia zaawansowania, znajd¹ w tej ksi¹¿ce wiadomo ci, które usprawni¹ i przyspiesz¹ ich pracê. Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: [email protected]
• 2.
  Spis treści Przedmowa ..................................................................................... 11 Prolog. Filozofia praktyka niedoskonałego ....................................... 19 Niedoskonałości, ograniczenia, definicje i zalecenia ......................... 29 Część I Podstawy ......................................................................37 Rozdział 1. Wymuszanie założeń projektowych: ograniczenia, kontrakty i asercje ..................................................... 39 1.1. Kilka oczywistych mądrości ............................................................................... 40 1.2. Kontrakty kompilacji — ograniczenia ................................................................ 41 1.3. Kontrakty wykonawcze: warunki wejściowe, końcowe i niezmienniki ............... 49 1.4. Asercje ................................................................................................................ 56 Rozdział 2. Życie obiektów ............................................................................... 67 2.1. Cykl ycia obiektu ............................................................................................... 67 2.2. Kontrola klientów ................................................................................................ 68 2.3. Dobrodziejstwa list inicjalizacji .......................................................................... 73 Rozdział 3. Hermetyzacja zasobów .................................................................... 81 3.1. Poziomy hermetyzacji zasobów .......................................................................... 81 3.2. Typy POD ........................................................................................................... 82 3.3. Pośrednie typy opakowujące ............................................................................... 84 3.4. Typy RRID .......................................................................................................... 87 3.5. Typy RAII ........................................................................................................... 92 3.6. RAII — podsumowanie ...................................................................................... 95 Rozdział 4. Hermetyzacja danych i typy wartości ............................................... 97 4.1. Poziomy hermetyzacji danych ............................................................................. 98 4.2. Typy wartości a typy egzystencjalne ................................................................... 98 4.3. Klasyfikacja typów wartości ............................................................................... 99 4.4. Typy otwarte ..................................................................................................... 101 4.5. Typy hermetyzowane ........................................................................................ 103 4.6. Typy wartości .................................................................................................... 104 4.7. Arytmetyczne typy wartości .............................................................................. 106 4.8. Typy wartości — podsumowanie ...................................................................... 107 4.9. Hermetyzacja — podsumowanie ....................................................................... 107
• 3.
  6 Język C++. Gotowe rozwiązania dla programistów Rozdział 5. Modele dostępu do obiektów ........................................................ 113 5.1. Gwarantowany czas ycia ................................................................................. 113 5.2. Kopia dla wywołującego ................................................................................... 115 5.3. Oryginał dla wywołującego ............................................................................... 116 5.4. Obiekty współdzielone ...................................................................................... 116 Rozdział 6. Zasięg klas .................................................................................. 119 6.1. Wartość ............................................................................................................. 119 6.2. Stan ................................................................................................................... 124 6.3. API i usługi ....................................................................................................... 128 6.4. Mechanizmy języka ........................................................................................... 132 Część II Przetrwanie w świecie rzeczywistym ............................135 Rozdział 7. ABI .............................................................................................. 137 7.1. Udostępnianie kodu ........................................................................................... 137 7.2. Wymagania ABI C ............................................................................................ 139 7.3. Wymagania ABI C++ ....................................................................................... 144 7.4. C — i wszystko jasne ........................................................................................ 148 Rozdział 8. Obiekty bez granic ........................................................................ 157 8.1. Czy by przenośne tabele funkcji wirtualnych? ................................................. 157 8.2. Przenośne tabele vtable ..................................................................................... 161 8.3. Przenośność — podsumowanie ......................................................................... 169 Rozdział 9. Biblioteki dynamiczne ................................................................... 171 9.1. Jawne wywołania funkcji .................................................................................. 171 9.2. To samość — jednostki i przestrzeń konsolidacji ............................................. 174 9.3. Czas ycia ......................................................................................................... 175 9.4. Wersjonowanie .................................................................................................. 176 9.5. Własność zasobów ............................................................................................ 179 9.6. Biblioteki dynamiczne — podsumowanie ......................................................... 180 Rozdział 10. Wątki ........................................................................................... 181 10.1. Synchronizacja dostępu do wartości całkowitych ............................................. 182 10.2. Synchronizacja dostępu do bloków kodu — regiony krytyczne ........................ 186 10.3. Wydajność operacji atomowych ........................................................................ 190 10.4. Rozszerzenia wielowątkowe ............................................................................. 195 10.5. TSS — składowanie danych w wątkach ............................................................ 199 Rozdział 11. Obiekty statyczne ......................................................................... 207 11.1. Globalne obiekty statyczne ............................................................................... 209 11.2. Singletony ......................................................................................................... 214 11.3. Lokalne obiekty statyczne funkcji ..................................................................... 222 11.4. Składowe statyczne ........................................................................................... 224 11.5. Obiekty statyczne — podsumowanie ................................................................ 227 Rozdział 12. Optymalizacja ............................................................................... 229 12.1. Funkcje inline .................................................................................................... 229 12.2. Optymalizacja wartości zwracanej ..................................................................... 231 12.3. Optymalizacja pustych klas bazowych .............................................................. 234 12.4. Optymalizacja pustych klas potomnych ............................................................ 237 12.5. Zapobieganie optymalizacji .............................................................................. 239
• 4.
  Spis treści 7 Część III Kwestie językowe ........................................................243 Rozdział 13. Typy podstawowe ......................................................................... 245 13.1. Komu bajt? ........................................................................................................ 246 13.2. Typy całkowitoliczbowe o stałym rozmiarze .................................................... 249 13.3. Du e typy całkowitoliczbowe ........................................................................... 255 13.4. Typy niebezpieczne ........................................................................................... 257 Rozdział 14. Tablice i wskaźniki ....................................................................... 263 14.1. Nie powtarzaj się ............................................................................................... 263 14.2. Degeneracja tablic do wskaźników ................................................................... 265 14.3. dimensionof() .................................................................................................... 268 14.4. Nie mo na przekazywać tablic do funkcji ......................................................... 270 14.5. Tablice są zawsze przekazywane przez adres .................................................... 273 14.6. Tablice typów dziedziczonych .......................................................................... 274 14.7. Brak tablic wielowymiarowych ......................................................................... 281 Rozdział 15. Wartości ...................................................................................... 285 15.1. NULL — słowo kluczowe, którego nie było ..................................................... 285 15.2. Spadek do zera .................................................................................................. 292 15.3. Naginanie prawdy ............................................................................................. 294 15.4. Literały .............................................................................................................. 296 15.5. Stałe .................................................................................................................. 302 Rozdział 16. Słowa kluczowe ............................................................................ 311 16.1. interface ............................................................................................................. 311 16.2. temporary .......................................................................................................... 314 16.3. owner ................................................................................................................. 317 16.4. explicit(_cast) .................................................................................................... 321 16.5. unique ................................................................................................................ 326 16.6. final ................................................................................................................... 327 16.7. Nieobsługiwane słowa kluczowe ...................................................................... 328 Rozdział 17. Składnia ....................................................................................... 331 17.1. Układ klasy ....................................................................................................... 331 17.2. Wyra enia warunkowe ...................................................................................... 334 17.3. for ...................................................................................................................... 338 17.4. Zapis zmiennych ............................................................................................... 341 Rozdział 18. Definicja typów za pomocą typedef ................................................ 345 18.1. Definicje typu dla wskaźników ......................................................................... 347 18.2. Co wchodzi w skład definicji? .......................................................................... 349 18.3. Nowe nazwy ...................................................................................................... 354 18.4. Prawdziwe definicje typu .................................................................................. 356 18.5. Dobre, złe i brzydkie ......................................................................................... 361 Część IV Świadome konwersje ...................................................369 Rozdział 19. Rzutowanie ................................................................................... 371 19.1. Niejawna konwersja .......................................................................................... 371 19.2. Rzutowanie w C++ ............................................................................................ 372 19.3. Przypadek rzutowania w stylu C ....................................................................... 373 19.4. Rzutowanie na sterydach ................................................................................... 375 19.5. explicit_cast ...................................................................................................... 377 19.6. literal_cast ......................................................................................................... 382 19.7. union_cast ......................................................................................................... 385
• 5.
  8 Język C++. Gotowe rozwiązania dla programistów 19.8. comstl::interface_cast ........................................................................................ 388 19.9. boost::polymorphic_cast ................................................................................... 399 19.10. Rzutowanie — podsumowanie .......................................................................... 401 Rozdział 20. Podkładki ..................................................................................... 403 20.1. Ogarnąć zmiany i zwiększyć elastyczność ........................................................ 404 20.2. Podkładki atrybutów ......................................................................................... 406 20.3. Podkładki logiczne ............................................................................................ 408 20.4. Podkładki sterujące ........................................................................................... 409 20.5. Podkładki konwertujące ..................................................................................... 411 20.6. Podkładki zło one ............................................................................................. 414 20.7. Przestrzenie nazw a sprawdzenie Koeniga ........................................................ 420 20.8. Dlaczego nie typy cechujące? ........................................................................... 423 20.9. Dopasowanie strukturalne ................................................................................. 424 20.10. Przełamywanie monolitu ................................................................................... 426 20.11. Podkładki — podsumowanie ............................................................................. 428 Rozdział 21. Forniry .......................................................................................... 429 21.1. Lekkie RAII ...................................................................................................... 430 21.2. Wiązanie danych z operacjami .......................................................................... 431 21.3. Przypomnienie zało eń ..................................................................................... 438 21.4. Forniry — podsumowanie ................................................................................. 440 Rozdział 22. Sworznie ...................................................................................... 441 22.1. Dodawanie nowej funkcjonalności .................................................................... 442 22.2. Wybór skóry ...................................................................................................... 442 22.3. Przesłanianie metod niewirtualnych .................................................................. 443 22.4. Wykorzystywanie zasięgu ................................................................................. 445 22.5. Symulowany polimorfizm czasu kompilacji — sworznie wsteczne .................. 447 22.6. Parametryzowalne pakowanie polimorficzne .................................................... 449 22.7. Sworznie — podsumowanie .............................................................................. 451 Rozdział 23. Konstruktory szablonów ................................................................ 453 23.1. Ukryte koszty .................................................................................................... 455 23.2. Wiszące referencje ............................................................................................ 455 23.3. Specjalizacja konstruktorów szablonów ............................................................ 457 23.4. Pośrednictwo argumentów ................................................................................ 458 23.5. Ukierunkowywanie na konkretne rodzaje argumentów .................................... 460 23.6. Konstruktory szablonów — podsumowanie ...................................................... 461 Część V Operatory ....................................................................463 Rozdział 24. operator bool() ............................................................................. 465 24.1. operator int() const ............................................................................................ 465 24.2. operator void *() const ...................................................................................... 466 24.3. operator bool() const ......................................................................................... 467 24.4. operator !() — not! ............................................................................................ 468 24.5. operator boolean const *() const ........................................................................ 468 24.6. operator int boolean::*() const .......................................................................... 469 24.7. Stosowanie operatorów w praktyce ................................................................... 469 24.8. operator! ............................................................................................................ 473 Rozdział 25. Szybkie i nieinwazyjne łączenie ciągów znaków ............................. 475 25.1. fast_string_concatenator<> ............................................................................... 476 25.2. Wydajność ......................................................................................................... 484 25.3. Praca z innymi klasami obsługującymi ciągi znaków ....................................... 487
• 6.
  Spis treści 9 25.4. Inicjalizacja łączenia ......................................................................................... 488 25.5. Patologiczne nawiasowanie ............................................................................... 489 25.6. Standaryzacja .................................................................................................... 490 Rozdział 26. Jaki jest Twój adres? .................................................................... 491 26.1. Nie mo na pobrać rzeczywistego adresu ........................................................... 491 26.2. Co dzieje się w czasie konwersji? ..................................................................... 494 26.3. Co zwracać? ...................................................................................................... 496 26.4. Jaki jest Twój adres — podsumowanie ............................................................. 498 Rozdział 27. Operatory indeksowania ................................................................ 501 27.1. Przekształcanie wskaźników i operatory indeksowania .................................... 501 27.2. Obsługa błędów ................................................................................................. 504 27.3. Zwracana wartość .............................................................................................. 506 Rozdział 28. Operatory inkrementacji ................................................................ 509 28.1. Brakujące operatory przyrostkowe ....................................................................... 510 28.2. Wydajność ......................................................................................................... 511 Rozdział 29. Typy arytmetyczne ........................................................................ 515 29.1. Definicja klasy .................................................................................................. 515 29.2. Konstruktor domyślny ....................................................................................... 516 29.3. Inicjalizacja (nadawanie wartości) ..................................................................... 517 29.4. Konstruktor kopiujący ....................................................................................... 519 29.5. Przypisanie ........................................................................................................ 519 29.6. Operatory arytmetyczne .................................................................................... 520 29.7. Operatory porównania ....................................................................................... 520 29.8. Dostęp do wartości ............................................................................................ 521 29.9. Klasa SInteger64 ............................................................................................... 521 29.10. Obcinanie, promocja do większego typu i testowanie warunków ..................... 522 29.11. Typy arytmetyczne — podsumowanie .............................................................. 525 Rozdział 30. Skrócona ewaluacja ...................................................................... 527 Część VI Rozszerzanie możliwości języka C++ ............................529 Rozdział 31. Czas życia wartości zwracanej ...................................................... 531 31.1. Klasyfikacja problemów związanych z czasem ycia wartości zwracanej ........ 532 31.2. Do czego słu y zwracanie przez referencję? ..................................................... 533 31.3. Rozwiązanie pierwsze — szablon integer_to_string<> ..................................... 533 31.4. Rozwiązanie drugie — mechanizm TSS ........................................................... 536 31.5. Rozwiązanie trzecie — rozszerzanie RVL ........................................................ 541 31.6. Rozwiązanie czwarte — statyczne określanie rozmiaru tablicy ......................... 543 31.7. Rozwiązanie piąte — podkładki konwertujące ................................................. 545 31.8. Wydajność ......................................................................................................... 547 31.9. RVL — wielkie zwycięstwo automatycznego przywracania pamięci ............... 548 31.10. Potencjalne zastosowania .................................................................................. 549 31.11. RVL — podsumowanie ..................................................................................... 549 Rozdział 32. Pamięć ......................................................................................... 551 32.1. Rodzaje pamięci ................................................................................................ 551 32.2. Najlepsze w obu rodzajach ................................................................................ 553 32.3. Alokatory .......................................................................................................... 565 32.4. Pamięć — podsumowanie ................................................................................. 569
• 7.
  10 Język C++. Gotowe rozwiązania dla programistów Rozdział 33. Tablice wielowymiarowe ................................................................ 571 33.1. Udostępnianie składni indeksowania ................................................................. 572 33.2. Określanie rozmiaru w czasie wykonywania programu .................................... 573 33.3. Określanie rozmiaru na etapie kompilacji ......................................................... 579 33.4. Dostęp blokowy ................................................................................................ 582 33.5. Wydajność ......................................................................................................... 586 33.6. Tablice wielowymiarowe — podsumowanie .................................................... 589 Rozdział 34. Funktory i zakresy ........................................................................ 591 34.1. Bałagan składniowy .......................................................................................... 591 34.2. Funkcja for_all() ............................................................................................... 592 34.3. Funktory lokalne ............................................................................................... 595 34.4. Zakresy .............................................................................................................. 604 34.5. Funktory i zakresy — podsumowanie ............................................................... 612 Rozdział 35. Właściwości ................................................................................. 613 35.1. Rozszerzenia kompilatora ................................................................................. 615 35.2. Sposoby implementacji ..................................................................................... 616 35.3. Właściwości pola .............................................................................................. 617 35.4. Właściwości metody ......................................................................................... 624 35.5. Właściwości statyczne ....................................................................................... 638 35.6. Właściwości wirtualne ...................................................................................... 642 35.7. Zastosowania właściwości ................................................................................ 642 35.8. Właściwości — podsumowanie ........................................................................ 645 Dodatki .......................................................................647 Dodatek A Kompilatory i biblioteki ................................................................. 649 A.1. Kompilatory ...................................................................................................... 649 A.2. Biblioteki ........................................................................................................... 651 A.3. Inne źródła ........................................................................................................ 653 Dodatek B Pycha w końcu Cię zgubi! ............................................................. 655 B.1. Przecią anie operatora ...................................................................................... 656 B.2. Jak zawiodło DRY ............................................................................................ 657 B.3. Programowanie paranoiczne ............................................................................. 657 B.4. Do szaleństwa i jeszcze dalej ............................................................................ 658 Dodatek C Arturius ........................................................................................ 661 Dodatek D Płyta CD ....................................................................................... 663 Epilog ........................................................................................... 665 Bibliografia ................................................................................... 667 Skorowidz ..................................................................................... 675
• 8.
  Rozdział 4. Hermetyzacja danych itypy wartości W poprzednim rozdziale omawialiśmy hermetyzację zasobów jako proces odmienny od hermetyzacji danych. Hermetyzacja zasobów dotyczy bardziej samego mechanizmu ni zawartości zasobów, natomiast hermetyzację danych mo na w uproszczeniu zdefiniować odwrotnie (choć w konkretnych przypadkach to rozró nienie często ulega rozmyciu). Hermetyzacja danych niesie ze sobą tradycyjne zalety klasycznej, obiektowej herme- tyzacji: 1. Spójność danych. Stan instancji obiektu mo na zainicjalizować tak, by utworzyć poprawną całość. Wszelkie modyfikacje instancji za pośrednictwem metod interfejsu są atomowe, co oznacza, e stan składowych będzie spójny przed wywołaniem metody i po jego zakończeniu. 2. Zmniejszenie zło oności. Kod kliencki operuje na instancjach obiektów za pośrednictwem dokładnie zdefiniowanego publicznego interfejsu i nie musi (a w dodatku nie potrzebuje) znać poziomu wewnętrznej zło oności typu. 3. Odporność na zmiany. Kod kliencki jest niezale ny od wewnętrznych zmian wprowadzanych w implementacji typu. Mo liwe jest te działanie na kilku ró nych typach o podobnych interfejsach publicznych, ale ró nych postaciach wewnętrznych. Klasy implementujące hermetyzację danych mogą równie implementować hermetyzację zasobów (dobrym przykładem są wszelkie klasy napisów), ale w przypadku zasobów chodzi przede wszystkim o sposób hermetyzacji, podczas gdy my zajmiemy się teraz samymi danymi. Dalszym rozwinięciem hermetyzacji danych są typy wartości. W rozdziale omówimy ró nicę między typami wartości (ang. value types) a typami egzystencjalnymi (ang. entity types) i przyjrzymy się dokładnie cechom wyró niającym typy wartości. Zoba- czymy te , jak ró ne poziomy hermetyzacji wpływają na definicje typów wartości.
• 9.
  98 Część I ♦ Podstawy 4.1. Poziomy hermetyzacji danych W poprzednim rozdziale poznaliśmy ró ne poziomy hermetyzacji zasobów, od otwar- tych struktur z dostępem poprzez funkcje API po klasy całkowicie hermetyczne. Poziomom hermetyzacji danych odpowiadają dostępne w C++ specyfikatory dostępu. Dane niehermetyzowane są dostępne dla dowolnego innego kontekstu i są definiowane w bloku RWDNKE klasy (lub w bloku domyślnym struktury lub unii). W pełni hermetyczne dane są definiowane w bloku RTKXCVG lub RTQVGEVGF typu klasowego. Przy niewielkiej ilości przykładów mo e się wydawać, e istnieje ścisły związek mię- dzy poziomem hermetyzacji a stopniem, w jakim dany typ jest typem wartości. Nie jest to jednak regułą i nie musi istnieć adna bezpośrednia relacja między tymi własnościa- mi. Jest to tylko kolejna myląca kombinacja cech i dobrze mieć świadomość ró nicy między tymi dwoma pojęciami. 4.2. Typy wartości a typy egzystencjalne Ujmując rzecz mo liwie najprościej — i jest to moja prywatna, robocza definicja — typy wartości mo na opisać jako rzeczy, które po prostu są, a typy egzystencjalne jako rzeczy, które coś robią. Bjarne Stroustrup podaje świetną definicję typów wartości, nazywając je typami kon- kretnymi1: „Ich celem jest robienie jednej małej rzeczy dobrze i wydajnie. Na ogół nie dają mo liwości modyfikacji swego zachowania”. Langer i Kreft [Lang2002] podają bardziej precyzyjne definicje. Typami wartości są „typy posiadające zawartość, których zachowanie nieodłącznie zale y od tej zawarto- ści. Na przykład dwa łańcuchy znakowe zachowują się ró nie, jeśli ró nią się zawar- tością, a zachowują się tak samo przy takiej samej zawartości (a ich porównywanie wykazuje równość). Zawartość jest ich najwa niejszą cechą”. Istotne jest podkreślenie, e równość jest wa niejsza od to samości, co moim zdaniem stanowi jeden z najwa - niejszych wyró ników typów wartości. Langer i Kreft definiują typy egzystencjalne jako takie typy, „których zachowanie jest w du ej mierze niezale ne od zawartości. Zachowanie jest ich najwa niejszą cechą”. Tym samym sprawdzanie równości typów egzystencjalnych jest, ogólnie rzecz biorąc, działaniem bezcelowym. Osobiście wolę prostotę mojej własnej definicji (có za nie- spodzianka), ale kwalifikacja typów zawarta w definicji Langera i Krefta jest istotna. 1 Dla mnie typ konkretny to taki, dla którego mo na tworzyć instancje, czyli typ kompletny (bo widać definicję) i nieabstrakcyjny (nie ma adnych metod czysto wirtualnych do wypełnienia). eby było śmieszniej, nawet w przypadku typu abstrakcyjnego istnieją ró ne definicje. Znowu ból mózgu.
• 10.
  Rozdział 4. ♦Hermetyzacja danych i typy wartości 99 W kontekście tego rozdziału będę traktował pojęcie typu egzystencjalnego jako jednolite, choć w rzeczywistości obejmuje ono wielką ró norodność typów, w tym co najmniej typy konkretne, abstrakcyjne, polimorficzne i niepolimorficzne. Wiele z tych pojęć zo- stanie omówionych osobno w dalszych częściach ksią ki. W pozostałej części tego rozdziału przyjrzymy się typom wartości i spróbujemy usta- lić, czy mo na mówić o tylko jednym ich rodzaju. Jak zwykle zamierzam twierdzić, e jest inaczej. 4.3. Klasyfikacja typów wartości Bjarne Stroustrup [Stro1997] definiuje semantykę wartości (w przeciwieństwie do semantyki wskaźników) jako niezale ność skopiowanych typów. Daje to nam świetną podstawę, ale nie wystarczy do definicji. Eugene Gershnik, jeden z recenzentów tej ksią ki, ma własną, niezale ną od języka definicję typów wartości. Dany typ jest typem wartości, jeśli: 1. Instancję mo na utworzyć jako kopię innej instancji lub później ją taką kopią uczynić. 2. Ka da instancja ma własną to samość. Zmiana jednej instancji nie powoduje wprowadzenia zmian w innej instancji. 3. Instancja nie mo e polimorficznie zastąpić instancji innego typu w czasie wykonania ani być przez taką instancję zastąpiona. Powy sza definicja jest atrakcyjna, ale zdecydowanie zbyt szeroka jak na mój gust. W dalszej części tego rozdziału nieco ją zawęzimy. Jednym z mo liwych podejść do typów wartości jest ocena, czy i w jakim stopniu za- chowują się rozsądnie. Czego na przykład moglibyśmy się spodziewać po poni szych wyra eniach? 5VTKPI UVT 2KGTYQVP[ PCRKU 5VTKPI UVT 0KGFQUMQPC [ 5VTKPI UVT % EJCT EQPUV
• 11.
  EU UVTEAUVT UVT UVT UVT wyra enie 1 KH UVT ] _ wyra enie 2 UVT'ORV[ wyra enie 3 UVT wyra enie 4 Moim zdaniem wyra enie 1. spowodowałoby sklejenie UVT, i UVT (w tej kolej- ności). Wynik zostałby umieszczony w UVT, powodując nadpisanie, rozszerzenie lub zastąpienie zakresu pamięci, w którym w chwili utworzenia UVT został zapisany ciąg
• 12.
  100 Część I ♦ Podstawy 2 2KGTYQVP[ PCRKU . Stwierdziłbym te , e z chwilą zakończenia wyra enia 1. wskaźnik EU stałby się niepoprawny i dalsze korzystanie z niego prowadziłoby do zachowania nieokreślonego (oczywiście nie byłoby tego problemu, gdyby metoda 5VTKPIEAUVT była zadeklarowana jako VGORQTCT[ [patrz punkt 16.2], gdy przypisanie byłoby wtedy niedopuszczalne). Typowym rozumieniem wyra enia 2. byłoby wykonanie bloku pod warunkiem, e UVT „nie ma”. Problem polega na ustaleniu, co dokładnie oznacza to „niebycie” — mo e chodzi o brak zawartości, mo e o zawieranie pustego ciągu , a mo e o jedno i drugie? Zresztą równie dobrze mo e chodzić o zawierania ciągu HCNUG ! Takie wyra enie jest niejednoznaczne, a wieloznaczność jest najgorszym wrogiem poprawności i łatwości pielęgnacji. Niestety, nieraz widywałem identyczne konstrukcje w kodzie produkcyjnym. Trzecie polecenie mo e oznaczać „opró nij UVT”, ale równie dobrze mo e znaczyć „zwróć wartość wskazującą, czy ciąg UVT jest pusty”3. Osobiście wybrałbym zawsze pierwsze znaczenie wyra enia, rozumując zgodnie z zasadą, e nazwami typów i zmien- nych są rzeczowniki, a nazwami metod i funkcji czasowniki. Niestety, biblioteka stan- dardowa nie zgadza się ze mną w tej kwestii, a trudno się nie zgadzać z biblioteką stan- dardową4. Wyra enie 4. jest pozbawione sensu, gdy nie przychodzi mi do głowy aden rozsądny sposób inkrementacji ciągu znaków w C++5 (dodatek B przytacza historię z zamierzchłych czasów, gdy takich zahamowań nie miałem). W przypadku typów wbudowanych nie ma problemu z przewidywalnością zachowa- nia, gdy jest ono z góry określone i nienaruszalne. Tworząc własne typy, mamy zatem obowiązek zapewnienia przewidywalności ich działania ze zdefiniowanymi operato- rami. Ka dy, kto napisze na przykład typ całkowitoliczbowy o zwiększonej precyzji i zdefiniuje QRGTCVQT jako dzielenie modulo, zostanie nieuchronnie zlinczowany. Typy z zało enia traktowane jak wartości powinny w miarę mo liwości zachowywać się „tak jak KPV-y” [Meye1996]. W pozostałej części rozdziału przyjrzymy się całemu spektrum typów wartości. Wyró - niam tu cztery poziomy: 1. Typy otwarte — zwykłe struktury z funkcjami API. 2. Typy hermetyzowane — częściowo lub całkowicie hermetyzowane typy klasowe, obsługiwane za pośrednictwem metod. 2 Jest to wprawdzie wygodne, ale stosowanie operatora do napisów jest pewnym nadu yciem. Dodawanie jest operacją arytmetyczną i stosowanie jej do ciągów znakowych jest pierwszym krokiem na krętej i niebezpiecznej ście ce (patrz dodatek B). W rozdziale 25. zignoruję jednak moje własne zastrze enia w pogoni za chwałą zwycięzcy. 3 Problem polega tu na niejednoznaczności słowa empty w nazwie metody. W pierwszym rozumieniu mo e to być forma rozkazująca czasownika, czyli polecenie opró nij, natomiast w drugim rozumieniu jest to przymiotnik pusty — przyp. tłum. 4 W przypadku bibliotek STLSoft musiałem przełknąć swoje zasady i dostosować się do większości: małe litery, podkreślenia, GORV[ itd. 5 W Perlu i niektórych innych językach skryptowych występuje inkrementacja ciągów znakowych polegająca na dokonaniu interpretacji numerycznej ciągu, zwiększeniu wyniku o jeden i konwersji z powrotem na ciąg znaków. W przypadku Perla jest to jak najbardziej na miejscu, ale kod C++ takich rzeczy wyprawiać nie powinien.
• 13.
  Rozdział 4. ♦Hermetyzacja danych i typy wartości 101 3. Typy wartości — całkowicie hermetyzowane typy klasowe, w tym operatory przypisania, równości i nierówności. 4. Arytmetyczne typy wartości — u ywane do wartości numerycznych, w tym wszystkie operatory arytmetyczne. W zale ności od punktu widzenia, za typy wartości mo na uznać wszystkie powy sze typy lub tylko dwa ostatnie. W klasyfikacji umieściłem jednak wszystkie, gdy odpo- wiadają one odrębnym i stosowanym w praktyce przedziałom spektrum. 4.4. Typy otwarte 4.4.1. Otwarte typy POD Typami otwartymi nazwiemy typy proste o publicznie dostępnych składowych, najczę- ściej pozbawione metod — innymi słowy, są to agregaty (C++98: 8.5.1; 1). Rozwa my typ WKPVGIGT: UVTWEV WKPVGIGT ] WKPVAV NQYGT8CN WKPVAV WRRGT8CN _ Jest to struktura bardzo prosta i niemal całkowicie bezu yteczna. Jako taka stanowi świetny przykład otwartego typu wartości, gdy , ogólnie rzecz biorąc, typy takie nie- specjalnie nadają się do u ytku. Korzystanie z typów otwartych w charakterze typów wartości wymaga niezwykłej cier- pliwości. Nie mogą one brać udziału w prostych porównaniach, a wykonywanie na nich działań arytmetycznych wymaga ręcznego operowania na ich składowych. WKPVGIGT K WKPVGIGT K DQQN D.GUU K K błąd kompilacji! DQQN D'SWCN K K błąd kompilacji! WKPVGIGT K K K błąd kompilacji! Powinniśmy jednak być wdzięczni językowi, e z marszu odrzuca wszystkie te ope- ratory, gdy w ten sposób chroni nas ju podczas kompilacji. Porównywanie według składowych byłoby bardzo niebezpieczne — prawdopodobnie dałoby się w wielu przy- padkach określić poprawną równość czy te nierówność, ale skąd kompilator miałby znać priorytety operatorów w sprawdzaniu mniejszości? (Warto wiedzieć, e dla zacho- wania zgodności wstecznej ze strukturami kompilator dopuszcza konstruktory kopiu- jące i przypisanie kopiujące [patrz podrozdział 2.2]). Pomimo powa nych problemów z praktycznym korzystaniem z typów otwartych, czasa- mi praca z nimi jest nieunikniona, najczęściej podczas łączenia się z API systemu opera- cyjnego lub biblioteki, na przykład w celu uzyskania dostępu do operacji arytmetycznych
• 14.
  102 Część I ♦ Podstawy o zwiększonej precyzji [Hans1997]. W celach instrukta owych załó my, e z jakichś względów musimy jednak korzystać ze zdefiniowanych wcześniej 64-bitowych liczb całkowitych. W takiej sytuacji trzeba utworzyć API do wykonywania operacji na tych typach. XQKF 7+A#UUKIP WKPVGIGT
• 15.
  NJU WKPVAV JKIJGT WKPVAV NQYGT XQKF 7+A#FF WKPVGIGT
• 16.
  TGUWNV WKPVGIGT EQPUV
• 17.
  NJU WKPVGIGT EQPUV
• 18.
  TJU XQKF 7+AKXKFG WKPVGIGT
• 19.
  TGUWNV WKPVGIGT EQPUV
• 20.
  NJU WKPVGIGT EQPUV
• 21.
  TJU KPV 7+A%QORCTG WKPVGIGT EQPUV
• 22.
  NJU WKPVGIGT EQPUV
• 23.
  TJU FGHKPG 7+A+U.GUU6JCP RK RK 7+A%QORCTG RK RK FGHKPG 7+A+U'SWCN RK RK 7+A%QORCTG RK RK FGHKPG 7+A+U)TGCVGT6JCP RK RK 7+A%QORCTG RK RK Z pomocą takiego API, mo emy zaimplementować pierwotny kod w całkowicie legalny sposób: WKPVGIGT K WKPVGIGT K DQQN D.GUU 7+A+U.GUU6JCP K K DQQN D'SWCN 7+A+U'SWCN K K WKPVGIGT K 7+A#FF K K K Straszne rzeczy. Na szczęście C++ umo liwia nam znaczne ulepszenie tego rozwiązania. 4.4.2. Struktury danych C++ Zanim wszyscy pobiegniemy do naszego kodu źródłowego i w obiektowym amoku zaczniemy nerwowo zamieniać ka de UVTWEV na ENCUU, musimy sobie uświadomić, e dotychczas omówiliśmy tylko te otwarte typy danych, w których poszczególne składo- we stanowią logiczną całość, a wprowadzanie zmian w indywidualnych składowych stanowi ewidentne zagro enie dla stanu logicznego całej struktury. Istnieją jednak typy otwarte, na których mo na wykonywać takie operacje i które tym samym nie stanowią adnego zagro enia. Odró nianie typów bezpiecznych od nie- bezpiecznych opiera się na stwierdzeniu, czy wprowadzanie zmian w poszczególnych składowych prowadzi do naruszenia znaczenia całości. Spójrzmy na następujący typ określający walutę: UVTWEV %WTTGPE[ ] KPV OCLQT7PKV dolary, złotówki KPV OKPQT7PKV centy, grosze _ Jest to przykład niebezpiecznego typu otwartego, gdy istnieje mo liwość podania war- tości składowej OKPQT7PKV, która uczyni całą instancję typu %WTTGPE[ logicznie błędną. Z kolei poni szy typ jest idealnym przykładem całkowicie bezpiecznego typu otwartego:
• 24.
  Rozdział 4. ♦Hermetyzacja danych i typy wartości 103 UVTWEV 2CVTQP ] 5VTKPI PCOG nazwisko %WTTGPE[ YCNNGV zasobność portfela _ Nie ma nierozerwalnego związku między nazwiskiem a zawartością portfela, stąd te wprowadzenie dowolnej zmiany w polu PCOG lub YCNNGV nie prowadzi do adnego oczy- wistego naruszenia spójności logicznej typu 2CVTQP. Takie typy nazywane są strukturami danych C++ [Stro1997]. Jak zawsze w przypadku rozgraniczeń istnieje tu pewna szara strefa, ale powy sze dwa przykłady są całkowicie jednoznaczne: jeden jest czarny, a drugi biały. 4.5. Typy hermetyzowane Otwarte typy wartości POD są kruchymi tworami, a ich zastosowanie ogranicza się do przypadków, w których korzystanie z pojęć wy szego poziomu jest ewidentnie szko- dliwe dla innych wymagań, na przykład wydajności, współpracy między językami czy łączenia typów. Wydaje się oczywistym, e większość typów nie jest u yteczna, dopóki nie odpowiadają one co najmniej kolejnemu poziomowi, jakim są typy hermetyzowane (poni szą definicję mo na w równym stopniu stosować do typów egzystencjalnych). Definicja: Typy hermetyzowane umożliwiają odczyt i modyfikację stanu instancji obiek- tu za pośrednictwem odpowiedniego interfejsu publicznego. Kod kliencki nie powinien (i nie potrzebuje) mieć bezpośredniego dostępu do składowych takich typów. Typy hermetyzowane pozwalają pojęciowo odgraniczyć stan logiczny od fizycznego. Ogólnie rzecz biorąc, typy hermetyzowane pozwalają w większym stopniu ukryć imple- mentację (niekiedy całkowicie), co zapewnia bezpieczeństwo, oraz dostarczają metody bezpiecznego dostępu do odpowiedniej reprezentacji wartości. Operacje na składowych NQYGT8CN i WRRGT8CN naszego przykładowego typu WKPVGIGT mogłyby się odbywać za pośrednictwem metod klasy w rodzaju #FF , #UUKIP itp. Korzystanie z metod daje kontrolę dostępu i modyfikacji wewnętrznego stanu instancji, stąd te mo liwe jest narzu- canie niezmienników klas (podrozdział 1.3), co pozwala znacznie podnieść jakość kodu. Typy mogą te udostępniać metody obsługi typowych lub spodziewanych operacji, by uniknąć ręcznego ich tworzenia w kodzie klienckim. Niestety, zbiór takich operacji jest zawsze otwarty, nawet jeśli (jako dobrzy obywatele) zachowujemy ortogonalność typu. Efekt ten mo na nieco złagodzić, stosując wolne funkcje w miejsce metod klas wszędzie tam, gdzie jest to mo liwe [Meye2000]. Klasowa implementacja naszego przykładowego typu będzie wyglądać mniej więcej tak jak pokazana na listingu 4.1 klasa 7+PVGIGT. Zawiera ona zmienne składowe typu WKPVGIGT, co pozwala wykorzystać gotowe funkcje zdefiniowanego wcześniej API).
• 25.
  104 Część I ♦ Podstawy Listing 4.1. ENCUU 7+PVGIGT ] RWDNKE 7+PVGIGT 7+PVGIGT WKPVAV NQY 7+PVGIGT WKPVAV JKIJ WKPVAV NQY KHFGH #%/'.+$A%1/2+.'4A57221465A$+6A+06 7+PVGIGT WKPVAV NQY GPFKH
• 26.
  ACMELIB_COMPILER_SUPPORTS_64BIT_INT
• 27.
  7+PVGIGT 7+PVGIGT EQPUV TJU porównania RWDNKE UVCVKE DQQN +U.GUU6JCP 7+PVGIGT EQPUV K 7+PVGIGT EQPUV K UVCVKE DQQN +U'SWCN 7+PVGIGT EQPUV K 7+PVGIGT EQPUV K UVCVKE DQQN +U)TGCVGT6JCP 7+PVGIGT EQPUV K 7+PVGIGT EQPUV K operacje arytmetyczne RWDNKE UVCVKE 7+PVGIGT /WNVKRN[ 7+PVGIGT EQPUV K 7+PVGIGT EQPUV K UVCVKE 7+PVGIGT KXKFG 7+PVGIGT EQPUV K 7+PVGIGT EQPUV K RTKXCVG WKPVGIGT OAXCNWG _ 4.6. Typy wartości Po typach hermetyzowanych ju tylko mały krok dzieli nas od typów, które uwa am za prawdziwe typy wartości. Głównym wyró nikiem typu wartości jest moim zdaniem mo liwość porównywania, czyli posiadanie cechy EqualityComparable [Aust1999, Muss2001]. Oznacza to zwracanie sensownych wyników porównań pod względem równości i nierówności, zgodnie z definicją Langera-Krefta [Lang2002] (patrz pod- rozdział 4.2). Dla typów klasowych kompilator nie udostępnia domyślnie operatorów porównania, więc musimy je zdefiniować samodzielnie. Przede wszystkim potrzebujemy typów, które zachowują się rozsądnie. Główny problem typów hermetyzowanych polega na niemo ności ich u ycia w kodzie wykorzystującym porównania pod względem równości. Szczególnie istotna jest mo liwość umieszczania typów wartości w kontenerach składujących według wartości, w tym w kontenerach biblioteki standardowej. Mo emy wprawdzie tworzyć instancje kontenera UVFXGEVQT 7+PVGIGT i operować nimi, gdy kontener nie nakłada ograniczeń co do unikalno- ści składowanych elementów, jednak nie mo emy wyszukiwać instancji naszego typu za pomocą standardowego algorytmu UVFHKPF : UVFXGEVQT7+PVGIGT XK XKRWUJADCEM K
• 28.
  Rozdział 4. ♦Hermetyzacja danych i typy wartości 105 XKRWUJADCEM K XKRWUJADCEM K UVFHKPF XKUVCTV XKGPF 7+PVGIGT błąd! brak operatora == dla UInteger64 (UVFXGEVQT przechowuje elementy bez porządkowania, więc nie ma potrzeby defi- niowania operatora do porównania porządkującego). Przekształcenie naszego typu w typ wartości będzie bardzo proste. W poprzedniej implementacji 7+PVGIGT zdefiniowaliśmy metodę +U'SWCN , którą mo emy teraz wykorzystać do definicji operatorów równości i nierówności: KPNKPG DQQN QRGTCVQT 7+PVGIGT EQPUV K 7+PVGIGT EQPUV K ] TGVWTP 7+PVGIGT+U'SWCN K K _ KPNKPG DQQN QRGTCVQT 7+PVGIGT EQPUV K 7+PVGIGT EQPUV K ] TGVWTP QRGTCVQT K K _ Dodatkową zaletą takiego podejścia jest fakt, e uczyniliśmy typ pełnym typem warto- ści przez dodanie funkcji nieskładowych [Meye2000]. Funkcje te poprzednio nie istniały, stąd te na pewno nie istnieje aden kod wymagający ich obecności (lub nieobecności) i tym samym osiągnęliśmy cel bez tworzenia jakichkolwiek problemów pielęgnacyj- nych (przytyk odautorski: to właśnie bezmyślne wciskanie wszystkiego do klas jest powodem niekontrolowanego puchnięcia wielu środowisk programistycznych i nie- sprawiedliwych opinii na temat braku wydajności C++). Mo emy zatem powrócić do naszej definicji typu wartości i zaproponować następującą jej postać6: Definicja: Typ wartości Instancje obiektów nie mogą polimorficzne zastępować instancji innego typu w czasie uruchamiania ani być przez nie zastępowane. Instancje można tworzyć jako kopie innych instancji lub je takimi kopiami później uczynić. Każda instancja ma samodzielną tożsamość logiczną. Zmiana stanu logicznego jednej instancji nie wpływa na stan logiczny innej (stan fizyczny może być współdzielony, jeśli tak wskazują decyzje projektowe dla danej implementacji, ale tylko pod warunkiem, że nie wpływa to na niezależność logiczną). Instancje można porównywać z dowolnymi innymi instancjami (w tym z samymi sobą) pod względem równości i nierówności. Obie te relacje są zwrotne, symetryczne i prze- chodnie. 6 Eugene twierdzi, e wymaganie sprawdzania równości nie jest konieczne, więc nie mogę ochrzcić definicji mianem definicji typu wartości Gershnika-Wilsona, jak by to gładko nie spływało z języka.
• 29.
  106 Część I ♦ Podstawy 4.7. Arytmetyczne typy wartości Ostatni krok naszej wspinaczki po drabinie typów wartości polega na dodaniu obsługi typowych operatorów arytmetycznych, co pozwoli naszemu przykładowemu typowi uczestniczyć w tradycyjnych działaniach, na przykład: WKPVGIGT K WKPVGIGT K DQQN D.GUU K K w porządku DQQN D'SWCN K K w porządku WKPVGIGT K K K w porządku K K K K
• 30.
  K Najpierw zajmiemy się operatorem mniejszości QRGTCVQT , gdy dzięki niemu stanie się mo liwe porządkowanie instancji typu. Mo liwość porównywania pod względem mniejszości jest określana mianem własności LessThanComparable [Aust1999] i jest nieodzowną cechą typów obsługiwanych przez STL — zgodnie ze standardem, jest to jedyna cecha wymagana. Przyznaję, e mam osobistą skłonność do korzystania wy- łącznie z tego porównania, nawet jeśli oznacza to pisanie mniej czytelnego kodu, na przykład pisanie CUUGTV UKG KPFGZ zamiast CUUGTV KPFGZ UKG . Nie jestem jednak wcale pewien, czy jest to praktyka godna polecenia. Mo emy zatem dodać operator mniejszości do dotychczasowej definicji naszego typu, implementując go (podobnie jak w przypadku operatorów równości i nierówności) jako funkcję nieskładową. Instancje tak zdefiniowanego typu 7+PVGIGT mo emy ju umiesz- czać w kontenerach biblioteki standardowej, na przykład UVFUGV czy UVFOCR. W ten sam sposób mo na dodać wiele innych operatorów arytmetycznych, ale ich wybór zale y od konkretnego typu. Tworzony przez nas typ 7+PVGIGT jest typem całkowi- toliczbowym, stąd te wskazane byłoby zdefiniowanie wszystkich operatorów, a więc , ,
• 31.
  , , ,`, , , , ^, @ i odpowiadających im operatorów przypisania (w rozdzia- le 29. przyjrzymy się sposobom optymalnego implementowania takich operatorów). Świetnym przykładem definicji wolnych operatorów jest klasa szablonowa VTWGAV[RGFGH (podrozdział 18.4), w której wszystkie operatory arytmetyczne dla klasy są zdefinio- wane jako wolne funkcje. Tak samo mo emy postępować w przypadku innych typów. Najwa niejszą kwestią jest zdefiniowanie tylko tych operatorów, które mają sens. Po- wracając do przykładu typu %WTTGPE[ określającego walutę, z pewnością chcielibyśmy mieć mo liwość dodawania i odejmowania instancji %WTTGPE[ za pomocą operatorów i , ale ju mno enie nie miałoby większego sensu (na przykład $6.50 razy 2.93 PLN). Z kolei przydałaby się mo liwość przemno enia instancji %WTTGPE[ przez liczbę, ale ju dodawanie i odejmowanie liczb nie byłoby potrzebne. Oczywiście C++ pozwala zdefiniować dowolny operator dla dowolnej klasy i przypi- sać mu dowolne działanie, co mo e stanowić przedmiot karygodnych nadu yć (patrz dodatek B). W pierwszym przykładzie tego rozdziału widzieliśmy klasę 5VTKPI ze zde- finiowanymi operatorami i . U ywanie operatora do łączenia łańcuchów znako-
• 32.
  Rozdział 4. ♦Hermetyzacja danych i typy wartości 107 wych jest błędem,7 gdy nie oblicza on sumy arytmetycznej argumentów. Jest to jednak tak przydatne zastosowanie, e niemal wszyscy przymykamy oko na jego niemoral- ność i rozkoszujemy się wygodą (mo e i jest ono wygodne, ale na pewno nie wydajne; w rozdziale 25. zobaczymy, e mo na tę operację znacząco przyspieszyć). Nadu ywanie operatorów jest wprawdzie szeroko akceptowaną praktyką, ale mimo to jest paskudnym zwyczajem i nale y unikać tej pokusy. Wiem, bo sam niegdyś zgrze- szyłem. Bardzo zgrzeszyłem (patrz dodatek B). 4.8. Typy wartości — podsumowanie Gdy przyglądam się spektrum typów wartości, nasuwa mi się ciekawa analogia z iterato- rami STL. Najtrudniejszym do naśladowania iteratorem jest iterator dostępu bezpośred- niego, ale obsługują go wskaźniki, w których implementacji wyręcza nas sam język. Podobnie najtrudniejszym w implementacji pojęciem spośród mo liwych typów warto- ści jest typ arytmetyczny, który z kolei jest domyślnym typem dla podstawowych typów całkowitoliczbowych. Potęga C++ przejawia się w zezwoleniu nam na własnoręczne definiowanie takich pojęć. Mo na te zadumać się nad faktem, e naszym szczytowym osiągnięciem jest określenie składni najbardziej podstawowych z typów. 4.9. Hermetyzacja — podsumowanie Du o mówiliśmy o teoretycznych aspektach typów wartości, ale pozostaje jeszcze kwestia hermetyzacji takich typów. Z podręczników dowiemy się, e jako sumienni, obiektowi obywatele powinniśmy zawsze całkowicie hermetyzować typy. Niestety, rzeczywistość rzadko bywa taka prosta. Zaproponuję siedem mo liwych implementacji typu 7+PVGIGT, z których tylko trzy są w pełni hermetyzowane. Wybór odpowiedniej w danym zastosowaniu postaci zale y od odpowiedzi na trzy podstawowe pytania. Czy potrzebujemy implementacji bazującej na istniejącym API w C lub z nim współpra- cującej? Jeśli tak, to nasza implementacja będzie musiała zawierać istniejącą strukturę (postać 2.) lub po niej dziedziczyć (postać 3.), gdy tylko w ten sposób mo emy prze- kazywać odpowiednie elementy klasy do API w C8. Jeśli nie, to wystarczy zawieranie składowych struktury (postać 1.). 7 Jest to kolejne moje kontrowersyjne stwierdzenie, za które prawdopodobnie nieźle mi się oberwie. Musimy jednak pamiętać, e popularność ani nawet przydatność nie są równoznaczne z poprawnością, a ta ksią ka dostarcza licznych tego przykładów. 8 Przynajmniej bez uciekania się do dyrektyw pakujących, rzutowania i innych paskudnych sztuczek. Lepiej skorzystać z samej struktury C.
• 33.
  108 Część I ♦ Podstawy Listing 4.2. postać #1 ENCUU 7+PVGIGT ] metody i operatory typu wartości RTKXCVG WKPVAV NQYGT8CN WKPVAV WRRGT8CN _ postać #2 ENCUU 7+PVGIGT ] metody i operatory typu wartości RTKXCVG WKPVGIGT OAXCNWG _ postać #3 ENCUU 7+PVGIGT RTKXCVG WKPVGIGT ] metody i operatory typu wartości _ Z premedytacją wybrałem jako przykład 64-bitowe liczby całkowite, gdy w rzeczywi- stej implementacji mogę oszukiwać, korzystając z konwersji z i na prawdziwe 64-bitowe liczby całkowite, które są u ywane do faktycznej realizacji operacji arytmetycznych. Gdybyśmy chcieli obsłu yć dowolnych rozmiarów liczby całkowite korzystające z API C (opisane na przykład w [Hans1997]), to musielibyśmy pracować na strukturach C. Czy wszystkie operacje mo na hermetyzować w ramach typu? Jeśli tak, to do zapew- nienia pełnej hermetyzacji wystarczy prawdopodobnie zadeklarowanie wewnętrznej implementacji jako RTKXCVG (postacie 1 – 3). Jeśli nie, to interakcja z innymi funkcjami czy typami będzie wymagała ujawnienia jakiejś części stanu wewnętrznego (w przy- padku typów mo emy skorzystać z deklaracji typów zaprzyjaźnionych za pomocą mo- dyfikatora HTKGPF — patrz punkt 2.2.9). W ustaleniu, czy konieczne jest ujawnianie szczegółów implementacji na zewnątrz, pomo e kilka pytań pomocniczych. Czy będziemy tworzyć typ unikalny, czy jeden z wielu podobnych? Klasycznym przykła- dem mo e tu być obsługa czasu. W samym C mamy VKOGAV, UVTWEV VO, UVTWEV VKOGXCN, #6', (+.'6+/', 5;56'/6+/' i wiele innych typów czasowych, a jeśli dodatkowo uwzględnić typy C++, lista będzie praktycznie nieograniczona. Któ nie implementował własnego typu czasu czy daty? Jeśli nasz typ jest takim właśnie jednym z wielu, to musimy uwzględnić ewentualną potrzebę interakcji i wzajemnej konwersji z typami ju istniejącymi. Czy potrzebujemy interakcji z interfejsem w stylu C? W świecie idealnym odpowiedź brzmiałaby zawsze „nie”, ale w świecie rzeczywistym jest nią często „tak”. Ka da chyba implementacja klasy daty będzie bazować na jednym z typów C, gdy w przeciwnym
• 34.
  Rozdział 4. ♦Hermetyzacja danych i typy wartości 109 razie musielibyśmy ręcznie przepisywać cały skomplikowany, mudny i podatny na błędy kod do obsługi kalendarza. Mo e komuś lata przestępne, kalendarz gregoriański albo poprawki orbitalne? Dziękuję bardzo. Tylko jak się upewnić, e nasza hermetyza- cja objęła wszystkie potrzebne funkcje? Społeczność C++, ogólnie rzecz biorąc, ignoruje wszelkie informacje związane z tą kwestią. Moim zdaniem z wielką szkodą dla całej społeczności twórców oprogramowa- nia.9 Producenci narzędzi skwapliwie unikają wyprowadzania programistów z błędu, bo im bardziej programista przyzwyczai się do pracy z jakąś „naprawdę przydatną kla- są”, tym mniej będzie się interesować alternatywnymi rozwiązaniami. Implikacje takie- go przyzwyczajenia wykraczają daleko poza preferowanie jednego, wybranego środo- wiska. Z pewnością ka dy miał do czynienia z projektami nieodwracalnie związanymi z określonym systemem operacyjnym tylko dlatego, e programiści nie chcieli (lub nie potrafili) wykroczyć poza ramy konkretnego środowiska tworzenia aplikacji. Jest to potę na niedoskonałość C++, z którą rozprawimy się bezlitośnie w części drugiej. W wielu zastosowaniach praktycznych ewidentnie nie mamy wyboru i musimy się za- dowolić częściową hermetyzacją. Mo na ją osiągnąć na kilka sposobów. Najprościej byłoby zmienić specyfikator dostępu z RTKXCVG na RWDNKE (postacie 4 – 6), ale spowo- dowałoby to ujawnienie całej zawartości klasy. Listing 4.3. postać #4 ENCUU 7+PVGIGT ] metody i operatory typu wartości RWDNKE WKPVAV NQYGT8CN WKPVAV WRRGT8CN _ postać #5 ENCUU 7+PVGIGT ] metody i operatory typu wartości RWDNKE WKPVGIGT OAXCNWG _ postać #6 ENCUU 7+PVGIGT RWDNKE WKPVGIGT ] metody i operatory typu wartości _ 9 Niektórzy recenzenci tej ksią ki narzekali nawet, e w publikacji ewidentnie poświęconej C++ nie powinienem omawiać przykładów kodu zgodnego z C.
• 35.
  110 Część I ♦ Podstawy Istnieją sposoby nieco bardziej dyskretnego ujawniania informacji. Dobrze sprawdzają się tu funkcje dostępowe, ale są one wyjątkowo nieestetyczne: postać #6 ENCUU 7+PVGIGT RTKXCVG WKPVGIGT ] metody i operatory typu wartości RWDNKE WKPVGIGT IGVAWKPVGIGT WKPVGIGT EQPUV IGVAWKPVGIGT EQPUV brzydkie! _ Mo na te paskudztwa nieco ugładzić, odpowiednio definiując operator GZRNKEKVAECUV, któremu przyjrzymy się dokładniej w podrozdziałach 16.4 i 19.5. Listing 4.4. postać #7 ENCUU 7+PVGIGT RTKXCVG WKPVGIGT ] metody i operatory typu wartości RWDNKE QRGTCVQT GZRNKEKVAECUVWKPVGIGT QRGTCVQT GZRNKEKVAECUVWKPVGIGT EQPUV EQPUV _ W ten sposób zapobiegamy niejawnemu dostępowi do wnętrza klasy, zapewniając jed- nocześnie dostęp jawny. Inną mo liwością jest dodanie do klasy osobnej metody dla ka dej operacji API, którą chcemy udostępnić u ytkownikom klasy nadrzędnej. Z zagadnieniem tym są ściśle związane kolejne dwa pytania, pozwalające dodatkowo sprecyzować kryteria wyboru rozwiązania: Czy względy wydajności będą wymagać naruszenia ortogonalności? Mo e się zdarzyć, e niektóre przydatne operacje na naszych typach będą stanowić logiczną kombinację dwóch prostszych operacji, ale połączenie ich w jedną całość da znaczny przyrost wy- dajności. Co gorsza, takie łączenie jest niekiedy dokonywane wyłącznie dla wygody. Jak by na to nie patrzeć, jest to pierwszy krok na drodze do opasłych klas o przera a- jącej ilości metod (patrz UVFDCUKEAUVTKPI ). Prawidłowy wybór w tej kwestii zale y od konkretnego sytuacji, ale trzeba pamiętać, by faworyzować wydajność tylko w przy- padku metod stanowiących autentyczne wąskie gardła. Wszelkie decyzje nale y podej- mować na podstawie faktycznych pomiarów, a nie instynktu (w tej kwestii dość często omylnego). Czy mo emy być pewni uniknięcia dołączania plików podczas konsolidacji i kompilacji? Jest to kolejny niedostatecznie omówiony aspekt projektowania klas. Jeśli całą imple- mentację typu mo na wydajnie zapisać w postaci definicji wbudowanej, to w ogóle nie musimy się przejmować dołączaniem podczas konsolidacji. Dołączanie takie obejmuje implementacje funkcji skompilowane osobno w ramach tej samej jednostki konsolida- cji lub umieszczone w zewnętrznych bibliotekach (statycznych bądź dynamicznych).
• 36.
  Rozdział 4. ♦Hermetyzacja danych i typy wartości 111 Tak czy inaczej musimy jeszcze pomyśleć o plikach dołączanych podczas kompilacji, czyli wszystkich plikach niezbędnych do kompilacji danej klasy. Ironią losu jest to, e zmniejszenie ilości plików dołączanych podczas konsolidacji często zwiększa ilość pli- ków dołączanych podczas kompilacji. Niestety, trudno jest uniknąć dołączania podczas kompilacji, a im bardziej staramy się zapewnić przenośność, tym więcej plików trzeba dołączać. Powodem tego jest koniecz- ność obsłu enia niestandardowych typów (podrozdział 13.2), funkcji kompilatorów, konwencji wywołania (rozdział 7.) i tym podobnych. Wszelkie tego typu moduły są (zupełnie rozsądnie) umieszczane w osobnych, dokładnie przetestowanych plikach nagłówkowych, które rozrastają się w miarę dojrzewania poszczególnych rozwiązań. Pozwala to scentralizować obsługę ró nych architektur, kompilatorów, systemów ope- racyjnych i bibliotek. Jak widać, hermetyzacja danych nie jest sprawą oczywistą, stąd te (podobnie jak w przy- padku wielu innych zagadnień omawianych w tej ksią ce) jedyną uniwersalną zasadą jest pamiętanie o wszystkich poruszonych kwestiach. Zakres działania tworzonych przez nas klas nie powinien być ograniczony do środowiska, w którym je piszemy, a poniewa klasy nie myślą, więc to my powinniśmy myśleć za nie.