Заинтересовалось несколько человек. Спасибо! Брошу пример и библиотеку чуть позже. Просто добавил еще пару возможностей. В частности — возможность создания динамической группы на основе уже созданной другой. Что-то типа виртуального LIKE. Так что, как протестирую — сразу брошу.
Хотя, вот с примером — проблема в том, какой сделать пример? Моя тестовая программка для этого не годится — слишком много в ней лишней служебной информации. Так что — принимаются любые предложения.
Или слать простой пример основных методов использования? А уже каждый себе, на его основе, сделает что ему надо.
Кстати!
Знаете-ли вы, что для локальных переменных процедуры, размером более 256 байт, место выделяется не на стеке данной процедуры, а в глобальной памяти системы? При этом учитывается размер именно конкретной переменной, а не общий размер всех локальных переменных процедуры. Для массивов считается общий размер всех элементов массива.
Отсюда — два вывода.
Для рекурсивных процедур, если размер некоторых локальных переменных сопоставим с 256 байт, имеет смысл умышленно делать такие переменные больше 256 байт. Тем более не бойтесь описывать переменные большой длины (если в этом есть необходимость). Это позволит при одном и том же размере стека, выделенного для потока, достичь большей глубины рекурсивности без боязни напороться на ошибку переполнения стека! Т.е., например, вместо нескольких строк размером <= 256 байт, лучше завести хоть с десяток, но размером больше 256 байт.
Второй вывод несколько настораживающий. В операционных системах, типа W9x, которые плохо контролируют память, используемую задачами, вполне возможна потеря памяти при аварийном сбросе задачи. Особенно актуально для рекурсивных процессов, которые могут «свалить» приложение на большой глубине рекурсии. Конечно — если в этих процедурах есть переменные размером больше 256 байт.
Кстати-2.
Не рекомендую использовать большую вложенность рутинок. Не рекурсивность (с этим все в порядке), а именно последовательный вызов разных рутинок друг из друга. Дело в том, что при использовании рутинок, компилятор генерит очень хитрый код для возможности вывалиться из процедуры по оператору Return из любой рутинки. Так вот, при таком подходе, большая вложенность различных рутинок может привести к потере адреса возврата! По крайней мере, у меня так было пару раз. Так что, будьте проще:)
Кстати-3.
Правильно пишут в Help, что доступ к неявным переменным в рутинках менее эфективен по скорости чем доступ к переменным, объявленных, например, прямо в самой рутинке. Только не пишут, почему! А все дело в том, что место под такие неявные переменные выделяется не на стеке рутинки а в глобальной памяти. Независимо от их размера. А еще нужно учесть накладные расходы менеджера памяти на каждое такое выделение. Таким образом, с десяток неявных переменных типа Long (4байта), в конечном итоге обойдутся не в 40 байт, а значительно больше. Опять же — возможная потеря памяти при аварийном завершении программы!