Cheloveck, только не сделайте неправильные 

Это уже как получится.
Кто на что учился...

Добавлено через 1 минуту и 3 секунды
Lazin, Спасибо что не проигнорировали.
1.

Вы хотите недочётов - их есть у меня! (Ж

нет итерации
нет поиска по предикату
нет поддержки комментариев в конце строки
нет соответствия именам функций load-save, read-write
нет возможности указывать настройку case-insensetive
нет возможности байндинга к переменным в коде
пустые строки гонятся через весь цикл
комменты не учитываются
повторы переменной не поддерживаются
multi-threading не поддерживается
нельзя делать переменные без секций
нельзя раскрывать переменные среды вида: AAA = ${WINDIR}\SYSTEM32\cmd.exe
нет типизации - всё гонится в string
неправильно парсится строка вида A = (B=C)
не исключающие друг-друга проверки в главном цикле парсинга
многострочные параметры не поддерживаются
load-save одного и того же файла уничтожает все комментарии
пустые секции также уничтожаются
допускаются левые имена как в переменных, так и в секциях
если записывать пустые данные в существующий файл, то функция write уничтожает его
использование iterator вместо const_iterator

потом уже просто надоело их находить 

Поясните пожалуйста.



Поясните.



А разве в стандартном ини такое поддерживается?



Вы полагаете, что этим должны заниматься функции манипуляции ини файлом?



Имеете в виду что-то типа variant?



Опять же - А разве в стандартном ини такое поддерживается?

С остальным согласен.
2.

а зачем он там? в несколько потоков парсить ini файл?  

Я не представляю реального примера. Но теоретически...возможно.

И в каком же состоянии будет пребывать объект? Что будет при вызове его деструктора?


А зачем?


Как отличать комментарии от данных, не являющихся комментариями?


Для этого можно использовать синхронизирующий прокси.

По пунктам

это зачем?


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


а где она есть? Единого стандарта на INI файлы нет. Я читал, что комменты в конце строки потдеживают только некотроые программы.


Хорошо, просмотрю код и поправлю.


ниразу не предполагалась. Это замедлит работу, а нужно ли? Мне нет, код писался в первую очередь для себя.


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


Пустые строки гонятся, если находятся между комментами. Ибо я стараюсь сохранить комменты между секциями в первозданном виде.


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


Я должен вернуть две строки? Брось, это уже перебор. Никто не потдерживает повторы.


А зачем?


Можно. loadGlobalSection, но только, если секций в файле нет. Смешанных типов никогда не видел. Либо есть секции, либо их нет вообще.


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


Так везде. Ну, допустим в VCL встроен конвертор. А надо оно? Руки на что? Эта фанкция тут так же не нужна. Данные хранятся в строках и дожны быть в них представлены.


Такие строки хранить запрещено, не знаю как у всех, но у меня нельзя.


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


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


Кажется я об этом уже сказал.


Если ты захочешь что-то написать в эту секцию, она появится. Зачем нужны пустые секции? Ну, ладно здесь я ещё более или менее согласен.


Левые? это какие? В секциях любые символы кроме [, = и ]. А чем плохое имя секции &%*/--, если ты об этом?


А это не логично? Загрузи файл и допиши свои пустые данные? Вообще, бред какой-то...


Ну, если не заметил, то функции это вспомогательные и объявлены в cpp файле. И я меняю значение переменной обращаясь к итератору.



Если юзер обработает bad_alloc, то всё будет отлично, если не обработает, то программа повиснет на любом из этих исключений.

Добавлено @ 15:00

Я сделал выводы. Боюсь, что Вы их посчитаете неправильными, но я больше никогда не буду выкладывать код. Даже если он будет идеальным, всё-равно его обосрут с ног до головы. Потому что у халатика нет преламутровых пуговец.

ЗЫ Тема закрыта, линки убрал. Обсуждать больше нечего.

Это сообщение отредактировал(а) Cheloveck - 25.6.2009, 18:05

Что и требовалось доказать.

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

Это сообщение отредактировал(а) zim22 - 25.6.2009, 17:38

Ну, если не считать того, что программа через некоторое время, скорее всего, издохнет на фиг из-за двойного удаления, всё будет просто превосходно  

на мой взгляд стоит делать такую библиотеку так:
Для начала реализовать SAIni (simple api for ini) парсер, путь даже на С чистом. Сам файл зачитывать нет нужды в память - достаточно описывать элементы как <смещение, длина>. Работать с файлом как проекцией на память (хотя это и не обязательно). Также парсер для записи потоковой нужен. Вопросы кодировки решаются тут.

Далее над этим парсером надстраивается DOM парсер. В простейшем случае это вектор базовых IElement. В нем достаточно одного метода - ELEMENT_TYPE GetType(). Например Section наследуется от IElement и дополнительно содержит vector элементов типа "ПолеСЗначением". Ну и также присуствуют типы : Поле, Значение, Комментарий. Значение абстрактное, и может быть ЗначениеТипаInt, ЗначениеТипаFloat, ЗначениеТипаСтрока etc. При чтении используется "ЗначетиеТипаСтрока". Тут есть где развернуться шаблонолюбителям 8)

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

Как вам идея ?

/* если ктото не чостет это бредом, то можно поучавствовать в создании - одному лень и скучно */

Это сообщение отредактировал(а) jonie - 25.6.2009, 19:58

UnrealMan, 
нет поиска по предикату 
А зачем?
stl-way (:

Как отличать комментарии от данных, не являющихся комментариями?
очень просто: если символ комментария находится внутри строкового литерала - то он считается частью данных. иначе - комментарий.

Ini-файл - это по сути хранилище ассоциативного массива ассоциативных массивов. По названию секции находим секцию, по названию ключа находим значение. Покажи, где std::map реализует поиск по предикату.


Ах, тут ещё строковые литералы надо вводить. А вслед за этим escape sequences, universal character names и директивы препроцессора C?  Но вот беда: такая натюнингованная структура по-прежнему не будет позволять удобно хранить вложенные секции. Если хочется чего-то продвинутого, то лучше сразу отказаться от ini-файлов и использовать другой формат.

ini файл хорош тем, в отличие, например от xml что не требует специальных знаний вроде перечня символов подлежащих экранированию, DTD схем, XSD схем и т.д.