Как можно использовать XML и C?

Сам в шоке.

Они наркоманы, не верь им!

правильный язык программирования
правильный язык разметки

Отличное сочетание, что не так?

Тред не читал.

libxml2

какбэ особой зависимости между С и XML не наблюдается. XML используется много где. в основном там, где нужно юзерочитабельный формат. впрочем, читабельность XML весьма относительна. а обмен данными, например, в С гораздо проще и быстрее в бинарном формате.
если ты имеешь в виду морды, то практически все графические интерфейсы умеют себя рисовать из XML динамически. так что разницы особой нет. я юзала такие вещи c C++ и wxWidgets, например, для генерации множества разных морд без компиляции, чтобы не запариваться с рисованием гуёв, которые я органически рисовать не люблю. а XML накидать проще пареной репы. он подгружается и софтина из него рисует гуй на лету, навешивает события по атрибутам в том же XML'е (это я уже городила свой огород) - вот и готова софтинка. просто и удобно. такую же хрень можно и на С писать. и на любом другом языке.

например, в С гораздо проще и быстрее в бинарном формате.

Смелое заявление. Особенно про «проще».

Надеюсь, она это в порыве постинга, да и тема не об этом в общем то.

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

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

на С проще работать с бинарём, чем парсить XML. и технически проще, и по скорости быстрее. ну и объёмы данных, какбэ: в текстовом формате данные распухают многократно, эффективность передачи падает. в сетях для скорости и простоты парсинга часто используют бинарные XML разных сортов.

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

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

Бинарные протоколы это не Си-структуры. Видимо тут недопонимание. Ничего против бинарных протоколов не имею

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

Особенно про «проще».

Таки да, самодельный бинарный TLV на C таки будет проще поддерживать, чем XML.

именно! потому что парсер XML написать куда сложнее. и работать он будет медленно и печально. добавляем объёма - и вот вам уже нужны SAX парсеры, потому что DOM сожрёт всю память. а в бинаре всё проще, памяти меньше, читай себе байтики и передавай юзеру. а если поток гигабайтный? в XML тут уже даже SAX не справится.

А как же http, smpt, jabber и многое многое другое? Я имею ввиду что они все текстовые...

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

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

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

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

Iron_Bug, eao197,

Написать TLV на C просто. И поддерживать тоже просто. Если сам это делаешь. Но если код меняет ещё несколько человек, возможны сюрпризы. Не будешь же за всеми бегать и поучать.

когда я могу гонять по сети десятки гигов бинарей в TCP/IP

Типичные holywar'ы. Одна сторона налегает на человеко-читаемость, человеко-генерируемость и самодокументацию. Другая сторона налегает на эффективность размера и скорости кодирования-декодирования. Как будто кто-то будет делать бинарные конфиги или гонять по сети картинки в PPM закодированные в UTF-32.

Но если код меняет ещё несколько человек, возможны сюрпризы.

Например?

Баги со вложенностью, когда схема меняется.

Быстрее и проще обычно не сочетается...

Баги со вложенностью, когда схема меняется.

В смысле тег 0xd раньше вкладывался в тег 0xa, а со временем стал вкладываться в тег 0xb?

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

Какой-нибудь XML предотвратил такую проблему, хотя бы просто читаемым примером структуры данных. Но, конечно же, экономим микросекунды, и генерить/парсить XML просто глупо.

expat, не?

На приёмной стороне был косяк с определением, где надо начинать обрабатывать новый вложенный блок. Причём всё казалось работающим, но не совсем.

Ну тут-то еще концы найти можно. Я вот в свое время столкнулся с ситуацией, когда Xerces крэшил все приложение после парсинга нескольких тысяч XML-сообщений. Тупо в один прекрасный момент отдаешь ему корректный XML — а он валит все по сегфолту. Концов так и не смогли найти, помогла смена Xerces на libxml2.

Так что косяки везде можно встретить, но вот работу с TLV можно на коленке за день-два написать, а вот для XML-я без внешних зависимостей, да еще и не сильно маленьких, не обойтись.

