Форматы хранения текстовых данных

CSV же. Парсить легко, готовых парсеров куча, под твои задачи подходит.

SQLite

Печально, что виндозаточенный.

С чего бы это?

Конец строки по стандарту виндовый

CSV

виндозаточенный

Щито?

Форматы хранения текстовых данных (комментарий)

O_O а какая разница? Это ж просто разделительные символы для данных.

А, ну тогда HTTP тоже виндозаточенный.

Очень желательна легкость парсинга from scratch.

CSV

виндозаточенный.

ЩИТО?

Чтобы напрямую редактировать в линуксе нужно поприседать.

Посмотри, в каком формате октава сохраняет матрицы. Очень удобно.

Конец строки по стандарту виндовый

ВНЕЗАПНО: в email тоже.

man dos2unix

Весь новый чужой код этой штукой прогоняй.

Чтобы напрямую редактировать в линуксе нужно поприседать.

man sed

Большинство редакторов поддерживают как UNIX, так и DOS line endings, причём вне зависимости от операционной системы.

Весь новый чужой код этой штукой прогоняй.

sed -i 's/\s*$//'

Я лучше на сях напишу очередной велосипед, чем этой гадостью буду пользоваться!

sed это и есть велосипед на сях.

http://hkar.ru/psqW

Как-то не присобачивается

Что это?

Диалог писобачивания внешней утилиты к QtCreator'у.

Мне он ни о чём не говорит.

Парсить легко

Я б не сказал, что легко. Там всякие особые случаи, а это уже как минимум конечный автомат для парсинга. Хотя, есть готовые решения, это да, так ведь и для XML и для JSON они есть.

тебе обязательно стандарт? придумай свой формат, что тут сложного?

Очень желательна легкость парсинга from scratch.

довольно расплывчато - что конкретно понимается под этим?

Скорость важна?

Объемы?

ЗАЧЕМ ты пытаешься прикрутить это к QtCreator'у?

Я так понял, ТС собрался велосипедить свой парсер для своих данных. В этом случае ему не нужно реализовывать поддержку особых случаев.

Написание же полноценного (или даже неполноценного) XML/JSON парсера — гораздо более сложная задача.

Понятно, что при использовании готовых парсеров такой проблемы вообще не возникнет. Однако, для задачи ТС эти форматы избыточны, ИМХО.

Тысячи их. Прогрессивная молодёжь выбирает JSON, ибо компактнее XML и при этом не хуже.

ТС просил текстовый, а ты что дал?

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

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

YAML ещё компактнее.

Лучше брать табуляцию, как разделитель.

Вполне возможно.

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

Там скорость парсинга говёная, и сложность парсера запредельная. Как доктор говорю.

А нахрена мне запускать стопятьсот редакторов, стопятьсот консолей, если я могу это делать в одном окне? Прикрутил уже.

Не надо ля-ля.

http://www.yaml.org/spec/1.2/spec.html

every JSON file is also a valid YAML file

Office Open XML

ТС просил текстовый, а ты что дал?

Где он просил тектовый? «Необходимо хранить двумерную таблицу строковых значений» - чем не таблица в SQLite?

«желательна легкость парсинга» - вообще ничего парсить не нужно

А ты в заголовок смотрел?

А ты в заголовок смотрел?

А где там про то что формат хранения должен быть текстовым? Но формально ты прав, мне нужно было написать «SQLite Database File Format»

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

CSV

виндозаточенный

Это чем же?

CSV умеют ВСЕ СУБД, с линуксовыми вендовыми концами строк, с разными кавычками, с разными разделителями, табами и пробелами и пр. и пр.

Юзай XML, ибо кроссплатформенный, стандартизированный и понятный.

Чтобы напрямую редактировать в линуксе нужно поприседать.

Вроде как все адекватные редакторы умеют работать с обоими видами конов строк, что в винде, что в линуксе.

http://www.boost.org/doc/libs/1_55_0/libs/serialization/doc/index.html

xml и работает.

Чтобы напрямую редактировать в линуксе нужно поприседать.

сколько лет пользуюсь csv, но никогда не было проблем с редактированием, лол.