практически всегда С++ сам сделает все необходимое при обычном сравнении одного типа с другим. я понять не могу: зачем может понадобиться делать это "врукопашную"?

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

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

ели бы автору нужно было сравнивать одинаковые заранее неизвестные типы, я бы посоветовал использовать union, и то это годится только для равно/не равно, если смотреть широко. Ну а если решать то что хочет конкретно автор - советую читать паттерны, в частности паттерн фабрика.
Я так делал у себя для определения некоего универсального поля. Потом наследовал через ряд различных классов, в каждом случае переопределял метод.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Все так, только у ТС данные в виде 4-х байтового массива, а как интерпретировать эти 4 байта определяется значением enum-а в отдельной переменной.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

А пользователь с поздним связыванием к объекту приходит или в compile time?

уже в runtime будет определяться что и с чем сравнивать. для ясности дам такой пример. есть, к примеру, датчик освещенности. пользователь хочет автоматически управлять освещением. он в неком конфигураторе к объекту "датчик освещенности" подключает объект "сравнение", а к нему объект "реле". на один "вход" объекта "сравнение" теперь подается информация с датчика, а на второй пользователь хочет зацепить свой источник. только одному ему известно какой. этой может быть вход АЦП (целое), а может результат какого-то вычисления (дробное). объекту "сравнение" будут указаны типы аргументов из перечня. его задача правильно сравнить данные по указанному типу. ну а сами данные всегда лежат в одном и том же месте памяти.

В любом случае, без явных приведений не обойтись. А это if-ы, либо switch-case.
Ну и так как сравнивать нужно по-любому однотипные данные, значит приводим их к одному типу.

вот-вот

тема называется "C++ сравнение данных с заранее неизвестными типами", а не С. А Вы лезете со своими ифами...
RealHann читаем о виртуальных классах, методах, читаем паттерны и тогда прийдет понимание как это все элегантно построить через указатели на материнский класс и динамическое выделение памяти.

давайте вместо кучи нравоучений вы тут продемонстрируете, как это будет элегантно, конкретным кодом? а то на словах все Львы Толстые...

Не буду я за автора что-то решать - у меня была своя похожая задача где требовалось унифицировать поля которые я выводил на ЖК.
Если ему хочется плюсов, то я бы это делал так.
Я бы определил три вида абстрактных классов - входной, передающий/преобразующий, выходной. На основе материнского класса определяем всех возможных наследников.
Для входных - разные каналы ввода (цыфрове, аналоговые, булевые...). Для выходных и передающих аналогично.
Ну и вот имеем передающий класс, внутри содержащий указатели на объекты ввода, виртуальный метод преобразования, и указатель на выходной класс. Метод преобразования, по указателю смотрит что там за идентификаторы и вызывает соответствующий метод/преобразования. Ну да, без ифов не обойтись .
Вообще топикстартер изобретает велосипед - среду визуального программирования, причем хочет упростить задачу - изобретаем устройства для умного дома? Чтобы юзер мог сам конфигурировать систему? Я с подобным работал когда-то (Альфа от Микрола) - насколько я помню, если выход дает флоат, то его невозможно было подключить к интовому входу. Надо было ставить блок приведения.
Есть у ОВЕНа программируемые реле и к ним среда OWENLogic. По моему там тоже надо приводить типы, иначе не "скомпилится".

вот с этого надо было и начинать, а не с "лезете со своими ифами...". это во-первых.
а во-вторых, даже описание того, что вы рекомендуете, заняло больше места, чем мой вариант (отлично работающий на С++), а реально это было бы килобайта 3 кода. очень элегантно, слов нет.

ну извините за ифы.
Так топикстартеру нужно динамическое конфигурирование структуры данных. Я говорю о том, что размах проблемы намного шире, чем он себе представляет. Сейчас ему надо просто сравнивать. А завтра он захочет пропорциональны регулятор поставить. А послезавтра импульсный пид регулятор (для регулировки подогрева пола, например).
С хорош для решения простых задач. Когда задача разростается и усложняется - Вы запутаетесь в коде. Как по мне лучше сразу забить половину флеша объектным кодом, зато получить задел на будущее.

Может всё-таки variant как универсальный тип данных обмена между всеми участниками экосистемы? Т.е. у каждого модуля как ны выходе так и на входе универсальный variant - а сами объекты типа variant уже сами разбираются кто из них "круче".

прямо-таки напрашивается сравнение числа 1E-99 cо строкой "ваще нихрена!"

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

вообще-то я пытался намекнутть, что:
- во-первых, variant далеко не панацея
- во-вторых (и в главных!) автор топика слишком перемудрил с вариантами сравнения.

для системы, которая в run-time решает, что с чем сравнивать, необходимо и достаточно привести все варианты к наиболее подходящему одному, ведь очевидно, что сравнивать разные по смыслу данные, например, СИМВОЛ или СТРОКУ с ЧИСЛОМ - это бессмыслица. сравнивать можно строку со строкой, символ с символом, а число с числом, то есть данные одинаковых смыслов, а значит, и типов.
ну а для чисел нет смысла применять разные типы, т.к. float покроет любой практический диапазон. в результате нет никаких "загадочных" преобразований, все прозрачно и естественно, сравниваются всегда однотипные данные, всегда известно, какие именно типы. нет проблемы.

на этом я пока и остановился. привел все к double

Символ легко можно сравнивать с числом.