//...
T* t1=new T;
//...
void* ptr=t1;
//...
delete ptr; // Корректна ли эта операция?
Боюсь, не очень. delete-операция должна сперва вызвать деструктор, а при данном раскладе как она это будет делать?
Если дтор виртуальный, то можно делать делит через указатель на базовый класс. А здесь полностью потеряна информация о типе.
В таком случае память под сам обьект будет освобождена без проблем, но деструктор вызван не будет, что, естественно, плохо.
Конечно плохо.
Хочу сделать простой сборщик мусора для C++. Со сборщиком мусора должны работать "умные" указатели (реализовано в виде шаблона). Они обращаются к сборщику мусора, который увеличивает и уменьшает счетчики ссылок. По таймеру раз в несколько секунд вызывается сборщик мусора, который удаляет все объекты, у которых значение счетчика ссылок 0. Как сделать нормальное удаление?
Есть еще идея нескольких сборщиков мусора (по одному на тип) - тогда сборщик можно сделать в виде шаблона, но увеличивается расход памяти и сложность работы.
frp твои предложения? Сборка мусора, одна из функций диспетчера памяти. Я не знаю для чего ты используешь динамическое выделение памяти, поэтому и предложил auto_ptr, который удаляет объект, после выхода из поля видимости. Все зависит от того, что нужно.
Со сборщиком мусора должны работать "умные" указатели (реализовано в виде шаблона). Они обращаются к сборщику мусора, который увеличивает и уменьшает счетчики ссылок. По таймеру раз в несколько секунд вызывается сборщик мусора, который удаляет все объекты, у которых значение счетчика ссылок 0. Как сделать нормальное удаление?
А таймер-то зачем? Надо удалять сразу, как счетчик ссылок стал равен 0. Этот http://loki-lib.sourceforge.net/ материал уже изучен?
А таймер-то зачем? Надо удалять сразу, как счетчик ссылок стал равен 0
можно и по таймеру... в этом есть смысл - процедура удаления очень быстрая (ведь она ничего не удаляет!)
поможет, если вы скажем выделяете и уничтожаете в цикле много одних и тех-же объектов (вместо стека LIFO).
написать-то такое просто... но отладить, и сопровождать - без меня, пожалуйста
можно и по таймеру... в этом есть смысл - процедура удаления очень быстрая (ведь она ничего не удаляет!)
поможет, если вы скажем выделяете и уничтожаете в цикле много одних и тех-же объектов (вместо стека LIFO).
В этом случае можно и по таймеру... бр... ну такого выделения в цикле лучше избегать
TX sum = 0;
for ( i = 1; i <= 1000; i++)
{
TX a = TX::read();
sum += a;
}
что такого?
ничего.
а если TX это матрица 1000*1000?
а как работает TX::TX(TX&)?
а как TX::operator+=(TX&)?
так и получаются.. "титаники" в памяти... точнее "летучие голландцы"
Немного передумал насчёт сборки мусора. Теперь буду просто использовать умные указатели, которые будут освобождать память сразу после удаления. Всё уже реализовал. Тему можно закрывать.
Умные указатели не достаточно умные, чтобы побороть циклические ссылки.
У меня как-то возникло подозрение, что в Mono и .NET это никак не решено и объекты остаются в памяти до завершения выполнения программы. В C++ и других языках для этого есть тупые указатели (а так же умные, проверяющие, что память не освобождена).
Умные указатели не достаточно умные, чтобы побороть циклические ссылки.
У меня как-то возникло подозрение, что в Mono и .NET это никак не решено и объекты остаются в памяти до завершения выполнения программы. В C++ и других языках для этого есть тупые указатели (а так же умные, проверяющие, что память не освобождена).
В языках с "автоматическим" управлением памятью либо используются алгоритмы поиска циклических ссылок в машине сборки мусора (ява?) или могут дополнительно предоставляться "weak ptrs", в порядке исключения предоставляющие возможность ссылаться на объект не увеличивая его refcounter (предполагается, что забота программиста следить, чтоб порядок удаления объектов был правильным или беспокоиться, что ссылка может остаться зависшей) ((какой-то из) смоллтоков, библиотеки для С++).
В системах с отложенной сборкой мусора (ява и, полагаю, .Нет...) никто вам не гарантирует удаления объектов _сразу же_, поэтому они и правда могут оставаться в памяти до завершения выполнения программы - и даже не зависимо от того, циклические ссылки или нет - пока программе хватает памяти для размещения новых объектов.
возникло подозрение, что в Mono и .NET это никак не решено и объекты остаются в памяти до завершения выполнения программы.
Решено. Не знаю точно, какой метод использовали в .NET и Mono, но можно посмотреть, в частности «mark and sweep» (есть и другие методы: отправная точка).