Есть функция, хочется узнать мнение со стороны

[OmegaBerkut]

Если следующую функцию вызвать с параметрами например "C:\", 0 - стек не рванёт ?

private void ScanDir(string intputpath, int level)
{
	string[] inner_paths;
	try
	{
		inner_paths=Directory.GetDirectories(intputpath);
	}
	catch { return; }
	string tabs="";
	int i=0;
	for (;i<level;i++)
		tabs+="\t";
	for (i=0;i<inner_paths.Length;i++)
	{
		info+=tabs+"<DIR> "+inner_paths[i]+"\r\n";
		ScanDir(inner_paths[i],level+1);
		inner_paths[i]=null;
	}
	inner_paths=null;
	try
	{
		inner_paths=Directory.GetFiles(intputpath);
	} catch { return; }
	for (i=0;i<inner_paths.Length;i++)
	{
		info+=tabs+inner_paths[i]+"\r\n";
			inner_paths[i]=null;
	}
}

Переменная string info - глобальная, до вызова функции опустошается руками.
Функцию планируется вызывать в потоке под try, и всё что отсканил - всё моё.

upd: перепилил так, что бы по минимуму использовать локальную область видимости: только индексатор и текущая папка; массив же спихнул в глобалку ... P. S. Ещё не проверял ...

[Пепел Феникса]

вы переделайте на хвостовую рекурсию, тогда никогда не рванет.
а по факту очень маловероятно, только если стек итак почти исчерпан.

[Alex11223]

Сообщение от Пепел Феникса

переделайте на хвостовую рекурсию

А она ж не гарантирована в C#.

Сообщение от OmegaBerkut

Переменная string info - глобальная, до вызова функции опустошается руками.

Зачем заниматься всякой фигней из-за придуманной проблемы?

Особенно совсем бессмысленными "оптимизациями" типа i и присваиваний null.

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

Для табов цикл кстати вообще не нужен:

new string('\t', level)

И для строки с путями

String.Join("\r\n", paths.Select(s => tabs + s))

И не используйте имена переменных с _, так не принято в C#.

[Пепел Феникса]

Сообщение от Alex11223

А она ж не гарантирована в C#

я имел в виду и развернуть естественно.

[OmegaBerkut]

Сообщение от Alex11223

Зачем заниматься всякой фигней из-за придуманной проблемы?

Зачем критиковать без повода ? Что конкретно вам сделали мои "велосипеды" ?
Переменные без нижнего подчёркивания ? А как же тогда быть с осмысленным названием для тех переменных, у которых два и более слов ? Пусть даже и с сокращением ... Писать через большую букву ? Согласен. Но мне не удобно.
И почему НЕ ПРИНЯТО ? За это убивают ? Программа начинает работать хуже ?

P. S. Мне когда переменную нужно передать в класс для хранения, я не парюсь с названием переменной внутри класса, и параметром в конструкторе/функции ... В функции имя параметра обычное "blablabla", а внутри класса - "_blablabla".
Что значит вообще не принято ? Откуда категория и категоричность ?

[Alex11223]

Сообщение от OmegaBerkut

Зачем критиковать без повода ? Что конкретно вам сделали мои "велосипеды" ?

Превратили нормальную функцию которая могла бы просто вернуть значение в непонятно что

Сообщение от OmegaBerkut

А как же тогда быть с осмысленным названием для тех переменных, у которых два и более слов ?

В C# принято использовать camelCase (для классов, свойств и методов — CamelCase).

Сообщение от OmegaBerkut

И почему НЕ ПРИНЯТО ? За это убивают ? Программа начинает работать хуже ?

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

[OmegaBerkut]

Сообщение от Alex11223

Превратили нормальную функцию которая могла бы просто вернуть значение в непонятно что

Это превращение для оптимизации использования памяти, что в моём случае имеет значение. Об оптимизации чуть дальше.

Сообщение от Alex11223

В C# принято использовать camelCase (для классов, свойств и методов — CamelCase).

Про "негласные" правила наименования переменных и свойств я знаю.

Сообщение от Alex11223

Людям читать менее удобно Исходный код же в первую очередь для людей

Код я пишу исключительно для себя; деньги мне за этот код никто не платит. Если я зарабатываю на своём кодинге - я стараюсь придерживаться всех гласных и "негласных" правил.
Если код чисто для себя, и/или за бесплатно, то в таком случае посторонние люди, которые сами залезли в мой код - это "их проблема", что "им неудобно читать".
Любой форум можно считать исключением - сюда я выкладываю лишь выдержку из кода, и здесь простите всего одно название переменной, которое не понравилось только вам ... Впредь буду стараться для вас писать код "по правилам".

Теперь об оптимизации ...
1. Я кода пришёл в шарп из C++ - то обнаружил, что мне не обязательно следить за использованием памяти; отсюда есть одна проблема: я могу "забыть", отвыкнуть от того, что нужно следить за использованием памяти; ибо если мне придётся вернуться обратно в C++, или перейти на какой нибудь Java - то я столкнусь с Leak Memmory. Именно поэтому я стараюсь придерживаться собственного принципа, который гласит - "если выполняешь выделение памяти - будь так добр сделать всё доступное, что бы освободить те переменные, которые используешь".
2. Ручное зануление ссылочных типов данных таки влияет на использование памяти. Можете сами посмотреть на поведение памяти процесса во время выполнения даже этого кода ... Если я зануляю все ссылки внутри массивов, и зануляю все массивы, и зануляю все ссылки - сборщик мусора освобождает память быстрее. И наоборот.
Раньше грешил использованием GC.Collect(), но когда настала пора обработки больших объёмов данных - я обнаружил, что цикл с этим коллектом работает примерно в 15 раз медленнее, поэтому сейчас я только зануляю ссылки. Зануление же ссылок на скорость влияет очень слабо, так как ссылки внутри массива я зануляю в том месте, где точно знаю, что это мне больше не понадобится; например - в конце тела цикла.

