W dniu piątek, 18 sierpnia 2017 08:02:33 UTC+2 użytkownik AK napisał:
> Użytkownik "fir" <p...@g...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)

do góry

On Friday, August 18, 2017 at 7:51:41 AM UTC+2, AK wrote:
> Użytkownik "M.M." <m...@g...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

do góry

On Friday, August 18, 2017 at 7:09:09 AM UTC+2, Borneq wrote:
> W dniu 17.08.2017 o 23:56, Wojciech Muła pisze:
> > Bo standard wymusza określone cechy - np. std::shared_ptr jest
> > bezpieczny wątkowo. A to znaczy, że może okazać się za wolny. :)
> >
> > w.
> >
> używa:
> long volatile a = 5;
> _InterlockedIncrement(&a);
> _InterlockedDecrement(&a);
>
> a te dwie funkcje kompilowane są tylko do przedrostka lock przed inc/dec
> w kodzie assemblerowym.

http://en.cppreference.com/w/cpp/atomic/atomic
;->

pzdr
bartekltg

do góry

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." <m...@g...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

do góry

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.

do góry

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

do góry

On Friday, August 18, 2017 at 12:07:45 PM UTC+2, bartekltg wrote:
> 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).

https://www.youtube.com/watch?v=JfmTagWcqoE (13 minuta)
Ale wydaje mi sie, ze było gdzieś szerzej.

pzdr
bartekltg

do góry

W dniu 18.08.2017 o 12:07, bartekltg pisze:
> 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.

unique_ptr - trzeba stosować move zamiast przypisania.
Mam font mający wskaźnik na właściciela - okno.
Teraz w oknie tworzę font: new Font(move(*this)) ?

do góry

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?

A jeśli wystarczy, to może i Java wystarczy, po co się męczyć z C++, wszak
wiadomo, że pisanie programów, nie wspomniawszy o pisaniu zoptymalizowanych
programów, w C++ jest i dużo trudniejsze i wymaga dużo więcej czasu.

Nie wiem czy wystarczy. Gdy używam C++ i gdy użycie C++ jest uzasadnione, to
zazwyczaj drobiazgi przeszkadzają (czyli nie-wystarczają). Kiedyś musiałem
wywalić np. obiekt QDateTime, bo za wolno wykonywał, wydawałoby się, proste
operacje na dacie i czasie.

>[...]

Pozdrawiam

do góry

On Friday, August 18, 2017 at 12:38:19 PM UTC+2, Borneq wrote:
> W dniu 18.08.2017 o 12:07, bartekltg pisze:
> > 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.
>
> unique_ptr - trzeba stosować move zamiast przypisania.
> Mam font mający wskaźnik na właściciela - okno.
> Teraz w oknie tworzę font: new Font(move(*this)) ?

To zależy, co chcesz osiagnać.
A ja tego nie wiem. Nie wiem nawet, co robisz w tej linijce;-)

u_ptr moze być złym rozwiązanie do danego problemu. Wszytko zależy od problemu;-)

pzdr
bartekltg

do góry