LINUX.ORG.RU

libgc 1.0 - библиотека автоматической сборки мусора для C++


0

0

LibGC - небольшая, быстрая, портируемая и многопоточная библиотека сборки мусора для C++, распространяемая по лицензии BSD. Разработчик отмечает простоту и гибкость в использовании, а также эффективность. А что скажете вы? :)

>>> Домашняя страница



Проверено: Shaman007 ()
Ответ на: комментарий от catap

Использование GC (или reference count) упрощает логику программы. К тому же не всегда очевидно, где именно вставлять delete :)

anonymous
()
Ответ на: комментарий от anonymous

Вы пример такого упращения...

А на тему, что не очевидно когда... Это возможно, но на то вам и дан мозг, что бы понять, когда надо удалить объект, а не надеятся на гравицапу.

catap ★★★★★
()
Ответ на: комментарий от catap

>Это возможно, но на то вам и дан мозг, что бы понять, когда надо удалить объект, а не надеятся на гравицапу.

Когда надо удалять и где надо удалять - немного разные понятия. Зная _когда_ надо удалять не всегда возможно решить _где_ надо удалять.

К тому же, зачем выполнять дурную работу? Пусть машина сама решает такие неинтересные технические вопросы. Разве что кроме случаев где это действительно чем-то обоснованно.

WFrag ★★★★
()
Ответ на: комментарий от WFrag

> Разве что кроме случаев где это действительно чем-то обоснованно.

Например если своевременное удаление объекта является критичным моментом для программы.

mutronix ★★★★
()
Ответ на: комментарий от anonymous

Гравицапа нужна для пепелаца, чтобы полететь на планету Плюк. Стоит полспички. Ку-ууу...

"Кин-дза-дза"

anonymous
()
Ответ на: комментарий от mutronix

>Например если своевременное удаление объекта является критичным моментом для программы.

Чаще всего критичным является своевременное освобождение некоторого ресурса (причем не памяти). Удаление объекта - всего лишь один из способов этого достичь, правда как раз больше всего подходящий под идеологию C++.

WFrag ★★★★
()
Ответ на: комментарий от WFrag

C++ - объектно-ориентированный язык, поэтому естественно связать ресурс с объектом и в деструкторе его освободить, других путей просто нет.

anonymous
()
Ответ на: комментарий от catap

не всегда delete спасает!

Мозг дан думать, а эта тулза могут помочь думать... Хотя можть у тя проц в мозг интегрирован, все может быть и ты помнишь все выделения памяти, даже когда делаешь связные списки, да вообще работаешь с динамическими данными...

anonymous
()
Ответ на: комментарий от anonymous

> C++ - объектно-ориентированный язык, поэтому естественно связать ресурс с объектом и в деструкторе его освободить, других путей просто нет.

Вот и не правда ваша. Часто в классе ведется подсчет ссылок на объект и деструктор не удаляет объект до тех пор пока на него ссылается хотя бы один указатель-дескриптор(до боли знакомо, правда?) В этом случае за удаление объекта отвечает закрытая функция-член класса вызываемая из деструктора или перегруженного оператора "=", а не сам деструктор. Управление памятью в С++ это отнюдь не простая задача. Это же не Java.

mutronix ★★★★
()
Ответ на: комментарий от anonymous

>C++ - объектно-ориентированный язык, поэтому естественно связать ресурс с объектом и в деструкторе его освободить, других путей просто нет.

Да, но можно по разному связать ресурс и объект. Например, можно освобождать ресурс из dispose(). :) То есть освобождение в деструкторе - вообще не единственный вариант.

Я имел ввиду, что в C++ принято управлять ресурсами основываясь на принципе RAII.

WFrag ★★★★
()
Ответ на: комментарий от catap

Чудило, не всегда ты вообще имеешь право удалять объекты явным образом. Это крайне неэффективно и по времени, и по памяти.

anonymous
()
Ответ на: комментарий от mutronix

>Вот и не правда ваша. Часто в классе ведется подсчет ссылок на объект и деструктор не удаляет объект до тех пор пока на него ссылается хотя бы один указатель-дескриптор(до боли знакомо, правда?) В этом случае за удаление объекта отвечает закрытая функция-член класса вызываемая из деструктора или перегруженного оператора "=", а не сам деструктор.

