auto_ptr a deklaracja lokalnej zmiennej

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ł

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ł

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.

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.).

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);

"

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ł

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.

0

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

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).

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