Lua C++ Swig Polymorphism

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
Swig-user mailing list
Swig-user <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/swig-user

Odd dueling types

I have a weirdness with SWIG that I need some help with from someone
smarter than me (hey William...nudge, nudge, wink, wink ;).  Please bear
with my while I explain...

I'm using SWIG 1.3.40, wrapping C++ to Python.

I have a template class called Vector that defines various types of
vectors (ints, doubles, etc.) and sizes.  The particular case I'm
looking at is:

    Vector<3, double>

This is typedef'd within the system as:

    typedef Vector<3, double>     Vector3d;

I have a transport class called Parameter, who has, among many other
constructors, one that takes this typedef:

    Parameter(const Vector3d& vec);

The typedef ends up defined correctly in the SWIG-generated output (as
"SWIGTYPE_p_Vector3d"), and this type is referenced only within the
SWIG-generated output such that it is transported internally where it
should be, but I cannot directly reference it within Python; e.g., the
following code wouldn't work, because Vector3d is not "exposed" to
Python as a defined type:

    v = Vector3d(1.4, 3.004, 0.343)

So, to actually have it defined within Python, I added a template
instantiation within my interface file:

    %template(Vector3d)     Vector<3, double>;

This then makes Vector3d a known type within Python, and I can create
them directly as I require.

HOWEVER...The %template instance of Vector3d has a different internal
type within the SWIG generated code than the typedef'd version.  The
%template'd version is defined as
"SWIGTYPE_p_LWSDK__VectorT_3_double_t", which appears to be causing
matching failure with regard to the Parameter constructor, when I do
something like this in Python:

    v = Vector3d(1.4, 3.004, 0.343)
    p = Parameter(v)

The "v" variable is of type "SWIGTYPE_p_LWSDK__VectorT_3_double_t", not
"SWIGTYPE_p_Vector3d", which causes the value to be treated as "void*"
(the fall-through).  The Parameter class has a "void*" constructor, but
it is there just to raise a run-time assert, because "void*" is
disallowed as a valid transport type.

SO...I need to have the Vector3d as a known type within Python, but I
need it to be handled by SWIG as the typedef'd type so it selects the
correct Parameter ctor.  Is this a mapping problem?  Would a %rename
solve the problem?  I'm really rather confused on this one, and would
appreciate any help.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: Odd dueling types

On Wed, 31 Mar 2010, Bob Hood wrote:

> This is typedef'd within the system as:
>
>    typedef Vector<3, double>     Vector3d;
...
> The "v" variable is of type "SWIGTYPE_p_LWSDK__VectorT_3_double_t", not
> "SWIGTYPE_p_Vector3d", which causes the value to be treated as "void*"
> (the fall-through).

I suspect that you're not feeding SWIG the typedef for Vector3d.  The 
%template does not eliminate the need for this.

Josh

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: Odd dueling types

On 3/31/2010 10:03 PM, Josh Cherry wrote:
>
>
> On Wed, 31 Mar 2010, Bob Hood wrote:
>
>> This is typedef'd within the system as:
>>
>>    typedef Vector<3, double>     Vector3d;
> ...
>> The "v" variable is of type "SWIGTYPE_p_LWSDK__VectorT_3_double_t", not
>> "SWIGTYPE_p_Vector3d", which causes the value to be treated as "void*"
>> (the fall-through).
>
> I suspect that you're not feeding SWIG the typedef for Vector3d.  The
> %template does not eliminate the need for this.

Thanks for the response, Josh.

The typedef is defined in a header called "Vector.h", and I include that
in the interface file, in both the #include and %include forms.  I
assumed this was enough, since "SWIGTYPE_p_Vector3d" is defined by its
inclusion.  Is there some kind of additional, explicit declaration that
I need to make in the interface file?

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: Odd dueling types

