Użytkownik "Michoo" <m...@v...pl> napisał:

> Jakie, kurcze, "ręczne" malloc? Jeżeli w c++ oprzesz sobie cały interface na
shared_ptr<T> to masz
> dokładnie to co robi java/C#, tylko z deterministycznym zwalnianiem zasobów. Jak
trzymasz się
> wzorca pimpl to masz kod używający new tylko w konstruktorze a delete wcale.

Misiu

Nie ucz ojca dzieci robic (dlaczego kurcze Wam mlodym _ciagle_ sie od lat
wydaje, ze pozjadaliscie wszytskie rozumy/umiejetnosci w stosunku
do nas "matuzalemow;) ?).
Sam tak robie od lat.
I nie shared_pt tylko: shared_ptr, scoped_ptr i grin_ptr itp
Tylko powiedz mi Musiu dlaczego w C++ musze sie tyle nameczyc
(no i jeszcze ten PIMPL niezbedny) jesli w Javie mam to ad hoc
i bez udziwnien/komplikacji/ograniczen PIMPLa (dziedziczenie) itp ?
No po co ? Przeciez wtedy pisze niby w C++, ale _tak naprawde w Javie_ :)

Zwlaszcza, ze shared_ptr jest "atomowy" rowniez w sensie wielowatkowosci,
a wiec naprawde _cholernie_ kosztowny w stosunku do jednowatkowosci.
Tyle, ze ja sobie "mutexowania" w shared_ptr wylaczyc nie moge
nawet gdybym w dokumentacji duzymi bukwami napisal, ze
program/modul jest jednowatkowy.
Przecie smart_ptr to szablon, a wiec macro a wiec kompilator g.. wie o
kontekscie uzycia (nie umie zoptymalizowac).
W Javie/.NET refs sa _wewnetrzym wbudowanym podstawowym mechanizmem_
obslugi obiektow, wiec Java/.NET sobie moze to o wiele lepiej (i czymi to)
zoptymalizowac

PS: i nieprawda jest, ze mam wtedy "deterministyczne" zwalnianie zasobow.
Mamy tak/podobnie jak w Javie/C# (smieciarka), czyli wolnienie gdy ref_count
zjedzie do 0. (No ale o cykle to juz musze niestety zadbac/pilnowac sam:).

> Spieprzyć kod można w dowolnym języku.

Czasem sam jezyk (C++) "pieprzy"" kod.

> P.S.
> Przypominam, że miałeś udowodnić jak to kolejność ewaluacji operatorów w C/C++ jest
dowolna.

a nie chce mi sie teraz:) Moze jutro ?
I badz precyzyjny: pisalem ze "kolejnosc evaluacji operatorow" _o tym samym
priotrytecie_
jest dowolna.
Nawiasy w tym przypadku sa opuszczane juz na etapie (umownego) parsingu.

AK