|
|
| Linia 4: |
Linia 4: |
| | {Inteligentne wskaźniki} | | {Inteligentne wskaźniki} |
| | | | |
| − | ==Wstęp==
| + | '''Zadanie 1 ''' Napisz testy sprawdzające działanie szablony |
| | + | inteligentnego wskaźnika opartego na zliczaniu referencji. |
| | | | |
| − | Wskaźniki to jeden z bardziej pożytecznych elementów języka C/C++, ale
| + | '''Zadanie 2 ''' Napisz klasę wytyczna do wskaźnika <code><nowiki> Ref_ptr</nowiki></code> opartą o |
| − | napewno najbardziej niebezpieczny. Zabawa z gołymi wskaźnikami
| + | listę referencji. |
| − | przypomina żonglerkę odbezpieczonymi granatami. To nie jest już
| |
| − | kwestia, czy nastąpi wybuch, ale tego, kiedy on nastąpi. Możliwości
| |
| − | wywołania wybuchu i jego konsekwencje są wielorakie:
| |
| − | * Możemy usunąć wskaźnik, nie zwalniając pamięci, na którą on
| |
| − | wskazuje. Jeśli żaden inny wskaźnik nie wskazuje na ten obszar, to
| |
| − | jest on bezpowrotnie stracony dla naszej aplikacji i mamy do
| |
| − | czynienia z wyciekiem pamięci.
| |
| − | * Możemy zwolnić ten sam obszar pamięci kilkakrotnie.
| |
| − | Powoduje to zwykle krach całej aplikacji.
| |
| − | * Podobnie, jeśli spróbujemy zdereferencjonować wskaźniki
| |
| − | zerowe (<code><nowiki> null</nowiki></code>).
| |
| − | * No i oczywiście mamy całe spektrum możliwości sięgnięcia za
| |
| − | pomocą wskaźnika tam, gdzie nie powinniśmy, odczytując lub co gorsza,
| |
| − | zmieniając, nie te zmienne co trzeba.
| |
| − |
| |
| − | Jeśli więc nie czujemy się jak Rambo albo sam Chuck
| |
| − | Norris, to powinniśmy poszukać jakiś zabezpieczeń. W C++
| |
| − | zabezpieczenia są dostarczane poprzez możliwość definicji własnych
| |
| − | typów. Dzięki klasom możemy nie korzystać z dynamicznej alokacji
| |
| − | pamięci bezpośrednio, ale za pośrednictwem klas, które dbają o alokację
| |
| − | w konstruktorach, dealokację w destruktorach, zwiększają i
| |
| − | zmmniejszają pamięć na żądanie, itp. Przykładem takiego podejścia są
| |
| − | np. kontenery STL, których jedną z zalet, jest właśnie zarządzanie
| |
| − | własną pamięcią. Jeśli jednak ciągle potrzebujemy wskaźników, to możemy
| |
| − | rozważyć opakowanie ich w klasy. Jest to możliwe dzięki możliwościom,
| |
| − | jakie w C++ daje przeładowywanie operatorów. W szczególności możemy
| |
| − | przeładowywać operatory dereferencjonowania <code><nowiki> operator*()</nowiki></code> i
| |
| − | <code><nowiki> operator->()</nowiki></code>. W ten sposób możemy upodobnić zachowanie
| |
| − | definiowanych przez nas typów, do zachowania wskaźników.
| |
| − | Takie typy nazywamy inteligentnymi wskaźnikami, ponieważ dostarczają
| |
| − | nam dodatkowej funkcjonalności ponad zwykłe zachowanie wskaźnika.
| |
| − | | |
| − | Tak jak i u ludzi rodzaje inteligencji wskaźników bywają różne;
| |
| − | inteligente wskaźniki występują w najróżniejszych wariacjach. Podział
| |
| − | tych wariantów można przeprowadzić na wiele sposobów, ja skoncentruję
| |
| − | się na dwóch grupach:
| |
| − | * Zachowanie wskaźników podczas kopiowania, przypisywania
| |
| − | i niszczenia. Nazwiemy to prawami własności.
| |
| − | * Zachowanie się operatorów <code><nowiki> operator*()</nowiki></code> i <code><nowiki> operator->()</nowiki></code>.
| |
| − | Nazwiemy to kontrolą dostępu.
| |
| − |
| |
| − | Poniżej krótko przedstawię przegląd głównych możliwości w każdej z
| |
| − | powyższych grup.
| |
| | | | |
| − | ==Prawa własności==
| + | '''Zadanie 3 ''' Napisz klasę wytyczną do wskaźnika <code><nowiki> ref_ptr</nowiki></code> opartą o licznik we wskazywanym obiekcie. Załóż, że obiekty wskazywane dziedziczą z klasy: |
| | | | |
| − | Głównym powodem używania inteligentnych wskaźników jest uzyskanie
| + | <nowiki> class Handle { |
| − | kontroli nad operacjami kopiowania, przypisywania i niszczenia
| + | private: |
| − | wskaźnika. W tym kontekście mówimy często, że wskaźnik jest albo nie
| + | size_t _count; |
| − | jest właścicielem obiektu, na który wskazuje. Poniżej przedstawiam cztery
| |
| − | typowe schematy wskaźników.
| |
| − | | |
| − | ====Głupie wskaźniki====
| |
| − | | |
| − | Zwykłe (nieinteligentne) wskaźniki nie są właścicielami obiektów, na
| |
| − | którę wskazują. Kopiowanie czy przypisanie, prowadzi do współdzielenia
| |
| − | referencji (oba wskaźniki wskazują na ten sam obiekt), często
| |
| − | niezamierzonej. Zniszczenie wskaźnika nie powoduje
| |
| − | zniszczenia (dealokacji pamięci) obiektu na który on wskazuje.
| |
| − | Przedstawia to rysunek [[##fig:ptr_vulgaris|Uzupelnic fig:ptr_vulgaris|]] na którym zilustrowano
| |
| − | przebieg wykonania kodu:
| |
| − | | |
| − | <nowiki> void f() {
| |
| − | X *px( new X);
| |
| − | X py(px);
| |
| − | X pz(new X);
| |
| − | pz = py;
| |
| − | }
| |
| − | | |
| − | f();
| |
| − | </nowiki>
| |
| − | | |
| − | [width<nowiki> =</nowiki> ]{mod11/graphics/vulgaris.eps}
| |
| − |
| |
| − | {Zwykłe wskaźniki.}
| |
| − |
| |
| − | ====Zliczanie referencji====
| |
| − | | |
| − | Wskaźniki zliczające referencje są niejako właścicielami grupowymi
| |
| − | obiektu, na który wskazują. Kopiowanie i przypisanie powoduje
| |
| − | współdzielnie referencji, ale kontrolowane, w tym sensie, że
| |
| − | monitorowana jest liczba wskaźników do danego obiektu. Na zasadzie
| |
| − | "ostatni gasi światło" zniszczenie wskaźnika powoduje zniszczenie
| |
| − | obiektu wtedy, gdy był to jedyny (ostatni) wskaźnik na ten obiekt.
| |
| − | Liczenie referencji reprezentuje więc prostą wersję "odśmieczacza"
| |
| − | (garbage-collector). Zachowanie się tego typu wskaźników prezentuje
| |
| − | rysunek [[##fig:ptr_reference|Uzupelnic fig:ptr_reference|]] w oparciu o analogiczny kod:
| |
| − | | |
| − | <nowiki> void f() {
| |
| − | ref_ptr<X> px(new X);
| |
| − | ref_ptr<X> py(px);
| |
| − | ref_ptr<X> pz(new X);
| |
| − | pz = py;
| |
| − | }
| |
| − | | |
| − | f();
| |
| − | </nowiki>
| |
| − | | |
| − | [width<nowiki> =</nowiki> ]{mod11/graphics/reference.eps}
| |
| − |
| |
| − | {Wskaźniki zliczające referencje.}
| |
| − |
| |
| − | ====Głęboka/fizyczna kopia====
| |
| − | | |
| − | Takie wskaźniki są pojedynczymi właścicielami obiektów na które
| |
| − | wskazują i zachowują się jak wartości, a nie, wskaźniki. Kopiowanie bądź
| |
| − | przypisanie powoduje fizyczne kopiowanie obiektu wskazywanego.
| |
| − | Zniszczenie wskaźnika powoduje zniczenie wskazywanego obiektu. Od
| |
| − | zwykłych wartości obiektów różnią się tym, że mają zachowanie
| |
| − | polimorficzne i używane są tam, gdzie polimorfizm jest nam potrzebny, a
| |
| − | więc nie możemy użyć bezpośrednio samych obiektów. Zachowanie kodu:
| |
| − | | |
| − | <nowiki> void f() {
| |
| − | clone_ptr<X> px(new X);
| |
| − | clone_ptr<X> py(px);
| |
| − | cloen_ptr<X> pz(new X);
| |
| − | pz = py;
| |
| − | }
| |
| − | | |
| − | f();
| |
| − | </nowiki>
| |
| − | | |
| − | ilustruje rysunek [[##fig:deep_copy|Uzupelnic fig:deep_copy|]].
| |
| − |
| |
| − | [width<nowiki> =</nowiki> ]{mod11/graphics/deep_copy.eps}
| |
| − |
| |
| − | {Wskaźniki wykonujące kopie fizyczne.}
| |
| − |
| |
| − | Zastosowanie wskaźników z głębokim kopiowaniem zilustruję na
| |
| − | przykładzie podanego już wcześniej przykładu z kształtami
| |
| − | geometrycznymi. W programie wykorzystującym takie kształty na pewno
| |
| − | zachodzi konieczność kopiowania kształtów. Załóżmy, że wybraliśmy
| |
| − | (myszką) jakiś kształt i wskaźnik do niego jest przechowywany w
| |
| − | zmiennej <code><nowiki> Shape *selected</nowiki></code>. Załóżmy, że jest to obiekt typy
| |
| − | <code><nowiki> Circle</nowiki></code>. Teraz chcemy uzyskać kopię tego kształtu. Przypisanie
| |
| − | | |
| − | <nowiki> Shape *copy = selected;
| |
| − | </nowiki>
| |
| − | | |
| − | oczywiście nie jest poprawne, bo uzyskamy dwa wskaźniki na jeden obiekt. A
| |
| − | my potrzebujemy drugiego obiektu. Bez koniecznośći polimorfizmu
| |
| − | wystarczyłoby użyć konstruktora kopiującego:
| |
| − | | |
| − | <nowiki> Shape *copy = new Shape(*selected);
| |
| − | </nowiki>
| |
| − | | |
| − | Niestety w naszym przypadku ten kod się nawet nie skompiluje, bo klasa
| |
| − | <code><nowiki> Shape</nowiki></code> jest klasą abstrakcyjną. Nawet gdyby nie była, to i tak
| |
| − | zostałby utworzony obiekt typu <code><nowiki> Shape</nowiki></code> a nie <code><nowiki> Circle</nowiki></code>. W celu
| |
| − | zaimplementowania kopiowania polimorficznego możemy wyposażyć naszą
| |
| − | klasę <code><nowiki> Shape</nowiki></code> w funkcje
| |
| − | | |
| − | <nowiki> virtual Shape *clone() const = 0
| |
| − | </nowiki>
| |
| − | | |
| − | i następnie zdefiniować ją w każdej podklasie:
| |
| − | | |
| − | <nowiki> class Circle :public Shape { | |
| − | ...
| |
| − | Circle *clone() {return new Circle(*this);};
| |
| − | }
| |
| − | </nowiki>
| |
| − | | |
| − | Możemy wtedy skopiować (sklonować) nasz obiekt za pomocą:
| |
| − | | |
| − | <nowiki> Shape *copy = selected->clone();
| |
| − | </nowiki>
| |
| − | | |
| − | Możemy teraz tę technikę, nazywaną również wzorcem prototypu, lub
| |
| − | fabryką klonów (zob. {gamma}), zastosować w implementacji inteligentnego
| |
| − | wskaźnika <code><nowiki> clone_ptr</nowiki></code>:
| |
| − | | |
| − | <nowiki> clone_ptr<Shape> selected;
| |
| − | ...
| |
| − | clone_ptr<Shape> copy(selected);
| |
| − | </nowiki>
| |
| − | | |
| − | ====autoptr====
| |
| − | | |
| − | Wskaźniki <code><nowiki> auto_ptr</nowiki></code> (jedyne inteligentne wskaźniki dostępne w
| |
| − | standardzie C++) są pojedynczymi, bardzo zaborczymi, właścicielami obiektu,
| |
| − | na który wskazują. Tak zaborczymi, że nie dopuszczają możliwości
| |
| − | współdzielenia obiektu ani jego kopiowania. Próba skopiowania, albo
| |
| − | przypisania prowadzi do przekazania własności: obiekt
| |
| − | kopiowany(przypisywany) oddaje/przekazuje prawo własności do
| |
| − | posiadanego obiektu drugiemu obiektowi. Oznacza to, że obiekt
| |
| − | kopiowany lub przypisywany jest zmieniany w trakcie tych operacji.
| |
| − | Ilustruje to rysunek [[##fig:auto_ptr|Uzupelnic fig:auto_ptr|]] na podstawie kodu:
| |
| − | | |
| − | <nowiki> void f() {
| |
| − | auto_ptr<X> px(new X);
| |
| − | auto_ptr<X> py(px);
| |
| − | auto_ptr<X> pz(new X);
| |
| − | pz = py;
| |
| − | }
| |
| − | | |
| − | f();
| |
| − | </nowiki>
| |
| − | | |
| − | [width<nowiki> =</nowiki> ]{mod11/graphics/auto_ptr.eps}
| |
| − |
| |
| − | {Wskaźniki <tt>autoptr</tt>.}
| |
| − |
| |
| − | To bardzo nieintuicyjne zachowanie:
| |
| − | obiekty <code><nowiki> auto_ptr</nowiki></code> nie są modelami konceptu <code><nowiki> Assignable</nowiki></code>.
| |
| − | Wskaźniki te zostały wprowadzone, aby wspomagać bezpieczną alokację
| |
| − | zasobów (głównie pamięci), według wzorca "alokacja zasobów jest
| |
| − | inicjalizacją" {Stroustrup}. Rozważmy następujący przykład:
| |
| − | | |
| − | <nowiki> int f() {
| |
| − | BigX *p = new BigX;
| |
| − | /*... tu coś się dzieje */
| |
| − | delete p;
| |
| − | return wynik;
| |
| − | }
| |
| − | </nowiki>
| |
| − | | |
| − | To typowe zastosowanie dynamicznej alokacji pamięci.
| |
| − | Problem polega na tym, że jeżeli pomiędzy przydziałem pamięci a jej
| |
| − | zwolnieniem coś się stanie, to będziemy mieli wyciek pamięci. To coś,
| |
| − | to może być np. dodatkowe wyrażenie <code><nowiki> return</nowiki></code> lub rzucony wyjątek.
| |
| − | W obu przypadkach zniszczone zostaną wszystkie statycznie zaalokowane
| |
| − | obiekty w tym i wskaźnik <code><nowiki> p</nowiki></code>. Ale ponieważ jest to zwykły wskaźnik
| |
| − | jego zniszczenie nie spowoduje zwolnienia wskazywanej przez niego
| |
| − | pamięci. Rozwiązaniem jest właśnie uczynienie go obiektem będącym właścicielem
| |
| − | wskazywanej pamięci:
| |
| − | | |
| − | <nowiki> int f() {
| |
| − | auto_ptr<BigX> p(new BigX);
| |
| − | | |
| − | /*... tu coś się dzieje */
| |
| − | | |
| − | return wynik;
| |
| − | }
| |
| − | </nowiki>
| |
| − | | |
| − | Teraz przy wyjściu z funkcji zostanie wywołany destruktor <code><nowiki> p</nowiki></code>, a on
| |
| − | zwolni przydzieloną pamięć.
| |
| − | | |
| − | Wzkaźniki <code><nowiki> auto_ptr</nowiki></code> mogą być przekazywane i zwracane z funkcji.
| |
| − | Jeśli przekażemy <code><nowiki> auto_ptr</nowiki></code> do funkcji przez wartość, to
| |
| − | spowodowane tym kopiowanie spowoduje, że własność zostanie przekazana
| |
| − | na argument funkcji i pamięć zostanie zwolniona, kiedy funkcja
| |
| − | zakończy swoje działanie.
| |
| − | | |
| − | <nowiki> template<typename T> void val(T p) {
| |
| − | };
| |
| − | | |
| − | auto_ptr<X> px(new X);
| |
| − | val(px);
| |
| − | /* px zawiera wskaźnik null. pamięć jest zwolniona */
| |
| − | cout<<px.get()<<endl;
| |
| − | /* zwraca opakowany wskaźnik na X, powinnien być zero*/
| |
| − | </nowiki>
| |
| − | | |
| − | Jeśli przekażemy <code><nowiki> auto_ptr</nowiki></code> przez referencje, to kopiowania nie
| |
| − | będzie, przekazanie własności będzie zależeć od tego, czy wkaźnik
| |
| − | zostanie skopiowany lub przypisany wewnątrz funkcji.
| |
| − | | |
| − | <nowiki> template<typename T> void ref_1(T &p) {
| |
| − | T x = p;
| |
| − | };
| |
| − | template<typename T> void ref_2(T &p) {
| |
| − | };
| |
| − | | |
| − | auto_ptr<X> px(new X);
| |
| − | ref_2(px);
| |
| − | /* nic sie nie zmieniło*/
| |
| − | cout<<px.get()<<endl; /* wypisuje jakiś adres*/
| |
| − | ref_1(px)
| |
| − | /* px zawiera wskaźnik null. pamięć jest zwolniona */
| |
| − | cout<<px.get()<<endl;
| |
| − | /* zwraca opakowany wskaźnik na X, powinnien być zero*/
| |
| − | </nowiki>
| |
| − | | |
| − | W przypadku przekazania <code><nowiki> auto_ptr</nowiki></code> jako referencji do stałej sprawa
| |
| − | jest bardziej skomplikowana. Obecny standard stanowi, że wskaźnik
| |
| − | <code><nowiki> auto_ptr</nowiki></code> przekazany jako referencja do stałej nie przekazuje
| |
| − | własności, tzn. operacje, które by to tego prowadziły nie powinny się
| |
| − | skompilować. Z tych samych powodów nie powinien skompilować się kod
| |
| − | używający kontenerów STL zawierających wskaźniki <code><nowiki> auto_ptr</nowiki></code>.
| |
| − | | |
| − | <nowiki> template<typename T> void cref_1(const T &p) {
| |
| − | T x = p;
| |
| − | };
| |
| − | template<typename T> void cref_2(const T &p) {
| |
| − | };
| |
| − | | |
| − | auto_ptr<X> px(new X);
| |
| − | cref_2(px);
| |
| − | /* OK, nic się nie stanie*/
| |
| − | cout<<px.get()<<endl; /* wypisuje jakiś adres*/
| |
| − | cref_1(px) /* nie skompiluje się */
| |
| − | | |
| − | std::vector<auto_ptr<X> > v(10); /* nie skompiluje się*/
| |
| − | /* {mod11/code/auto_ptr.cpp}{autoptr.cpp}*/
| |
| − | </nowiki>
| |
| − | | |
| − | Różne implementacje różnie sobie z tym radzą i w praktyce wynik
| |
| − | kompilowania powyższych fragmentów kodu może być różny na różnych
| |
| − | platformach. Jest to dość techniczne zagadnienie, zainteresowane
| |
| − | osoby odsyłam do {szablony} i {josuttis}.
| |
| − | | |
| − | ==Kontrola dostępu==
| |
| − | | |
| − | Poza kontrolą rodzaju praw własności, inteligentny wskaźnik daje nam
| |
| − | możliwość kontroli nad operacjami dostępu do wskazywanego obiektu
| |
| − | poprzez operatory <code><nowiki> operator->()</nowiki></code> i <code><nowiki> operator*()</nowiki></code>. Wpływać na
| |
| − | zachowanie tych operatorów możemy dwojako: po pierwsze, w oczywisty
| |
| − | sposób możemy wykonać dodatkowy kod, zanim zwrócimy z nich odpowiednią
| |
| − | wartość:
| |
| − | | |
| − | <nowiki> T &operator*() {
| |
| − | /* zrob coś */
| |
| − | return *_p;
| |
| − | }
| |
| − | </nowiki>
| |
| − | | |
| − | Ten dodatkowy kod może np. sprawdzać, czy wskaźnik <code><nowiki> _p</nowiki></code> nie jest
| |
| − | zerowy, może zliczać wywołania, itp.
| |
| − | | |
| − | Po drugie, możemy zmienić zwracany typ. Wbudowane operatory <code><nowiki> *</nowiki></code> i
| |
| − | <code><nowiki> -></nowiki></code> zwracają odpowiednio <code><nowiki> T&</nowiki></code> i <code><nowiki> T*</nowiki></code>. Oczywiście my możemy
| |
| − | zwrócić cokolwiek, ale żeby to miało jakiś sens, powinny to być obiekty
| |
| − | zachowujące się jak <code><nowiki> T&</nowiki></code> i <code><nowiki> T*</nowiki></code>. Takie obiekty, które "zachowują
| |
| − | się jak coś", ale tym nie są (kwacze jak kaczka, ale to nie jest
| |
| − | kaczka) nazywamy obiektami zastępczymi (proxy).
| |
| − | | |
| − | ===Proxy===
| |
| − | | |
| − | Dlaczego moglibyśmy chcieć używać obiektów zastępczych?
| |
| − | | |
| − | Typowe zastosowanie to implemenatacja operacji przypisania do obiektów,
| |
| − | które tak naprawdę obiektami nie są. Weźmy jako przykład
| |
| − | <code><nowiki> ostream_iterator</nowiki></code> dostarczany przez STL, który zezwala traktować
| |
| − | plik wyjściowy jak kontener z iteratorem typu <code><nowiki> OutputIterator</nowiki></code>:
| |
| − | | |
| − | <nowiki> vector<int> V(10,7);
| |
| − | copy(V.begin(), V.end(), ostream_iterator<int>(cout, ""));
| |
| − | </nowiki>
| |
| − | | |
| − | Przypatrzny się temu przykładowi bliżej. Jeśli zdefiniujemy
| |
| − | | |
| − | <nowiki> ostream_iterator<int>(cout, "") iout;
| |
| − | </nowiki>
| |
| − | | |
| − | to w zasadzie jedyną dozwoloną operacją jest przypisanie i zwiększenie
| |
| − | następujące po sobie:
| |
| − | | |
| − | <nowiki> (*iout) = 666; ++iout;
| |
| − | </nowiki>
| |
| − | | |
| − | Ewidentnie nie istnieje żaden obiekt, do którego referencje moglibyśmy
| |
| − | zwrócić. Możemy jednak zwrócić obiekt zastępczy, który będzie
| |
| − | definiował operator przypisania:
| |
| − | | |
| − | <nowiki> class writing_proxy {
| |
| − | std::ostream &_out;
| |
| − | public:
| |
| − | writing_proxy(std::ostream &out) :_out(out) {};
| |
| − |
| |
| − | void operator = (const T &val) {
| |
| − | _out<<val;
| |
| − | }
| |
| − | };
| |
| − | /* {mod11/code/out.cpp}{out.cpp} */
| |
| − | </nowiki>
| |
| − | | |
| − | Tę klasę zamkniemy wewnątrz klasy <code><nowiki> ostream_iterator</nowiki></code>
| |
| − | | |
| − | <nowiki> template<typename T> class ostream_iterator:
| |
| − | public std::iterator <std::output_iterator_tag, T > {
| |
| − | | |
| − | class writing_proxy {
| |
| − | /*...*/
| |
| − | };
| |
| − |
| |
| − | std::string _sep;
| |
| − | std::ostream &_out;
| |
| − | writing_proxy _proxy;
| |
| | public: | | public: |
| − | ostream_iterator(std::ostream &out,std::string sep): | + | Handle():_count(0){}; |
| − | _out(out),_sep(sep),_proxy(_out){};
| |
| − | void operator++() {_out<<_sep;}
| |
| − | void operator++(int) {_out<<_sep;}
| |
| − | writing_proxy &operator*() {return _proxy;};
| |
| − | };
| |
| − | /* {mod11/code/out.cpp}{out.cpp} */
| |
| − | </nowiki>
| |
| | | | |
| − | Dziedziczenie z klasy <code><nowiki> iterator</nowiki></code> zapewni nam, że nasz
| + | void add_ref() { ++_count;} |
| − | <code><nowiki> ostream_iterator</nowiki></code> posiada wszystkie typy stowarzyszone wymagane
| + | bool remove_ref() {--_count; return _count = = 0;} |
| − | przez iteratory STL. To z kolei pociąga za sobą możliwość użycia
| + | size_t count() const {return _count;}; |
| − | <code><nowiki> iterator_traits</nowiki></code>(zobacz [[##lbl:iterator-traits|Uzupelnic lbl:iterator-traits|]]). Bez tego nie
| |
| − | moglibyśmy używać <code><nowiki> ostream_iterator</nowiki></code> w niektórych algorytmach STL.
| |
| − | | |
| − | Teraz możemy juz używać wyrażeń typu:
| |
| − | | |
| − | <nowiki> ostream_iterator<int> io(std::cout,"");
| |
| − | (*io) = 44;
| |
| − | /* {mod11/code/out.cpp}{out.cpp} */
| |
| − | </nowiki>
| |
| − | | |
| − | Wywołanie <code><nowiki> *io</nowiki></code> zwraca <code><nowiki> writing_proxy</nowiki></code>. Następnie wywoływany
| |
| − | jest
| |
| − | | |
| − | <nowiki> writing_proxy::operator = (44)}
| |
| − | </nowiki>
| |
| − | | |
| − | który wykonuje operację
| |
| − | | |
| − | <nowiki> std::cout<<44;
| |
| − | </nowiki>
| |
| − | | |
| − | Widać też, że operacja
| |
| − | | |
| − | <nowiki> i = (*io)
| |
| − | </nowiki>
| |
| − | | |
| − | nie powiedzie się (nie skompiluje). W tym przypadku jest to pożądane
| |
| − | zachowanie, bo taka operacja nie ma sensu. Jeślibyśmy jednak
| |
| − | chcieli umożliwić działanie operacji przypisania w drugą stronę możemy
| |
| − | w obiekcie proxy zdefiniować operator konwersji na typ <code><nowiki> T</nowiki></code>.
| |
| − | | |
| − | <nowiki> operator T() {return T();}; /* uwaga bzdurny przykład !!! */
| |
| − | </nowiki>
| |
| − | | |
| − | Wtedy wykonanie
| |
| − | | |
| − | <nowiki> i = (*io)
| |
| − | </nowiki>
| |
| − | | |
| − | przypisze zero do zmiennej <code><nowiki> i</nowiki></code>. W ten sposób obiekty proxy
| |
| − | pozwalają nam rozróżniać użycie operatora <code><nowiki> *</nowiki></code> do odczytu i do
| |
| − | zapisu.
| |
| − | | |
| − | Obiekty zastępcze stanowią zresztą często spotykany wzorzec projektowy
| |
| − | (zobacz {gamma}). Poniżej przedstawię jeszcze jedną "sztuczkę"
| |
| − | opisaną w {alexandrescu}.
| |
| − | | |
| − | ===Opakowywanie wywołań funkcji===
| |
| − | | |
| − | Załóżmy, że mamy obiekt typu:
| |
| − | | |
| − | <nowiki> struct Widget {
| |
| − | void pre() {cout<<"pre"<<endl;}; | |
| − | void post() {cout<<"post"<<endl;}; | |
| − | | |
| − | void f1() {cout<<"f1"<<endl;}
| |
| − | void f2() {cout<<"f2"<<endl;}
| |
| − | /*{mode11/code/pre_post.cpp}{prepost.cpp} */
| |
| − | }
| |
| − | </nowiki>
| |
| − | | |
| − | Niech
| |
| − | | |
| − | <nowiki> Smart_prt<Widget> pw(new Widget);
| |
| − | </nowiki>
| |
| − | | |
| − | będzię inteligentnym wskaźnikiem do <code><nowiki> Widget</nowiki></code>.
| |
| − | Chcemy, aby każde wywołanie funkcji z <code><nowiki> Widget</nowiki></code> np.
| |
| − | | |
| − | <nowiki> pw->f1()
| |
| − | </nowiki>
| |
| − | | |
| − | zostało poprzedzone poprzez wywołanie funkcji <code><nowiki> pre()</nowiki></code>, a po nim
| |
| − | nastąpiło wywołanie funkcji <code><nowiki> post()</nowiki></code>. Jedną z możliwości jest
| |
| − | oczywiście zmiana kodu funkcji <code><nowiki> f1</nowiki></code> i <code><nowiki> f2</nowiki></code>,
| |
| − | tak aby wywoływały na początku
| |
| − | <code><nowiki> pre()</nowiki></code> i <code><nowiki> post()</nowiki></code> na końcu. Można też dodać zestaw funkcji
| |
| − | opakowywujących:
| |
| − | | |
| − | <nowiki> f1_wrapper() {pre();f1();post();}
| |
| − | </nowiki>
| |
| − | | |
| − | Jest to jednak niepotrzebne duplikowanie kodu i możliwe do
| |
| − | zastosowania tylko jeśli mamy możliwość zmiany kodu klasy <code><nowiki> Widget</nowiki></code>.
| |
| − | | |
| − | Można jednak zrobić inaczej. Zdefiniujemy pomocniczą klasę:
| |
| − | | |
| − | <nowiki> template<typename T> struct Wrapper {
| |
| − | T* _p;
| |
| − | Wrapper(T* p):_p(p) {_p->pre();}
| |
| − | Wrapper() {_p->post();} | |
| − | | |
| − | T* operator->() {return _p;} | |
| | }; | | }; |
| − | /*{mode11/code/pre_post.cpp}{prepost.cpp} */
| |
| − | </nowiki>
| |
| − |
| |
| − | W klasie inteligentnego wskaźnika przedefiniujemy <code><nowiki> operator->()</nowiki></code>
| |
| − | tak, aby zwracał <code><nowiki> Wrapper<T>(T *)</nowiki></code> zamiast<code><nowiki> T*</nowiki></code>.
| |
| − |
| |
| − | <nowiki> template<typename T> struct Smart_ptr {
| |
| − | T *_p;
| |
| − | Smart_ptr(T *p):_p(p) {};
| |
| − | Smart_ptr(){delete _p;};
| |
| − |
| |
| − | Wrapper<T> operator->() {return Wrapper<T>(_p);};
| |
| − | T &operator*() {return *_p};
| |
| − | /*{mode11/code/pre_post.cpp}{prepost.cpp} */
| |
| − | };
| |
| − | </nowiki>
| |
| − |
| |
| − | Jeśli teraz wywołamy
| |
| − |
| |
| − | <nowiki> pw->f1();
| |
| − | </nowiki>
| |
| − |
| |
| − | to będą się dziać następujace rzeczy:
| |
| − | * zostanie wywołany
| |
| − |
| |
| − | <nowiki> pw.operator->();
| |
| − | </nowiki>
| |
| − |
| |
| − | operator ten zwraca obiekt <code><nowiki> tmp</nowiki></code> typu <code><nowiki> Wrapper<Widget></nowiki></code>, ale
| |
| − | najpier musi go skonstruować, a więc
| |
| − | * zostanie wywołany konstruktor
| |
| − |
| |
| − | <nowiki> tmp = Wrapper<Widget>(p);
| |
| − | </nowiki>
| |
| − |
| |
| − | który wywoła
| |
| − |
| |
| − | <nowiki> p->pre();
| |
| − | </nowiki>
| |
| − | * Jeśli <code><nowiki> operator->()</nowiki></code>, zwróca obiekt który posiada
| |
| − | <code><nowiki> operator->()</nowiki></code>, to jest on wywoływany rekurencyjnie, aż zostanie
| |
| − | zwrócony typ wskaźnikowy. Tak więc zostanie wywołany
| |
| − | <code><nowiki> tmp.operator->()</nowiki></code> który zwróci <code><nowiki> p</nowiki></code>.
| |
| − | * Poprzez ten wskaźnik zostanie wywołana funkcja
| |
| − |
| |
| − | <nowiki> p->f1();
| |
| − | </nowiki>
| |
| − | * Zakończy się wywołanie <code><nowiki> pw.operator->()</nowiki></code>, a więc zostanie
| |
| − | wywołany destruktor obiektu tymczasowego <code><nowiki> tmp</nowiki></code> który wywoła
| |
| − |
| |
| − | <nowiki> p->post();
| |
| − | </nowiki>
| |
| − |
| |
| − | Widać więc, że w końcu zostanie wykonana sekwencja wywołań:
| |
| − |
| |
| − | <nowiki> p->pre();
| |
| − | p->f1();
| |
| − | p->post();
| |
| | </nowiki> | | </nowiki> |
| | | | |
| − | i tak będzie dla dowolnej wywoływanej metody.
| + | '''Zadanie 4 ''' |
| − | Jesli jednak wywołamy funkcję <code><nowiki> f1()</nowiki></code> za pomocą wyrażenia:
| + | Zaimplementuj iterator pozwalający wkładać wartości na koniec |
| − | | + | kontenera. |
| − | <nowiki> (*pw).f1();
| |
| − | </nowiki>
| |
| − | | |
| − | to ten mechanizm nie zadziała i nie ma możliwości, aby go w tej sytuacji
| |
| − | zaimplementować. Może to być traktowane jako wada, bo nie jesteśmy w
| |
| − | stanie zapewnić, że każde wywołanie funkcji zostanie opakowane, ale z
| |
| − | drugiej strony mamy, do dyspozycji możliwość wyboru pomiędzy opakowanym
| |
| − | i nieopakowanym wywołaniem funkcji.
| |
| − | | |
| − | ==Współdzielenie reprezentacji==
| |
| − | | |
| − | Opisując inteligentne skaźniki, nie można nie wspomnieć o technice
| |
| − | implementacyjnej, która jest ściśle z nimi związana, a mianowicie o
| |
| − | współdzieleniu reprezentacji. Technika ta polega na oddelegowaniu
| |
| − | całego (lub prawie całego) zachowania klasy do innego obiektu,
| |
| − | nazywanego reprezentacją, a w obiekcie klasy przechowywanie tylko uchwytu
| |
| − | do reprezentacji (zob rysunek [[##fig:cow|Uzupelnic fig:cow|]]).
| |
| − | [p]
| |
| − |
| |
| − | {}
| |
| − |
| |
| − | <nowiki> class Wichajster {
| |
| − | public:
| |
| − | void do_something() {_rep->do_something();}
| |
| − | private:
| |
| − | WichajsterRep _rep;
| |
| − | }
| |
| − | </nowiki>
| |
| − | | |
| − | Techniki tej używamy np. kiedy chcemy oszczędzić czas i miejsce
| |
| − | potrzebne na kopiowanie obiektów. Kilka kopi obiektów klasy
| |
| − | <code><nowiki> Wichajster</nowiki></code> może współdzielić jedną reprezentację, korzystając np.
| |
| − | ze zliczania referencji. Istotną różnicą w stosunku do inteligentnych
| |
| − | wskaźników jest zachowanie w przypadku zmiany jednego z obiektów. W
| |
| − | przypadku wskaźników, współdzielenie referencji jest planowaną cechą
| |
| − | podejścia: kiedy zmieniamy obiekt poprzez jeden ze wskaźników,
| |
| − | wszystkie inne wskaźniki wskazują na zmieniony obiekt.
| |
| − | | |
| − | W przypadku współdzielenia reprezentacji chcemy cały czas rozróżniać
| |
| − | obiekty, współdzielenie jest tylko technicznym środkiem optymalizacji.
| |
| − | Wymaga to zastosowania techniki "copy on write", tzn. w momencie, w
| |
| − | którym dokonujemy na obiekcie operacji mogącej go zmienić i jeśli
| |
| − | posiada on współdzieloną reprezentację, to tworzymy nową fizyczna
| |
| − | kopię tej reprezentacji i dopiero ją zmieniamy. Przedstawione to jest
| |
| − | na rysunku [[##fig:cow|Uzupelnic fig:cow|]].
| |
| − | | |
| − | W przypadku metod łatwo stwierdzić, które zmieniaja obiekt, a które nie;
| |
| − | problem występuje tylko z metodami które zwracaja referencje do wnętrza
| |
| − | obiektu. Takie metody mogą służyć zarówno do zapisu jak i do odczytu.
| |
| − | Cześciowym rozwiązaniem może być użycie obiektów proxy, tak jak to
| |
| − | opisano w poprzednim podrozdziale. Szczegółowy opis tej techniki
| |
| − | znajduje się w {MeyersMECPP}.
| |
| − | | |
| − | ==Iteratory==
| |
| − | | |
| − | Iteratory to kolejny rodzaj inteligentnych wskaźników. Jeżli chodzi o
| |
| − | prawa własności czy kontrolę dostępu, to w większości zachowują się jak
| |
| − | zwykłe wskaźniki. Wyjątkiem są specjalne iteratory takie, jak
| |
| − | <code><nowiki> ostream_iterator</nowiki></code>, czy <code><nowiki> back_inserter</nowiki></code>, wspomniane powyżej.
| |
| − | Ale zasadniczo inteligencja iteratorów umiejscowiona jest w operacjach
| |
| − | arytmetycznych. Chodzi głównie o operator <code><nowiki> operator++()</nowiki></code>, ponieważ
| |
| − | wyposażone są w niego wszystkie iteratory kontenerów z STL. To
| |
| − | właśnie jest zresztą podstawowa rola iteratora: przechodzenie do
| |
| − | kolejnych elementów, semantyka wskaźnika to już wybór twórców STL.
| |
| − | | |
| − | ==Implementacje==
| |
| − | | |
| − | Widać, że różnorodność inteligentnych wskaźników może przyprawić o
| |
| − | zawrót głowy. A nie rozważyliśmy jeszcze wszystkich kwestii
| |
| − | dotyczących ich zachowania. Wyczerpująca dyskusja na ten
| |
| − | temat znajduje się w {alexandrescu}. Tam też podana jest
| |
| − | implemenatcja uniwersalnego szablonu klasy inteligentnego wskaźnika
| |
| − | parametryzowanego kilkoma klasami wytycznymi. Alternatywą jest użycie
| |
| − | szeregu klas (szablonów) implementujacych jeden typ wskaźnika każda.
| |
| − | Zbiór takich klas można znaleźć w bibliotece <code><nowiki> boost</nowiki></code>
| |
| − | ({<math>\displaystyle BOOST_LIBS/smart_ptr/smart_ptr.htm}{smart\_ptr}).
| |
| − | Bardzo dobre opisy implementacji inteligentnych wskaźników znajdują
| |
| − | się również w \cite{szablony} i \cite{MeyersMECPP}.
| |
| − | | |
| − | Tutaj dla przykładu zaprezentuję implementację wskaźnika zliczającego
| |
| − | referencję, parametryzowanego jedną klasą wytyczną. Jest to podejście
| |
| − | zbliżone do \cite{szablony}.
| |
| − | | |
| − | ==Zliczanie referencji==
| |
| − | | |
| − | Implementacje zliczanie referencji różnią się przede wszystkim
| |
| − | miejscem, w którym umieszczony zostanie licznik. Dwie główne możliwości
| |
| − | to wewnątrz lub na zewnątrz obiektu, na który wskazujemy. Pierwszy
| |
| − | wariant jest ewidentnie możliwy tylko wtedy, jeśli mamy dostęp do
| |
| − | kodu tej klasy. W każdej z tych dwu grup mamy dalsze możliwości np:
| |
| − | \beginfigure
| |
| − | \begincenter
| |
| − | \includegraphics[width=\floatwidth]{mod11/graphics/counter.eps}
| |
| − | \endcenter
| |
| − | \caption{Wkaźniki ze współdzielniem referencji.}
| |
| − | \endfigure
| |
| − | # Obiekt wskazywany udostępnia miejsce na licznik, zarządzaniem licznikiem
| |
| − | zajmuje się wskaźnik
| |
| − | # Obiekt wskazywany udostępnia nie tylko licznik, ale i interfejs do
| |
| − | zarządzania nim.
| |
| − | # Licznik jest osobnym obiektem. Każdy wskaźnik posiada wskaźnik
| |
| − | na obiekt wskazywany i wskaźnik na licznik (zobacz
| |
| − | rysunek~[[##fig:counter|Uzupelnic fig:counter|]]).
| |
| − | # Licznik jest osobnym obiektem który zawiera również wskaźnik do
| |
| − | obiektu wskazywanego. Każdy wskaźnik zawiera tylko wskaźnik do
| |
| − | licznika (zobacz rysunek~[[##fig:counter|Uzupelnic fig:counter|]]).
| |
| − | # Nie ma licznika, wskaźniki do tego samego obiektu połączone są w
| |
| − | listę (zobacz rysunek~[[##fig:counter|Uzupelnic fig:counter|]]).
| |
| | | | |
| − | Pokażę teraz przykładową implementację szablonu wskaźnika
| + | '''Zadanie 5 ''' Zaimplementuj iterator realizujący przechodzenie po drzewie binarnym. Drzwo opearte jest o strukturę: |
| − | parametryzowanego jedną klasą wytyczną określającą którąś z powyższych
| |
| − | strategii, aczkolwiek przy jednej wytycznej jest to wysiłek który
| |
| − | pewnie się nie opłaca, jako że kod wspólny jest dość mały. Ale
| |
| − | implementacja ta może stanowić podstawę do rozszerzenia o kolejne
| |
| − | wytyczne.
| |
| − | | |
| − | Najpierw musimy się zastanowić na interfejsem lub raczej konceptem
| |
| − | klasy wytycznej. W sumie najłatwiej to zrobić, implemetując konkretną
| |
| − | wytyczną. Zaczniemy od osobnego zewnętrznego licznika
| |
| − | (strategia~[[##lbl:external|Uzupelnic lbl:external|]]).
| |
| − | Klasa wytyczna musi zawierać wsaźnik do wspólnego licznika:
| |
| − | | |
| − | <nowiki> template<typename T> struct Extra_counter_impl {
| |
| − | /*...*/
| |
| − | private:
| |
| − | size_t *_c;
| |
| − | };
| |
| − | </nowiki>
| |
| − | | |
| − | i funkcje zwiększające i zmniejszające licznik:
| |
| − | | |
| − | <nowiki> public:
| |
| − | bool remove_ref() {--(*_c);return *_c==0;};
| |
| − | void add_ref() {++(*_c);};
| |
| − | size_t count() {return *_c;};
| |
| − | };
| |
| − | </nowiki>
| |
| − | | |
| − | Funkcja zmniejszająca licznik zwraca prawdę, jeśli usunięta została
| |
| − | ostatnia referencja do wskazywanego obiektu. Potrzebna też będzie
| |
| − | funkcja niszcząca licznik:
| |
| − | | |
| − | <nowiki> void cleanup() { | |
| − | delete _c;
| |
| − | _c=0;
| |
| − | }
| |
| − | </nowiki>
| |
| − | | |
| − | Potrzebne będą dwa konstruktory: defaultowy, który nic nie robi:
| |
| − | | |
| − | <nowiki> Extra_counter_impl():_c(0) {}; | |
| − | </nowiki>
| |
| − | | |
| − | i konstruktor inicjalizujący licznik obiektu powstającego po raz pierwszy:
| |
| − | | |
| − | <nowiki> Extra_counter_impl(T* p):_c(new size_t) {*_c=0;};
| |
| − | </nowiki>
| |
| − | | |
| − | który przydziela pamięć dla licznika. Argument <code><nowiki> T* p</nowiki></code> służy tylko
| |
| − | do rozróżnienia tych konstruktorów.
| |
| − | | |
| − | Korzystając z tej klasy nietrudno jest, napisać szablon inteligentnego
| |
| − | wskaźnika. Obiekt klasy <code><nowiki> Extra_counter_impl</nowiki></code> może być składową
| |
| − | tego szablonu lub możemy z tej klasy wytycznej
| |
| − | dziedziczyć (zob~[[##lbl:wytyczne|Uzupelnic lbl:wytyczne|]]).
| |
| − | | |
| − | Niestety, przy tak zdefiniowanym interfejsie do klasy wytycznej,
| |
| − | bedziemy mieli problem próbując zaimplementować inne strategie, w
| |
| − | szczególności strategię w której licznik i wskaźnik na obiekt
| |
| − | wskazywany znajdują się w tym samym obiekcie
| |
| − | (strategia~[[##lbl:indirect|Uzupelnic lbl:indirect|]]). Dlatego zmienimy trochę naszą
| |
| − | implementację wytycznej i założymy, że obiekty tej klasy będą
| |
| − | zawierać również wskaźnik na obiekt wskazywany.
| |
| − | | |
| − | <nowiki> T *_p;
| |
| − | </nowiki>
| |
| − | | |
| − | i dodamy funkcję
| |
| − | | |
| − | <nowiki> T* pointee() {return _p;}
| |
| − | </nowiki>
| |
| − | | |
| − | Musimy jeszcze poprawić funkcję czyszczącą:
| |
| − | | |
| − | <nowiki> void cleanup() {
| |
| − | delete _c;
| |
| − | delete _p;
| |
| − | _p=0;
| |
| − | }
| |
| − | /* \href{mod11/code/ref_ptr.h}{ref\_ptr.h} */
| |
| − | </nowiki>
| |
| − | | |
| − | I jeden z konstruktorów:
| |
| − | | |
| − | <nowiki> Extra_counter_impl(T* p):_c(new size_t),_p(p) {*_c=0;};
| |
| − | </nowiki>
| |
| − | | |
| − | Szablon wskaźnika korzystający z tak zdefiniowanej klasy wytycznej może
| |
| − | wyglądać następująco:
| |
| − | | |
| − | <nowiki> template<typename T,
| |
| − | typename counter_impl = Extra_counter_impl<T> >
| |
| − | class Ref_ptr {
| |
| − | public:
| |
| − | Ref_ptr() {};
| |
| − | Ref_ptr(T *p):_c(p) {
| |
| − | _c.add_ref();
| |
| − | };
| |
| − | | |
| − | ~Ref_ptr() {detach();}
| |
| | | | |
| − | Ref_ptr(const Ref_ptr &p):_c(p._c) {
| + | <nowiki> template<typename T> class binary_tree { |
| − | _c.add_ref();
| |
| − | }
| |
| | | | |
| − | Ref_ptr &operator=(const Ref_ptr &rhs) { | + | class node { |
| − | if(this!=&rhs) { | + | T _val; |
| − | detach();
| + | node *_left; |
| − | _c=rhs._c;
| + | node *_right; |
| − | _c.add_ref();
| |
| | } | | } |
| − | return *this;
| |
| − | }
| |
| − |
| |
| − | T* operator->() {return _c.pointee();}
| |
| − | T &operator*() {return *(_c.pointee());}
| |
| − |
| |
| − | size_t count() {return _c.count();};
| |
| − | private:
| |
| − | mutable counter_impl _c;
| |
| − | void detach() {
| |
| − | if (_c.remove_ref() ) _c.cleanup();
| |
| − | };
| |
| − | };
| |
| − | /* \href{mod11/code/ref_ptr.h}{ref\_ptr.h} */
| |
| − | </nowiki>
| |
| − |
| |
| − | ==auto\_ptr==
| |
| | | | |
| − | Implementacja wskaźnika <code><nowiki> auto_ptr</nowiki></code> oparta jest o dwie funkcje.
| + | node* _root; |
| − | Jedna zwalnia przechowywany wskaźnik zwracając go na zewnątrz i
| |
| − | oddając własność:
| |
| | | | |
| − | <nowiki> T* release() {
| |
| − | T *oldPointee = pointee;
| |
| − | pointee = 0;
| |
| − | return oldPointee;
| |
| − | }
| |
| − | /* \href{mod11/code/auto_ptr.h}{auto\_ptr.h} */
| |
| − | </nowiki>
| |
| − |
| |
| − | <code><nowiki> pointee</nowiki></code> jest przechowywanym (zwykłym) wskaźnikiem.
| |
| − |
| |
| − | <nowiki> private:
| |
| − | T *pointee;
| |
| − | </nowiki>
| |
| − |
| |
| − | Druga funkcja zamienia przechowywany wskaźnik na inny, zwalnianiając
| |
| − | wskazywaną przez niego pamięć:
| |
| − |
| |
| − | <nowiki> void reset(T *p = 0) {
| |
| − | if (pointee != p) {
| |
| − | delete pointee;
| |
| − | pointee = p;
| |
| − | }
| |
| − | }
| |
| − | /* \href{mod11/code/auto_ptr.h}{auto\_ptr.h} */
| |
| − | </nowiki>
| |
| − |
| |
| − | Za pomocą tych funkcji można już łatwo zimplementować resztę szablonu np.:
| |
| − |
| |
| − | <nowiki> template<class T> class auto_ptr {
| |
| − | public:
| |
| − | explicit auto_ptr(T *p = 0): pointee(p) {}
| |
| − |
| |
| − | template<class U>
| |
| − | auto_ptr(auto_ptr<U>& rhs): pointee(rhs.release()) {}
| |
| − |
| |
| − | ~auto_ptr() { delete pointee; }
| |
| − |
| |
| − | template<class U>
| |
| − | auto_ptr<T>& operator=(auto_ptr<U>& rhs)
| |
| − | {
| |
| − | if (this != &rhs) reset(rhs.release());
| |
| − | return *this;
| |
| − | }
| |
| − |
| |
| − | T& operator*() const { return *pointee; }
| |
| − | T* operator->() const { return pointee; }
| |
| − | T* get() const { return pointee; }
| |
| | } | | } |
| − | /* \href{mod11/code/auto_ptr.h}{auto\_ptr.h} */
| |
| | </nowiki> | | </nowiki> |
| − |
| |
| − | Konstruktor kopiujacy i operator przypisania są szablonami. W ten
| |
| − | sposób można kopiować również wskaźniki <code><nowiki> auto_ptr</nowiki></code> opakowywujące
| |
| − | typy, które mogą być na siebie rzutowane np. można przypisać
| |
| − | <code><nowiki> auto_ptr<Derived></nowiki></code> do <code><nowiki> auto_ptr<Base></nowiki></code>, jeśli <code><nowiki> Derived</nowiki></code>
| |
| − | dziedziczy publicznie z <code><nowiki> Base</nowiki></code>. Konstruktor <code><nowiki> auto_ptr(T *p =
| |
| − | 0)</nowiki></code> został zadeklarowany jako <code><nowiki> explicit</nowiki></code>, wobec czego nie
| |
| − | spowoduje niejawnej konwersji z typu <code><nowiki> T*</nowiki></code> na <code><nowiki> auto_ptr<T></nowiki></code>.
| |
| − |
| |
| − | Różne impelentacje <code><nowiki> auto_ptr</nowiki></code> różnią się szczegułami dotyczącymi
| |
| − | obsługi <code><nowiki> const auto_ptr</nowiki></code> i przekazywania <code><nowiki> auto_ptr</nowiki></code> przez stałą
| |
| − | referencję. Powyższa implentacja wzięta, z \cite{MeyersMECPP}, nie
| |
| − | posiada pod tym względem żadnych zabezpieczeń. Szczegółowa dyskusja
| |
| − | tego zagadnienia i bardziej zaawansowana implementacja znajduje się w
| |
| − | \cite{josuttis}. Temat ten jest też poruszony w \cite{szablony}.
| |
| − | Warto też zaglądnąć do implementacji <code><nowiki> auto_ptr</nowiki></code> dostarczonej z
| |
| − | wraz z kompilatorem <code><nowiki> g++</nowiki></code>.</math>
| |
