Без шума и пыли вышла очередная версия кроссплатформенной библиотеки libconfig 1.1.2

балакали, балакали - сіли та й заплакали... ті все таки нашел, что нельзя сделать в .ini файлах? поделись, плз

Ну нравится формат *.ini, ну и пользуйся, раз для твоих задач подходит. Если твоё приложение только и делает что их правит (нафик это, не пойму) то какраз стоит задуматся о оптимизации.

Хотя я и знаю что эти требования надуманы, всё же замечу, что и для XML это вполне реализуемо.

Почему нет такой такой реализации? Дык она, значит, нах никому не нужна.

А если есть непреодолимое желание обращастя с конфигом как с базой данных (что бы все изменения сразу фиксировались), то подойдут класические СУБД или Sedna(для XML).

PS

А для сверхскоростной правки лутше всего подойдёт бинарный формат. На много быстрей чем *.ini ;-)

если надо запоминать позицию и размер окон, то сохранять надо часто, плюс например список последних запросов( файлов и т.д.) так что єто не надуманная задача

привязка к БД єто существенное увеличение размера бинарника - или для людей, которіе пишут на xml размер єто пустое слово?

+ бинарній формат и БД не доступен для ручной правки через текстовій редактор - а мі говорим про универсальность

> конфиги не бівают метровіми, а потому используя буфер скажем в 4Кб мі за один-два шага передвинем нужную часть конфига и єто будет намного бістрее генерации xml

ОЧень смешно. Сформировать xml - этож просто нереально времяемкая задача. Особенно по сравнению с файловыми операциями.

>балакали, балакали - сіли та й заплакали... ті все таки нашел, что нельзя сделать в .ini файлах? поделись, плз

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

> А вот у программ получается каша. И по дефолту в том числе.

А того же GConf нормальные XML получаются.

> KDE'шник рекомендует гномий инструментарий?

Да, а что? Вменяемые люди знают об инструментарии конкурентов и не испытывают комплексов.

> Это лучше хорошо структурированных конфигов?

Да. Много лучше. Всё равно, что использование экскаватора по сравнению с лопатой. Про централизованное администрирование я уже писал.

> лишь бы гадостей написать, успокойтесь уже - аргументы другие закончились?

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

> config.Write( _("User"), name ); - это велосипед??? кому-то уже и стенка не поможет...

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

я давал ссылку на справку wxWidgets - там подробно расписано, как получить список, а не значение по имени

куда мне до вас :) мне еще учиться и учиться у вас безапеляционно заявлять о своей правоте и посылать всех в детский сад не приводя аргументов и не замечать аргументов конкурентов

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

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

>там подробно расписано, как получить список, а не значение по имени

Мне нужен не список по имени, а формат конфига (пример для трех окон) и код их позиционирования. Пример на любом языкое умеющем DOM+XPath - я привел.

>на самом деле файловых операций при записи xml будет даже больше, в зависисмости какими порциями пишется в файл текст xml

Сума сойти. Ты сказал что твой конфиг помещается в 4kb. Я тебе больше дам - я выделю 16kb для генерации XML впамяти и одноразовой записи на диск. Какой ужас...

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

wxConfig config( appname ); config.SetPath( _("/windows") );

wxString name; long dummy;

bool found = config->GetFirstEntry( str, dummy); while ( found ) { config.SetPath( _("/windows/") + name );

long x = config.ReadInt( _("x") ); long y = config.ReadInt( _("y") );

wxWindow::FindWindowByName( name )->SetPosition( wxPoint( x, y ) );

found = config.GetNextEntry( name, dummy); }

форматирование сбилось, но суть думаю понятна - код написан для wxWidgets, который использует .ini файлы для конфигов

ах..да вид конфига :)

[ Application ] Font = Tahoma, 8, Bold

[ Windows / First ] x = 5 y = 10

[ Windows / Second ] x = 5 y = 10

[ Windows / Third ] x = 5 y = 10

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

Это потрясающе. А в ini файле этого делать не надо?

> wxString name; long dummy;

Не скомпиляется. Хреново из хелпа скопировал - не все переменные переименовал.

И что это во твоему не XML? Этот класик вообще в реестр лазить(как реестр - живет?), а якобы ini файлы он превращает в подобие иерархии которое врапает slashed пути. Что забавно - так это то что ты не замечаешь того что и libconfig, и wxconfig пишут свою примитивную имплементацию недоXPath, и придумывают свой недоxml, одни заменяя теги на фигурные скобки, а другие вообще превращая Section в мутантства типа:

[Application]

Path=/tmp

[Application/Window/A]

