Użytkownik "M.M." <m...@g...com> napisał:

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

ZDECYDOWANIE TAK ! (ba! warto nawet _wylacznie_ tego uzywac).

PS: Pytanie tak z 20 lat spoznione. Juz wtedy bylo warto (vide:
boost::smart_pointers).
PS1: Jak zwykle w "standaryzacji" C++ czegos zapomniano/niedorobiono. Jest nim
copy_pointer.

AK

do góry

Użytkownik "Borneq" <b...@a...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

do góry

On Wednesday, August 16, 2017 at 10:18:39 PM UTC+2, AK wrote:
> Użytkownik "Borneq" <b...@a...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

do góry

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" <b...@a...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

do góry

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

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.

do góry

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.

do góry

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 :)
PS1: "Optymalizuj" wtedy gdy to _naprawde_ jest potrzebne

AK

do góry

Użytkownik "Wojciech Muła" <w...@g...com> napisał:
> Użytkownik "Borneq" <b...@a...hidden.pl> napisał:
>
> > Warto, kompilator się sam martwi o zwolnienie pamięci. Pytanie - jak to jest od
środka robione.
>
> .. a co Cie to obchodzi?

> Bo standard wymusza określone cechy - np. std::shared_ptr jest
> bezpieczny wątkowo. A to znaczy, że może okazać się za wolny. :)

Zgadza sie :), ale.
1. jego (shared_ptr-a) thread-safe jest naprawde tani, bo atomowy (zwykle rozkaz
assemblera).
2. Martwic sie o to nalezy dopiero, gdy problem wydajnoisciowy sie pojawi a nie
jeszcze "przez
obudzeniem".

AK

do góry

Użytkownik "Borneq" <b...@a...hidden.pl> napisał:

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

No widzisz :)!!!? A tak sie martwiles Krzyzowcze o wydajnosc:)
PS: No dooobra... Nie ma tak miodzio. Na Win to klasyczny mutex
(tak bylo w boost:shared_ptr. teraz (w standardzie, czy VC++2015) nie wiem
Rozstalem sie bez zalu na stare lata z ++żykami na dobre...

AK

do góry

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!

do góry