Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #30213 > unrolled thread

Automatic Reference Counting

Back to article view | Back to pl.comp.programming

Contents

  Automatic Reference Counting Borneq <borneq@antyspam.hidden.pl> - 2017-08-14 01:17 +0200
    Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-13 16:35 -0700
      Re: Automatic Reference Counting Borneq <borneq@antyspam.hidden.pl> - 2017-08-14 02:40 +0200
        Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-14 01:03 -0700
          Re: Automatic Reference Counting Borneq <borneq@antyspam.hidden.pl> - 2017-08-14 10:14 +0200
            Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-14 01:31 -0700
              Re: Automatic Reference Counting Borneq <borneq@antyspam.hidden.pl> - 2017-08-14 15:10 +0200
                Re: Automatic Reference Counting Borneq <borneq@antyspam.hidden.pl> - 2017-08-14 15:17 +0200
                Re: Automatic Reference Counting Borneq <borneq@antyspam.hidden.pl> - 2017-08-14 15:26 +0200
                Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-14 06:36 -0700
            Re: Automatic Reference Counting "AK" <nobody@nowhere.net> - 2017-08-16 22:17 +0200
              Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-16 14:31 -0700
                Re: Automatic Reference Counting fir <profesor.fir@gmail.com> - 2017-08-17 09:01 -0700
                  Re: Automatic Reference Counting "AK" <nobody@nowhere.net> - 2017-08-18 08:01 +0200
                    Re: Automatic Reference Counting fir <profesor.fir@gmail.com> - 2017-08-18 00:20 -0700
                Re: Automatic Reference Counting "AK" <nobody@nowhere.net> - 2017-08-18 07:50 +0200
                  Re: Automatic Reference Counting bartekltg <bartekltg@gmail.com> - 2017-08-18 01:42 -0700
                    Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-18 01:53 -0700
                    Re: Automatic Reference Counting Borneq <borneq@antyspam.hidden.pl> - 2017-08-18 11:37 +0200
                      Re: Automatic Reference Counting bartekltg <bartekltg@gmail.com> - 2017-08-18 03:07 -0700
                        Re: Automatic Reference Counting bartekltg <bartekltg@gmail.com> - 2017-08-18 03:10 -0700
                        Re: Automatic Reference Counting Borneq <borneq@antyspam.hidden.pl> - 2017-08-18 12:38 +0200
                          Re: Automatic Reference Counting bartekltg <bartekltg@gmail.com> - 2017-08-18 06:02 -0700
                        Re: Automatic Reference Counting "AK" <nobody@nowhere.net> - 2017-08-19 21:51 +0200
                          Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-19 14:02 -0700
                            Re: Automatic Reference Counting fir <profesor.fir@gmail.com> - 2017-08-19 14:17 -0700
                              Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-19 17:46 -0700
                                Re: Automatic Reference Counting fir <profesor.fir@gmail.com> - 2017-08-20 00:46 -0700
                                  Re: Automatic Reference Counting fir <profesor.fir@gmail.com> - 2017-08-20 01:14 -0700
                                    Re: Automatic Reference Counting fir <profesor.fir@gmail.com> - 2017-08-20 01:26 -0700
                                      Re: Automatic Reference Counting fir <profesor.fir@gmail.com> - 2017-08-20 01:42 -0700
                                    Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-20 03:30 -0700
                                      Re: Automatic Reference Counting fir <profesor.fir@gmail.com> - 2017-08-20 04:01 -0700
                                        Re: Automatic Reference Counting fir <profesor.fir@gmail.com> - 2017-08-20 04:16 -0700
                                        Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-20 04:51 -0700
                                Re: Automatic Reference Counting "AK" <nobody@nowhere.net> - 2017-08-20 10:41 +0200
                              Re: Automatic Reference Counting "AK" <nobody@nowhere.net> - 2017-08-20 10:35 +0200
                              Re: Automatic Reference Counting Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-08-21 07:49 +0200
                                Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-21 03:23 -0700
                          Re: Automatic Reference Counting bartekltg <bartekltg@gmail.com> - 2017-08-20 04:55 -0700
                      Re: Automatic Reference Counting "M.M." <mmarszik@gmail.com> - 2017-08-18 03:40 -0700
              Re: Automatic Reference Counting Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-17 14:56 -0700
                Re: Automatic Reference Counting Borneq <borneq@antyspam.hidden.pl> - 2017-08-18 07:09 +0200
                  Re: Automatic Reference Counting "AK" <nobody@nowhere.net> - 2017-08-18 07:58 +0200
                  Re: Automatic Reference Counting bartekltg <bartekltg@gmail.com> - 2017-08-18 01:50 -0700
                Re: Automatic Reference Counting "AK" <nobody@nowhere.net> - 2017-08-18 07:54 +0200
          Re: Automatic Reference Counting "AK" <nobody@nowhere.net> - 2017-08-16 22:16 +0200

