Add the macros
%typemap_asfromcheck()
%typemap_asfrom()
that can be used to defined all the different typemaps
for types where the As/From/Check methods are provided.
All the basic type (int, char,...) typemaps are implemented
using them.
The std::string and std::complex<T> are reimplemented using
the new %typemap_asfrom/check macros too. This helps to complete
all the previously missing typemaps (consttab, varin, varout,..)
and also ilustrates how to define the As/From/Check methods
to use with the %typemap_asfrom/check macros.
As a byproduct, the C complex typemap was added, and the file
complex.i
can be used to load the complex support for either C or C++. The
original C++ std_complex.i is still there, and the corresponding C
ccomplex.i too, if they need to be included explicitly.
Also, the As/From methods are declared via %fragment, so, they
can be reused as needed, and only appear in the wrapped code if
they corresponding typemap is invoked, making the typemaps
and the entire code shorter and simpler.
Marcelo.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@5691 626c5289-ae23-0410-ae9c-e8d60b6d4f22
Add the macros
%typemap_asfromcheck()
%typemap_asfrom()
that can be used to defined all the different typemaps
for types where the As/From/Check methods are provided.
All the basic type (int, char,...) typemaps are implemented
using them.
The std::string and std::complex<T> are reimplemented using
the new %typemap_asfrom/check macros too. This helps to complete
all the previously missing typemaps (consttab, varin, varout,..)
and also ilustrates how to define the As/From/Check methods
to use with the %typemap_asfrom/check macros.
As a byproduct, the C complex typemap was added, and the file
complex.i
can be used to load the complex support for either C or C++. The
original C++ std_complex.i is still there, and the corresponding C
ccomplex.i too, if they need to be included explicitly.
Also, the As/From methods are declared via %fragment, so, they
can be reused as needed, and only appear in the wrapped code if
they corresponding typemap is invoked, making the typemaps
and the entire code shorter and simpler.
Marcelo.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5691 626c5289-ae23-0410-ae9c-e8d60b6d4f22
%fragment("Hello","header") "..."
%fragment("Hi","header",fragment="Hello") "..."
the latter fragment will include the first one if is invoked.
more than one fragment can be included at the time, just
keep adding fragment="f1",fragment="f2", etc.
this is used to emulate typemaps reuse, where all the
reusable typemap code is put in a fragment static method,
and then it can be included from another fragment typemap
as needed.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@5690 626c5289-ae23-0410-ae9c-e8d60b6d4f22
%fragment("Hello","header") "..."
%fragment("Hi","header",fragment="Hello") "..."
the latter fragment will include the first one if is invoked.
more than one fragment can be included at the time, just
keep adding fragment="f1",fragment="f2", etc.
this is used to emulate typemaps reuse, where all the
reusable typemap code is put in a fragment static method,
and then it can be included from another fragment typemap
as needed.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5690 626c5289-ae23-0410-ae9c-e8d60b6d4f22
they only accept PyStrings.
now the raw pointer from calloc.i, for example, works
fine.
some of the SWIG_PyObj_(As|From)XXX routines are getting
too large, so, they also will go into the runtime library.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@5689 626c5289-ae23-0410-ae9c-e8d60b6d4f22
they only accept PyStrings.
now the raw pointer from calloc.i, for example, works
fine.
some of the SWIG_PyObj_(As|From)XXX routines are getting
too large, so, they also will go into the runtime library.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5689 626c5289-ae23-0410-ae9c-e8d60b6d4f22
null chars, which are allowed in C++ and python, and proper
sizes:
you can use a shorter string to assign a char[6]:
x = "he\0l" -> x := {'h','e',0,'l',0, 0}
but you always get back in python the original size:
x := {'h','i','0','0',0, 0} -> "hi\0\0\0\0"
Better mapping of (char*)0, now you get a None in the python
side, and using None, you get a (char*)0, just like
all the other C++ pointers. Before (char*)0 was mapped
into python as "", or as seg. faults.
Better mapping of "", which is not None nor (char*)0.
Added more tests using primitive types with simple templates.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@5687 626c5289-ae23-0410-ae9c-e8d60b6d4f22
null chars, which are allowed in C++ and python, and proper
sizes:
you can use a shorter string to assign a char[6]:
x = "he\0l" -> x := {'h','e',0,'l',0, 0}
but you always get back in python the original size:
x := {'h','i','0','0',0, 0} -> "hi\0\0\0\0"
Better mapping of (char*)0, now you get a None in the python
side, and using None, you get a (char*)0, just like
all the other C++ pointers. Before (char*)0 was mapped
into python as "", or as seg. faults.
Better mapping of "", which is not None nor (char*)0.
Added more tests using primitive types with simple templates.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5687 626c5289-ae23-0410-ae9c-e8d60b6d4f22
typedef char namet[5];
const namet def_namet = {'h','o', 0, 'l','a'};
ie, char arrays with null embedded characters, and other odd
char[ANY] situations.
add the corresponding test to the primitive_types.i and runme files.
Marcelo
----------------------------------------------------------------------
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@5685 626c5289-ae23-0410-ae9c-e8d60b6d4f22
typedef char namet[5];
const namet def_namet = {'h','o', 0, 'l','a'};
ie, char arrays with null embedded characters, and other odd
char[ANY] situations.
add the corresponding test to the primitive_types.i and runme files.
Marcelo
----------------------------------------------------------------------
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5685 626c5289-ae23-0410-ae9c-e8d60b6d4f22
for primitive types.
Finally, you can safetly write:
%apply int {enum Hello};
%apply long {size_t};
%apply int {MyIntClass};
or using references
%apply const int& {const enum Hello&};
%apply const long& {const size_t&};
%apply const int& {MyIntClass&};
and all the primitive typemaps(in, out, directorin, directorout,
constcode, throws, varin, varout) are safetly applied to the
desired types (including the proper conversions when needed).
In fact, the python.swg file now has no typemap
defined for enums, and only use the %apply directives
as above.
Now the primitive_types.i extensive test runs properly.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@5683 626c5289-ae23-0410-ae9c-e8d60b6d4f22
for primitive types.
Finally, you can safetly write:
%apply int {enum Hello};
%apply long {size_t};
%apply int {MyIntClass};
or using references
%apply const int& {const enum Hello&};
%apply const long& {const size_t&};
%apply const int& {MyIntClass&};
and all the primitive typemaps(in, out, directorin, directorout,
constcode, throws, varin, varout) are safetly applied to the
desired types (including the proper conversions when needed).
In fact, the python.swg file now has no typemap
defined for enums, and only use the %apply directives
as above.
Now the primitive_types.i extensive test runs properly.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5683 626c5289-ae23-0410-ae9c-e8d60b6d4f22
