Библиотека yXML версия 1.1

> Думаю нижеприведенный код как пример API библиотеки вас бы устроил. Это из libxml.

А ну вообще да, то, что нужно :-D

>Ну то есть, специальные теги <?..> и <!..> пропускаются, чтобы не выдавать ошибок. Однако их обработки нет.

Кодировка хоть UTF-8 или тоже свой лисапед?

> Кодировка хоть UTF-8 или тоже свой лисапед?

свой

> свой

Как назвал?

> Как назвал?

Кодировка не поддерживается, в общем. Имена тегов/атрибутов лучше писать латиницей.

> Как назвал?

yISO-8859-1

> yISO-8859-1

:-D

> Последовательность <foo>1<bar/> > </foo> парзится полностью, хотя не должна

Вообще-то это нормальный xml. Вот и xmllint со мной согласен:
$ cat test.xml
<foo>1<bar/> > </foo>
$ xmllint test.xml
<?xml version="1.0"?>
<foo>1<bar/> &gt; </foo>

>Проверки на NULL лучше делать явно, чем if(f).

чем это лучше?

типа NULL не всегда == 0 ?

> типа NULL не всегда == 0 ?

Для C++ лучше if(f), для желательно if(f != NULL)

>Ну кому-нибудь наверняка пригодится, раз пригодилось мне.

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

> Ускорение поиска тегов/атрибутов по имени. Просто сравнить сначала длину, а потом уже содержимое быстрее, чем искать сразу через сравнение по содержимому.

Ой. Ты не с того конца оптимизируешь. Если на то пошло, то сравнить первые два символа строк (программируется проще, чем 4, а работает сильно эффективнее, чем 1) ещё оптимальнее. Но вообще, на современных процессорах операции со строками оптимизированы так, что самому проще не задумываться. Например, сравнение скорости strcpy и memcpy не факт, что в пользу memcpy будет. Сам был удивлён реальным бенчмаркам, после этого перестал бояться strlen.

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

Да, не нюхал, не нюхал ты minixml. Еслиб понюхал, делать yXML тебе бы в голову не пришло.

> Например, сравнение скорости strcpy и memcpy не факт, что в пользу memcpy будет.

Пруф?

Алгоритм быстрого поиска по строкам придуман ужо черт знает когда.

>Ускорение поиска тегов/атрибутов по имени. Просто сравнить сначала длину, а потом уже содержимое быстрее, чем искать сразу через сравнение по содержимому.

не думаю, что вы даже заметите разницу в скорости ;-) особенно, если учитывать что ваш xml парсер предназначен для простых приложений с простым xml

Кастую r. А то в треде стало скучно

:)

я конечно не шарю ни разу, но парсинг XML это типичная задача для конечного автомата, почему не был выбран именно такой подход в реализации данной библиотеки?

>я конечно не шарю ни разу, но парсинг XML это типичная задача для конечного автомата, почему не был выбран именно такой подход в реализации данной библиотеки?

ибо и это было давно сделано.

Автору захотелось втупую распарсить свой аленький xml-конфиг, что он героически в лоб и сделал.

есчё одна такая новость, я достану свои сорцы аналогичной херни двухлетней давности на lex/c буду каждый день их менять и постить сюда как новость:

<новость>

После долгого запоя вышел новый сволочной SAX парсер, самый сволочной SAX парсер в мире, в новой версии он есчё сволочнее, так как оттуда какието сволочи выбросили совсем ненужные им фичи.

Если вас наш парсер не устраивает, мы постараемся сделать его есчё меньше и оптимальней. Сообщите что бы вы хотели из него есчё выбросить.

Вы можете помочь проэкту, притащив ящик пива по адресу (sciped).

</новость>

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

PS: я тоже пишу индусский код, но он у меня хотя бы разборчивый...

> Пруф?

Пруф был в какой-то ньюсгруппе в юзенете по си, на которую я однажды был подписан. Я там тоже соптимизировал чужой алгоритм, заменив strcpy на memcpy, при чём по делу заменил-то, длина уже была заранее известна. В ответ мне показали бенчмарки. После этого я перестал париться такими микрооптимизациями.

:)))

ну этож надо! Вчера только заюзал версию 1.0, но столкнулся с тем что она не захотела парсить шапку <?xml...?>
модифицировал немного исходник, все равно не парсило (видимо изза "простых текстовых значений внутри тегов"), пришлось заюзать minixml (mxml) lib

А оказывается мне надо было просто один день подождать :)

Вобще автор молодец, либа хорошая. Небольшие конфиги 1.0 читал лихо, думаю 1.1 теперь будет и с более серьезными задачами справляться.

> Алгоритм быстрого поиска по строкам придуман ужо черт знает когда.

Их много придумано. Разные работают с разной скоростью в зависимости от разных условий. Однако, есть простая оптимизация имени меня самого простого алгоритма. На моих бенчмарках (т.е. на моих данных) эта оптимизация давала большой прирост по сравнению с обычним c++-ным !=. Суть в том, что загрузить два первых символа в short от каждой строки и сравнить их, выходит заметно быстрее, чем простое посимвольное сравнение. Я когда-то это обсуждал, не помню, кажется в ru.unix.prog. Может в другом месте. Если у меня появится, наконец, хотя бы месяц относительно спокойной работы, то я, наконец, доделаю NNTP для LOR, и тогда активно буду сам участвовать в разных обсуждениях тут. Последний год одни авралы и все бестолковые блин.