Page 1 of 3  [1] 2 3  Next page →

#30213 — Automatic Reference Counting

Języki Objective-C i Swift polegają na zliczaniu referencji. Jakie są 
sposoby radzenia sobie z pętlami?

[toc] | [next] | [standalone]

#30214

On Monday, August 14, 2017 at 1:17:27 AM UTC+2, Borneq wrote:
> Języki Objective-C i Swift polegają na zliczaniu referencji. Jakie są 
> sposoby radzenia sobie z pętlami?

Nie znam konkretnie tego zagadnienia, ale w ogóle kojarzy mi się z
teorią grafów, coś w stylu: oznacz wierzchołek jako odwiedzony.

Pozdrawiam
P.S.
Rozumiem, że chodzi o X wskazuje na Y, a Y wskazuje na Z.

[toc] | [prev] | [next] | [standalone]

#30215

W dniu 14.08.2017 o 01:35, M.M. pisze:
> On Monday, August 14, 2017 at 1:17:27 AM UTC+2, Borneq wrote:
>> Języki Objective-C i Swift polegają na zliczaniu referencji. Jakie są
>> sposoby radzenia sobie z pętlami?
> 
> Nie znam konkretnie tego zagadnienia, ale w ogóle kojarzy mi się z
> teorią grafów, coś w stylu: oznacz wierzchołek jako odwiedzony.

Co takiego jak weak_ptr które są również w C++.
Jak zrobione są shared_ptr i weak_ptr w C++?
Czy shared_ptr to obiekt a nie wskaźnik na obiekt, który ma pole
- goły wskaźnik
- wskaźnik na blok kontrolny - tutaj dodatkowy malloc?
Blok kontrolny to licznik referencji.
To jeszcze proste ale jak jest z weak:
Blok kontrolny to licznik referencji + drugi licznik.
Jak debugowałem shared_ptr to ma on w bloku kontrolnym _Uses i _Weaks - 
po to by łatwiej było go konwertować na weak?
Bo konwersja jest konieczna. Czy shared ma oba liczniki, tylko jednego 
nie wykorzystuje?
Jakie reguły zwalniania weak?
Tu jest przykład: 
https://www.codeproject.com/Articles/541067/Cplusplus-Smart-Pointers
ale chciałem się dowiedzieć więcej

[toc] | [prev] | [next] | [standalone]

#30216

On Monday, August 14, 2017 at 2:40:04 AM UTC+2, Borneq wrote:
> W dniu 14.08.2017 o 01:35, M.M. pisze:
> > On Monday, August 14, 2017 at 1:17:27 AM UTC+2, Borneq wrote:
> >> Języki Objective-C i Swift polegają na zliczaniu referencji. Jakie są
> >> sposoby radzenia sobie z pętlami?
> > 
> > Nie znam konkretnie tego zagadnienia, ale w ogóle kojarzy mi się z
> > teorią grafów, coś w stylu: oznacz wierzchołek jako odwiedzony.
> 
> Co takiego jak weak_ptr które są również w C++.
> Jak zrobione są shared_ptr i weak_ptr w C++?
> Czy shared_ptr to obiekt a nie wskaźnik na obiekt, który ma pole
> - goły wskaźnik
> - wskaźnik na blok kontrolny - tutaj dodatkowy malloc?
> Blok kontrolny to licznik referencji.
> To jeszcze proste ale jak jest z weak:
> Blok kontrolny to licznik referencji + drugi licznik.
> Jak debugowałem shared_ptr to ma on w bloku kontrolnym _Uses i _Weaks - 
> po to by łatwiej było go konwertować na weak?
> Bo konwersja jest konieczna. Czy shared ma oba liczniki, tylko jednego 
> nie wykorzystuje?
> Jakie reguły zwalniania weak?
> Tu jest przykład: 
> https://www.codeproject.com/Articles/541067/Cplusplus-Smart-Pointers
> ale chciałem się dowiedzieć więcej

