Про память (незнаю как еще назвать)...

← →
ms (2005-01-05 07:43) [0]

Моя программа на VC++.NET предназначена для поиска файлов. И эта не конечная ее цель. Она может искать включая подкаталоги, по аттрибутам, дате создания/изменения/доступа, по размеру и тд.. и тп.. Но вот представьте себе: я начинаю сканировать диск C:\ полностью включая подкаталоги и программа мне находит 41 481 файлов. Информацию об каждом файле она хранит в классе CArray (такое я хранилище выбрал, хотя можно было и вопользоваться stl но так как я пишу mfc приложение...). Каждый файл представлен вот такой структурой:
struct f_item
{
f_item (LPCTSTR szFilePath = _TEXT("\0"), const LPWIN32_FIND_DATA lpWFD = NULL);

LPWIN32_FIND_DATA lpWFD;
LPTSTR szFilePath;

~f_item();
};
И вот, после того как она найдет она весит - 50 000 КБ если работает под юникодом, а в ANSI кодировке 37 000 КБ что также очень много. Такой же тест я провожу в виндосовском поисковике, но она как я вычислил занимает меньше - около 27 000 КБ.
Как мне быть? Может стоит использовать виртуальную память?

← →
uny © (2005-01-05 07:46) [1]

а имя каждого файла вместе с его путём хранится?

← →
ms (2005-01-05 08:04) [2]

uny © (05.01.05 07:46) [1]

Ну да. Он мне нужен будет потом для того чтобы переименовывать этот файл

← →
uny © (2005-01-05 08:24) [3]

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

← →
ms (2005-01-05 08:37) [4]

uny © (05.01.05 08:24) [3]

Отличная идея! Ох тупая моя бошка, немогла догадаться даже до такого! ;) Спасибо

← →
uny © (2005-01-05 08:45) [5]

ms
можно ещё больше) - даже имена каталогов хранить в этом виде. т.е. не полностью пути, а только ссылки
c:\
d:\
temp
windows

нужный путь 1 = [0]+[1]
нужный путь 2 = [1]+[3]

хеширование такое

← →
ms (2005-01-06 07:41) [6]

uny © (05.01.05 08:45) [5]

Неплохо, сделал все по вашей схеме. Теперь сканирование всего диска C:\ в котором уже 43 000 файлов занимает 16 700 КБ. А может можно сделать еще меньше?

ms
навскидку - посмотреть как именно у Вас всё хранится.
если текстовые поля, то можно ограничить длину - стринг не обычный, а только, скажем 30 символов - ну или каждое поле делать динамической длины и выделяь памяти сколько нужно только. если имя файла 3 символа - выделять только 3 или сколько там нужно

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

← →
ms (2005-01-06 09:19) [8]

uny © (06.01.05 08:40) [7]

У меня все динамически. Выделяю поле например char* pszFileName = new TCHAR [ 20 ];
Вот теперь немного другая проблема возникает. У меня структура f_item теперь имеет такой вид:
struct f_item
{
f_item (LPCTSTR pszFileName = _T("\0"), f_item* parent = NULL);
LPTSTR pszFileName;
f_item* parent;
LPTSTR ExtractFileName () const;
~f_item();
};

Например файл C:\Windows\sample.txt . sample.txt - f_item, его parent (родитель) "Windows", а тот в свою очередь имеет предка "C:"
Ссылки на конечные файлы (например на структуру с pszFileName = "sample.txt") у меня хранятся в массиве. Как мне тогда корректно выгружать объекты f_item если например parent"ы файла "sample.txt" и "samefile.bat" имеют имеют одну ссылку на f_item с pszFileName = "Windows"? Пока я выгружаю вот так, но рано или поздно оператор delete натыкается на освобожденный указатель и возникает ошибка.
f_item::~f_item()
{
delete [] pszFileName;
delete parent;
}
Вобщем если вы меня поняли и у вас есть идея, буду рад.

ms
можно добавить функциональности - Вы же подсчитываете общее количество найденных файлов? - почему бы не подсчитывать количество объектов в каждом каталоге/диске? т.е. создать массив размером такой же как и массив всех путей, и для каждого "parent"а" указать количество объектов - дисков, каталогов или файлов, которые в нём содержатся. если происходит удаление, то минусовать, а освобождать указатель только если внутри более ничего не содержится.
памяти больше займёт, но зато не будет ошибок и можно кнопку добавить = "удалить все пустые каталоги".
ещё можно в процессе поиска подсчитывать размеры всех каталогов, и если удаляется файл изнутри - тоже минусовать.

Про память (незнаю как еще назвать)... Найти похожие ветки