Width=10

Height=20

[Application/Window/B]

Width=10

Height=20

[Application/Window/C]

Width=10

Height=20

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

>но суть думаю понятна - код написан для wxWidgets, который использует .ini файлы для конфигов

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

> И что это во твоему не XML?

а что по твоему xml?

> Забавно что инстинктивно тебе этого функционала хочется

По-твоему задачу можно решить только одним путем?

> wxConfig использует под вендой реестродля конфигов

напиши wxFileConfig если пишешь прогу под винду и тебе неприятно знать где хранятся данніе

>если надо запоминать позицию и размер окон, то сохранять надо часто, плюс например список последних запросов( файлов и т.д.) так что єто не надуманная задача

Действительно... я бы никогда не догадался скидывать на диск положения окон при каждом их перетаскивании... никогда бы так не делал... но раз нада так нада... :)

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

Список последних изменений я бы тоже с натяжкой отнёс конфигам... Я привык что лог!=кофиг. Может гдето и по другому.

Хотя желане улалять из логов их начало вполне логично и опрвдано. XML естечтвенно тут не даёт возможности сделать это минимальными усилиями (при значительном размере логов) ибо создавался не для этого. Обработка списков это задача другх инструментов (на XML я её могу реить но мне тоже не нравятся некрасивые костыли (только красивые :) ) ). Ну gaim, допустим, хратит всё в таком виде, только там не очень большие объёмы данных + хранится всё в нескольких файлах.

>привязка к БД єто существенное увеличение размера бинарника - или для людей, которіе пишут на xml размер єто пустое слово?

Про отношение XML-щиков к размеру, тебе любой XML-щик быстро объяснит :-D (тут гдето уже советовали перед тем как спрашивать дать ему в руки чтото типа сковородки или кирпича для убедительности)

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

Кстати, на сколько действительно увеличивается бинарник, если в него не включать саму СУБД?

>+ бинарній формат и БД не доступен для ручной правки через текстовій редактор - а мі говорим про универсальность

А добавть в софтинке пару кнопочек "импорт"/"экспорт" религия не позволяет?

Дай, лутше своё определение понятия "универсальность", ато не понятно о чём говорим.

>И что это во твоему не XML? Этот класик вообще в реестр лазить(как реестр - живет?), а якобы ini файлы он превращает в подобие иерархии которое врапает slashed пути. Что забавно - так это то что ты не замечаешь того что и libconfig, и wxconfig пишут свою примитивную имплементацию недоXPath, и придумывают свой недоxml, одни заменяя теги на фигурные скобки, а другие вообще превращая Section в мутантства типа:

Лутше не путать понятия XML и дерево, ато начнут тут всякие придиратся ;)

>перемешивая структуру и данные. Забавно что инстинктивно тебе этого функционала хочется (иерархичности представления данных, доступ по путям, иерархическое форматирование), но ты красноглазо выступаешь против формата который это все предоставляет и библиотек которые это реализуют вместо этого пользуясь _реестром_(под вендой).

Кстати, DOM можно представить и в совершенно отличном от XML виде. Например, в JavaScript есть стандртные типы данных: Array для потомков и Object для списка атрибутов и самих узлов. По аналогии, в Perl тоже есть масивы и хеши и на этом подходе основаны простые библиотеки для работы м XML.

Кроме того, на сколько я знаю, в Python и Perl есть возможность сохранять такие еонструкции в родном формате, редактировать всё это дело, потом загружать и делать eval. Хоть это и тот же DOM, но это не каким другим образом не XML (Типа можно править привычным редактором кода не пребегая к XML редакторам).

PS

Странно что XML-ненавистники умолчали про такую возможность. А могли бы превести как аргумент в своё оправдание ;)

Хотя да... XML-ненавистники всего лиш тупые ниасилившие красноглазеги :-D

> Хотя да... XML-ненавистники всего лиш тупые ниасилившие красноглазеги :-D

Ну пребывайте, пребывайте в своих наивных иллюзиях Ж)