Ja mam inne pytanie, czy warto tego używać i dlaczego?
Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#30217

W dniu 14.08.2017 o 10:03, M.M. pisze:
> Ja mam inne pytanie, czy warto tego używać i dlaczego?

Warto, kompilator się sam martwi o zwolnienie pamięci. Pytanie - jak to 
jest od środka robione.

[toc] | [prev] | [next] | [standalone]

#30218

On Monday, August 14, 2017 at 10:14:58 AM UTC+2, Borneq wrote:
> W dniu 14.08.2017 o 10:03, M.M. pisze:
> > Ja mam inne pytanie, czy warto tego używać i dlaczego?
> 
> Warto, kompilator się sam martwi o zwolnienie pamięci. Pytanie - jak to 
> jest od środka robione.

Widzę że coś jak QMutexLocekr w Qt, tylko że mutex locker samo
odblokowuje mutex a nie zwalnia pamięć :) 
http://doc.qt.io/qt-4.8/qmutexlocker.html

Bardzo rzadko używam malloc i new. Gdy muszę parę linijek wpisać aby 
zwolnić pamięć, to korona z głowy mi nie spadnie. Procedury staram się 
pisać w ten sposób, aby był jeden punkt wyjścia, więc wszelkie 
zwalnianie zasobów łatwiej ogarnąć, bo są zamieszczone zbiorczo na 
końcu. 

Jak to jest robione od środka... nie znam pełnej funkcjonalności, 
trudno powiedzieć. Na pewno w destruktorze zwalnia pamięć - ale
myślę że to wiesz. Więc co pytasz? Dlaczego pytasz?

Jeśli w pierwszy poście pętlami nazwałeś cykle w grafie, to rozwiązuje
się to przez oznaczenie wierzchołka grafu jako oznaczony - tak jak
pisałem, ale nie odpowiedziałeś czy o to chodziło, czy zrozumiałeś, itd.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#30219

W dniu 14.08.2017 o 10:31, M.M. pisze:
> Widzę że coś jak QMutexLocekr w Qt, tylko że mutex locker samo
> odblokowuje mutex a nie zwalnia pamięć :)
> http://doc.qt.io/qt-4.8/qmutexlocker.html

W poniższym przykładzie listy cyklicznej jest coś źle.
Shared nie powinien zwalniać, a zwalnia wszystkie z wyjątkiem jednego i 
to przed opuszczeniem test(),
zamiana na weak skutkuje tym że jest na zmianę tworzenie i zaraz 
zwalnianie. Coś nie tak, jak w teorii.

#include <memory>
#include <iostream>
using namespace std;

class Node
{
private:
	int n;
public:
	Node(int n): n(n)
	{
		cout << "Constructor Node is called " << n <<endl;
	}
	~Node()
	{
		cout << "Destructor Node is called " << n << endl;
	}
	shared_ptr<Node>  prev;
};



int test()
{
	shared_ptr<Node> node = shared_ptr<Node>(new Node(0));
	shared_ptr<Node> first = node;
	for (int i = 1; i < 5; i++)
	{
		shared_ptr<Node> prev = node;
		node = shared_ptr<Node>(new Node(i));
		node->prev = prev;
	}
	node->prev = node;
	printf("====\n");
     return 0;
}

int main()
{
	test();
	return 0;
}

[toc] | [prev] | [next] | [standalone]

#30220

W dniu 14.08.2017 o 15:10, Borneq pisze:
>      shared_ptr<Node> first = node;
>      node->prev = node; <---error

zaraz zaraz, powinno być first->prev = node;nawet zmienna jest first
teraz nie zwalnia wcale i jest ok.

