Библиотека хранения данных для C++

Я хотел бы использовать в своем коде небольшую библиотеку C++, которая позволила бы сделать что-то вроде:

DataStore ds;
ds.open("data.bin");
int num=5;
std::string str="some text";
ds.put("key1",num);
ds.put("key2",str);
ds.get("key1");// returns int(5)
ds.get("key2");// returns std::string("some text")

Стиль использования не обязательно должен быть таким же, как в этом примере кода, но принцип должен остаться (получить/установить значение любого типа и сохранить его в большом двоичном объекте файла). Библиотека также не должна быть основана на SQL и не должна быть оболочкой SQL. Что это за библиотеки и в чем их преимущества?

РЕДАКТИРОВАТЬ: будет использоваться не более 10 тыс. ключей, прибл. 100 байт данных на ключ, файл не обязательно должен быть переносимым между компьютерами или ОС, файл не должен редактироваться в текстовом редакторе (в противном случае он выглядит более профессионально) и не должен быть многопоточным.


c++ data-storage
person Community    schedule 01.05.2013    source источник
comment
Существуют десятки или более проектов библиотеки ini. Даже если ни один из этих объектов не является таким простым в использовании, как ваше описание, создание такого объекта над ними наверняка будет тривиальным.   -  person mah    schedule 01.05.2013
comment
@mah, ты прав, но мне не нравится хранить данные в INI-файле, я думаю, что это не очень профессионально...   -  person    schedule 01.05.2013
comment
Это большое пространство. Ответ зависит от некоторых вопросов. У вас есть 1000, 1000000 или 100000000 ключей? Должен ли файл быть переносимым между машинами? Должен ли файл быть редактируемым в текстовом редакторе? Должен ли файл быть доступен для нескольких процессов одновременно?   -  person brian beuning    schedule 01.05.2013
comment
@brianbeuning Я добавил запрошенные вами ответы.   -  person    schedule 01.05.2013
comment
Возможно, boost::serialization?   -  person JBentley    schedule 01.05.2013
comment
@JBentley как насчет объединения сериализации и фиксации результатов в BerkeleyDB?   -  person    schedule 01.05.2013
comment
Какой тип возврата ??? DataStore::get(std::string const& key) ? В C++ система типов фиксируется во время компиляции.   -  person MSalters    schedule 02.05.2013
comment
@MSalters это может быть функция шаблона с соглашением о вызовах, например get‹int›(key) ... но это не главное, использование не должно быть одинаковым. Я нашел API STL BerkeleyDB правильным, и он также очень хорошо вписывается в код.   -  person    schedule 02.05.2013

Ответы (2)


arrow_upward
5
arrow_downward

Один из вариантов — использовать BerkeleyDB и его C API, C++ API или C++ STL API:

BekeleyDB занимает мало места, является быстрым, зрелым и надежным. Еще одним преимуществом BerkeleyDB является то, что большинство языков сценариев, таких как Python, Perl и т. д., имеют привязки к ней, так что вы можете манипулировать (просматривать, визуализировать) данными с их помощью.

Недостатком является то, что все, что вы можете хранить в нем, — это пара ключ-значение, где и ключ, и значение являются строками (или, скорее, блобами), поэтому вам нужно преобразовать типы данных C++ в строки/блобы.

person piokuc    schedule 01.05.2013
comment
Ладно, удачи. Спасибо за редактирование, я не знал о третьем API. - person piokuc; 03.05.2013

arrow_upward
2
arrow_downward

Было бы нетрудно создать класс, который делает то, что вы описываете, простым способом. Все, что вам нужно, это некоторые функции, которые могут читать / записывать ключи, тег для «какого типа это» [возможно, в сочетании с размером хранимых данных, если мы предполагаем, что хранимые данные не огромны — и я имею в виду несколько МБ на элемент или около того]. Вы можете найти какую-то "индексную структуру" или "где находится следующий элемент" ссылки на местоположение помогают.

Есть небольшая проблема с тем, как отображается ваш ds.get(std::string): вы не можете вернуть int и std::string из одной и той же функции. Вы можете написать функцию, которая принимает std::string в качестве ссылки, и другую, которая принимает int в качестве ссылки, или что-то в этом роде.

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

файл не должен редактироваться в текстовом редакторе (в противном случае он выглядит более профессионально)

Должен сказать, я с этим не согласен. Я считаю, что редактируемые текстовые файлы выглядят ОЧЕНЬ профессионально. Тот факт, что он двоичный, просто усложняет ситуацию, и с ним сложнее справиться, если что-то в приложении не работает так, как вы хотите (например, он сохранил путь установки, вы переместили его, и он больше не работает, и поскольку вы не можете запустите его, он не позволит вам редактировать эту конфигурацию).

person Mats Petersson    schedule 01.05.2013
comment
хорошо, в некоторых случаях вы правы с редактируемой частью, но у меня есть и другие причины не использовать легко редактируемые файлы... - person ; 01.05.2013