ОБАНА! Единственный интерестный пост во всем этом треде о домашней работе для студента младшего курса!

А не растолкует ли уважаемый сэр что он собственно имел ввиду? Если я правильно понял, то тут два постулата:

1) Деструктор вызывается, а объект не уничтожается - ибо ссылок на него есть и так моного раз...

2) Из перегруженного оператора = вызывается некая "закрытая функция-член класса", которая и уничтожает объект, не вызывая его деструктор.

Был бы счастлив получить урок эксперта!

anonymous
()
Ответ на: комментарий от anonymous

>Вот уж какая форма GC почти никогда недопустима, так это подсчёт ссылок.

А я то думаю почему в случае shared ownership в жабских программах ссылки считают? Понял таперича - неправильно делают. А как правильно то? Научи.

anonymous
()
Ответ на: комментарий от anonymous

>Чудило, не всегда ты вообще имеешь право удалять объекты явным образом. Это крайне неэффективно и по времени, и по памяти.

Не растолкует ли уважаемый сэр ламеру, каким образом это накладно по времени и по памяти?

anonymous
()
Ответ на: комментарий от anonymous

Парой постов выше это растолковано. Когда надо удалить хэш-таблицу о паре сотен мегабайт, а у тебя на memory management по регламенту предусмотренно строго не более 0.1% машинного времени в рассчёте на одну минуту, то делать это явным образом - бред свинячий, тогда как GC легко с задачей справится, причём - без каких бы то ни было дополнительных накладных расходов.

Вообще же, лучший вариант - комбинированный. Там, где можно автоматически вывести случаи явного удаления объектов - удалять явно, а в остальных случаях использовать GC. Так умеет пока только MLTon, однако.

anonymous
()
Ответ на: комментарий от anonymous

Читай, как нормальные GC устроены - про компактифицирующий stop and copy, про инкрементальный mark and sweep...

anonymous
()
Ответ на: комментарий от anonymous

>Когда надо удалить хэш-таблицу о паре сотен мегабайт, а у тебя на memory management по регламенту предусмотренно строго не более 0.1% машинного времени в рассчёте на одну минуту, то делать это явным образом - бред свинячий, тогда как GC легко с задачей справится, причём - без каких бы то ни было дополнительных накладных расходов.

А я выделю блок в пару сотен мегов, размещу там свою таблицу и грохну ее за один раз - просто грохнув блок. Или вообще не буду грохать, а использую для другой такой таблицы или ... короче - куча способов - только ДЕБИЛ не догонит. А вообще говоря, я по глупости своей думал, что в RT приложениях обычно память динамически стараются не распределять...

anonymous
()
Ответ на: комментарий от anonymous

> А вообще говоря, я по глупости своей думал, что в RT приложениях обычно память динамически стараются не распределять...

Это раньше так было, когда еще не было правильных, доказанных RT GC. Вот и приходилось лечить головную боль топором, отказываясь от динамического распределения памяти вообще. Зато теперь...

anonymous
()
Ответ на: комментарий от anonymous

>итай, как нормальные GC устроены - про компактифицирующий stop and copy, про инкрементальный mark and sweep..

Спасибочки за совет. Вы забыли еще слово multigenerational. Так ведь читал и доки и исходный код, и сам писАл - по глупости - в студенчестве зеленом...

И что?

anonymous
()
Ответ на: комментарий от anonymous

Ну ты правильно догнал тему, что ты - дебил.

Любишь искать приключения на свою убогую жопу, изобретать лишний раз велосипед, и писать что-то, по функциональности аналогичное GC - тогда как прекрасно мог бы воспользоваться уже готовым - ну так сам себе этически ограниченный антропоморфный дендроид.

anonymous
()
Ответ на: комментарий от anonymous

И то, что был дебилом, дебилом и помрёшь. Считать ссылки будет только идиот, когда есть гораздо более эффективные алгоритмы. А уж как хорошо считать ссылки на циклических структурах - просто сказка и пейсня, все конкретные пацаны чиста ссылки и считают...

anonymous
()
Ответ на: комментарий от anonymous