On 4/1/2010 11:10 AM, Bob Hood wrote:
> Thanks for the response, Josh.
> The typedef is defined in a header called "Vector.h", and I include that
> in the interface file, in both the #include and %include forms.  I
> assumed this was enough, since "SWIGTYPE_p_Vector3d" is defined by its
> inclusion.  Is there some kind of additional, explicit declaration that
> I need to make in the interface file?
>   

As it turns out, that's exactly what it needed.  Consolidating the types
required the addition of an explicit, SWIG-based typedef:

    typedef Vector<3, double> Vector3d;
    %template(Vector3d)  Vector<3, double>;

Apparently, the typedef in the C++ header was actually interfering!

After discovering this, I reviewed the template section of the SWIG
documents, but there's no mention that I could find of this requirement.

Thanks, Josh, for pointing me in the right direction.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Addressing implicit conversion

Recap: I'm wrapping C++ for Python using SWIG 1.3.40.  Again, bear with
me while I set this up...

I have a component factory that produces a type of ComponentReference. 
In C++, this code would like like:

    ComponentReference comp =
ComponentFactory::instance()->create("Circle");

I have this wrapped just fine, and it functions in Python like this:

    comp = ComponentFactory.instance().create(String("Circle"))

In the above two lines of code, you can actually see an example of what
I'm coming to:  Python (i.e., SWIG) must perform an explicit type
definition of the string literal (to type String()), where it is done
implicitly in the C++ code by the compiler, because create() has the
following signature:

    ComponentReference create(const String& component_type_id);

The component reference generated by the ComponentFactory is intended to
be passed to a global execute() function, with C++ code looking like the
following:

    ComponentReference comp =
ComponentFactory::instance()->create("Circle");
    ...
    ::execute(comp);

However, the signature of the execute() function looks like this:

    bool execute(const Component& comp);

In C++, this isn't a problem due to implicit type conversions, and the
ComponentReference executes just fine when passed to execute(). 
However, SWIG appears to do "literal" typing, such that execute() will
not match when called from Python, because it has no signature that
takes a ComponentReference:

    # comp is a 'ComponentReference'
    comp = ComponentFactory.instance().create(String("Circle"))
    # this call fails because it's expecting type 'Component'
    execute(comp)

Is there a way that I can tell SWIG that the 'ComponentReference' type
(internally, type "SWIGTYPE_p_ComponentReference") is type 'Component'
(internally, type "SWIGTYPE_p_Component") so that it will perform the
conversion of the arguments for execute()?  In other words, can I
manually "fake" the implicit conversion that C++ does for me automatically?

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

wrapper a function whose parameters are out type pointer to structure

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
Swig-user mailing list
Swig-user <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/swig-user

Re: SWIG_SHARED_PTR and "using boost::shared_ptr;"

On Sun, 30 Aug 2009 00:38:40 +0100 William S Fulton <wsf <at> fultondesigns.co.uk> wrote:

WSF> > Please consider this example:
WSF> > 
WSF> > 	%module example
WSF> > 
WSF> > 	%include "boost_shared_ptr.i"
WSF> > 
WSF> > 	SWIG_SHARED_PTR(Foo, Foo)
WSF> > 
WSF> > 	%inline %{
WSF> > 	#include <boost/shared_ptr.hpp>
WSF> > 	using boost::shared_ptr;
WSF> > 
WSF> > 	struct Foo
WSF> > 	{
WSF> > 	    shared_ptr<Foo> Get();
WSF> > 	};
WSF> > 	%}
WSF> > 
WSF> > SWIG compiles it (using -csharp) fine but the generated C++ code doesn't
WSF> > compile because it looks like this:
WSF> > 
WSF> > 	SWIGEXPORT void * SWIGSTDCALL CSharp_Foo_Get(void * jarg1) {
WSF> > 	  void * jresult ;
WSF> > 	  Foo *arg1 = (Foo *) 0 ;
WSF> > 	  boost::shared_ptr< Foo > *smartarg1 = 0 ;
WSF> > 	  SwigValueWrapper< shared_ptr< Foo > > result;
WSF> > 	  
WSF> > 	  
WSF> > 	  smartarg1 = (boost::shared_ptr<  Foo > *)jarg1;
WSF> > 	  arg1 = (Foo *)(smartarg1 ? smartarg1->get() : 0); 
WSF> > 	  result = (arg1)->Get();
WSF> > 	  jresult = result ? new shared_ptr< Foo >(result) : 0; 
WSF> > 	  return jresult;
WSF> > 	}
WSF> > 
WSF> > Notice the use of SwigValueWrapper: it is wrong because it can't be
WSF> > converted to bool and so using it in the ternary operator ?: in the one but
WSF> > last line fails.
...
WSF> Actually the behaviour is the same if you use shared_ptr as a return 
WSF> type or an input parameter. There does seem to be a bug here as SWIG 
WSF> doesn't fully use 'using shared_ptr;'. This is a general bug where this 
WSF> type of using statement is not used by SWIG for templates of 
WSF> non-primitive types. Until this is fixed,

 Hello again,

 I've just tested this example with SWIG from svn (r11961) and it still
