Feature #378

Feature #593: Support generic filters

provide omlc?_get()/omlc?_set() function which takes the data type as one argument

Added by Olivier Mehani over 1 year ago. Updated 4 months ago.

Status:New Start date:02/09/2010
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:-
Target version:2.8.0

Description

This need is caused by the need to write generic filters, but there may be other situations when this could be useful too.

A filter with an output schema definition of OML_INPUT_TYPE will determine the actual type at run time depending on which MP is connected to the instance.

Then, it is not possible to hard code the omlc_get_*() calls in the sample() function, nor the omlc_set_*() in the process() one.

This problem could be solved by a pair of functions such as

FIXME_t /* see comment */
omlc_set(OmlValue* value, int val, OmlValueT type) {
  swicth(type) {
  case OML_INT64_TYPE:
    return omlc_set_int64(value, val);
  ...
  }
}

FIXME_t /* see comment */
omlc_get(OmlValue* value, OmlValueT type) {
  swicth(type) {
  case OML_INT64_TYPE:
    return omlc_get_int64(value);
  ...
  }
}

I'm not sure how to handle the return type of both functions, though, as they may vary depending on the value of argument type (hence the FIXMEs).

Some pre-processor macro may be better suited than an actual function:

#define omlc_set(value, type, val)   (omlc_set_ ##type(value, val))
#define omlc_get(value, type)   (omlc_get_ ##type(value))

The problem being that type in the argument will be an OmlValueT whereas the omlc_set_* function have stdint names.

I suppose an additional hack like what follows could settle everything, but I don't find it particularly elegant.

#define omlc_set_OML_INT64_TYPE(value, val) omlc_set_int64(value, val)
#define omlc_get_OML_INT64_TYPE(value) omlc_get_int64(value)
/* ... for all types ... */

Related issues

related to Feature #516: Add more type testing macros/functions to public interfac... New 03/03/2011

History

#1
Updated by Olivier Mehani over 1 year ago

s/TYPE/VALUE/g for the type names... I should have double checked...

#2
Updated by Jolyon White 11 months ago

I don't think the pre-processor token pasting hacks will work because by the time the values get to the filter you'll be dealing with enums (i.e. integers) rather than the symbols themselves. I can see some value in adding some getter functions, but in the filter you have to decide what to do for each type, unless you use a function like oml_value_to_double(). This means an exhaustive switch statement, so there's no value gained by having a single omlc_get() function as per your first suggestion, even if you could get around the return type issue.

Your omlc_set() function should return void, and don't forget that the val parameter needs to have a C type appropriate to the type parameter. This suggests a variadic function.

#3
Updated by Jolyon White 11 months ago

Summary of discussion with Olivier:

The use case motivating this involves a filter that potentially changes its behaviour based on the type of its input; this means that the filter functions must either use conversion or type promotion routines like omlc_value_copy() and oml_value_to_double(), or they must have some sort of switch statement that selects a behaviour based on the type. In this case, it doesn't make sense to duplicate the switch statement in the value getter routine, as the caller will already know the type. Therefore, the solution to the use case should involve adding getter functions for each OML type, and various helper routines in the same vein as omlc_is_integer(), omlc_is_numeric(), etc.

See #516.

#4
Updated by Thierry Rakotoarivelo 4 months ago

  • Target version set to 2.8.0

#5
Updated by Thierry Rakotoarivelo 4 months ago

  • Parent task set to #593

Also available in: Atom PDF