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

Красивый интерфейс. Даже придраться не к чему особо. Но exception'ы прикрутить надо обязательно.

 

Респект.
Тоже залез в тред с целью предраться, но даже не придумал к чему)

 

Для перечисления параметров нужны итераторы.

 

Ustus
Booster

О чем вы говорите, это же ахтунг)))

Ну вообще-то всю жизнь юзалась функция RegQueryValueEx. Функция RegGetValue появилась только с W2k3/WXP64.


На счет операторов - все несколько интереснее. Т.к. функции енумерации работают по индексу, то есть мысль сделать итераторы рандомными, на оператор [] возложить доступ к чайлдам, и предоставить функции ::empty и ::size. Тоже самое относится и к значениям.

О каких параметрах идет речь? Ключи (keys) сейчас перебираются итераторами. Значения (values) - тоже. Что такое "параметр"?

 

_DEN_

Почему?

Не понял связи.

Снова не понял логики. Реестр - дерево, параметры(имя, значение). Зачем в принципе тут нужен произвольный доступ по индексу? Что это даст?

Да values. Плохо посмотрел.

 

Booster

Можешь привести хотя бы одну уважаемую библиотеку (читай - stl, boost, loki), где в _паблик интерфейсе_ точит какая конструкция?

Связь здесь очень простая. Цель либы - обобщить работу с реестром наиболее естественным образом с точки зрения семантики языка C++. Реестр - штука которая есть только под виндой. Соответсвенно, с либой будет работать человек, который 1) умеет работать с реестром под виндой и 2) "знает" язык С++. Помимо всего прочего, библиотека должна быть максимально проста. Один из методов достижения простоты - оправдывание интуитивных ожиданий пользователя от ее публичного интерфейса. Иными словами, если человек всю жизнь писал RegQueryValueEx, то вполне логично предположить, что именно "query" будет тем именем, которое покажется пользователю, знакомому с работой с реестром, наиболее естественным и подходящим. Мои рассуждения в чем-то грешат?

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

 

_DEN_

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

Проблемы microsoft, что они считают реестр бд. Для меня же более естественно, работать с библиотеками унифицированным образом, и требовать чтобы пользователь до этого работал с RegQueryValue несколько странно. Я например давно не работал с реестром, и уже забыл что там RegQueryValue и искал get. К тому-же этому интерфейсу по-моему ничто не мешает быть кросплатформенным, по крайней мере с виду.

Рандомный доступ там сделан для перечисления, более не для чего он не нужен. У нас для этого есть итераторы. Ради чего поддерживать ненужный интерфейс? Разве человек не будет знать как работать с итераторами? Отрубать нужный функционал действительно не стоит, но зачем тащить не нужный. Интересно почему в stl всем контейнерам не сделали рандомного доступа, наверно были на то причины.

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

 

Booster

Тебе не кажется, что у тебя слишком много аргументов начинается с "Но для меня... Но лично мне... Для меня же..."?

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

Конечно! Массивы в большинстве языков имеют доступ с константной сложностью. От оператора [] ожидается константная (или _хотя_бы_ логарифмическая, то есть "почти константная") сложность исполнения. У контейнера не будет такого оператора если он не в состоянии справиться с такими требованиями (Или если такой оператор просто не имеет смысла - std::multimap). Если мне апи предоставляет индексированный доступ к чему-либо, то я вправе ожидать константной, или хотя бы логарифмической сложности доступа. Нет никаких объективных причин, которые запретили бы рассматривать определенный этаж дерева как плоский вектор.

 

_DEN_

Это плохо?

Вроде я аргументировал. Давай ещё раз. Индекс принимает только RegEnumKey.
Because subkeys are not ordered, any new subkey will have an arbitrary index. This means that the function may return subkeys in any order. Всё это говорит о том, что назначение индекса только перечисление. Но есть же итераторы, зачем иметь абсолютно идентичный интерфейс? Чтобы доступ был идентичен виндовому реестру? Зачем? Ты фанат mfc?
Разве не лучше стремиться к стандартному С++ интерфейсу, а не симбиозу WinApi + C++?

Рассматривай, но опять, для чего?

 

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

 

Booster

Это необъективно. Пока ты что-то делаешь для себя - это одно, тут нормально. Если же ты делаешь что-то для всех - это совсем другое, тут плохо.

Не только. Еще RegEnumValue.


TSS

Такая задача не ставится. Вообще, нужна ли тут семантика вектора, я пока что не решил. Этот вопрос имеет более так скажем глубокие корни. Нужно проанализировать модель и понять, где интерфейс апи-функций является просто интерфейсом апи-функций, а где интерфейс говорит о существовании некоторой концепции. Не все так просто.


Кстати, Booster, оператор [] с явным вызовом и указанием типа - это слишком маргинальных ход конем. Никто из уважаемых людей такие вещи в паблике не выставляет.

 

_DEN_

Ну и что там(где ?) секретного скажи, щаc опишем и выложем если нужно будет.

 

Гы Просто некошерно.

 

А я думал что бан в Гугле это сказки )
Windows Registry Library

 

J0E

А я думал что шутки про бан в гугле уже устарели лет 10 назад. Так себе библиотечка-то.

 

Дело не в смешно, поинт в том, что ты не первый, а Гугла 10 лет назад не было

А про библиотечку написал бы, что там так себе, а? Без этого критика ближе к старческому ворчанию. Как по мне (я исходники ни от одной не видел) stlsoft в разы лучше твоей, поскольку юзабельна.