Сборка мусора gcc

есть boehm gc, но это кривое говно

У gcc нет и не может быть сборки мусора для C, поелику он компилятор, который в силу своих способностей пытается соответствовать стандартам, а не среда исполнения. Не в ansi c, не в posix c мусорщик не фигурирует. Однако существует libgc, предоставляющая альтернативные функции выделения памяти в куче. Разрешите полюбопытствовать, не троллинга ради, а для каких целей вы хотите использовать C с мусорщиком?

>Есть ли у gcc сборка мусора для чистого C?

Уверен, что ничего путного ты не найдешь, так что смело можешь плакать. А потом ты либо бросишь эту затею, либо будешь лепить какую-нибудь фигню в стиле: http://www.rsdn.ru/article/cpp/GCcpp.xml

У gcc нет и не может быть сборки мусора для C, поелику он компилятор, который в силу своих способностей пытается соответствовать стандартам, а не среда исполнения. Не в ansi c, не в posix c мусорщик не фигурирует. Однако существует libgc, предоставляющая альтернативные функции выделения памяти в куче. Разрешите полюбопытствовать, не троллинга ради, а для каких целей вы хотите использовать C с мусорщиком?

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

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

> сборка мусора для чистого C
Что только люди не делают, лишь бы не учить новые ЯП. -_-

> Активно использую calloc и malloc, с большим объёмом данных возможны слишком мелкие и частые выделения и освобождения памяти. Боюсь фрагментации памяти и повисания указателей.

http://en.wikipedia.org/wiki/Memory_pool

> Что только люди не делают, лишь бы не учить новые ЯП. -_-

если человек пишет на С и хочет, чтоб все работало еще быстрее, - «новые ЯП» со всякими GC ему явно не нужны

>«новые ЯП»

новые

Гыгыгы.

> Гыгыгы.

а вот нарко^W лисперы пришли; ты уже закончил писать свою обертку к DirectX?, или из-за обсырания других языков времени не хватает на этот мега-кул проект на мега-кул лиспе? ;)

Я всегда надеюсь на то, что человек может уметь FFI, линковку и прочее.
PS: Преждевременная оптимизация — корень всех (или большинства) проблем в программировании. (Дональд Кнут же!)

> PS: Преждевременная оптимизация — корень всех (или большинства) проблем в программировании. (Дональд Кнут же!)

преждевременная - да, но когда уже все работает и тесты написаны - тот же memory pool может дать весомый прирост в производительности

Боюсь фрагментации памяти

GC для С эту проблему при всём желании не решит.

Именно. Поколений и компактификации для си быть не может никак.

Есть ли у gcc сборка мусора для чистого C?

Нет

Каким образом задействовать и что почитать?

убирай сам за собой.

ALLOCA(3) Linux Programmer’s Manual ALLOCA(3)

NAME
alloca - allocate memory that is automatically freed

SYNOPSIS
#include <alloca.h>

void *alloca(size_t size);

DESCRIPTION
The alloca() function allocates size bytes of space in the stack frame of the caller.
This temporary space is automatically freed when the function that called alloca()
returns to its caller.

RETURN VALUE
The alloca() function returns a pointer to the beginning of the allocated space. If
the allocation causes stack overflow, program behavior is undefined.

CONFORMING TO
This function is not in POSIX.1-2001.

нууу valgrind в помощь.

что с ним не так?

> ALLOCA(3) Linux Programmer’s Manual ALLOCA(3)

«узкость» в области применения и не решает проблем с производительностью при частом выделении/освобождении памяти

у автора как я понял большие выделения памяти.

> у автора как я понял большие выделения

весна...

> «узкость» в области применения и не решает проблем с производительностью при частом выделении/освобождении памяти

Чиво? Что может быть быстрее арифметической операции с указателем стека?

> Чиво? Что может быть быстрее арифметической операции с указателем стека?

таво, по условию у нас «слишком мелкие и частые выделения и освобождения памяти», можешь сравнить работу с пулом и alloc в таком режиме

если пишешь на Ц, то почему-бы не использовать АПР? Там все есть, включая мемори-пулы.

у меня связка Ц(АПР) + ЕКЛ. Все прекрасно скриптуется.

Glib slices

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

Мой тебе совет, либо перестань думать что ты умнее выбранного компилятора и среды, либо не пиши на высокоуровневых языках. Если мне память не изменяет malloc из glibc выделяет память очень хитро и даже как-то борется с фрагментацией. А вот будет ли оное делать левый malloc, левого libgc я не знаю. Если боишься что память течь будет, valgrind тебе в руки.

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

Вот мне и интересно какого плана задачи требуют использования C. Известные мне (микроконтроллеры, ядра и драйвера, интерпретаторы) не очень дружат с накладными расходами на сборку мусора.