@zimny_stolec: Wszyscy wyjechali do ciepłych krajów.
#pdk

na wyniku tej operacji to czemu trzeba osobno dereferencjowac unique ptr?

@zimny_stolec: pytasz, czemu zeby przeprowadzic operacje na obiekcie zwracanym przez pierwsza operacje trzeba najpierw wykonac pierwsza operacje?

W czym masz kłopot?

@edgar_k: @frax: @zimny_stolec: Jestem ekspertem, potwierdzam.
Ten operator to chyba najgorzej zdefiniowany operator po operatorze postinkrementacji.
Jednak to nie przeszkadza bo chainowanie pointerów to coś czego powinno się unikać w C++.

@zimny_stolec: No iterator też jest semantycznie wskaźnikiem. Jeżeli klasa A miała być virtualnym adapterem dla tego iteratora, to twój pomysł jest jak najbardziej wporządku. Pamiętaj tylko o abstakcyjnej klasie bazowej(interfejsu), bez którego ten pomysł jest niepełny. Jedyne co możesz zrobić to nałożyć cukier nad std::unique_ptr udający iterator:
template class PointerHandler = std::uniqueptr > class IteratorReferenceWrapper;

Są tu jakieś mirki które konkretnie ogarniają działanie operatora -> ? :P

@zimny_stolec: są.

A co, chciałbyś zadac pytanie?

@zimny_stolec: pewnie są

@edgar_k: Z tego co zdążyłem się zorientować to ten operator działa rekurencyjnie. Powiedzmy że mam klasę A która ma zdefiniowany przeciążony operator->(). I mam unique ptr. Według mojego rozumowania wywołanie operatora->() na tym unique ptr powinno zaskutkować wywołaniem operatora->() na obiekcie klasy A który ten ptr przechowuje, nie? A u mnie działa jedynie wywołanie operatora*() na unique ptr i dopiero wtedy wywołanie operatora->() (już na obiekcie klasy A.)

A u mnie działa jedynie wywołanie operatora*() na unique ptr i dopiero wtedy wywołanie operatora->() (już na obiekcie klasy A.)

@zimny_stolec: no a jak inaczej? Musi zdereferencjowac (co za słowo) kontener i potem dopiero może wywoływac na obiekcie

zapomniałem zawołać @lionbest

@edgar_k: ale skoro wywołanie operatora->() skutkuje wywołaniem tego samego operatora na wyniku tej operacji to czemu trzeba osobno dereferencjowac unique ptr?

@edgar_k: rzeczywiście, po sprawdzeniu na innej klasie operator dla unique pointera tak nie dziala, ale wciaz nie moge zczaić czemu :v

zdereferencjowac

@edgar_k: zdereferować?

@zimny_stolec: Domyślnie, operator -> jest skrótem notacyjnym, działającym tak że a->b oznacza (*a).b. Przy przeciążeniu, wymusza się sprowadzenie obiektu do zwykłego wskaźnika, i wtedy a->b oznacza *(a.operator->()).b.

A tak ogólnie, to wstaw sobie zamiast unique poitera zwykły wskaźnik, zamień sobie użycie _->_ na *(_)._ i ci wyjdzie, czym to się różni.

@zimny_stolec: operator-> używa się tylko wtedy kiedy obiekt ten jest rodzajem wskaźnika. Tworzenie wskaźnika do wskaźnika nie jest prawidłowym rozwiązaniem. Czemu unique ptr nie może być w A? jeżeli dlatego że masz wiele typów to zrób szablon template< template class PointerHandler = std::unique_ptr > class A.
Jeżeli się opakowuje wskaźnik to zazwyczaj klasa ma się zachowywać jak on.

@lionbest: klasa nie ma opakowywać unique pointera a iterator (konkretniej ma to być dekorator iteratora). Domyślam się że tworzenie unique_pointera na iteratorze jest słabe ale ten dekorator musi dziedziczyć po abstrakcyjnej klasie i trzeba go opakować w unique pointera żeby móc korzystać z wirtualności metod w klasie abstrakcyjnej. Chyba że źle myślę bo doświadczony zbytnio nie jestem :P

@lionbest: Dzięki. A jeśli i tak obsługuję tylko jeden konkretny typ iteratora to da się to zrobić prościej?

@zimny_stolec: Wtedy nie potrzeba nic robić, A i tak zamierzasz zrobić unique, więc prościej zrobić noncopyable (delete na kopjującym i operatorze przypisania). Jeżeli zamierzasz go zrobić sharable to IteratorReferenceWrapper i tak ci jest potrzebny, ale nie koniecznie na klasę tylko na konkretny iterator.