C++ сравнение данных с заранее неизвестными типами

[ARV]

если у меня 7 возможных типов, то 49 if-ов выглядят тупо. c A>B

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

[Аlex]

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

[ARV]

Если речь идёт о пользовательских типах

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

RealHann писал(а):

Код:

enum _cmp_type_e {
  _cmp_char =   'C',
  _cmp_ushort = 'U',
  _cmp_short =  'S',
  _cmp_uint =   'T',
  _cmp_int =    'I',
  _cmp_float =  'F'
};

[Ярослав555]

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

Последний раз редактировалось Ярослав555 Вт фев 20, 2018 14:21:06, всего редактировалось 1 раз.

[AndyBig]

ARV писал(а):

вся беда в том, что у топикстартера стандартные типы

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

[Siarzhuk]

RealHann писал(а):

это один из виртуальных объектов общего конструктора. выполняет задачу сравнения. чего с чем неизвестно, пока этого не укажет пользователь в конфигураторе. у объекта два "входа" для аргументов, управление типами этими аргументами и "выход" < = >

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

[RealHann]

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

[Аlex]

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

[ARV]

Ну и так как сравнивать нужно по-любому однотипные данные, значит приводим их к одному типу.

вот-вот

Код:

typedef enum _cmp_type_e {
  _cmp_char =   'C',
  _cmp_ushort = 'U',
  _cmp_short =  'S',
  _cmp_uint =   'T',
  _cmp_int =    'I',
  _cmp_float =  'F'
} cmp_t;

typedef struct{
   cmp_t type;
   uint8_t data[4];
} data_t;

float normalize(data_t *data){
   switch(data->type){
      case _cmp_char: return *(char*)data->data;
      case _cmp_ushort: return *(unsigned short *)data->data;
      ...
   }
}

int compare_data(data_t *data1, data_t *data2){
   if(normalize(data1) > normalize(data2))
      return 1;
   else if(normalize(data1) < normalize(data2))
      return -1;
   else return 0;
}

[Ярослав555]

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

[ARV]

как это все элегантно построить

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

[Ярослав555]

ARV писал(а):

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

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

[ARV]

Ну да, без ифов не обойтись

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

[Ярослав555]

ARV писал(а):

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

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

[Siarzhuk]

RealHann писал(а):

уже в runtime будет определяться что и с чем сравнивать

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

[ARV]

Может всё-таки variant как универсальный тип данных обмена между всеми участниками экосистемы?

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

[Siarzhuk]

ARV писал(а):

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

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

[ARV]

Да и наличие в экосистеме акторов умеющих использовать лексический генератор таки преполагает

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

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

[RealHann]

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

[AndyBig]

сравнивать можно строку со строкой, символ с символом, а число с числом

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