fails in the same way so I decided to try to see if I could do something
myself to help fixing it. I hope the information below might be at least
somehow useful for this.

WSF> consider the following workarounds:
WSF> 
WSF> 1) Add the following into the SwigValueWrapper template in swig.swg:
WSF> 
WSF>    operator bool() const { return *pointer.ptr; }
WSF> 
WSF> 2) Modify the typemaps in Lib/csharp/boost_shared_ptr.i to not rely on 
WSF> the implicit operator bool(), by making a call to shared_ptr::get() 
WSF> instead, so that the null/non-null check is done on the underlying pointer.

 I don't like neither of those because SwigValueWrapper really shouldn't be
used at all here in the first place. Unfortunately I still can't understand
what exactly makes SWIG to decide to use it in the first place. I see that
in the example above SwigType_alttype() is called for both boost::shared_ptr
and just shared_ptr (i.e. "t" is "p.boost::shared_ptr<(Foo)>" or just
"shared_ptr<(Foo)>" on entry). However for the former it's always called
with local_tmap==1 so, because value_wrapper_mode==0, it always returns 0.
For the latter however it is called with local_tmap==0 which prevents it
from returning 0 immediately. Instead it calls SwigType_isclass() which
returns true. Then it tries to look up the corresponding(?) node with
Swig_symbol_clookup() and this returns NULL. And hence, because later on
SwigType_issimple() && SwigType_istemplate() both return true as well for
"shared_ptr<(Foo)>", the function returns 1 and the wrapper is generated.
Something is wrong here but I don't even know at which step. The last one
seems right, i.e. the type is simple and is a template. So it must be
something before but what? Should Swig_symbol_clookup() succeed for this
type? Or should SwigType_isclass() fail for it?

 I suspect it should be the latter because it does return false for
boost::shared_ptr<> (if I hack the code to remove local_tmap check) but I'd
like to have a confirmation of this before I dive further into this code
and try to fix it. Also, if anybody has a better explanation of what SWIG
considers to be a class than "A class is defined by its type-table entry
maps to itself", it'd be great. More generally, any pointers in the right
direction would be much appreciated.

 Thanks,
VZ

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
Swig-user mailing list
Swig-user <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/swig-user

hiding base classes?

 Hello,

 In some cases a base class is used in C++ code mostly or maybe even
uniquely as a way to avoid code duplication and it doesn't really make
sense to expose it via SWIG. However I still need to expose the methods
defined in this base class as part of all the derived classes. I.e. I'd
like to pretend, for the purpose of wrappers generation, that the base
class doesn't exist but still provide the same API for the derived class as
in C++.

 I tried %importing (instead of %including) the header defining the base
class and then %ignoring it but this didn't work and I can't think of
anything else to try. So is this just impossible to do with SWIG or am I
missing some trick here?

 Thanks in advance,
VZ

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
Swig-user mailing list
Swig-user <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/swig-user

Lua Cpp Swig - Smart Pointers to Nil Check

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
Swig-user mailing list
Swig-user <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/swig-user