[C++-sig] Re: Interchanging SWIG & Boost bindings.

[Jacek Generowicz]

David Abrahams <dave at boost-consulting.com> writes:

> Jacek Generowicz <jacek.generowicz at cern.ch> writes:
> 
> > The first is that the Boost and SWIG wrappings do not recognize that
> > they are actually wrapping the _same_ underlying C++ class. Would it
> > be possible to make a Boost-wrapped foo look sufficiently like a
> > SWIG-wrapped foo, in order for the SWIG-wrapped bar.baz to accept it
> > as an argument, and to know how to access the underlying C++ object
> 
> You've got to ask the SWIG guys about that part.

SWIG guys ... I'm asking y'all !  :-)

(Yes, I'll approach the SWIG list directly, if there is no response here.)

> > (and vice versa)? 
> 
> Yes, the vice versa one we can cover.  You just need to register an
> appropriate lvalue from-Python converter.
> 
> > I'm thinking along the lines of some converter utility which takes
> > Boost/SWIG-wrapped objects and transforms them into ones which look
> > like SWIG/Boost-wrapped ones, _without_ need to re-create the
> > original bindings.
> 
> That sentence is meaningless to me, sorry.  What's the difference
> between a Boost/SWIG-wrapped object and a SWIG/Boost-wrapped one?

Apologies. It's a shorthand which turns out to be useless :-) I meant:

  ... some converter utility which takes Boost wrapped objects and
  transforms them into ones which look like SWIG wrapped ones, and
  vice versa ...

> What does "re-create the original bindings" mean?

It means, to modify the configuration files (be it SWIG .i files, or
the C++ source files which contain boost::python "instructions"), and
rebuild the Python extension module.

> > However, if we can offer the response "Just convert your histogram
> > with the function Boost_to_SWIG before you pass it in"
> 
> Unlikely to be possible in that direction, unfortunately (though I'm
> not familiar with SWIG internals).  SWIG_to_Boost is not really
> possible as a Python function either, at least, not without
> additional arguments.

And the extra arguments are unlikely to be obvious to your average
end-user, I guess ?

> > (or, better still, prevent the situation from arising in the first
> > place)
> 
> That one seems more likely to be plausible.

Would it be based on the principle of "Thou shalt create thy Boost and
SWIG bindings according to these guidelines"? or do you imagine it
would be possible to provide some means of automatically making
existing modules conformant?

> > Do you foresee any show-stopping problems?
> 
> Only the obvious one: we have two really big somewhat independent
> projects already

Actually, _we_ have three projects: we have a "dictionary" package,
which fakes-up introspection capablilities in C++, by parsing header
files with GCC-XML; via a Python binding to the dictionary we can give
Python users access to any C++ objects for which they generate the
dictionary. It may not give you the prettiest interface, but you get
it almost for free, so it serves a purpose. We'd need this to
inteproperate with the other two, but as it is relatively young, we
have a fair amount of freedom to adapt it to the demands of Boost and
SWIG.