🚀 go-pugleaf

piątek, 10 marca 2023 o 15:41:14 UTC+1 Przemek Biernat napisał(a):
> On Thursday, March 9, 2023 at 10:40:41 PM UTC+1, Sebastian Nibisz wrote:
> > czwartek, 9 marca 2023 o 22:24:34 UTC+1 Przemek Biernat napisał(a): 
> > > On Thursday, March 9, 2023 at 10:19:07 PM UTC+1, Sebastian Nibisz wrote: 
> > > > czwartek, 9 marca 2023 o 19:44:15 UTC+1 Przemek Biernat napisał(a): 
> > > > > On Thursday, January 19, 2023 at 1:51:44 PM UTC+1, Sebastian Nibisz wrote: 
> > > > > > Odkopię ten historyczny temat. 
> > > > > > Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https://github.com/pebal/sgcl 
> > > > > Korzysta z STL'a? 
> > > > Korzysta. Obecnie raczej trudno obyć się bez STL'a. 
> > > Obyłem się. Napisałem własną bibliotekę, która została rozwinięta. STL jest słabe. Iteratory przez wartość, brak cykli, brak klonowania iteratora, bida. Szczerze to nie wiem do czego służy SGCL, jak mi wyjaśnisz to napiszę własną wersję, może będzie działać wydajniej. 
> > SGCL to współbieżny, całkowicie bezpauzowy garbage collectror dla C++. Chcesz napisać szybszy? Powodzenia. Szczególnie w tym, aby w ogóle działał.
> Garbage collector w C++, hmm, ciekawe, tylko po co? Nie lepiej dobrze nauczyć się pisać w C++ i kontrolować czas życia obiektu z użyciem new i delete. Alokator ma jakiś sens bo przyspiesza tworzenie nowych obiektów. W naszym kompilatorze jest o ile dobrze pamiętam wsparcie dla scope'ów więc sprawa jest odrobinę łatwiejsza jeżeli się nie mylę. Co ja tam mogę wiedzieć.
Nie da się wszystkim zarządzać ręcznie, bo problem własności nie zawsze jest trywialny. Poszukaj implementacji współbieżnego stosu w C++, który zwalnia pamięć. Nawet biblioteka boost takiej nie ma a mając GC implementacja jest trywialna.