[OSC_dev] advice for callback (oscit)

[Jamie Bullock]

On Fri, 2008-12-26 at 17:43 +0100, Gaspard Bucher wrote:
> Hi list !
> 
> I started extracting the library from rubyk but I jump on a difficult
> problem: in rubyk all values passed between objects and used in OSC
> calls are sub-classes of Value (a smart pointer with reference
> counting). This means every function has the type:
> 
> const Value method_name (const Value& param)
> 
> A "Value" can be a Number, a Hash, a Matrix, a String or just Nil
> (Array coming soon).
> 
> All this is fine in a C++ environment but I do not see how we could
> easily use the "value" stuff in a plain C interface.
> 
> ========= oscit C interface ========
> 
> The values will be replaced by an array of union [float / int / string
> / xxx]. So the signature of registering methods will be (C interface)
> :
> 
> void my_function(OscVal * ret, const OscVal * arg)
> 
> You register the function with something like:
> 
> register_method("/some/url", my_function, "ffi")
> 
> Inside "my_function", values are simply retrieved with:
> 
> arg[0]->f = float
> arg[1]->i = int
> etc.
> 
> Type checking is done by "oscit", 

Sorry to be pedantic, but could we refer to the protocol a 'oscit' and
the the implementation as 'liboscit'? Otherwise I can see people quickly
becoming confused.

> the only verification should be (arg
> == NULL) because methods can either receive the correct signature or
> Nil.
> 
> The storage space for return values is also prepared and the function
> should just write:
> 
> ret[0]->f = ...
> ret[1]->i = ...
> etc
> 
> This setting has the following advantages:
> 
> 1. fast to parse
> 2. no dynamic memory allocation during runtime (done once on
> registration for "ret" and "arg")
> 
> The drawbacks are:
> 
> 1. fixed type signature
> 2. same type signature for argument and return value

You could overcome this by wrapping the union in a struct which holds a
'type identifier' for the Value. For a small computational efficiency
cost, you get get a relatively large gain in flexibility and
maintainability:

typedef enum OscType_ {
	FLOAT,
	INT,
	DOUBLE,
	STRING
} OscType

typedef struct Value_ {
	OscType type;
	union ctype_ {
		char *s;
		float f;
                double d;
                int i;
                void *r;
        } ctype;
} Value;

> Does this seem ok for the "C" users out there ?

I'm fine with your original suggestion, it's simple and efficient, but I
thought i'd suggest the above as a possible alternative.

Jamie

-- 
www.postlude.co.uk
http://www.linkedin.com/in/jamiebullock