[toc] | [prev] | [next] | [standalone]

#30221

W dniu 14.08.2017 o 15:10, Borneq pisze:
>      shared_ptr<Node>  prev;

zamiana na weak_ptr<Node>  prev;
skutkuje:
Constructor Node is called 0
Constructor Node is called 1
Constructor Node is called 2
Destructor Node is called 1
Constructor Node is called 3
Destructor Node is called 2
Constructor Node is called 4
Destructor Node is called 3
====
Destructor Node is called 0
Destructor Node is called 4

Żle bo wszystkie destructory powinny być wołane po kresce, za szybko 
teraz zwalnia.
---
	shared_ptr<Node>  prev;
	weak_ptr<Node>  weakprev;

first->weakprev = node;

Teraz ok, czyli najgłębszy wskazujący ten na szczycie powinien być tylko 
weak.

[toc] | [prev] | [next] | [standalone]

#30222

On Monday, August 14, 2017 at 3:10:41 PM UTC+2, Borneq wrote:
> W dniu 14.08.2017 o 10:31, M.M. pisze:
> > Widzę że coś jak QMutexLocekr w Qt, tylko że mutex locker samo
> > odblokowuje mutex a nie zwalnia pamięć :)
> > http://doc.qt.io/qt-4.8/qmutexlocker.html
> 
> W poniższym przykładzie listy cyklicznej jest coś źle.
> Shared nie powinien zwalniać, a zwalnia wszystkie z wyjątkiem jednego i 
> to przed opuszczeniem test(),
> zamiana na weak skutkuje tym że jest na zmianę tworzenie i zaraz 
> zwalnianie. Coś nie tak, jak w teorii.
> 
> #include <memory>
> #include <iostream>
> using namespace std;
> 
> class Node
> {
> private:
> 	int n;
> public:
> 	Node(int n): n(n)
> 	{
> 		cout << "Constructor Node is called " << n <<endl;
> 	}
> 	~Node()
> 	{
> 		cout << "Destructor Node is called " << n << endl;
> 	}
> 	shared_ptr<Node>  prev;
> };
> 
> 
> 
> int test()
> {
> 	shared_ptr<Node> node = shared_ptr<Node>(new Node(0));
> 	shared_ptr<Node> first = node;
> 	for (int i = 1; i < 5; i++)
> 	{
> 		shared_ptr<Node> prev = node;
> 		node = shared_ptr<Node>(new Node(i));
> 		node->prev = prev;
> 	}
> 	node->prev = node;
Dopiero teraz nie mam wątpliwości, co nazywałeś pętlą w 
pierwszym wątku :)
> 	printf("====\n");
>      return 0;
> }
> 
> int main()
> {
> 	test();
> 	return 0;
> }

[toc] | [prev] | [next] | [standalone]

#30304

Użytkownik "Borneq" <borneq@antyspam.hidden.pl> napisał:

> Warto, kompilator się sam martwi o zwolnienie pamięci. Pytanie - jak to jest od środka robione.

.. a co Cie to obchodzi?

AK 

[toc] | [prev] | [next] | [standalone]

#30325

On Wednesday, August 16, 2017 at 10:18:39 PM UTC+2, AK wrote:
> Użytkownik "Borneq" <borneq@antyspam.hidden.pl> napisał:
> 
> > Warto, kompilator się sam martwi o zwolnienie pamięci. Pytanie - jak to jest od środka robione.
> 
> .. a co Cie to obchodzi?

Zgaduję, że On się zastanawia jaki będzie narzut pamięciowy i 
czasowy.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#30344

W dniu środa, 16 sierpnia 2017 23:31:52 UTC+2 użytkownik M.M. napisał:
> On Wednesday, August 16, 2017 at 10:18:39 PM UTC+2, AK wrote:
> > Użytkownik "Borneq" <borneq@antyspam.hidden.pl> napisał:
> > 
> > > Warto, kompilator się sam martwi o zwolnienie pamięci. Pytanie - jak to jest od środka robione.
> > 
> > .. a co Cie to obchodzi?
> 
> Zgaduję, że On się zastanawia jaki będzie narzut pamięciowy i 
> czasowy.
> 
moim zdaniem jest to typowy przyklad oszlomstwa broneq (ktorego ja nie ukrywam nie lubie i uwazam za oszolomskiego matola - z wielu wzgledow np ze wzgledu na glupote jego niektorych 'twierdzen', to ze nie jest w stanie sformulowac poprawnie pytania podjac dyskusji wyciagnac glebszych wnioskow itd itd) ktore kaze mu zadawac pytania na temat wszystkiego  co wleci biedakowi w 
wyszukiwarke

