[Swig-devel] [ swig-Bugs-1864275 ] stl.i PySequence_Cont uses assign(...) incorrectly

[SourceForge.net <no...@so...>]

Bugs item #1864275, was opened at 2008-01-05 00:05
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1864275&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: python
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Scott (ses4j)
Assigned to: Nobody/Anonymous (nobody)
Summary: stl.i PySequence_Cont uses assign(...) incorrectly

Initial Comment:
In pycontainer.swg (about line 680) in the fragment StdSequenceTraits, there is an issue/bug that causes problems when SWIGging some complicated types.

fragment StdSequenceTraits has the line seq->assign(pyseq.begin(), pyseq.end()).  I recommend not using assign ever and using the SWIG_STD_NOASSIGN_STL part always instead, and changing the insert() call to:

seq->insert(seq->end(), (value_type) ((*it).operator value_type()));

instead.

This will explicitly call the PySequence_Ref generated conversion operator PySequence_Ref<T>::operator T(), rather than the old way, which hoped C++ would call that operator implicitly (which it won't always do... read on).  

I ran into trouble while attempting to create a SWIG wrapper for boost::optional<T>.  It worked well until we created a std::vector< boost::optional< int > > and tried to SWIG that.  It failed to compile because the assign() finally tried to implicitly convert from int to PySequence_Ref<boost::optional<int> >.  This takes two implicit conversions and so the compiler choked.  Explicitly calling PySequence_Ref::operator T() forced the PySequence_Ref to spit out the T (not a fake pretend-reference-wrapper-of-T), and made the compiler's job much easier.

I saw this in SWIG 1.3.31 and 1.3.32 for Python, on Windows using MSVC 2003.  Probably affects all Python, all C++ compilers, when using std::vector<> of any type that has a very soft, flexible constructor (like boost::optional<>).


----------------------------------------------------------------------

>Comment By: William Fulton (wsfulton)
Date: 2008-01-12 23:13

Message:
Logged In: YES 
user_id=242951
Originator: NO

Could you put together a small template class simulating the feature of
boost::optional so that we can use it as a test case? Then I can try out
your suggested fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1864275&group_id=1645