Вам наверное и не вдомёк - какие форматы используются в конторах где стоят мейнфреймы например (намекали уже выше вам про fixed-length, delimited и пр.), и вообще вы думаете, наверное, что B2B появился совсем недавно и осуществляется он исключительно посредством xml-мессаджей. И что очередей тоже не существовало до появления JMS и уж тем более - до MQ. И транзакций - до появления JMS или скорее там у вас - MTS.
Пребывайте в своей наивности и дальше - многих тут переубедить всё равно неудастся. Их надо-бы посадить на реальную сырую дату из разнородных источников, где ошибки в данных в каждом файле - это правило. И править эти данные заставить по мере прихода - или ручками или в ихних xml-редакторах (о dtd или любой другой грамме можно забыть, так как дата-провайдеров вы в 99% не контролируете и это их прерогатива - что вам слать, и насколько битое). Да кто-ж пионеров взращённых на xml в серьёзные конторы-то возьмёт? Там как раз очень хорошо понимают - что такое Unix-way и почему xml - это windows-way. (намекаю опять: grep, sh, awk, sed, vi - это _строки_, MIME, HTTP итд - это тоже строки, и больше там _ничего_ не надо).

Ещё насмешили с XPath. Ай молодцы xml-щики. Сначала изобретаем никому не нужный костыль. Пиарим. Потом изобретаем прямой доступ к узлу, через путь, то-есть хэш (т.е. возвращаемся назад, но через жопу). Изобрели вышеприведённый property-формат:
---8<---
a.b.c=value
path/to/something=another_value #another way
path:to:another:something = just another ВЕЙ #why not unicode at the right?
---8<---

Рейзера что-ли бы почитали - если ни на что серьёзное не хватает. Или просто о стоимости (insert/update/select) операций над нодами вашего xml задумались (в O-notatins). Память занимаемую dom деревом вы и не рассматриваете, понимаю, вы же её не высвобождаете ж), но мне жалко вас, поддерживающих и отлаживающих state-машину кол-беков от SAX.
А как быть если данные вдруг порядка 4G или более близкий пример - динамический сайт и _всё_ в базе, включая flow? xml-config? ха-ха-ха.

Запомните - you will have complexity somewhere anyway. Не усложняйте себе жизнь привнесением сложности _искуственно_. Шарахнет очень скоро по яйцам.

Хватит уже по рекламкам учиться, даже если те и от alphaworks.
И oracle тоже нечего было-бы делать - всё что действительно нужно от базы - ведь давным-давно написали (выше 7.3 - как бы и не обязательно, ну можно 8 - максимум), а остальное - лабуда. Вот и пиарят и программеров индусских (а главное - менагеров) - работой занимают.

С перегруппировкой опять-же насмешили.

Скучно.

А ещё ЛОР. Позор линуксоиды.

Когда я подхожу к полкам с книгами в магазине и вижу стелажи по xml-лю - происходят 2 вещи: правая рука автоматически тянется к тому месту, где должна висеть сумка с магазинами, а разум почему-то допускает возможно и бредовыю идею - а может всё-таки в средневековье не нормальные книги на кострах сжигали? Может это историю как всегда исказили и донесли свойственно человеческому экспоненциальному восприятию - слишком гиперболизированно. А был может быть какой-нибудь ихний оккультный xml и лемминги читали слишком много и слишком сильно верили в написанное. После нормального ихнего SGML - аналога в религилзном мировоззрении.
И тут поверишь, что сжигание книг не всегда зло.

Щютка.

disclusure:
ниша SGML конечно же в паблишинге.

И ничего нельзя возводить в абсолют.

А ниша xml... - пока в маленьких документиках, и всё. точка.

> а что по твоему xml?

А что _по твоему_ XML?

> По-твоему задачу можно решить только одним путем?

Нет. Но можно не черезжопным.

>напиши wxFileConfig если пишешь прогу под винду и тебе неприятно знать где хранятся данніе

я прекрасно знаю про FileConfig. Ты не уловил фишки - основа дискуссии - представление конфигов потому что "от xml блевать тянет а INI кошерные по пятницам и кончикам пальцев приятно". Ты начал приводить примеры мегалибы, которая якобы работает с ini фалами рассказывая как клево и легко читать и править такие рульные файлы. Только оказалось что скриншоты твои под венду, а бекэндом для твоего кода под венду является реестр. Тут встает один интересный вопрос - каким же это образом ты защищаешь такой рульный конфиг хотя сам же и не используешь его и тебе грубо говоря плевать реестр там или INI? Интересный вопрос да?

> А что _по твоему_ XML?

неудобный, избыточный и медленный формат предаставления данных

> Нет. Но можно не черезжопным.

Тут наше мнение совпадает :)

> xотя сам же и не используешь его и тебе грубо говоря плевать реестр там или INI?

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

>неудобный, избыточный и медленный формат предаставления данных

НИ ОДНОГО технически грамотного эпитета.

вот такой я темный и безграмотный

<offtop>поставил eclipse 3.3 - по сравнению с предыдущими ( 3.2 например ) просто небо и земля, за 15 мин все проекты из cvs создал и собрал :)</offtop>