LINUX.ORG.RU

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


0

0

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

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



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

GC - гравицапа :)))) ой, не могу )) давно я так не смеялся :)) И про велогонки тоже замечательно подмечено.

Да, нигде кроме как на ЛОРе такого не услышишь :)

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

это тот товаришч, что недавно предлагал свои услуги
Trollям (qt-interest@trolltech.com list)?

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: шагом марш в топку! от Dselect

>> не скажете ли мне ламеру, какие RT "рантаймы c GC" вы знаете
> oberon (hard RT),
> http://www.ifr.mavt.ethz.ch/research/xoberon/introduction.html

Цитата со страницы:

"Further development will guarantee best-of-breed real-time
capabilities, like a real-time compatible incremental garbage collector"

Похоже, что нет там пока "realtime GC" - и неизвестно, будет ли.

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

Господам, спорящим по поводу с++, gc и RealTime иногда стоило бы задуматься о том, что RT ПО вообще как правило почему-то не пишется на с++. Сейчас я смотрю модно причислять себя к ламерам, поэтому я тоже скажу, что может я ламер, видел RT ПО на pure Си, видел даже на жаве, но на с++ - никогда.

Displacer ★★
()

а как там с русификацией?

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

>Господам, спорящим по поводу с++, gc и RealTime иногда стоило бы задуматься о том, что RT ПО вообще как правило почему-то не пишется на с++. Сейчас я смотрю модно причислять себя к ламерам, поэтому я тоже скажу, что может я ламер, видел RT ПО на pure Си, видел даже на жаве, но на с++ - никогда.

QNX?

mutronix ★★★★
()

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

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

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

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

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

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

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

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

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

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

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

--

SVK

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

Чувак, ты всё прочитал, что тут обсуждалось?

Компактификацию структур тоже сам, кривыми ручонками писать будешь? Отложенное инкрементальное освобождение для разлапистых структур (e.g., частей графов, где заранее не знаешь, сколько элементов оторвано - это к тому умнику, который предлагал удалять целыми страницами) - это тоже, ручонками нарисуешь, без GC? Да ты ламер, как я погляжу. Очень необразованный, но при этом очень самоуверенный ламер.

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

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

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

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

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

>RT ПО вообще как правило почему-то не пишется на с++.

Господа, которые с мозгами - сходите на www.qnx.ru и посмотрите на средства разработки под QNX например, далее сходите на www.qnx.org.ru -посмотрите форумы или задайте вопрос на форуме, посмотрите com.realtime, а потом уже и делайте выводы.

>что может я ламер, видел RT ПО на pure Си, видел даже на жаве, но на с++ - никогда.

протри глаза ламер.

P.S.

"жава" это что?

anonymous
()
Ответ на: комментарий от 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
()
Ответ на: комментарий от mutronix

> klalafuda, прокоментируйте пожалуйста ссылку, может я чего не так понял?

как средство разработки C++ конечно же есть. и gcc и intel и ошметки watcom. но сам QNX и Photon написаны на C. что в прочем ничего не говорит ни за ни против использования C++ в подобных проектах.

// wbr

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

> как средство разработки C++ конечно же есть. и gcc и intel и ошметки watcom. но сам QNX и Photon написаны на C.

Ясно, буду знать.

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

Забавно смотреть, как люди, в жизни не написавшие ни одного куска кода ни для операционной системы, ни драйвера, ни RT приложения раз от разу убеждают в том, что RT приложения нужно писать на С++ :) Да, еще они почему-то жутко любят QNX и считают, что он тоже написан на С++.

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

Если вы это о мне, то я никого не убеждал никого в том, что RT-приложения следует писать на С++. Про QNX я просто спросил. Ну а почему присутствующие тут люди не писали на С++ компоненты ОС(я так понял, вы подразумеваете ядро), думаю и так ясно. Нет открытых ядер на С++ и соответственно модули к ядрам тоже пишут на С. Был же патч для ядра позволяющий использовать исключения стандарта С++, так распространения он не получил.

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

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

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

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

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