Да и по производительности разница в скорости может достигать 4-5 раз. Если приложению нужно парсить XML всего один-два раза, это не о чем. А если десятки тысяч XML-лин в секунду, то сразу ощущается. Хотя, если речь об интеропе с чем-нибудь старым и ынтырпрайзным, то выбора-то и нет :(

но вот работу с TLV можно на коленке за день-два написать

В этой фразе прямо чувствуется возраст. На ЛОРе обычно говорят: «да я за 15 минут напишу».

Так что косяки везде можно встретить, но вот работу с TLV можно на коленке за день-два написать, а вот для XML-я без внешних зависимостей, да еще и не сильно маленьких, не обойтись.

Зачем при живом протобуффе и Авро писать что-то на коленке, да потом еще пару лет страдать из-за этого?

и как-то не было проблем никогда. потому что бинарник - это быстро и просто.

0JAg0LPQu9Cw0LLQvdC+0LUgLSDQvdCw0LPQu9GP0LTQvdC+Lgo=

а вот для XML-я без внешних зависимостей, да еще и не сильно маленьких, не обойтись

На flex-e получается без зависимостей вообще (только libc) и быстрее чем на expat-e.

Зачем при живом протобуффе и Авро писать что-то на коленке

Надеюсь, это риторические вопросы?

Нет, вполне серьезные.

На flex-e получается без зависимостей вообще (только libc) и быстрее чем на expat-e.

Вы предлагаете делать парсинг XML-я на flex (это который «новый» lex, т.е. генератор лексеров)?

Это не бинарник, а ты наверное веб дизайнер

А по мне, так вполне бинарник. Да, я верстальщик на джумле, как ты угадал?

Нет, вполне серьезные.

Например, в protobuf может не быть нужных для предметной области структур данных. Например, поддержки multimap-ов «из коробки». Или variant-ов.

У вас нет возможности поменять формат двоичного представления. Например, чтобы в TLV tag всегда был один октет, а Length — два. Или чтобы tag всегда был два октета, а Length — четыре. Или чтобы tag и length всегда были по четыре октета. Что может быть важно, если источником/приемником данных будет какое-нибудь маломощное устройство, в которое не запихнешь результат выхлопа Protobuf-овского компилятора. Или, если данные ходят по самодельной шине, скажем, в 32-бита и поэтому все PDU и элементы PDU нужно выравнивать на границу 32-х бит, дабы читать/писать в шину было проще.

Или вам нужно сериализовать/десериализовать структуры данных, которые уже есть. Ведь protobuf по спеке нагенерирует вам новых классов. И вам придется сначала перегонять инфу из своих классов в сгенерированные protobuf-ом, а потом уже из них в бинарный формат. Ну и то же самое, но в обратном порядке, при десериализации.

протобуф уже устарел, есть всякие capnproto и иже с ними, не копирующие данные в процессе разбора

Вы предлагаете делать парсинг XML-я на flex ... ?

Да. Так больше понравилось. Expat режет значения атрибутов, приходится их склеивать и тупит на незакрытых тегах. Libxml2 ваще не вариант(только для мелких файлов) т.к. все надо всосать в память за раз.

Типичные holywar'ы. Одна сторона налегает на человеко-читаемость, человеко-генерируемость и самодокументацию. Другая сторона налегает на эффективность размера и скорости кодирования-декодирования.

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

тот же веб вручную никто не верстает давно

А как верстают? Всю жизнь вручную верстаю и все вокруг так же. Или я что-то не так понял?

Всю жизнь вручную верстаю

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

в текстовом редакторе?

В IDE вроде WebStorm, но от текстового редактора оно отличается только подсветкой и всякими мелкими вкусностями.

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

Например?

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

Спасибо. Отстал от жизни.

Libxml2 ваще не вариант(только для мелких файлов) т.к. все надо всосать в память за раз.

Там не только DOM