SWIG misinterprets class names as namespaces if nested class definitions are declared separately:
%module example
%inline %{
// This version will not parse correctly.
class Outer {
class Inner;
};
class Outer::Inner {
class Inner2;
};
class Outer::Inner::Inner2 {
enum Test { Hello = 123 };
};
// This version will parse (but the inner classes will be ignored)
/*
class Outer {
class Inner {
class Inner2 {
enum Test { Hello = 123 };
};
};
};
*/
%}
example.i:14: Error: 'Outer::Inner' is not defined as a valid scope.
example.i:10: Warning 503: Can't wrap class Outer::Inner unless renamed to a valid identifier.
example.i:14: Warning 503: Can't wrap class Outer::Inner::Inner2 unless renamed to a valid identifier.
Nested classes are still an open issue in SWIG. For a short-term solution, you could try to apply one of the workarounds described in the SWIG documentation:
http://www.swig.org/Doc2.0/SWIGPlus.html#SWIGPlus_nested_classes
Sorry I should have mentioned I reported this as requested by William Fulton on the mailing list as "SWIG should at least be able to parse these even if they can't be usefully used from the wrappers."
Git master gives slightly different output, but still fails to handle this:
I just retested.
The version marked by
// This version will not parse correctly.
is now parsed successfully, so that part is actually addressed (and was William's main concern).With
swig -java -c++
the nested classes are all actually wrapped successfully. Theenum
is private in the example given, but if I insertpublic:
before it then it is wrapped too.Before I'd tested with a language SWIG doesn't support generating nested classes in (probably
-python
). That does fail with the error:I think the problem remaining here is probably that when "Inner ignored",
Outer::Inner
is not defined as a valid scope. That seems like a bug - anything later defined insideInner
should also just be ignored.