для определенных целей нужен маленький по объему кода, но достаточно неплохой алгоритм упаковки бинарных данных... главная загвоздка состоит в том, что для алгоритма невозможно выделить дополнительный буффер... посоветуйте пожалуйста алгоритм, который способен распаковывать данные из буффера со сжатыми данными в него же... то есть, поясню, если непонятно... у меня есть буффер, который гарантировано вмещает в себя распакованные данные, в этом буффере лежат сжатые данные, алгоритму необходимо распаковать данные в этот же буффер без создания дополнительных буфферов (канеш можно выделить на стеке пару килобайт, но этот объем существенно меньше объема распакованных данных)... и еще, в принципе мне не важно на каком языке программирования будет доступна реализация указанного вами алгоритма или даже может быть достаточно хорошей спецификации, но мне придется портировать этот алгоритм на С++ и Питон, так что канеш желателен код на С/С++... заранее спасибо!
Расположить исходные данные в буфере выровненные по концу буфера, а не по началу. А результат писать уже с начала буфера. Тогда наверное большинство алгоритмов сгодятся, скажем, те же коды Хаффмана.
да обычный лзв, только распаковывай после данных упакованных а потом перетащигь вверх вчом проблема ?
Не годится - длина части распакованных данных может оказаться меньше упакованных. Хаффман "сломается", если в конце окажутся символы с кодами длиной более 1 байта (большое количество различных символов, большая разница частот). Семейство LZ "сломается", если в конце окажутся уникальные комбинации символов. Если возможно выделить пару килобайт памяти, то можно попытаться разбить сжатые данные на блоки, размером не более пары килобайт, с таким расчетом, чтобы распакованные данные были не короче упакованного блока. Тогда можно будет хранить обрабатываемые блоки в памяти, не боясь их испортить. Но возможность такого трюка зависит от характера данных. И вообще, для выбора подходящего алгоритма сжатия желательно знать, что именно нужно сжимать.
спасибо, буду смотреть LZMAT и LZO, так как они поддерживают "decompression in place"... так же выяснилось, что есть алгоритмы из упаковщика UPX (UCL библиотека), которые тоже поддерживают подобные вещи... в любом случае большое спасибо за помощь!
Гм, в описании LZO говорится, что он поддерживает "in-place decompression". Но не уточняется, что именно имеется в виду и как это сделано. В принципе, наверное, возможно просчитать худшие варианты и заранее выделить буфер, размером немного больше распакованных данных, чтобы избежать "перекрытий". Но подходит ли такое решение в данном случае?
