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

Это не ошибка.

Я предлагаю тебе понять одну простую вещь - передо мной стоит конкретная задача - я решаю конкретную задачу.

Зачем тогда в софте пишут "version 1.0", "version 1.4" и т.п.?? Перед тобой стоят конкретные задачи и ты их решаешь. Если со временем появляются новые задачи, появляются новые версии решения задачи, патчи и т.п.

Иначе бы мы всегда имели лишь одну версию любого софтверного инструмента 

Вы о чем ?  это одна и та же версия - называется Atom 1.0



Я соглашаюсь понять эту вещь =) Не стоит наезжать, я грамотный человек и опыта тоже хватает.

Пару месяцев назад мы тоже решили решить конкретную задачу по обработке XML с помощью regex и других текстовых манипуляций - и вот начали появляться первые проблемы, т.к.  XML стал меняться (не формат, а содержимое).
Нам приходится заниматься поддержкой такого решения, поэтому планируем в ближайшее время перейти на DOM.


Я предлагаю остаться при своих мнениях. 

Я сейчас говорю не конкретных вещях. А в целом.


Ну, не я начал разбрасыватся такими фразами как "Ошибка". 


Я почти два года занимался тем, что писал на перле программы, которые занимались парсингом тех или иных файлов. И тоже сталкивался с проблемами, а порой приходилось какие-то пункты(не подпункты), вообще переделывать по-другому нежели в ТЗ. Это вполне естественное явление в программировании. И стоит ли по этому поводу говорить, что это ошибка ?? 

Да, вы правы, я как всегда некорректен =) больше не буду.

вообщем вся моя идея заключалась в том, что regex не для всего подходит. для многоно , но для XML - плохо.

Если вы утверждаете, что разбор XML с помощью regex правильнее и лучше, чем с помощью DOM, SAX и Xpath, 
то я могу попросить только не убеждать в этом других.



Это сообщение отредактировал(а) sir_nuf_nuf - 25.6.2008, 18:32

sir_nuf_nuf
regex универсальный, а вместе с встроенным функциями index, sunbstr можно получить очень приличную скорость, гибкость, экономию ресурсов и легкость. 

А вложенность тега entry легво можно обойти. Для этого перед началом работы основной процедуры. Нужно пройтись по xml документу и всем вложенным entry присвоить уровень вложенности. entry->entry1 и т.д. Благодаря тому что xml строже htm,l то тут можно вовсю использовать index и substr, а это самые быстрые функции для работы с текстом. 

К вам такая же просьба не убеждать других что парсить htm и xml и т.д рег. выражениями есть зло

не убедят  Знающий человек не убедится.

sir_nuf_nuf, началось после, того как вы утверждали кое-что  При прочнении заного топика - всё станет на свои места  (было утверждение, что regexp чаще плохо, чем хорошо)

;)

sir_nuf_nuf
С вашей задачей справились. А вот вы можете справиться вот с такой задачей используя парсер html.
Нужно получить все курсы валют от сюда savechange.ru. И вывести их в такой таблице
Валюта_IN,число,Валюта_OUT,число,RESERVE_Валюта_OUT,число

tolkien, он всё же про xml и подобия говорил... html сами знаете какой 

Ну вот опять... Речь не о том, какой формат файлов парсить, а какая у нас задача.

Если тебе нужно будет написать один(!) парсер, работающий как и с XML, так и с HTML, а может и еще с каким-нить интересным форматом файла?? Подчеркиваю один общий парсер??