There seems to be a regression with respect to generating c++/java code generation.
The appended Inputfile generates valid code with swig-2.0.4, however the compiler rejects the code generated by swig-2.0.9
Error message:
JAVA_wrap.cxx:574:64: error: declaration of reference variable 'result' requires an initializer
std::vector< FederateHandleSaveStatusPair >::const_reference result;
^~~~~~
JAVA_wrap.cxx:589:66: error: 'type name' declared as a pointer to a reference of type
'std::vector<FederateHandleSaveStatusPair>::const_reference' (aka 'const std::pair<FederateHandle, SaveStatus=""> &')
(std::vector< FederateHandleSaveStatusPair >::const_reference *)&jresult = new std::vector< FederateHandleSaveStatusPair ...
^
2 errors generated.
Command line (MacosX)
swig -java -c++ -I/System/Library/Frameworks/JavaVM.framework/Headers -I/System/Library/Frameworks/JavaVM.framework/Headers -o JAVA_wrap.cxx rti1516e.i
c++ -c -I/System/Library/Frameworks/JavaVM.framework/Headers JAVA_wrap.cxx
I did a git bisect: Offending Patch is
[7d038d4bd7762fb931d3a2112788cddc952792a2] Fix scoping of forward class declarations nested within a class (for C++). Also fix %template and resolution of template parameters that are typedefs
I see these errors when compiling GNU Radio with its SWIG Python interface; code compilation fails only under very specific circumstances. In this case, the argument is of type "std::vector<size_t>", and the pointer type that SWIG creates to hold the argument is of type "std::vector<unsigned int>" or "std::vector<unsigned long>" apparently depending on the CPU bit size (32 or 64, respectively). "size_t" is, I believe, always "unsigned long", so compiling works on a 64-bit CPU but fails on a 32-bit CPU. I think I have a work-around for the GNU Radio code, but I'd love to see SWIG fixed. Ideally, the pointer argument would of type "std::vector<size_t>*", so that it works no matter what the typedef value of size_t is.
I'm seeing the same problem attempting to build Java wrappers for CRFSuite, with Swig 3.0.2 on OS X. I'm keen to see the problem fixed or hear about any useful workarounds.
The generated C++ code from the example above compiled using SWIG 4.0.2 so closing as fixed.