mayton2019

В какой строке у тебя NPE?

Дело в том что bash сам по себе не является языком программирования. Он - просто связующий клей который вызывает внешние утилиты. Поэтому если у вас задача серъезная - то берите Perl/Python. Там есть сильные средства для процессинга текста и отчотов.

Bash подойдет только до первого out of memory как только у вас зайдет файл превышающий оперативку. Или просто зайдет "технически"-нетекстовый файл где строки будут сверх-длинные или просто вызывающие побочные эффекты. Обработать такую ситуацию в ЯП - нормально а в баше - сложно.

Поскольку речь идет о языке "C" - то надо корректно обрабатывать ошибки open/read/write/fseek/close и реагировать на них. И закрывать файловые хендлы при любом возможном исходе. Ну и не забывать делать free() после malloc(). Грубо говоря количество malloc должно быть всегда равно free.

Если была смерть posix-потока то надо как-то найти все брошеные дескрипторы-сироты и закрыть их тоже. Тоесть процесс-родитель должен как-то их видеть.

Есть хорошая поговорка про пудинг.

Вобщем для расчета значение математического выражения - его надо вычислить. Никакие брутфорсы скорее всего не помогут. Выражение может потребовать расчетов функций. И их надо провести. Как - это уже другой вопрос но ясно что не в строках.

Непонятно зачем автор обсуждает глифы и шрифты? Данная задача состоит из двух частей.
1) Преобразование двоичного числа (например int) в строковое представление двоичного числа.
2) Печать этой строки на экране используя (или не используя) явное указание шрифтов и прочее.

И мне кажется что автор не решил пункт (1) этой задачи. Этот пункт является обязательным на первых уроках информатики. Он называется "Системы счисления". Позиционные. Непозиционные. Перевод из одних систем в другие и прочее. Вот с этого надо начать обсуждение.

Вопрос в перспективе тянет на экспертную систему по выбору БД.

При данной постановке - можно брать любую документно-ориентированную. Все одинаково подходят.
Но если основной контент (80% берем по Паретто) это файлы - то можно брать Amazon S3, в дальнейшем с перспективой трансформировать это в DynamoDb если понадобятся транзакции или в Amazon Document Db (он же Mongo) если понадобится тонкая работа с атрибутами документов (или файлов).

Автор должен понять что в это вопросе нет единого правильного решения. Есть просто некая сравнительная табличка где есть набор фичей с одной стороны и набор DBMS с другой и нет такого покрытия которое бы закрыло ВСЕ фичи.

Если часто удаляется папка с over миллиардом файлов то можно пересмотреть эту задачу архитектурно. Например смонтировать эту папку как volume и форматировать ее. Это быстрее. В противоположность, файловые удаления по 1 штуке требуют фиксации транзакции для каждого файла. А это избыточные действия которые как раз и создают поток IOPs над структурами данных ext4. По аналогии с БД. То что делает автор это удаление каждой строчки из таблицы с коммитом. А то что я предлагаю - это по смыслу truncate table.

Если автору нужно хранить данные измерений (графики) в режиме append-only, то можно посмотреть в сторону InfluxDB.

Сразу 3 замечания.

Непонятно зачем автору считать 43 мегабайта на фоне 3Гб. Это 1%.
Непонятно зачем автор печатает физические размеры файлов. Ведь в них хранятся заголовки и всякие
прочие служебные структуры данных которые к размеру таблицы не относятся.
И непонятно зачем автор вывел длины файлов в размере который округлён в human-readable? Там все равно не учтены килобайты. Уж если пошёл счет на копейки так надо и копейки печатать.

Прости но уж очень много неточностей и косвенностей в самом вопросе. Просто нельзя так.

Почти таже самая проблема на стареньком HP Core i3. Пока стояла десятка все норм. Как только поставил Ubuntu 18 LTS - пошли регулярные дисконнекты. Субъективно вижу что очень низкая чувствительность антены приёмника в ноуте. Грешу на хреновые дрова. Так и не пролечил.

Workaround: Когда включаю смартфон в режиме wifi-точки и ложу его рядом прямо с корпусом ноута - связь появляется.

Можно эту прямоугольную "колбасу" вообще не поворачивать. А хранить вектор повернутости. И перегрузить оператор индекса чтобы доступ вел себя по правилам аффинных преобразований.

Вопрос звучит неправильно. Сам по себе С++ не имеет никаких встроенных в себя технологий для отрисовки графики. Это уже - задача библиотек которые будут зависеть от ОС или оконного менеджера.

И здесь Qt, Gnome, KDE, WTL просто производные от ОС.

Реляционная алгебра практически не умеет оперировать горизонтальными коллекциями. Такова она есть. И SQL создавался для других дел.

Самое правильное что можно сделать - создать временную табличку. Слить туда твои массивы с разворотом в 90 градусов и выполнить простейший (! реально простейший!) запрос с группировкой.

Это решение будет идеологически правильней, чем нагружать SQL не-свойственными ему задачами.

Делаешь две БД. И пишешь в одну все записи удовлетворяющие HASHCODE(primaryKeys, 2) == 0
а во вторую БД HASHCODE(primaryKeys, 2) == 1. При запросах соотв. делаешь запрос в две БД и объединяешь результат.

Господи как все сложно. Берешь и делаешь столько очередей - сколько надо приоритетов. И все.

Автор пытается делать стеганографию. Тоесть в картинке скрывать информацию. Здесь выбор PNG полезен тем что инфа лежит плотно и в случае "гладкого" характера информации сжимается. Наподобие архиватора.

SVG - не подходит т.к. векторный и расточительный.
JPG - тоже не подходит т.к. повреждает информацию. Ее потом нельзя будет извлечь из файла без потерь.

По поводу дополнения файла до размера кратного длине строки (padding). Там не 00 не FF не подходит. Так как в оригинальном файле тоже могут быть эти константы и алгоритм даст сбой. Надо почитать как делается в криптографии. Там есть специальный workaround. Если его не реализовать правильно то при обратном декодировани картинки в файл мы можем получить ложное удлиннение файла на размер хвостика последней строки пикселов. Насколько это большой дэмедж для исходного файла - ХЗ. Но лучше конечно его не нелать чтоб обратное декодирование было надёжным с точки зрения длины файла.

Самым быстрым являются хешмапы в памяти приложения. Но вопрос на самом деле более сложный. Как только нам нужно делать join 2-3 таблиц тогда - работает сложная квантовая механика оптимизатора и вариантов быстроты становится целая матрица.

rar имеет консольный тул. Его можно вызвать как то так
$ rar -l <namefile>
И проанализировать листинг. Там скорее всего напротив каждого шифрованного файла будет какая-то пометка или символ.

Автору - неприлично спрашивать такой вопрос совсем не подготовившись.