Оцените библиотеку для работы с реестром

Задача: написать на C++ лучшую в мире библиотеку для работы с виндовым реестром.

Что получилось:

1. Одинакого доступна и ANSI и UNICODE версия.

2. Библиотека выполнена в максимально приближенной к STL семантике. Семантика STL-контейнеров и итераторов.

3. Вся реализация скрыта в pimpl-ах, Windows.h наружу не торчит.


Пример использования:

http://www.everfall.com/paste/id.php?0spuxh1fuujc


Сейчас думаю над тем, как лучше сделать итерирование значений и их удаление.

 

Выглядит неплохо, исключения само собой предусмотрены в библиотеке?

 

TSS

Пока что обработка ошибок не сделана, но обязательно будет. Скорее всего ошибка на уровне апи будет плеваться объектом boost::system::system_error - мне кажется это наиболее кошерный вариант.

 

Добавлено итерирование и удаление значений. Ссылка та же.

Либа собирается с нулем варнингов на 4-м уровне ахтунгирования.

 

Так это.. а я смогу ее юзать работая "на дядю" ? =) Ну т.е. типа как там с лицензией и т.д., и когда будут исходники? Выглядит очень симпатично, прикольно, что раньше никто не придумал ничего такого..

 

Velheart

Либа написана для коммерческого проекта, поэтому пока что не ясно, можно ли вообще будет выложить сорцы в паблик.

 

_DEN_

Тогда смысл этого постинга? И я предпочитаю реестру конфиги, хотя идея неплоха.

 

_DEN_
Захват методов в хидерах используете(OBJECT_TYPE.ParseProcedure etc.) ?

 

Booster

Смысл этого постинга в том, чтобы показать внешний интерфейс библиотеки, чтобы о нем можно было высказать какое-то мнение.

 

Clerk

Эммм... Не совсем понял что это и как относится к реестру.

 

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

 

_DEN_
Если идёт прицел на стандартный интерфейс, то имхо и работу с параметрами имеет смысл сделать однотипно, например ассоциативным контейнером. Например вместо - division.query<key::multi_string> имхо красивее был-бы оператор [].

Ну и это явно нужно перенести в библиотеку:
#typedef registry::basic_key<char> key;
#typedef registry::basic_key<wchar_t> wkey;

 

Booster

Огласите весь список пожалуйста. На счет оператора - как ты себе представляешь обращение через operator [] когда нужно указывать тип?

Это и так в библиотеке. Вытащил наружу для наглядности.

 

operator []<Type>(key) не нравится?

 

Booster

Эта конструкция не скомпилируется. Приведи конкретный компилируемый пример, как ты это видишь.

 

_DEN_

Код (Text):

1. x.operator[]<Type>(key)

Тока так

 

Намного красивее.

 

Это конечно вопрос спорный, так как автовывод тоже имеет имеет право на жизнь. Но set/query тоже немного странно. Может тогда сделать полный комплект - operator [], get/set?
Где get тоже с автовыводом.

 

И get как-то привычнее, query бд напоминает.

 

<offtop>
Clerk, о чём вы? Это .LANG.C, а не .OS.KERNEL 8)

Насколько можно судить из поста, это просто сиприплюснутая обёртка для advapi. Красиво. Но не более того. Да и обработка ошибок под вопросом.
</offtop>

А LGPL не спасёт отца русской демократии?