Да, алгоритмы быстрого поиска имеют смысл, когда длины строк становятся существенными, на коротких не дают выигрыша.

Помнится, Вагнер предлагал конфиги на tcl писать, и просто линковать к программе libtcl. Мне кажется, так гораздо интереснее, чем на xml :)

насчет других парсеров (не ради рекламы:) )
есть http://www.minixml.org/ - там никаких колбэков не нужно

fp = fopen(OUT_FILE_NAME, "r");
mxml_node_t *tree = mxmlLoadFile(NULL, fp, MXML_NO_CALLBACK);
mxml_node_t *node = mxmlFindElement(tree, tree, "Tag_name", NULL, NULL, MXML_DESCEND);
value=mxmlElementGetAttr(node, "atrribute_name");

собсно в 3 строчки можно получить значение atrribute_name у тега Tag_name


А вобще yXML. Пусть тут кричат на форуме что XML не нужен для конфигов, и полностью согласен. Однако бывают случаи, когда надо прочесть из чужого громадного XML конфига буквально пару атрибутов и юзать громадные либы я не вижу смысла :)

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

а вобще да, XML для конфигов конечно не нужен :)

> там никаких колбэков не нужно

Колбэк, колбэк, я тебя съем!

Не ешь меня, я тебе песенку спою.

Есть ещё парсеры, валидирующие по xsd схеме. Подключать замучаешься, зато потом спасает от всякого мусора на входе в программа. Так сказать принимает на себя первый удар.

А есть еще pull парсеры, которые судя по описаниям сочетают удобства DOM с накладными расходами близкими к SAX. Надеюсь попробую использовать какой-нибудь из pull парсеров в каком-нибудь из ближайших проектов.

http://www.xmlpull.org/history/diagram.gif

Не всегда. Давняя история есть с
#define NULL 1 // good luck debugging it motherfuckers!

> #define NULL 1 // good luck debugging it motherfuckers!

такое легко и быстро находится

в c++ ЕМНИП такой проблемы нет

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

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

К примеру, только что сравнил libxml с yxml при чтении большого 10МБ XML-файла из конкретного реального проекта (то есть, данные реальные, а не какие-то тестовые).

libxml 0.71 сек
yxml 0.25 сек

Я конечно понимаю, что libxml это монстр, поддерживающий много стандартов, НО лично я их пока использовать не собирался.

PS конечно хоть разница почти в три раза, на практике загрузка программы на полсекунды дольше никого не расстроит :)

> Пруф был в какой-то ньюсгруппе в юзенете по си, на которую я однажды был подписан. В ответ мне показали бенчмарки.

Бенчили с gcc и стандартными функциями?

> После этого я перестал париться такими микрооптимизациями.

Да, это микрооптимизация, и как правило not worth doing. Меня заинтересовал другой аспект: каким чудом strcpy может оказаться быстрее memcpy? Или бенч сделан через одно место, или memcpy.

> Бенчили с gcc и стандартными функциями?

Насколько я помню, да. Бенч был вполне нормально сделан.

I like the != NULL. 
 When you see 
     (p != NULL) 
 then you have enough context to know that p is a pointer

Ну если делать простой тест (через использование clock), то выходит следующе (компилятор gcc):

+ memcpy быстрее на треть, чем strcpy при -O0
+ memcpy и strcpy идут вровень при -O1 и выше.

> Бенчили с gcc и стандартными функциями?

Вот кусок обсуждения: http://groups.google.com/group/comp.lang.c/browse_thread/thread/f6af472a03ddb..."Problem+in+Strdup()"#9f2bb9bc5a586617

Где-то рядом были бенчмарки. Сорри, это было 4 года назад, не так просто вспомнить что там было. Блин, и гугльгрупс глючит, не могу найти. Лан, времени нет искать, придётся поверить мне, что они были :)

>Я конечно понимаю, что libxml это монстр, поддерживающий много стандартов
libxml - это монстр который поддерживает стандарт xml :)

>НО лично я их пока использовать не собирался
Целью было написание highload приложения в котором 0.5сек являются большим боттлнеком?

>конечно хоть разница почти в три раза
1. Не в три раза, а на 0.5 сек. В "разах" считают скорость выполнения процесса полностью - тогда получается адекватное представление о том как сильно оптимизация повлияла на конечный результат.

2. Это потому что libxml выполняет необходимые проверки корректности ввода. В отличие от других менее добросовестных библиотек :)

----- test.c -----
int main()
{
#define null 1
return null;
}
------------------

g++ test.c -o test

Возвращает 1 :)

>такое легко и быстро находится
Например как?

Не знаю как в С, а в плюсах при попытке проинициализировать указатель на объект таким NULL-ом (int-ом по сути) будет ошибка инициализации указателя.

> Например как?

ловим креш, смотрим, что указтель равен 1, ставим брекпоинт на присваивание этой переменной значения "1", перезапускаем, останавливаемся по брекпоинту и видим, что NULL == 1

точно также если ловим креш из-за использования нулевого указателя, ставим брекпоинт на проверку, проходим ее, удивляемся, жмем волшебную комбинацию клавиш и переходим на #define NULL 1

Хм, не подумал :)