Dmitrii, на самом деле доказательство верности парсера-сериализатора для двух языков - это реально сложная инженерная задача. Тут.. даже в рамках одного языка чорт ногу сломает. Big-Little-Endian. Разное представление символов. Разная разрядность целых.
По хорошему автор должен был еще для С++ брать специальные библиотеки сериализации типа Thrift, Protobuf, AVRO e.t.c. и делать под них описание бинарного формата. И далее - генерировать готовые парсеры под С++ и ПХП. Так например сейчас делают в мессенджинговых системах на базе Kafka. Тело сообщения - бинарное в формате AVRO - и его понимают десятки языков и систем потому что есть схема. И есть стандарт на единое кросс-платформенное видение информации.
Обычно в операционке есть лимит на количество открытых файлов на пользователя.
Смотри утилиты ulimit. Смотри утилиту lsof для наблюдения за текущими открытыми
файлами. Их может быть визуально больше чем ты открыл т.к. ОС может файлом считать
разные вещи в т.ч. и сетевые сокеты.
Для коротких скриптов типа консольных приложений брошенные файловые дескрипторы - не являются
проблемой т.к. после завершения процесса - операционка все подметет. А вот проблему
могут создавать такие скрипты которые работают бесконечно. Они могут накапливать ресурсы
долго до тех пор пока не создадут реальные проблемы для хоста.
Я все равно не знаю Rust но выглядит как вполне себе законченое решение.
Можно еще попробовать рекурсию. Она заменит цикл for и тогда код визуально
станет еще меньше. И тогда finish надо будет передавать каждый раз как аргумент.
Кумулятивный. Но рекурсия это такое ... изысканное блюдо. Не везде подходит.
Вобщем вполне себе норм выглядит. Можно нести на зачот.
В настоящий момент я на рабочем ноуте под Windows где Gforth я погу запустить под WSL. Но как только я доберусь до своего домашнего десктопа - я обязательно снесу дефолтный .deb пакет и поставлю самый свежий с GitHub.
По теме. Топик можно закрывать. Я вобщем-то выяснил все что хотел.
По моему Java не регламентирует ограничений на объем кода в исходном виде. Хотя существует
лимит в байтах на JVM метод. Там кажется 64килобайта в байткоде.
По поводу тех кейсов когда это приемлемо. В современном проекте бывает кодогенерация.
Это связано с техниками генераторов парсеров (Antlr, JavaCC), или SOAP реализаций.
В этом случае обычно генерируемый код помечается аннотацией @Generated
и как-бы исключается из скоупа разработки. Грубо говоря, мы не желаем смотреть в код
написанный роботом. Мы доверяем этому коду. Но если надо вносить изменения - то меняем
соотв. исходник этой кодогенерации.
По поводу пределов восприятия для обычного модуля (класса) или метода (процедуры).
На лимит модуля кажется Никлаус Вирт ставил ограничение в 4000 строк. А по поводу
метода есть метрики Холстеда (Haltsted) которые буквально в виде числа выводят
сложность метода для человеческого восприятия. Тоесть я-бы исходил не из 30 тысяч
строк а из того насколько сложно (или не сложно) разбираться в этих строках человеку.
Данная задача решается во первых - анализом соседних data-rows. Это можно сделать с помощью оконной функции.
А во вторых... неважно. Решение уже есть. Второе - дело техники.
Другая идея. Я не знаю как работает TrueCrypt. Но допустим это симметричка в режиме ECB. Каждый блок шифруется независимо от другого и нету сцеплений. Размер блока нам известен допустим 4096 байт. Блок файловой системы. И допустим автор сохранил пароль (ключ).
Тогда я предлагаю следующее. Взять создать 2 логических тома которые полностью совпадают с оригинальным по размеру. Зашифровать первый. Сделать дубль на второй. Потом отформатировать первый так-же как и сделал автор. В quick format. После этого у нас есть два одинаковых диска первые из которых с поврежденными блоками.
Теперь если мы сравним их поблочно - то мы знаем что было повреждено.
Миллион раз было в фейсбуке. Писал кому-то что-то умное. И потом скролл-скролл. И капец. Потом ничего не найти. Вобщем этот Цукер-букер сделал соц-сеть с альцгеймером. Я уже в себе стал сомневаться. А вдруг я реально НЕ ПИСАЛ.
ThunderCat, да. Обычно крупные проекты реализуют не одну а множество парадигм и множество точек зрения на разработку. У таких проектов такой длинный lifecycle (видел Java-код которому по 15-20 лет) что меняются архитекторы и изнутри, их код и документация являют собой лоскутное одеяло. Тоесть там - можно найти вообще ВСЁ.
