auto_ptr a deklaracja lokalnej zmiennej

Odpowiedz Nowy wątek
2011-08-25 18:22
Michał
0

Witam

Jestem programistą C++ ale nie rozumiem jednej rzeczy. Po co używać auto_ptr'a? Czemu zamiast

auto_prt<MojaKlasa> ptr = auto_prt<MojaKlasa>(new MojaKlasa);

Funkcja(ptr);

nie zrobić po prostu

MojaKlasa mojaK;

Funkcja(&mojaK);
  • no bo też mamy zachowane zasady RAII

Pozdrawiam,
Michał

Pozostało 580 znaków

2011-08-26 10:07
Michał
0

Haha! Nikt nie wie?! :-) To tak jak ja... Programuję już klika ładnych lat w C++ i zacząłem się zastanawiać. I nie mogę znaleźć odpowiedzi... Aczkolwiek on musi istnieć, przestałem już dawno wierzyć w "błedy kompilatora" ;-)

Rozwinę temat, tzn. moje przemyślenia. Rozumiem zastosowanie bardziej zaawansowanych inteligentnych wskaźników, jak te z boost'a - takich np., które możemy kopiować/powielać, a one zliczają odwołania. Ale taki najprostszy auto_ptr< ? Jedyne w czym widzę sens to zwracanie takiego auto_ptr'a z funkcji, tzn. zwrócenia auto_ptr'a przez wartość. Wtedy tworzymy kopię auto_ptr'a, który jest >>względnie mały<< (nie to co kopiować obiekt klasy MojaKlasa, który może być duuuży). Wtedy faktycznie po tym jak ta kopia auto_ptr'a wyjdzie poza zasięg, to jego destruktor posprząta nasz obiekt stworzony przez new. OK, to ma sens. Ale widziałem miloion razy auto_ptr'a uzytego w taki sposób jak napisałem w poprzednim poście. I nie mogę sobie odpowiedzieć na pytanie jaka jest przewaga na wersją z przekazaniem adresu zmiennej lokalnej. OK, w jednym przypadku obiekt jest tworzony na stercie, a w drugim na stosie, ale to przecież nie ma znaczenia (poza może jakimiś super-wyspecjalizowanymi zastosowaniami). W jednym drugim przypadku obiekt będzie posprzątany po wyjściu poza zakres "widoczności". Więc gdzie popełniam błąd w moim rozumowaniu?

Pozdrawiam,
Michał

Pozostało 580 znaków

2011-08-26 10:13
0

Jedyna różnica jaką widzę to miejsce alokacji pamieci dla obiektu. W przypadku z auto_ptr masz alokację obiektu na stercie a na stosie leży tylko mały obiekt pointera. W drugim przypadku masz wszystko na stosie. Może to być zwyczajnie zabezpieczenie przed przypadkowym stack-overflow.

Pozostało 580 znaków

2011-08-26 13:16
0

Chodzi o tworzenie obiektów i przekazywanie ich własności.
Przy auto_ptr możesz utworzyć obiekt gdziekolwiek (np. w dziedziczonej funkcji) i przekazać go dalej (ptr.release())
Przy obiekcie na stosie nie masz takiej możliwości - obiekt musi utworzony w miejscu deklaracji i skasowany po wyjściu z funkcji.

Obiekty na stosie to najczęściej u mnie struktury danych, których nigdzie nie przekazuję na zewnątrz - po wyjściu z funkcji (string, vector, etc.).

Pozostało 580 znaków

2011-08-26 19:25
1

Przy użyciu auto_ptr nie musisz się martwić wyciekiem pamięci (chociaż pewnie i to się da). Przed opuszczeniem klamry zamykającej obszar dostępu do zmiennej klasa auto_ptr uaktywania destruktor który usuwa ten wskaźnik za Ciebie.
To oznacza, że podałeś zły przykład. Powinien brzmieć "jaka jest różnica między:

auto_prt<MojaKlasa> ptr = auto_prt<MojaKlasa>(new MojaKlasa);
 
Funkcja(ptr);

a

MojaKlasa * ptr = new MojaKlasa;
Funkcja(ptr);

"


Gdy się nie wie, co się robi, to dzieją się takie rzeczy, że się nie wie, co się dzieje ;-)
Piłeś coś? o_O Przecież autorowi chodziło dokładnie o to o co zapytał. Czytaj uważnie :) - Shalom 2011-08-29 09:29

Pozostało 580 znaków

2011-08-31 15:06
Michał
0

Dziękuję Wszystkim za odpowiedzi!

MJay - tak myślę, że chyba powinienem zapytać po co w ogóle używać wskaźnika, jeżeli nie chcemy go zwracać, ani nie potrzebujemy więcej niż jednego odwołania do obiektu. Powodu dla wskaźnika wtedy brak.

Pozdrawiam,
Michał

Pozostało 580 znaków

2011-09-03 21:40
0

Nie uważacie że auto_ptr< to trochę igranie z ogniem? Przypisanie wartości do nowego wskaźnika zeruje wskaźnik auto_ptr - na mój gust może to powodować problemy gdy np. ktoś nowy dołącza do projektu i jest mało doświadczony lub nie miał za bardzo styczności z auto_ptr. auto_ptr jest poza tym odradzany przez nowy standard.


Jeśli uważasz mój post za wartościowy - daj punkt.
Mój post pomógł Ci rozwiązać problem - zaznacz go.

Pozdrawiam

Pozostało 580 znaków

2011-09-03 21:48
0

dlatego też nowy standard przewiduje cały zestaw shared_ptr, scoped_ptr, unique_ptr, każdy do specyficznego zastosowania.

Pozostało 580 znaków

2011-09-04 12:51
0
Azarien napisał(a)

dlatego też nowy standard przewiduje cały zestaw shared_ptr, scoped_ptr, unique_ptr, każdy do specyficznego zastosowania.

...a za bezpośredniego następce auto_ptr uznaje się unique_ptr.

Z auto_ptr trzeba bardzo uważać, jest to najniebezpieczniejszy smart pointer (patrz np. argumenty funkcji, kontenery, wskazane wyżej przypisania).

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0