Комментарии 34
Почему бы не абстрагироваться от размеров выходных буферов? Библиотека может сама аллоцировать память в зависимости от алгоритма: bz2 требует 1%+600байт, lzo требует 16 байт на каждые 1024байта входного буфера. Сейчас это нужно либо помнить, либо это должно быть написано в доке, а так одной головной болью меньше, правда нужно незабыть эту память потом очистить.
И классно было бы видеть более подробные описания коммитов, ато ведь не понятно что «missing» значит что вы добавили файл лицензии, нужно смотреть диф.
И классно было бы видеть более подробные описания коммитов, ато ведь не понятно что «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;
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. Те, кто будет использовать свои механизмы управления памятью (аллокаторы) нужно подумать тысячу раз смогут передать указатель. Таких применений будет гораздо меньше, и для таких случаев можно будет заглянуть в маны или код и посмотреть сколько нужно точно выделить под буфер.
Вы уверены что это С++?
Поддержка LZMA планируется?
Не стану говорить, что «не нужно», но все же имхо полезнее и эффективнее было бы не писать свое с нуля, а добавлять поддержку новых форматов в libarchive. Это очень зрелый проект, прошедший проверку коллекцией портов FreeBSD; libarchive лежит в основе bsdtar и bsdcpio, отличается хорошей архитектурой и переносимостью.
Да бросите, посмотрите на время и на профиль пользователя. Человек только по ночам сишник, а так у него работа вебера в какойто очередной студии. Начать свой велосипед и собрать все грабли — отличный способ научиться чему-то новому для себя.
Честно говоря это кусок кода из внутренней субдшечки на С/C++, который мне интересно было отделить в виде отдельного маленького open source проекта, что как раз для меня ново и я как раз и хотел ощутить, как Вы правильно заметили, все грабли этого процесса.
Возможно. Впрочем, еще не ясно, что окажется полезнее: последовательно собирать все грабли, или сразу окунаться в хорошие архитектуру и код + учиться разработке в настоящем open source проекте. ;-)
О! Спасибо за наводку, когда встала задача я не нашел подобных библиотек поэтому написал свое. Видимо плохо искал. Сейчас изучу код, и возможно сделаю поддержку необходимых lzo и snappy в libarchive. Главное чтобы накладных расходов было минимум.
А паролить архивы умеет?
Не понимаю, зачем вообще нужны примеры использования без комментариев. Типа «догадайся сам».
GPL не самая удобная лицензия для библиотек…
Пока этот вопрос второстепенен, вначале разработка )
Многие просто не захотят тратить время на помощь проекту, если они наперед знают, что воспользоваться результатом не смогут. Если это не вопрос принципа, то лицензию лучше выбрать в самом начале работы.
Лицензию в любой момент можно сменить. Если найдуться люди, которые не не захотят участвовать в проекте только по причине лицензии, пусть напишут мне, что-нибудь придумаем.
Нельзя в любой момент ее сменить. Если к разработке подключатся другие люди, то вы не сможете сменить лицензию на их код. Разве что если каждого спрашивать разрешения на это.
Да, неплохо бы хотя б LGPL.
Зачем?
Чтобы можно было использовать в коммерческих продуктах с закрытым исходным кодом.
Вы владелец комерческого продукта с закрытым исходным кодом и хотите использовать данную библиотеку? Напишите мне, обсудим ))
Я, конкретно, — нет. Но достаточно большое количество библиотек выпускается под LGPL (а иногда даже под еще более свободными BSD или MIT) именно для того, чтобы их можно было использовать в продуктах с закрытым исходным кодом, как это ни странно звучит.
В свое время сделал для работы аналог за несколько дней.
Возможно не настолько полноценный, но ровно с такими же компрессорами (кроме непоявившегося тогда google slappy) + парой других свободных.
Все это было на классах + интерфейсах с фабрикой, что было удобно, так как сжатие довольно продолжительная операция и «динамика» никак не влияла на производительность.
Возможно не настолько полноценный, но ровно с такими же компрессорами (кроме непоявившегося тогда google slappy) + парой других свободных.
Все это было на классах + интерфейсах с фабрикой, что было удобно, так как сжатие довольно продолжительная операция и «динамика» никак не влияла на производительность.
Конкретный кусок кода, который выполнял ту же задачу, но был вшит в субд, был написан за пол дня. А вот причесывание в библиотеку заняло больше времени.
Классы, фабрики… Главное чтобы был Си интерфейс, а обертку можно написать. Проекты разные бывают, кто-то сжимает гиговые файлы, а кто-то делает сжатие объектов в несколько килобайт.
Классы, фабрики… Главное чтобы был Си интерфейс, а обертку можно написать. Проекты разные бывают, кто-то сжимает гиговые файлы, а кто-то делает сжатие объектов в несколько килобайт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
libral – слой абстракции доступа к библиотекам сжатия