syntax is as follows
%fragment("name","header") { /* an old fragment */ }
%fragment("name" {Type}, "header") { /* the fragment is type dependent */}
Now fragments can also be used inside templates:
template <class T>
struct A {
%fragment("incode"{A<T>},"header") {
/* 'incode' especialized fragment */
}
%typemap(in,fragment="incode"{A<T>}) {
/*
here we use the 'type especialized' fragment
"incode"{A<T> }
*/
}
};
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5753 626c5289-ae23-0410-ae9c-e8d60b6d4f22
%template() std::vector<int>;
to process the class "typedef"s and "typemap"s. Before
only the internal "typedef"s were processed.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5750 626c5289-ae23-0410-ae9c-e8d60b6d4f22
syntax is as follows
%fragment("name","header") { /* an old fragment */ }
%fragment("name" {Type}, "header") { /* the fragment is type dependent */}
Now fragments can also be used inside templates:
template <class T>
struct A {
%fragment("incode"{A<T>},"header") {
/* 'incode' especialized fragment */
}
%typemap(in,fragment="incode"{A<T>}) {
/*
here we use the 'type especialized' fragment
"incode"{A<T> }
*/
}
};
Also, there is a minor templ.c fix when expanding '#T'.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5749 626c5289-ae23-0410-ae9c-e8d60b6d4f22
resolved one if is needed.
Add examples showing the problem with SWIG_TypeQuery
and template+typedef and the old type str, and how
it works now.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5704 626c5289-ae23-0410-ae9c-e8d60b6d4f22
before the swig_type_info fields 'str' and 'name'
where not consistent, one was fully resolved (name),
the other not, therefore
typedef int Int;
template <class C> struct Class {};
SWIG_TypeQuery($descriptor(Class<int>*))
wasn't necessary the same that
typedef int Int;
template <class C> struct Class {};
SWIG_TypeQuery("Class<int> *")
the problem was visible only when the latter form was used,
like in a static auxiliar function outside a typemap.
also, relax type name comparison with blanks, ie
SWIG_TypeQuery("Class<int> *") := SWIG_TypeQuery("Class<int > *")
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5703 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
of the strings start like "Error. XXX", others like "XXX".
The format is now defined in 'error.c:Swig_error_msg_format()'.
- Normalize the multiline error/warning messages to correctly
use -Fformat definition.
- Centralize the error/warning format definitions in
'error.c:Swig_error_msg_format()'.
- Fix a minor error in cpp.c, that after finding an error, still
was emitting a redefined macro, producing duplicated error/warning
messages in parser.y.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5635 626c5289-ae23-0410-ae9c-e8d60b6d4f22
WARN_PARSE_REDUNDANT 322
similar to the g++ -Wredundant-decls flag.
This recovers the warnings that now are not been reported by
the original code
WARN_PARSE_REDEFINED 302
Redundant example:
int foo(int);
int foo(int);
Redefined example:
int foo(int);
double foo(int);
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5634 626c5289-ae23-0410-ae9c-e8d60b6d4f22
