[cable] Overload resolution and Matlab wrappers

[gareth.jones at stud.man.ac.uk]

I have been doing some work on CABLE to allow it to create wrappers
for Matlab as well as Tcl and to extend the overload resolution so
that it follows the C++ standard more closely.  To do this I altered
CableTclFacility to seperate the Tcl specific bits and the more
general bits and created CableInterpFacility which is interpreter
agnostic and CableTclFacility and CableMatlabFacility which
encapsulate the interpreter specific functionality.  I also changed
the generators, creating a CableInterpGenerator which is a sub-class
of CableGenerator and a super-class of CableTclGenerator and
CableMatlabGenerator.  I don't really understand the purpose of
CableGenerator, and I'm not very happy with what I've done here: it
all works but the interaction of the classes might be a little unclear
to other people.

The overload resolution works for implicit conversion sequences, but
is not necessarily correct for user defined conversion sequences.  I
might do some more work on this but I think a partial solution is
still useful.  The implementation of the overload resolution is a
little naïve but fairly clear (implemented more or less verbatim from
the standard).  Some cases can't be done (easily) such as wchar_t and
enum promotions (4.5) because there's no way (that I can see) to
discover the underlying type.  It may be possible to do something with
compilor specific #ifdef's if this was important.

To take account of the additional uncertainty inherent in the
conversion from interpreter data types to C++ types I added an extra
condition to the selection of viable functions to choose `better'
conversions.  I have tried to keep the old Tcl behaviour as far as
possible so that if there are methods f(int, double) and f(int,
double*) then

$object f 2 3.0

will still call f(int, double) because f(int, double*) is not
considered a viable function.  If f(int, double) did not exist (nor
f(double, long), f(float, double) etc.) then f(int, double*) would be
a viable function (as would f(int, int*) which may not be desirable).
In Matlab's case

f(object, int32(2), 3)

is considered ambiguous because Matlab makes no real distinction
between scalars and vectors and so both double and double* have equal
goodness.  But

f(object, int32(2), [2 3])

unambiguously refers to f(int, double*).  The goodness of various
conversions can be changed without too much difficulty (at compile
time at the moment but if it could be run time if it were really
necessary).

Matlab uses reference counting internally but doesn't expose it at the
API.  I've used Peter Boettcher's description of the mxArray_tag
structure to do garbage collection.  This is a compile-time option,
without it one has to explicitly destroy CxxObjects to avoid memory
leaks.

Do you think these changes would be of general use?  The diff is 200Kb
gzipped so I'm not sure if it would be reasonable to post it here.

Many thanks to whoever designed and wrote CABLE; it is an impressive
piece of work.

-- 
Gareth Jones <gareth.jones at stud.man.ac.uk>
Imaging Science and Biomedical Engineering
University of Manchester