sam swoja drogą przechodzilem podobna faze
interesowania 'wszystkim' ale ta faza u mnie sie skonczyla pare lat temu - jakie latwe swoja drogą bylo wtedy zycie o_O (choc czas uciekal).. - teraz jestem w innej fazie tj takiej od ktorej oczekiwaloby sie interesowania tylko waznymi i knokretnymi tematami prowadzacymi do okreslonego rezultatu (np zrobienie konkretnej gry, zrobienie konkretnej biblioteki) ta 'faza' 
zjakichs powodow jest dla mnie strasznie trudna...:C

[toc] | [prev] | [next] | [standalone]

#30351

Użytkownik "fir" <profesor.fir@gmail.com> napisał:

> moim zdaniem jest to typowy przyklad oszlomstwa broneq (ktorego ja nie ukrywam nie lubie i uwazam 
> za oszolomskiego matola -
[...]
> zjakichs powodow jest dla mnie strasznie trudna...:C

No to spie^H^H^H sio z powrotem do kibla (ś)fir-niety buraku!

[toc] | [prev] | [next] | [standalone]

#30352

W dniu piątek, 18 sierpnia 2017 08:02:33 UTC+2 użytkownik AK napisał:
> Użytkownik "fir" <profesor.fir@gmail.com> napisał:
> 
> > moim zdaniem jest to typowy przyklad oszlomstwa broneq (ktorego ja nie ukrywam nie lubie i uwazam 
> > za oszolomskiego matola -
> [...]
> > zjakichs powodow jest dla mnie strasznie trudna...:C
> 
> No to spie^H^H^H sio z powrotem do kibla (ś)fir-niety buraku!

no tak wam starym specjalistom od dziadostwa
kroku nie dotrzymam (choć nie mam takiego zamiaru)

[toc] | [prev] | [next] | [standalone]

#30348

Użytkownik "M.M." <mmarszik@gmail.com> napisał:

> > Warto, kompilator się sam martwi o zwolnienie pamięci. Pytanie - jak to jest od środka robione.
>
> .. a co Cie to obchodzi?

> Zgaduję, że On się zastanawia jaki będzie narzut pamięciowy i
> czasowy.

Taaa. Klasycznie jak to u Krzyżowca.
Jeszcze zanim uzyje, już optymalizuje....
PS: Krzyżowcu! W shared_ptr masz _za darmo_ (atomowo, bez lockow) thread-safe
      Naprawde warto :)
PS1: "Optymalizuj" wtedy gdy to _naprawde_ jest potrzebne

AK

[toc] | [prev] | [next] | [standalone]

#30353

On Friday, August 18, 2017 at 7:51:41 AM UTC+2, AK wrote:
> Użytkownik "M.M." <mmarszik@gmail.com> napisał:
> 
> > > Warto, kompilator się sam martwi o zwolnienie pamięci. Pytanie - jak to jest od środka robione.
> >
> > .. a co Cie to obchodzi?
> 
> > Zgaduję, że On się zastanawia jaki będzie narzut pamięciowy i
> > czasowy.
> 
> Taaa. Klasycznie jak to u Krzyżowca.
> Jeszcze zanim uzyje, już optymalizuje....
> PS: Krzyżowcu! W shared_ptr masz _za darmo_ (atomowo, bez lockow) thread-safe
>       Naprawde warto :)

Ale to thread-safe ogranicza się operacji na wskaźnikach. Jeśli w wątkach 
odpale:

th1:
  p1 -> foo();
th2: 
  p2 -> bar();

