Hack to use the std::array support for boost::array.
Is limited as it currently exposes some 'using' bugs in SWIG.
For example, the type system fails to see that pointers to std::array
and pointers to boost::array are the same.
This approach saves having to maintain separate boost::array support.
The 'using' bug ought to be fixed, otherwise separate boost_array.i
files could be easily made from the std_array.i files.
These work much like any of the other STL containers except Python slicing
is somewhat limited because the array is a fixed size. Only slices of
the full size are supported.
Hi
Would it be possible to add the following 2 typedefs to std_ios.i?
typedef basic_ios<char> ios;
typedef basic_ios<wchar_t> wios;
at present, it contains only
%template(ios) basic_ios<char>;
%template(wios) basic_ios<wchar_t>;
This means however that things like std::ios::openmode are currently not
recognised by SWIG. With the above typedefs, they are. Similar typedefs
should probably be added in std_iostream.i for ostream etc.
Also, while checking std_ios.i, it seems that the definition of basic_ios
has a copy-paste error in the private section (the constructor is still as
ios_base). To avoid confusion, I suggest to change that. Below is a diff
with the suggested changes.
Kris
Generated code does not include <string>, which is referenced in templates.
Clang may be incorrectly or aggresively instantiating some template.
E.g.,
import_stl_b_wrap.cxx:3199:51: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>
The erase and insert methods in the containers use const_iterator instead
of iterator in C++11. There are times when the methods wrapped must match
the parameters exactly. Specifically when full type information for
template types is missing or SWIG fails to look up the type correctly,
for example:
%include <std_vector.i>
typedef float Real;
%template(RealVector) std::vector<Real>;
SWIG does not find std::vector<Real>::iterator because %template using
typedefs does not always work and so SWIG doesn't know if the type is
copyable and so uses SwigValueWrapper<iterator> which does
not support conversion to another type (const_iterator). This resulted
in compilation errors when using the C++11 version of the containers.
Closes#73
on STL classes to "is_empty()" (previously this was automatically
renamed to "c_empty()").
*** POTENTIAL INCOMPATIBILITY ***
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@11772 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This change does not break backwards compatability
with python, so all works.
The python stuff, however, will still not do all
that ruby can now do.
Updated manual to reflect the change and improve
typemap documentation on the ruby side.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@9787 626c5289-ae23-0410-ae9c-e8d60b6d4f22
and moved it to python/std_common.i
Consolidated ruby code to use std/std_common.i
Added missing include to rubystdfunctors.swg
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@9781 626c5289-ae23-0410-ae9c-e8d60b6d4f22
containers that can use one.
Created file rubystdfunctors.swg to allow passing in
Ruby procs as functors to STL functions (swig-user list
suggestion for Python).
Fixed a bug in type_info() always failing for std::set.
Fixed a bug in type_info() always accepting any failed
conversion which could lead to overloaded functions to
fail when input wrong parameters.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@9775 626c5289-ae23-0410-ae9c-e8d60b6d4f22
of const correctness in the std swig STL library.
Need to bring it up in the swig-devel list.
Added new functions to swig_assert.
Changed some tests to reflect these changes.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@9730 626c5289-ae23-0410-ae9c-e8d60b6d4f22
