Как стать автором
Обновить

Комментарии 34

Почему бы не абстрагироваться от размеров выходных буферов? Библиотека может сама аллоцировать память в зависимости от алгоритма: bz2 требует 1%+600байт, lzo требует 16 байт на каждые 1024байта входного буфера. Сейчас это нужно либо помнить, либо это должно быть написано в доке, а так одной головной болью меньше, правда нужно незабыть эту память потом очистить.
И классно было бы видеть более подробные описания коммитов, ато ведь не понятно что «missing» значит что вы добавили файл лицензии, нужно смотреть диф.
Хорошая идея, в ближайшее время сделаю возможность указания NULL в качестве выходного буфера тогда память с помощью malloc будет выделена.
Насчет коментариев к коммитам — буду улучшать смысловую нагрузку )
Очень плохая идея. Лучше добавьте указатель на аллокатор и пусть пользователь сам решает, как ему удобней управлять памятью. В качестве варианта по-умолчанию, можно предоставить вариант на malloc/free, но должна быть возможность заменить их на статический пул, стек, трассирующий аллокатор.
Это Си, в нем нет аллокаторов, если только не писать самому. А если будете писать сами — то пожалуйста, передавайте указатель на выделенную аллокатором память.
Э… Аллокатор — это ж не класс std::allocator, а интерфейс управления памятью. Вот, к примеру, как он реализован в zlib:

typedef voidpf (*alloc_func) OF((voidpf opaque, uInt items, uInt size));
typedef void (*free_func) OF((voidpf opaque, voidpf address));

typedef struct z_stream_s {
<..>
alloc_func zalloc; /* used to allocate the internal state */
free_func zfree; /* used to free the internal state */
voidpf opaque; /* private data object passed to zalloc and zfree */
<..>
} z_stream;
Неправильно Вас понял, просто часто имеют в виду под аллокатором именно std::allocator. Те, кто будет использовать свои механизмы управления памятью (аллокаторы) нужно подумать тысячу раз смогут передать указатель. Таких применений будет гораздо меньше, и для таких случаев можно будет заглянуть в маны или код и посмотреть сколько нужно точно выделить под буфер.
Кстати, как насчет uncompress? в существующем решении используются *decompress функции, что означает, что нам самим придется хранить размер данных до сжатия. Тоесть если мне кто-то даст gzip архив 1мб, он может распаковаться хоть в 1мб, хоть в 100гб, но я этого не узнаю пока не распакую.
Для uncompress аналогично можно будет передать NULL в качестве выходного буфера, тогда он будет выделен с помощью malloc. Либо примерно указать размер который должен подойти, выполнить uncompress, если код возврата RAL_EBUFFER_TOO_SMALL, то realloc и снова uncompress.
Вы уверены что это С++?
Это Си библиотека которая может подключаться к С++ проектам за счет extern «C».
Поддержка LZMA планируется?
Необходимостм в LZMA не было, но если нужно могу добавить.
Не стану говорить, что «не нужно», но все же имхо полезнее и эффективнее было бы не писать свое с нуля, а добавлять поддержку новых форматов в libarchive. Это очень зрелый проект, прошедший проверку коллекцией портов FreeBSD; libarchive лежит в основе bsdtar и bsdcpio, отличается хорошей архитектурой и переносимостью.
Да бросите, посмотрите на время и на профиль пользователя. Человек только по ночам сишник, а так у него работа вебера в какойто очередной студии. Начать свой велосипед и собрать все грабли — отличный способ научиться чему-то новому для себя.
Честно говоря это кусок кода из внутренней субдшечки на С/C++, который мне интересно было отделить в виде отдельного маленького open source проекта, что как раз для меня ново и я как раз и хотел ощутить, как Вы правильно заметили, все грабли этого процесса.
Возможно. Впрочем, еще не ясно, что окажется полезнее: последовательно собирать все грабли, или сразу окунаться в хорошие архитектуру и код + учиться разработке в настоящем open source проекте. ;-)
Я думаю, у обоих подходов есть плюсы — повод попробовать и то и другое ;)
О! Спасибо за наводку, когда встала задача я не нашел подобных библиотек поэтому написал свое. Видимо плохо искал. Сейчас изучу код, и возможно сделаю поддержку необходимых lzo и snappy в libarchive. Главное чтобы накладных расходов было минимум.
А паролить архивы умеет?
Нет и не будет. Задача тут другая.
Не понимаю, зачем вообще нужны примеры использования без комментариев. Типа «догадайся сам».
Код хорошо документирован на языке С.
GPL не самая удобная лицензия для библиотек…
Пока этот вопрос второстепенен, вначале разработка )
Многие просто не захотят тратить время на помощь проекту, если они наперед знают, что воспользоваться результатом не смогут. Если это не вопрос принципа, то лицензию лучше выбрать в самом начале работы.
Лицензию в любой момент можно сменить. Если найдуться люди, которые не не захотят участвовать в проекте только по причине лицензии, пусть напишут мне, что-нибудь придумаем.
Нельзя в любой момент ее сменить. Если к разработке подключатся другие люди, то вы не сможете сменить лицензию на их код. Разве что если каждого спрашивать разрешения на это.
Да, неплохо бы хотя б LGPL.
Зачем?
Чтобы можно было использовать в коммерческих продуктах с закрытым исходным кодом.
Вы владелец комерческого продукта с закрытым исходным кодом и хотите использовать данную библиотеку? Напишите мне, обсудим ))
Я, конкретно, — нет. Но достаточно большое количество библиотек выпускается под LGPL (а иногда даже под еще более свободными BSD или MIT) именно для того, чтобы их можно было использовать в продуктах с закрытым исходным кодом, как это ни странно звучит.
В свое время сделал для работы аналог за несколько дней.
Возможно не настолько полноценный, но ровно с такими же компрессорами (кроме непоявившегося тогда google slappy) + парой других свободных.

Все это было на классах + интерфейсах с фабрикой, что было удобно, так как сжатие довольно продолжительная операция и «динамика» никак не влияла на производительность.
Конкретный кусок кода, который выполнял ту же задачу, но был вшит в субд, был написан за пол дня. А вот причесывание в библиотеку заняло больше времени.

Классы, фабрики… Главное чтобы был Си интерфейс, а обертку можно написать. Проекты разные бывают, кто-то сжимает гиговые файлы, а кто-то делает сжатие объектов в несколько килобайт.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.