p1 i p2 pokazują na tan sam obiekt (p2 to kopia p1)
To nadal mogę coś zepsuć, bo odpalenie foo nie będize czekało
na koniec bar (lub odwrotnie).
Czy coś źle rozumiem i to tez jest gwarantowane?

> PS1: "Optymalizuj" wtedy gdy to _naprawde_ jest potrzebne

Powtarza się jeszcze jedną mądrość. Zaczynac od unique_ptr, a nuz
wystarczy.

pzdr
bartekltg

[toc] | [prev] | [next] | [standalone]

#30356

On Friday, August 18, 2017 at 10:42:38 AM UTC+2, bartekltg wrote:
> On Friday, August 18, 2017 at 7:51:41 AM UTC+2, AK wrote:
> > Użytkownik "M.M." <mmarszik@gmail.com> napisał:
> > 
> > > > Warto, kompilator się sam martwi o zwolnienie pamięci. Pytanie - jak to jest od środka robione.
> > >
> > > .. a co Cie to obchodzi?
> > 
> > > Zgaduję, że On się zastanawia jaki będzie narzut pamięciowy i
> > > czasowy.
> > 
> > Taaa. Klasycznie jak to u Krzyżowca.
> > Jeszcze zanim uzyje, już optymalizuje....
> > PS: Krzyżowcu! W shared_ptr masz _za darmo_ (atomowo, bez lockow) thread-safe
> >       Naprawde warto :)
> 
> Ale to thread-safe ogranicza się operacji na wskaźnikach. Jeśli w wątkach 
> odpale:
> 
> th1:
>   p1 -> foo();
> th2: 
>   p2 -> bar();
> 
> p1 i p2 pokazują na tan sam obiekt (p2 to kopia p1)
> To nadal mogę coś zepsuć, bo odpalenie foo nie będize czekało
> na koniec bar (lub odwrotnie).
> Czy coś źle rozumiem i to tez jest gwarantowane?
> 
> > PS1: "Optymalizuj" wtedy gdy to _naprawde_ jest potrzebne
> 
> Powtarza się jeszcze jedną mądrość. Zaczynac od unique_ptr, a nuz
> wystarczy.
> 
> pzdr
> bartekltg

Tak intensywnie piszecie o tych sprytnych wskaźnikach... chyba będę
musiał się przeprosić z nimi. Ale ostatnio w ogóle mam bardzo mało
wskaźników w kodzie (nie licząc wskaźników na statyczne/automatyczne
obiekty). Większość wskaźników utworzonych przez new mam wewnątrz
wektorów, map, hash-map, list, więc dla mnie przydatność smartpointers
będzie pojawiała się bardzo rzadko.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#30358

W dniu 18.08.2017 o 10:42, bartekltg pisze:
> Powtarza się jeszcze jedną mądrość. Zaczynac od unique_ptr, a nuz
> wystarczy.

Czy wystarczy?
Mam obiekt właściciel i obiekty które on posiada.
Te mniejsze obiekty mają wskaźnik na właściciela.
Gdyby to było unique_ptr trzeba by zrobić move(*this) gdy z właściciela 
wołam konstruktor mniejszego obiektu.

[toc] | [prev] | [next] | [standalone]

#30359

On Friday, August 18, 2017 at 11:37:38 AM UTC+2, Borneq wrote:
> W dniu 18.08.2017 o 10:42, bartekltg pisze:
> > Powtarza się jeszcze jedną mądrość. Zaczynac od unique_ptr, a nuz
> > wystarczy.
> 
> Czy wystarczy?
> Mam obiekt właściciel i obiekty które on posiada.
> Te mniejsze obiekty mają wskaźnik na właściciela.
> Gdyby to było unique_ptr trzeba by zrobić move(*this) gdy z właściciela 
> wołam konstruktor mniejszego obiektu.

Jeśli to jest drzewo, to w dół idzie unique_ptr, a w górę choćby goły
wskaźnik. Ten goły zawsze jest ważny, bo obiekt w którym jest istnieje
tylko, jesli obiekt nadrzędny istnieje. 

Był jakiś fajny wykład o wykorystanu roznych kombinacji na cppcon (14, 15 albo 16).


pzdr
bartekltg

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | pl.comp.programming

csiph-web