OberonCore

Опыт показывает, что подобное утверждение каждый раз нуждается в отдельном доказательстве. Увы.

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

Если задача изначально заточена на рукосуйство, то и инструмент она требует соответствующий, рукосуйский.
Вот и всё.

Немного доработал ваш код.UPD: Исправил опечатку в комментарии.

XOR --- это симметрическая разность множеств /. Она есть везде, начиная с Оберона. В общем, без комментариев.

XOR для логических выражений есть: #.

Спасибо. Я страшный тормоз.
Следовательно мой код превращается в такое:

XOR это не симметрическая разность множеств.

{0} XOR {0} тоже = {}

XOR любых двух одинаковых значений даёт {}, сиречь 0000...

1 XOR 1 = 0
1 XOR 1 = 0FFFFFFFEH
Где правильно?

Да, похоже я не прав.

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

Если представить себе LONGINT как массив булевых значений. Т.е. мы имеем операцию индексации (пусть она будет {} ), а над значениями допустимы все логические операции, тогда весь код свелся бы к такому:

Что, IMHO, ясно и понятно.

Какие вы видите минусы у подобного подхода?

Вы считаете, что код или однозначно говорит, что решена задача viewtopic.php?p=55228#p55228 Хехе... А, по-моему, он просто короткий. И без комментариев (постановки задачи) хрен поймешь, что-либо сверх того, что автор решил заксорить первый бит с нулевым.

Там хотя бы это понятно сразу. Т.е. что именно что ксорят первый с нулевым. Т.е. ясно КАК, но не ясно ПОЧЕМУ. Это уже много лучше нежели не ясно как и не ясно почему.

Алексей, сказать честно, мне думается, что нужен иной базовый тип BIT, отличающийся от BOOLEAN своей НЕ ленивостью в логических операциях. Хотя, надо еще подумать, конечно же...
Причем, введенный на уровне АСТ (еще до аппаратно-зависимой части). Вот я же не просто смотрю, на написанную Евгением формулу под эпиграфом "я бы предположил, что в такие". Пытаюсь понять почему. Все правильно - именно в такие, если минимальный_размер_данных=много_битов, а тип BOOLEAN - только заготовка для условных переходов... Посмотрите - мой код на АСМе значительно больше походит на исходную формулу с битами, чем на то, во что ее превратит компилятор в АСТ

Илья Евгеньевич, специально к Вам вопрос: Вам же нравилась синтаксическая конструкция slice из Go (кажется...)

Мне представляется, что предложенный Алексеем SUBSET имеет slice в качестве наименьшего общего кратного. Не только для битовых массивов, но и для остальных - тоже.
Мне даже больше кажется - ссылочные переменные тоже этим slice-ом могли бы обобщиться
Ну посмотрите на какой-нибудь (сейчас под рукой нет) search из AD - в качестве VAR-переменной подставляется node.right - типичный "кусочек" записи node. И это эффективно срабатывает - алгоритму пофиг какой "кусочек" подставляли... хучь правый, хучь левый.
А дальше, внутри процедуры - от этой эффективности уже и след простыл, несколько раз один и тот же код переписывается. Только потому, что ссылочных переменных явно нет (но они на самом-то деле есть, но только как аргументы процедуры)

Илья, расскажите свои мысли про slice, ну и отношение к возможности его обобщения.

КАК без ПОЧЕМУ не "много лучше", а почти также плохо.

Как автор скажу: мне хочется, чтобы коллеги по работе, читающие мой код - поняли именно это.
Да и самому не хочется через пару лет в репе чесать: "чего я там какие-то множества сортировал..."

Не ну порог вхождения в тему всегда есть... Ну как же без этого.
Посмотрите на вставку в какое-нибудь RB-дерево - нифига ведь непонятно. Без букварей-то.
И это не есть плохо. Потому-что буквари читать надо.

Ну, моя мысль и практика простая - использовать интерфейс, подобный блэкбоксовому Files.File, для работы с любой двоичной памятью, независимо от её типа. В сочетании с процедурами, примеры которых я приводил здесь: viewtopic.php?f=2&t=2006

Это исключительно библиотечное решение. Это безопасное решение (невозможно испортить память помимо самого двоичного региона, с которым работаем). Это решение позволяет не импортировать SYSTEM практически нигде. Немного подумав, можно решить всё, что требуется по работе с двоичной памятью.

Это не для случая микроконтроллерной встроенки. Это для обычного системного и серверного ПО. Когда библиотечность решения даёт мизер накладных расходов по сравнению с латентностью ввода-вывода и проч.

К slice я не выказывал никаких эмоций, я просто выразил "узнавание": ага, ребята решают ту же проблему (безопасная работа с двоичной памятью), для той же ниши (серверное ПО), похожим путём, впаивая в язык похожие штуки.
Но у меня рулят КП+библиотеки

А кстати, почему чтобы работать с LONGINT как с SET я обязан импортировать SYSTEM? Где тут опасность?

Да нет, не обязаны!
Но чтобы разные структуры сериализовать в/из байт, обычно приходится.

Как так не обязан? А как мне из LONGINT сделать SET? Ведь к LONGINT не применымы SET-операции.

Я так понимаю, вы сами себе ответили? Или нужно ещё подробнее про строгую типизацию?