Опасаясь ошибок записи в память (из-за прямого доступа), решил создавать заполненные нулями кучи. Далее создается объект- менеджер кучи, который при обращении к нему выдает последовательно куски памяти для объектов с данными. Эти объекты с данными собственными средствами будут анализировать неизменность своих данных ( http://www.sql.ru/forum/actualthread.aspx?tid=993712&pg=-1).

По мере уничтожения кучи ее менеджер анализирует пустое пространство на сохранение заполненности нулями. Таким образом удастся полностью избежать ошибок работы с памятью.

Какие подводные камни не учел юный подован?

maytonА что объект (class/struct) не может отображаться в нули?

Можно, конечно, выдумывать редкие случаи. Можно придумать, что в кучи были взаимокомпенсирующие записи по недоступному месту. Но мне подобное кажется маловероятным. Условно говоря я не смогу отловить 1 ошибку из миллиона возможных. Приемлемая цена.

maytonНу я вот люблю инициализировать нулями вектора и матрицы.




Вполне себе приличный объект. И что? Он будет кандидат на чистку для твоего менеджера?

Никаких чисток менеджер производить не будет. Вот его задачи:
1. Первоначальное заполнение кучи нулями
2. Выдача кусков памяти под объекты во время работы
3. Проверка незаполненного пространства на "нулевость" перед удалением кучи.

Basil A. SidorovGermanV3. Проверка незаполненного пространства на "нулевость" перед удалением кучи.Задайтесь одним простым вопросом:
Что должен делать ваш кульный диспетчер, обнаружив (не)обнулённые байты в удаляемом куске?

P.S. Вопрос о производительности не задаётся из простого сострадания.

Он должен мне просигнализировать об ошибке. И если такое будет, то я оберну все операции записи проверкой из этого менеджера (которая легко будет отключаться с помощью define).

А что с производительностью?
1. При выделении памяти из кучи с помощью менеджера будет даже ускорение (поскольку он будет возвращать только указатели на свободное место)
2. При работе с данными- так же как и было
3. При удалении кучи- если выделение памяти было адекватным, то ничтожные накладные расходы (где-то в районе половины процента).

Basil A. SidorovGermanVА что с производительностью?
...Время на запись нулей и поиск не-нулей, значит, не учитываем ...
Ну-ну.

Вы похоже никогда не выделяли память в куче. Запись нулей происходит о-о-очень быстро. Кстати, если нет менеджера кучи, то это надо делать каждому объекту отдельно, так что при менеджере получается ускорение.

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

Менеджер кучи оказался не нужным :)

Так как выделение памяти из кучи идет в объекте (я не выделяю ее просто так, а под что-то конкретное), то именно в деструкторе объекта пусть и происходит анализ "зануления" неиспользованного места.

Anatoly MoskovskyGermanVЗапись нулей происходит о-о-очень быстро.
Вы ж сами писали что std::vector медленнее массива.
Вообще-то как раз из-за записи нулей в момент resize()

Одно с другим никак не связано: зануление кучи происходит при выделении памяти из кучи с помощью API Win32 (надо указать флаг при выделении памяти из кучи), а вектор- это какая-то ерунда (даже не знаю как точно характеризовать этот некачественный код). Вообще STL держится только на том, что целый вагон теоретиков пишут книжки, в которых всю книгу советуют использовать этот STL. Не спорю, что иногда полезно и сам в некоторых местах использую, но очень мало и только в тех местах, где не критично (один/два вызова).

Edd.DragonGermanVа вектор- это какая-то ерунда (даже не знаю как точно характеризовать этот некачественный код).
Ну так свой напишите под свои задачи. Вы ж этим фактически и занимаетесь. Только двигаясь не целенаправлено, а по синусоиде (то менеджер кучи, то вдруг прозрение о назначении конструкторов/деструкторов).

А количество ошибок уменьшают грамотным покрытием тестами, анализаторами типа Valgrind, статическими анализаторами кода, которые находят в коде типичные завтыки программистов, ну и отсутствием спешки.

И какой же контейнер проверяет память на "битость"? Зачем ерунду писать?

И хватит про свои контейнеры писать.

Модератор, прошу закрыть тему, поскольку тролли от STL опять активизировались. Ответ я получил.