[ Pobierz całość w formacie PDF ]
IDZ DO
PRZYK£ADOW
C++. 50 efektywnych
sposobów na udoskonalenie
Twoich programów
SPIS TRECI
KATALOG KSI¥¯EK
Autor: Scott Meyers
T³umaczenie: Miko³aj Szczepaniak
ISBN: 83-7361-345-5
Tytu³ orygina³
to Improve Your Programs and Design
Format: B5, stron: 248
KATALOG ONLINE
ZAMÓW DRUKOWANY KATALOG
TWÓJ KOSZYK
Pierwsze wydanie ksi¹¿ki „C++. 50 efektywnych sposobów na udoskonalenie twoich
programów” zosta³o sprzedane w nak³adzie 100 000 egzemplarzy i zosta³o
przet³umaczone na cztery jêzyki. Nietrudno zrozumieæ, dlaczego tak siê sta³o.
Scott Meyers w charakterystyczny dla siebie, praktyczny sposób przedstawi³ wiedzê
typow¹ dla ekspertów — czynnoci, które niemal zawsze wykonuj¹ lub czynnoci,
których niemal zawsze unikaj¹, by tworzyæ prosty, poprawny i efektywny kod.
Ka¿da z zawartych w tej ksi¹¿ce piêædziesiêciu wskazówek jest streszczeniem metod
pisania lepszych programów w C++, za odpowiednie rozwa¿ania s¹ poparte
konkretnymi przyk³adami. Z myl¹ o nowym wydaniu, Scott Meyers opracowa³
od pocz¹tku wszystkie opisywane w tej ksi¹¿ce wskazówki. Wynik jego pracy jest
wyj¹tkowo zgodny z miêdzynarodowym standardem C++, technologi¹ aktualnych
kompilatorów oraz najnowszymi trendami w wiecie rzeczywistych aplikacji C++.
Do najwa¿niejszych zalet ksi¹¿ki „C++. 50 efektywnych sposobów na udoskonalenie
twoich programów” nale¿¹:
• Eksperckie porady dotycz¹ce projektowania zorientowanego obiektowo,
projektowania klas i w³aciwego stosowania technik dziedziczenia
• Analiza standardowej biblioteki C++, w³¹cznie z wp³ywem standardowej biblioteki
szablonów oraz klas podobnych do string i vector na strukturê dobrze napisanych
programów
• Rozwa¿ania na temat najnowszych mo¿liwoci jêzyka C++: inicjalizacji sta³ych
wewn¹trz klas, przestrzeni nazw oraz szablonów sk³adowych
• Wiedza bêd¹ca zwykle w posiadaniu wy³¹cznie dowiadczonych programistów
Ksi¹¿ka „C++. 50 efektywnych sposobów na udoskonalenie twoich programów”
pozostaje jedn¹ z najwa¿niejszych publikacji dla ka¿dego programisty pracuj¹cego z C++.
Scott Meyers jest znanym autorytetem w dziedzinie programowania w jêzyku C++;
zapewnia us³ugi doradcze dla klientów na ca³ym wiecie i jest cz³onkiem rady
redakcyjnej pisma C++ Report. Regularnie przemawia na technicznych konferencjach na
ca³ym wiecie, jest tak¿e autorem ksi¹¿ek „More Effective C++” oraz „Effective C++ CD”.
W 1993. roku otrzyma³ tytu³ doktora informatyki na Brown University.
DODAJ DO KOSZYKA
CENNIK I INFORMACJE
ZAMÓW INFORMACJE
O NOWOCIACH
ZAMÓW CENNIK
CZYTELNIA
FRAGMENTY KSI¥¯EK ONLINE
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
Spis treci
Przedmowa ................................................................................................................... 7
Podzikowania............................................................................................................ 11
Wstp......................................................................................................................... 15
Przejcie od jzyka C do C++....................................................................................... 27
Sposób 1. Wybieraj const i inline zamiast #define......................................................................28
Sposób 2. Wybieraj <iostream> zamiast <stdio.h>.....................................................................31
Sposób 3. Wybieraj new i delete zamiast malloc i free...............................................................33
Sposób 4. Stosuj komentarze w stylu C++..................................................................................34
Zarzdzanie pamici.................................................................................................. 37
Sposób 5. U(ywaj tych samych form w odpowiadaj)cych sobie zastosowaniach
operatorów new i delete..............................................................................................38
Sposób 6. U(ywaj delete w destruktorach dla składowych wska,nikowych..............................39
Sposób 7. Przygotuj si1 do działania w warunkach braku pami1ci.............................................40
Sposób 8. Podczas pisania operatorów new i delete trzymaj si1 istniej)cej konwencji..............48
Sposób 9. Unikaj ukrywania „normalnej” formy operatora new................................................51
Sposób 10. Je6li stworzyłe6 własny operator new, opracuj tak(e własny operator delete............53
Konstruktory, destruktory i operatory przypisania......................................................... 61
Sposób 11. Deklaruj konstruktor kopiuj)cy i operator przypisania dla klas
z pami1ci) przydzielan) dynamicznie........................................................................61
Sposób 12. Wykorzystuj konstruktory do inicjalizacji, a nie przypisywania warto6ci.................64
Sposób 13. Umieszczaj składowe na li6cie inicjalizacji w kolejno6ci zgodnej
z kolejno6ci) ich deklaracji.........................................................................................69
Sposób 14. Umieszczaj w klasach bazowych wirtualne destruktory............................................71
Sposób 15. Funkcja operator= powinna zwraca; referencj1 do *this...........................................76
Sposób 16. Wykorzystuj operator= do przypisywania warto6ci do wszystkich składowych klasy......79
Sposób 17. Sprawdzaj w operatorze przypisania, czy nie przypisujesz warto6ci samej sobie......82
Klasy i funkcje — projekt i deklaracja.......................................................................... 87
Sposób 18. Staraj si1 d)(y; do kompletnych i minimalnych interfejsów klas..............................89
Sposób 19. Rozró(niaj funkcje składowe klasy, funkcje nieb1d)ce składowymi
klasy i funkcje zaprzyja,nione....................................................................................93
  6
Spis treci
Sposób 20. Unikaj deklarowania w interfejsie publicznym składowych reprezentuj)cych dane........98
Sposób 21. Wykorzystuj stałe wsz1dzie tam, gdzie jest to mo(liwe...........................................100
Sposób 22. Stosuj przekazywanie obiektów przez referencje, a nie przez warto6ci...................106
Sposób 23. Nie próbuj zwraca; referencji, kiedy musisz zwróci; obiekt...................................109
Sposób 24. Wybieraj ostro(nie pomi1dzy przeci)(aniem funkcji
a domy6lnymi warto6ciami parametrów...................................................................113
Sposób 25. Unikaj przeci)(ania funkcji dla wska,ników i typów numerycznych......................117
Sposób 26. Strze( si1 niejednoznaczno6ci...................................................................................120
Sposób 27. Jawnie zabraniaj wykorzystywania niejawnie generowanych funkcji
składowych, których stosowanie jest niezgodne z Twoimi zało(eniami..................123
Sposób 28. Dziel globaln) przestrze@ nazw................................................................................124
Implementacja klas i funkcji...................................................................................... 131
Sposób 29. Unikaj zwracania „uchwytów” do wewn1trznych danych.......................................132
Sposób 30. Unikaj funkcji składowych zwracaj)cych zmienne wska,niki
lub referencje do składowych, które s) mniej dost1pne od tych funkcji..................136
Sposób 31. Nigdy nie zwracaj referencji do obiektu lokalnego ani do wska,nika
zainicjalizowanego za pomoc) operatora new wewn)trz tej samej funkcji .............139
Sposób 32. Odkładaj definicje zmiennych tak długo, jak to tylko mo(liwe...............................142
Sposób 33. Rozwa(nie stosuj atrybut inline................................................................................144
Sposób 34. Ograniczaj do minimum zale(no6ci czasu kompilacji mi1dzy plikami....................150
Dziedziczenie i projektowanie zorientowane obiektowo............................................... 159
Sposób 35. Dopilnuj, by publiczne dziedziczenie modelowało relacj1 „jest” ............................160
Sposób 36. Odró(niaj dziedziczenie interfejsu od dziedziczenia implementacji........................166
Sposób 37. Nigdy nie definiuj ponownie dziedziczonych funkcji niewirtualnych.....................174
Sposób 38. Nigdy nie definiuj ponownie dziedziczonej domy6lnej warto6ci parametru............176
Sposób 39. Unikaj rzutowania w dół hierarchii dziedziczenia....................................................178
Sposób 40. Modeluj)c relacje posiadania („ma”) i implementacji z wykorzystaniem,
stosuj podział na warstwy.........................................................................................186
Sposób 41. Rozró(niaj dziedziczenie od stosowania szablonów................................................189
Sposób 42. Dziedziczenie prywatne stosuj ostro(nie..................................................................193
Sposób 43. Dziedziczenie wielobazowe stosuj ostro(nie............................................................199
Sposób 44. Mów to, o co czym naprawd1 my6lisz. Zdawaj sobie spraw1 z tego, co mówisz....213
Rozmaitoci.............................................................................................................. 215
Sposób 45. Miej 6wiadomo6;, które funkcje s) niejawnie tworzone i wywoływane przez C++.......215
Sposób 46. Wykrywanie bł1dów kompilacji i ł)czenia jest lepsze
od wykrywania bł1dów podczas wykonywania programów....................................219
Sposób 47. Upewnij si1, (e nielokalne obiekty statyczne s) inicjalizowane przed ich u(yciem.......222
Sposób 48. Zwracaj uwag1 na ostrze(enia kompilatorów...........................................................226
Sposób 49. Zapoznaj si1 ze standardow) bibliotek) C++...........................................................227
Sposób 50. Pracuj bez przerwy nad swoj) znajomo6ci) C++.....................................................234
Skorowidz................................................................................................................. 239
Dziedziczenie
i projektowanie
zorientowane obiektowo
Wielu programistów wyraa opini, e moliwo dziedziczenia jest jedyn korzyci
płync z programowania zorientowanego obiektowo. Mona mie oczywicie róne
zdanie na ten temat, jednak liczba zawartych w innych czciach tej ksiki sposobów
powiconych efektywnemu programowaniu w C++ pokazuje, e masz do dyspozycji
znacznie wicej rozmaitych narzdzi, ni tylko okrelanie, które klasy powinny dzie-
dziczy po innych klasach.
Projektowanie i implementowanie hierarchii klas róni si od zasadniczo od wszyst-
kich mechanizmów dostpnych w jzyku C. Problem dziedziczenia i projektowania
zorientowanego obiektowo z pewnoci zmusza do ponownego przemylenia swojej
strategii konstruowania systemów oprogramowania. Co wicej, jzyk C++ udostpnia
bardzo szeroki asortyment bloków budowania obiektów, włcznie z publicznymi,
chronionymi i prywatnymi klasami bazowymi, wirtualnymi i niewirtualnymi klasami
bazowymi oraz wirtualnymi i niewirtualnymi funkcjami składowymi. Kada z wy-
mienionych własnoci moe wpływa take na pozostałe komponenty jzyka C++.
W efekcie, próby zrozumienia, co poszczególne własnoci oznaczaj, kiedy powinny
by stosowane oraz jak mona je w najlepszy sposób połczy z nieobiektowymi cz-
ciami jzyka C++ moe niedowiadczonych programistów zniechci.
Dalsz komplikacj jest fakt, e róne własnoci jzyka C++ s z pozoru odpowie-
dzialne za te same zachowania. Oto przykłady:
Potrzebujesz zbioru klas zawierajcych wiele elementów wspólnych.
Powiniene wykorzysta mechanizm dziedziczenia i stworzy klasy
potomne wzgldem jednej wspólnej klasy bazowej czy powiniene
wykorzysta szablony i wygenerowa wszystkie potrzebne klasy
ze wspólnym szkieletem kodu?
  160
Dziedziczenie i projektowanie zorientowane obiektowo
Klasa A ma zosta zaimplementowana w oparciu o klas B. Czy A powinna
zawiera składow reprezentujc obiekt klasy B czy te powinna prywatnie
dziedziczy po klasie B?
Potrzebujesz projektu bezpiecznej pod wzgldem typu i homogenicznej klasy
pojemnikowej, która nie jest dostpna w standardowej bibliotece C++ (list
pojemników
udostpnianych
przez t bibliotek podano, prezentujc sposób 49.).
Czy lepszym rozwizaniem bdzie skonstruowanie szablonów czy budowa
bezpiecznych pod wzgldem typów interfejsów wokół tej klasy, która sama
byłaby zaimplementowana za pomoc ogólnych (
) wska3ników?
W sposobach prezentowanych w tej czci zawarłem wskazówki, jak naley znajdo-
wa odpowiedzi na powysze pytania. Nie mog jednak liczy na to, e uda mi si
znale3 właciwe rozwizania dla wszystkich aspektów projektowania zorientowane-
go obiektowo. Zamiast tego skoncentrowałem si wic na wyjanianiu, co
faktycznie
oznaczaj poszczególne własnoci jzyka C++ i co tak
naprawd
sygnalizujesz, sto-
sujc poszczególne dyrektywy czy instrukcje. Przykładowo, publiczne dziedziczenie
oznacza relacj „jest” lub specjalizacji-generalizacji (ang.
isa
, patrz sposób 35.) i jeli
musisz nada mu jakikolwiek inny sens, moesz napotka pewne problemy. Podobnie,
funkcje wirtualne oznaczaj, e „interfejs musi by dziedziczony”, natomiast funkcje
niewirtualne oznaczaj, e „dziedziczony musi by zarówno interfejs,
jak i
imple-
mentacja”. Brak rozrónienia tych znacze: doprowadził ju wielu programistów C++
do trudnych do opisania nieszcz.
Jeli rozumiesz znaczenia rozmaitych własnoci jzyka C++, odkryjesz, e Twój po-
gld na projektowanie zorientowane obiektowo powoli ewoluuje. Zamiast przekonywa
Ci o istniejcych rónicach pomidzy konstrukcjami jzykowymi, tre poniszych
sposobów ułatwi Ci ocen jakoci opracowanych dotychczas systemów oprogramo-
wania. Bdziesz potem w stanie przekształci swoj wiedz w swobodne i właciwe
operowanie własnociami jzyka C++ celem tworzenia jeszcze lepszych programów.
Wartoci wiedzy na temat znacze: i konsekwencji stosowania poszczególnych kon-
strukcji nie da si przeceni. Ponisze sposoby zawieraj szczegółow analiz metod
efektywnego stosowania omawianych własnoci jzyka C++. W sposobie 44. podsu-
mowałem cechy i znaczenia poszczególnych konstrukcji obiektowych tego jzyka.
Tre tego sposobu naley traktowa jak zwie:czenie całej czci, a take zwizłe
streszczenie, do którego warto zaglda w przyszłoci.
Sposób 35.
Dopilnuj, by publiczne dziedziczenie
modelowało relacj „jest”
Sposób 35. Dopilnuj, by publiczne dziedziczenie modelowało relacj „jest”
William Dement w swojej ksice pt.
Some Must Watch While Some Must Sleep
(W. H. Freeman and Company, 1974) opisał swoje dowiadczenia z pracy ze studen-
tami, kiedy próbował utrwali w ich umysłach najistotniejsze tezy swojego wykładu.
[ Pobierz całość w formacie PDF ]