веб, ASP, начало

[OmegaBerkut]

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

а куда денется то текущий элемент из стека процесса?(я имею в виду во всей линии рекурсивности)

Посчитать уровень вложения можно до начала обработки - именно здесь начинается увеличение нагрузки на CPU, но не на RAM; зато в дальнейшем нам не нужно, как я уже сказал, делать велосипед, за нас его сделает стек потока.
Я так часто делаю перед тем, как парсить HTML в своих программках для собственных целей (обработки информации). Да и с размером стека никогда проблем не было. Помню, что при работе с Win32API пару лет назад нас учили как задавать размер стека до создания потока. Внутри потока размер стека изменить не получится (хотя, если потанцевать с бубном ...)

upd:
Так же проще работать со следующими ситуациями ... У нас есть набор текста, и мы не знаем, сколько в этом тексте чисел, но нужно создать массив из этих чисел, размер которого (массива) задаётся при его создании. Мы сначала подсчитываем количество чисел, а потом создаём массив, и вторым циклом заполняем этот массив. Но это только в том случае, если мы работаем с массивом. Можно сделать тоже самое, но без подсчёта количества, а просто в процессе появления числа создавать новый элемент в динамическом списке. В таком случае нам плевать, сколько у нас чисел. И опять же - работа со списком (и любой другой структурой) означает ограничение возможности одновременного доступа ко всем элементам структуры. Можно делать полно-связную структуру, но тогда получится ахинея, ибо каждый элемент будет хранить массив (или ещё какую структуру ?) ссылок на все остальные элементы в структуре.

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

Посчитать уровень вложения можно до начала обработки

так же рекурсивно?
ибо там правила те же, что и при обычном разборе.

зато в дальнейшем нам не нужно, как я уже сказал, делать велосипед, за нас его сделает стек потока.

ручное увеличение стека, двойной проход, вы это называете не велосипед?
вы серьезно?

Я так часто делаю перед тем, как парсить HTML в своих программках для собственных целей (обработки информации). Да и с размером стека никогда проблем не было.

HTML не имеет глубокой вложенности обычно.

Помню, что при работе с Win32API пару лет назад нас учили как задавать размер стека до создания потока.

банальный параметр в CreateThread, изменить потом нельзя, не поломав всю систему защиты(вы не можете сделать Guard Page).

Так же проще работать со следующими ситуациями ... У нас есть набор текста, и мы не знаем, сколько в этом тексте чисел, но нужно создать массив из этих чисел, размер которого (массива) задаётся при его создании. Мы сначала подсчитываем количество чисел, а потом создаём массив, и вторым циклом заполняем этот массив.

итого двойной проход.

И опять же - работа со списком (и любой другой структурой) означает ограничение возможности одновременного доступа ко всем элементам структуры.

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

и если что System.Generics.List<> это массив, динамически расширяемый.

Можно делать полно-связную структуру, но тогда получится ахинея, ибо каждый элемент будет хранить массив (или ещё какую структуру ?) ссылок на все остальные элементы в структуре.

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

[Alex11223]

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

Я так часто делаю перед тем, как парсить HTML в своих программках

а я беру библиотеку для его парсинга.

[OmegaBerkut]

Пепел Феникса
При первом проходе не нужна рекурсия: опираясь лишь на количество обратных слэшей ('/') можно посчитать максимально возможный уровень вложения, не вдаваясь в конструкцию этой структуры.
Alex11223
Вы парсите весь документ, а я ищу определённые зависимости - это методы обработки, которые нужны лично для моих целей, о чём я уже говорил.

[come-on]

При первом проходе не нужна рекурсия: опираясь лишь на количество обратных слэшей ('/') можно посчитать максимально возможный уровень вложения

это все можно и без рекурсии делать )

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

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

Пепел Феникса
При первом проходе не нужна рекурсия: опираясь лишь на количество обратных слэшей ('/') можно посчитать максимально возможный уровень вложения, не вдаваясь в конструкцию этой структуры.

вы путаете количество тэгов с вложенностью, то есть в вашем случае еще и не оптимальное выделение стека.(перевыделение)

а учитывая что вы все это начали говоря о веб-сервере, ваш сервер только что потерял 100 клиентов в час, ибо у него кончится память иначе.(стек в отличие от кучи не может фрагментироваться)

итого подведя итог, всего что вы говорили.
я предлагаю:
1)нет рекурсии
2)использовать List<>(std::vector C++) для хранения списка открытых тэгов.
вы предлагаете
1)рекурсия
2)два прохода ради определения макс вложенности(а точнее кол-ва тэгов всего, вложенности там может не быть на практике). для обработки данных любой вложенности.
3)требуется создание нового потока для гарантии нужного размера стека.
4)из-за п1 возможно перевыделение стека.

вы уже сами своими п2-п3 уже создаете нехилый велосипед, вместо того чтоб просто применить List<>Add(std::vector.push_back)


это я подвел итог всех ваших предложений, дописав последствия.

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

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

[OmegaBerkut]

Пепел Феникса
Если заходит речь об асинхронном доступе к элементам любой структуры данных (в пределах одного потока), то массив будет предпочтительней. А любая другая структура - только при хранении ссылок на необходимые элементы.
И я знаю про пере-выделение памяти под стек, но я привёл это только как пример. Для более правильного выделения памяти естесно нужен другой подход. Но, как я уже говорил - это лишь вопрос выбора баланса между CPU и RAM при оптимизации .

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

Если заходит речь об асинхронном доступе к элементам любой структуры данных (в пределах одного потока)

так асинхронный или в пределах одного потока таки? О_о

Для более правильного выделения памяти естесно нужен другой подход.

ну я и спрашиваю, как вы собираетесь честно определить уровень вложенности без рекурсии?

Но, как я уже говорил - это лишь вопрос выбора баланса между CPU и RAM при оптимизации .

почитайте ниже итог, тут не стоит выбор CPU и RAM, не стоит.
потому что откушивая стек, вы тоже откусили рам.(и размер кстати не меньше, то есть потребление рам особо не изменяется(хотя может и вырасти, так как при рекурсии надо передавать больше данных между уровнями, чем при банальном массиве открытых)

но вы написали пару костылей, я же могу применить готовые классы.

где выигрыш то?

я вот сча посчитал, потребление рам выше, потребление CPU выше.
но там, зато мы может не думать

[OmegaBerkut]

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

так асинхронный или в пределах одного потока таки? О_о

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

И опять же - при рекурсии мы не строим хранилище, оно будет построено рекурсией.

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

И опять же вопрос баланса при оптимизации: хранить число (для массива), или данные (для списка).

массив хранит те же данные что и список, иначе нас какая-то хрень.

И опять же - при рекурсии мы не строим хранилище, оно будет построено рекурсией.

вы о чем?
о применении списка?
у вас с этим проблемы?


единственное преимущество рекурсии, это ее чучуть легче писать, и все.
но вот при обработке большой вложенности сразу всплывает тысяча костылей ради того чтоб рекурсия продолжала жить.
вы уверены что возможность не применять список/стек(многие ЯП имеют готовый класс на это кстати), того стоит?

+ неудастся написать генератор(енумератор по требованию) с рекурсией. только на колбэках если(причем без иного потока еще и без возможности приостановит обработку)