Я что-то не догнал. Читал недавно про Digital Mars D, там как раз есть GC, но сам автор говорит, что с точки зрения RT-программы, использование GC может привести к непредсказуемым задержкам, поскольку нельзя предсказать в какой момент сработает GC. Этой точки зрения, ручные new/delete более предсказуемы.

Casus ★★★★★
()
Ответ на: комментарий от anonymous

эта... если два обжекта будут друг на друга сцылатся а более на них никто сцылаться не будет то они так и повиснут в памяти... классика..

anonymous
()
Ответ на: комментарий от Casus

> там как раз есть GC, но сам автор говорит, что с точки зрения RT-программы, использование GC может привести к непредсказуемым задержкам,

Это значит, что его GC - не RT. Только и всего.

> ручные new/delete более предсказуемы

:) Традиционные new и delete непредсказуемы, независимо от того как их вызывать - руками или нет.

anonymous
()
Ответ на: комментарий от anonymous

> Был бы счастлив получить урок эксперта!

http://int3.net/ex-book/Alger/Alger_C++.zip

Глава 14. Основы управления памятью: Подсчет ссылок.

IMHO, любой программист на С++ must have this book.

mutronix ★★★★
()
Ответ на: комментарий от WFrag

>К тому же, зачем выполнять дурную работу?

если программирование с участием мозга это уже дурная робота то наверное пора большей части "программастов" задуматься о переквалификации в дворники.

не я понимаю, самоучение по дешевым книгам и отсутствие академического обучения рождают чудовищ, но не до такой же степени

anonymous
()
Ответ на: комментарий от anonymous

>все может быть и ты помнишь все выделения памяти, даже когда делаешь связные списки, да вообще работаешь с динамическими данными...

боже ж мой, программаст на программасте. скоро тут будут посты "а что за Esc? он где? ты что с процом в башке что помнишь все кнопки? тебе что мыши мало?"

anonymous
()
Ответ на: комментарий от anonymous

> самоучение по дешевым книгам и отсутствие академического обучения рождают чудовищ

Небезынтересно то, что как раз языки с автоматическим управлением памятью (Lisp, ML, Oberon и т.п.) пользуются куда бОльшим уважением именно в академических сообществах. И скорее всего именно потому, что у ученых есть задачи поинтереснее, чем поиск очередной утечки памяти или потертого блока. Другое дело программисты --- им за это платят. :-)

--

SVK

anonymous
()
Ответ на: комментарий от anonymous

Ты сильно болен на все головы.

Программирование с применением мозга тем и отличается от пионерщины, что не требует тратить время и силы на легко автоматизируемые, низкоуровневые задачи.

Жаль только, что большинство пионэров никогда не вырастут - у них слишком маленькие мозги, чтобы туда поместилось что-то большее.

Idiot
()
Ответ на: комментарий от anonymous

>эта... если два обжекта будут друг на друга сцылатся а более на них никто сцылаться не будет то они так и повиснут в памяти... классика..

Вот тестовый код для этого gc:

#include "gc.hpp"
using namespace gc;
#include <iostream>
using namespace std;

//big
class Foo : public Object {
public:
~Foo(){cout << "~Big()" << endl; };
Pointer<Foo> p;
int m_data[500];
};

void init()
{
Pointer<Foo> p, p1;
p = new Foo;
p1 = new Foo;
p->p = p1;
p1->p = p;
};

int main()
{
init();
cout << collectGarbage() << endl;
cin.get();
return 0;
};

А вот результаты его работы:
g++ main2.cpp gc.cpp
./a.out
~Big()
~Big()
4032



anonymous
()
Ответ на: комментарий от anonymous

если объекты ссылаются друг на друга, то им ничего не поможет.. Потому как GC не сможет за тебя решить какой из ник первый деструктурировать, единственное что он может -- это просто высвободить память, которую объекты занимали. А если в дестркуторе одного объекта мне понадобится поюзать второй? (напиши в деструкторе p->m_data;)

Я с данным gc не знаком, но боюсь, что это скорее бага, чем фича :-)

С другой стороны, полагаешься на GC, нефиг ресурсы в деструторе высвобождать, делай функцию close и зови ее руками.

dimonb
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.