Кодировочки или utf-8 и все все все...

Патамушта. https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-n...

gedit перед сохранением файла добавляет символ перевода строки (0x0A) ему в конец. Вне зависимости от того, есть он уже в конце или нет.

0A

Это '\n' - перевод строка.

Точно не знаю почему (видимо во избежание всяческих осложнений при обработке вроде diff'а) в текстовых файлах рекомендуется всегда ставить \n на конце. Git, например, даже предупреждает при коммите, если у файла нет \n на конце.

Редакторы считают себя самыми умными и добавляют к файлу \n

Да, что этот идиотизм делает в /development/?

а development тут притом, что прилетел вот такой вот файл без конечного 0A, а библиотека xml (pugixml) на него матерится...

Почему один 'лишний' байт 0A?

Потому что ты любишь переводить строки в конце файла.

pugixml

Лол, опенсорсная рабочая XML библиотека - это libxml. XML на C++ нет открытого некопилефтного рабочего, либо глючный Ксеркс, либо наколенные «пуги» различной степени кривости. И libxml везде есть из-коробки, лицензия правильная, используй его же.

Плюсую за либхмл! И апи там прекрасное.

libxml

Но внутри такой ад.

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

Даже если там под капотом ад. Какая тебе разница, если оно работает, не падает и дает удобный апи?

Какая тебе разница, если оно работает, не падает и дает удобный апи?

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

Вне зависимости от того, есть он уже в конце или нет.

Говнище этот gedit. Оно хоть отключается или надо жрать как обычно в гноме?

А, так ты тоже видел? В валгридне? Было, было у меня, я ще удивился с какого хера стабильная (на сквезе было, вновых то могли и исправить) либа подтекает.

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

IIRC следующий сниппет помогает супротив валгринда:

    xmlCleanupCharEncodingHandlers();
    xmlDictCleanup();
    xmlCleanupParser();

Я видел «утечки» в Valgrind, но они ушли после того как я в прикладном коде добавил пропущенные xmlFreeDoc(). Не знаю, как так получилось, но автор кода как-то хитро создал SAX2-подобный парсер, инициализировав его колбеками от DOM парсера libxml2, а нужные ему колбеки заменил. (Почему такой изврат вообще можно было сотворить?!).

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

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

А чому не почистить было уже после прохода по всем контекстам?

Потому что контекстов неограниченное количество, они начинаются и заканчиваются в непредсказуемое время. Вот как начали приходить данные по каналу, контекст создался. Когда другая сторона закончила передавать данные, контекст разрушается.

Лол, опенсорсная рабочая XML библиотека - это libxml. XML на C++ нет открытого некопилефтного рабочего, либо глючный Ксеркс, либо наколенные «пуги» различной степени кривости.

А про rapidxml что скажешь?

А про rapidxml

ctrl+f SAX : Phrase not found

что скажешь?

промолчу :)

Недопарсеры - это худшее из двух зол же. Если нужно парсить «настоящий» XML (в смысле с неймспейсами, поточно, с валидацией) - то надо брать настоящий парсер (т.е. libxml в С/С++). Если же на другом конце провода сидят дебилы, не могущие в JSON и пуляют Key->Value сообщения в виде плоского XML (в котором из фич XML используются только треугольные скобки) - то можно и руками/регулярками вытащить что-нужно, по крайней мере в таком случае можно ошибки входных данных предсказуемо обработать. А недопарсеры - это «ни два ни полтора».

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

Имелось в виду отключение добавлялки пустых строк конечно, хотя я и не удивлюсь если в гноме „открыть с помощью” выпилят.

Ну так это ж не бинарные данные, одна строка, пусть и пустая, быть должна, а строка отделяется переводом строки. Все вполне разумно. А насчет выпилят открыть с помощью — там же есть типа реестр gconf-editor и все доступно оттуда. Но даже если выпилят и конф-эдитор, то это xml-конфиги, и их вполне можно руками.

одна строка, пусть и пустая, быть должна

Но ведь таки не одна:

gedit перед сохранением файла добавляет символ перевода строки (0x0A) ему в конец. Вне зависимости от того, есть он уже в конце или нет.

А насчет выпилят открыть с помощью — там же есть типа реестр gconf-editor и все доступно оттуда. Но даже если выпилят и конф-эдитор, то это xml-конфиги, и их вполне можно руками.

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

Вот libxml, кстати, тоже недопарсер. Единственный парсер с полноценной поддержкой стандарта Xerces. Отвратный API у него из-за полного соответствия DOM/SAX API, а они в С++ выглядят дико, так создавались для Java макак. Ну и вообще такая ситуация связана с общей убогостью XML, имхо.

Кстати, офтоп но все же. Сначала в gnome-builder, а теперь и в gedit, появилась возможность фона в клеточку. Я так понимаю это реализовано в gktsourceview. Как бы пнуть гномеров, чтобы они в vte такое же запилили. Или им самим это дойдет.

А, нее ))) Поймал, есть такое.

Xerces C++ - мертвый проект. Там в JIRA ошибки приводящие к сегфолтам не фиксят по 5+ лет. А libxml - живой, ошибки (уязвимости в первую очередь) там активно фиксят.

Что не отрицает того факта, что Xerces имеет более полную реализацию стандарта, что только еще 1 гвоздь в гроб XML. Ну и там где я работал - форкнули Xerces, и исправляли его баги, это, наверно, проще чем пилить полноценную поддержку всего, что он поддерживает.