[pu4koff]

Ничего, что из-за string info там куча хлама на каждый чих создаётся в памяти? Для таких компоновок строк так-то придуман StringBuilder.

[Alex11223]

Сообщение от OmegaBerkut

Я кода пришёл в шарп из C++ - то обнаружил, что мне не обязательно следить за использованием памяти

В С++ (а не чистом С) тоже есть smart pointer'ы, RAII и т.п.

Сообщение от OmegaBerkut

Это превращение для оптимизации использования памяти, что в моём случае имеет значение.

Почему вы так решили? Вы замеряли оба варианта (и не забыли про классические ошибки начинающих замеряльщиков типа не Release сборки)?

Без оптимизации программа хуже работает? Если нет, то только зря усложнили код добавив глобальную переменную Теперь при чтении и изменении кода всегда придется помнить о ней, не забывать вызывать функцию до ее чтения, а потом захочется еще где-нибудь поменять ее значение и все станет еще сложнее, а потом по привычке появятся еще такие же переменные.
Ну и сложнее выполнять код параллельно, писать тесты и т.п.

[OmegaBerkut]

Сообщение от pu4koff

Ничего, что из-за string info там куча хлама на каждый чих создаётся в памяти?

string info как раз и предназначен для того, что бы напихивать туда этот хлам. У меня параллельный поток раз в минуту сбрасывает данные в файл и опустошает переменную. Естесна потоки синхронизированы, вручную.

Сообщение от Alex11223

Вы замеряли оба варианта

Я уже писал об этом в том же сообщении ...

Сообщение от OmegaBerkut

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

Сообщение от Alex11223

Без оптимизации программа хуже работает? Если нет, то только зря усложнили код

Вот этого я сейчас вообще не понял ...
Если БЕЗ оптимизации программа работает ХУЖЕ - то это нормально. ПОСЛЕ оптимизации программа работает лучше.

Сообщение от Alex11223

зря усложнили код добавив глобальную переменную

Для оптимизации я добавил в глобалку следующую инфу:
1) массив текущих папок;
2) текущий уровень вложения;
3) текущую папку для глобалки;
4) строка табуляции;
5) свойства для п. 2 и 3.

2 для того, что бы в его свойстве (5) менять табулятор (4) по необходимости;
3 добавлено исключительно для свойства (5), в котором подгуржаются текущие папки (1).

В результате получилась вот такая вот конструкция:

private void ScanDir()
{
	CurrentLevel++;
	string save_dir=CurrentDir;
	int i=0;
	if (current_dirs.Length>0)
		for (;i<current_dirs.Length;i++)
		{
			out_data+=current_tabs+"<DIR> "+CutPathName(current_dirs[i])+"\r\n";
			try { CurrentDir=current_dirs[i]; }
			catch
			{
				out_data+=current_tabs+"<ошибка доступа>\r\n\r\n";
				CurrentDir=save_dir;
				continue;
			}
			waiting=true; // синхронизатор этого потока
			Thread.Sleep(120); // задержка, что бы второй поток успел скинуть данные
			while (saving) // ожидание флага из потока записи
				Thread.Sleep(100);
			waiting=false;
			ScanDir();
			CurrentDir=save_dir;
		}
	else
		out_data+=current_tabs+"<папки отсутствуют>\r\n";
	save_dir=null;
	string[] inner_files;
	try { inner_files=Directory.GetFiles(save_dir); }
	catch { out_data+=current_tabs+"<ошибка доступа>\r\n\r\n"; return; }
	if (inner_files.Length>0)
		for (i=0;i<inner_files.Length;i++)
		{
			out_data+=current_tabs+CutPathName(inner_files[i])+"\r\n";
			inner_files[i]=null;
		}
	else
		out_data+=current_tabs+"<файлы отсутствуют>\r\n";
	inner_files=null;
	CurrentLevel--;
}

И всё работает. С минимальными затратами памяти, что в данном случае, как я уже говорил - важно.
Собстна массив inner_files используется только после рекурсивной обработки всех предыдущих каталогов, и на память никак не влияет.
Функция CutPathName(string) - это тоже собственный велосипед, но создано не из-за интереса, а из-за того, что я не нашёл вырезатор имени папки для собственно папки (Path.GetDirectoryName(string) не работает для каталога); для файла же оригинал - Path.GetFileName(string).
В памяти самой функции нужно хранить только индексатор для цикла обработки папок (переносить в глобалку чревато), и собственно текущая папка уровня.

Теперь у меня встал вопрос, как построить ThreeView по имеющемуся файлу ... Первое что приходит в голову - погружать по событию разворачивания уровня, в зависимости от уровня, бла-бла-бла ... Это ещё нужно сидеть мудрить ... Но у меня полный обход диска D:\ - 10,5 мегабайт текста в юникоде; поэтому всё упирается в необходимость эмпирических наблюдений.