Нужно сохранить некий набор данных в 100 Мб внутри библиотеки, т.е. без создания доп. файлов.

Есть утилита

xxd -i large_data.txt > large_data.h

— можно преобразовать в массив байт.

Но вот в чем беда — это загружается при запуске программы и не выгружается из памяти никогда.

Есть ли способ обойти — т.е. чтобы и не выносить данные в отдельные файлы, и при этом чтобы данные не находились перманентно в ОЗУ на протяжении всей работы программы?

Здравствуйте, Shmj, Вы писали:

S>Есть ли способ обойти — т.е. чтобы и не выносить данные в отдельные файлы, и при этом чтобы данные не находились перманентно в ОЗУ на протяжении всей работы программы?

Статика — на то и статика, чтобы не меняться.

S>Есть ли способ обойти — т.е. чтобы и не выносить данные в отдельные файлы, и при этом чтобы данные не находились перманентно в ОЗУ на протяжении всей работы программы?

1. Вынести статический массив в отдельную либу с динамической загрузкой/выгрузкой.
2. Хранить статический массив сжатых данных и динамически распаковывать.

S>Но вот в чем беда — это загружается при запуске программы и не выгружается из памяти никогда.
S>Есть ли способ обойти — т.е. чтобы и не выносить данные в отдельные файлы, и при этом чтобы данные не находились перманентно в ОЗУ на протяжении всей работы программы?
Исполняемые файлы и библиотеки современные ОС не загружают в ОЗУ, а отображают. Реальное аллокация физ страниц и вычитывание данных в них происходит при первом обращении.

Здравствуйте, Shmj, Вы писали:

S>Но вот в чем беда — это загружается при запуске программы и не выгружается из памяти никогда.

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

Здравствуйте, Shmj, Вы писали:

S>Но вот в чем беда — это загружается при запуске программы и не выгружается из памяти никогда.

Беда ли это?
Какая платформа? Какие ограничения на память?

S>Есть ли способ обойти — т.е. чтобы и не выносить данные в отдельные файлы, и при этом чтобы данные не находились перманентно в ОЗУ на протяжении всей работы программы?

Если это нормальная ОС с виртуальной памятью, то проблем особых нет. Ну, будет лежать здоровенный блок в странице констант, ну будет занимать место в адресном пространстве. ОС его отобразит из экзешника в виртуальную память и подгрузит при обращении.
Только надо, чтоб это были константы. Потому что страницу статических переменных ОС может скопировать (чтобы изменения не потерялись), а потом засовывать в своп. Впрочем, теоретизирую.

Если ОС нормальная, но память прямо реально жалко, — надо компилировать в динамическую библиотеку и загружать-выгружать вручную.

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

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

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

Здравствуйте, Shmj, Вы писали:

S>Нужно сохранить некий набор данных в 100 Мб внутри библиотеки, т.е. без создания доп. файлов.

S>Есть утилита
Вообще же, есть утилита, которая напрямую перегоняет бинарник в объектник, без генерации-компиляции. Называется bin2obj.

Здравствуйте, Кодт, Вы писали:

S>>Есть утилита
К>Вообще же, есть утилита, которая напрямую перегоняет бинарник в объектник, без генерации-компиляции. Называется bin2obj.

Но как можно, это же не кросс-платформенно. Получается нужно минимум 3 а может и больше obj-файла — для каждой платформы свой.

Здравствуйте, Shmj, Вы писали:

S>Но как можно, это же не кросс-платформенно. Получается нужно минимум 3 а может и больше obj-файла — для каждой платформы свой.

Очень даже кроссплатформенно.
Исходниками являются сишные/плюсовые тексты и вот этот вот бинарный файл.
А объектные файлы, получаемые для разных платформ — ну так они, ясное дело, для каждой платформы свои. Хоть из текстов компилятором, хоть из бинаря конвертером.

Единственный мотив перегнать бинарь в сишный текст — это сократить требования к инструментам сборки для целевой платформы.
Типа, а вдруг для неё не окажется bin2obj, или она там с какими-то причудами? А сишный компилятор и так и этак должен быть.

Ну и билдсистемы "из коробки" часто заточены под сборку проектов, написанных на одном языке.
Прикручивать сторонние языки (бинарь — это такой тривиальный язык) и сторонние компиляторы (bin2obj — это такой тривиальный компилятор) может быть не самым простым делом.