|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
11.09.2016, 17:29 | #71 | |
Спокойный псих
Участник клуба
Регистрация: 19.03.2013
Сообщений: 1,538
|
Цитата:
Я так часто делаю перед тем, как парсить HTML в своих программках для собственных целей (обработки информации). Да и с размером стека никогда проблем не было. Помню, что при работе с Win32API пару лет назад нас учили как задавать размер стека до создания потока. Внутри потока размер стека изменить не получится (хотя, если потанцевать с бубном ...) upd: Так же проще работать со следующими ситуациями ... У нас есть набор текста, и мы не знаем, сколько в этом тексте чисел, но нужно создать массив из этих чисел, размер которого (массива) задаётся при его создании. Мы сначала подсчитываем количество чисел, а потом создаём массив, и вторым циклом заполняем этот массив. Но это только в том случае, если мы работаем с массивом. Можно сделать тоже самое, но без подсчёта количества, а просто в процессе появления числа создавать новый элемент в динамическом списке. В таком случае нам плевать, сколько у нас чисел. И опять же - работа со списком (и любой другой структурой) означает ограничение возможности одновременного доступа ко всем элементам структуры. Можно делать полно-связную структуру, но тогда получится ахинея, ибо каждый элемент будет хранить массив (или ещё какую структуру ?) ссылок на все остальные элементы в структуре.
Подпись ? Не, не слышал ...
Последний раз редактировалось OmegaBerkut; 11.09.2016 в 17:36. |
|
11.09.2016, 17:36 | #72 | |||||||
Старожил
Регистрация: 28.01.2009
Сообщений: 21,000
|
Цитата:
ибо там правила те же, что и при обычном разборе. Цитата:
вы серьезно? Цитата:
Цитата:
Цитата:
Цитата:
если доступ последовательный связанный список нормально себя чувствует. и если что System.Generics.List<> это массив, динамически расширяемый. Цитата:
вы видимо не до конца базовые типы понимаете. Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
Программа делает то что написал программист, а не то что он хотел. Функции/утилиты ждут в параметрах то что им надо, а не то что вы хотите. Последний раз редактировалось Пепел Феникса; 11.09.2016 в 17:40. |
|||||||
11.09.2016, 17:37 | #73 |
Старожил
Регистрация: 12.01.2011
Сообщений: 19,500
|
а я беру библиотеку для его парсинга.
Ушел с форума, https://www.programmersforum.rocks, alex.pantec@gmail.com, https://github.com/AlexP11223
ЛС отключены Аларом. |
11.09.2016, 17:41 | #74 |
Спокойный псих
Участник клуба
Регистрация: 19.03.2013
Сообщений: 1,538
|
Пепел Феникса
При первом проходе не нужна рекурсия: опираясь лишь на количество обратных слэшей ('/') можно посчитать максимально возможный уровень вложения, не вдаваясь в конструкцию этой структуры. Alex11223 Вы парсите весь документ, а я ищу определённые зависимости - это методы обработки, которые нужны лично для моих целей, о чём я уже говорил.
Подпись ? Не, не слышал ...
|
11.09.2016, 17:44 | #75 | |
Участник клуба
Регистрация: 21.10.2015
Сообщений: 1,361
|
Цитата:
Последний раз редактировалось come-on; 11.09.2016 в 17:53. |
|
11.09.2016, 17:44 | #76 | ||
Старожил
Регистрация: 28.01.2009
Сообщений: 21,000
|
Цитата:
а учитывая что вы все это начали говоря о веб-сервере, ваш сервер только что потерял 100 клиентов в час, ибо у него кончится память иначе.(стек в отличие от кучи не может фрагментироваться) итого подведя итог, всего что вы говорили. я предлагаю: 1)нет рекурсии 2)использовать List<>(std::vector C++) для хранения списка открытых тэгов. вы предлагаете 1)рекурсия 2)два прохода ради определения макс вложенности(а точнее кол-ва тэгов всего, вложенности там может не быть на практике). для обработки данных любой вложенности. 3)требуется создание нового потока для гарантии нужного размера стека. 4)из-за п1 возможно перевыделение стека. вы уже сами своими п2-п3 уже создаете нехилый велосипед, вместо того чтоб просто применить List<>Add(std::vector.push_back) это я подвел итог всех ваших предложений, дописав последствия. Цитата:
малые зависимости хорошо находятся регуляркой. а что-то сложное...когда пишете код руками на такое, вы сильно увеличиваете свое время на написание и поддержку. Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
Программа делает то что написал программист, а не то что он хотел. Функции/утилиты ждут в параметрах то что им надо, а не то что вы хотите. Последний раз редактировалось Пепел Феникса; 11.09.2016 в 17:55. |
||
11.09.2016, 17:55 | #77 |
Спокойный псих
Участник клуба
Регистрация: 19.03.2013
Сообщений: 1,538
|
Пепел Феникса
Если заходит речь об асинхронном доступе к элементам любой структуры данных (в пределах одного потока), то массив будет предпочтительней. А любая другая структура - только при хранении ссылок на необходимые элементы. И я знаю про пере-выделение памяти под стек, но я привёл это только как пример. Для более правильного выделения памяти естесно нужен другой подход. Но, как я уже говорил - это лишь вопрос выбора баланса между CPU и RAM при оптимизации .
Подпись ? Не, не слышал ...
|
11.09.2016, 17:57 | #78 | |||
Старожил
Регистрация: 28.01.2009
Сообщений: 21,000
|
Цитата:
Цитата:
Цитата:
потому что откушивая стек, вы тоже откусили рам.(и размер кстати не меньше, то есть потребление рам особо не изменяется(хотя может и вырасти, так как при рекурсии надо передавать больше данных между уровнями, чем при банальном массиве открытых) но вы написали пару костылей, я же могу применить готовые классы. где выигрыш то? я вот сча посчитал, потребление рам выше, потребление CPU выше. но там, зато мы может не думать Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
Программа делает то что написал программист, а не то что он хотел. Функции/утилиты ждут в параметрах то что им надо, а не то что вы хотите. Последний раз редактировалось Пепел Феникса; 11.09.2016 в 18:00. |
|||
11.09.2016, 18:00 | #79 |
Спокойный псих
Участник клуба
Регистрация: 19.03.2013
Сообщений: 1,538
|
Тут я ошибся в выражении - случайного доступа. Вы писали об этом.
Но тем не менее даже при асинхронном доступе (из разных потоков) будет проще залезть в массив, нежели искать элемент в списке. И опять же вопрос баланса при оптимизации: хранить число (для массива), или данные (для списка). И опять же - при рекурсии мы не строим хранилище, оно будет построено рекурсией.
Подпись ? Не, не слышал ...
|
11.09.2016, 18:09 | #80 | ||
Старожил
Регистрация: 28.01.2009
Сообщений: 21,000
|
Цитата:
Цитата:
о применении списка? у вас с этим проблемы? единственное преимущество рекурсии, это ее чучуть легче писать, и все. но вот при обработке большой вложенности сразу всплывает тысяча костылей ради того чтоб рекурсия продолжала жить. вы уверены что возможность не применять список/стек(многие ЯП имеют готовый класс на это кстати), того стоит? + неудастся написать генератор(енумератор по требованию) с рекурсией. только на колбэках если(причем без иного потока еще и без возможности приостановит обработку) Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
Программа делает то что написал программист, а не то что он хотел. Функции/утилиты ждут в параметрах то что им надо, а не то что вы хотите. Последний раз редактировалось Пепел Феникса; 11.09.2016 в 18:14. |
||
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Небольшое веб-приложение на ASP.NET | aly-lucenko | Фриланс | 10 | 10.01.2014 23:31 |
Веб-приложение asp.net MVC и с чем его едят | nec117 | ASP.NET | 0 | 18.04.2011 17:04 |