[cable] passing number &'s to method

[Brad King]

Steve,

> I'm trying my first Cable project and I hope this is an easy question for
> you: in Tcl, how can I pass the second argument to the following method?
> 
> 	OFCondition findAndGetSint16(const DcmTagKey&, short&)
> 
> The OFCondition and DcmTagKey classes are wrapped up and working nicely,
> and I can call a similar method to get a string type... but I don't know
> what to do about the basic types (I also need int, float, double, etc but
> I assume they'll all fit the same pattern).
> 
> Background: I'm trying to wrap the DCMTK tools from University of
> Oldenberg - a very nice dicom implementation you can find at
> http://dicom.offis.de.  I plan to try hooking up their code into vtk/itk
> at the tcl level.  So far CMake and Cable have worked great (until I hit
> this question).

Since the second argument is a reference type, a Tcl variable cannot be
passed directly to it.  The reason is that after the call is made, there
is no way for the wrappers to know where to place the value for Tcl to
find.  You will need to implement a wrapper in C++ to provide the value to
you without a reference.  If you have a C++ method return a short& type,
then it will pass the second argument without a problem.

For example:

template <typename T>
class ReferencePasser
{
  T n;
public:
  ReferencePasser(): n(0) {}
  ReferencePasser(T i): n(i) {}
  T& Pass() { return n; }
  T Get() const { return n; }
  void Set(T i) { n = i; }
};

Wrapping "ReferencePasser<short>" as ReferencePasser_short will allow the
following in Tcl:

# Wrap the findAndGetSint16 method of foo.
proc FindAndGetSint16 { foo key result } {
  upvar $result res
  set srp [ReferencePasser_short 0]
  set val [$foo findAndGetSint16 $key [$srp Pass]]
  set res [$srp Get]
  return $val
}

This assumes that "foo" is an instance of a class with a findAndGetSint16
method.  If findAndGetSint16 is a namespace-level function, I would
suggest writing a class that wraps all such functions and hides these
details.  Cable doesn't deal with namespace-level functions very well
right now, and an upcoming re-write (currently in a cvs branch) will not
support them at all for a while.  Both versions deal with static methods
in a class with no trouble, though.

I know that the above is very, very ugly, and I wish I had a better
solution right now.  This problem is on my wish-list of things to fix in
the future.

-Brad