swig generates a set method for a public reference with private copy constructor and assignment operator

[excaliburtb]

As the title says:

swig is generating a setter for a reference in the S_define but the referenced type has a private unimplemented copy constructor and assignment operator:

See the following example sim: (removed as it had an error. See comment below for updated example sim.)

Error produced is:

build/home/tbrain/test_code/SIM_test_nocpyref/S_source_py.cpp: In function ‘PyObject* _wrap_VehicleOneSimObject_aliasTestObject_set(PyObject*, PyObject*)’:
build/home/tbrain/test_code/SIM_test_nocpyref/S_source_py.cpp:16120:40: error: ‘VehicleOne& VehicleOne::operator=(const VehicleOne&)’ is private within this context
   if (arg1) (arg1)->aliasTestObject = *arg2;
                                        ^~~~
In file included from /home/tbrain/test_code/SIM_test_nocpyref/S_source.hh:84,
                 from build/home/tbrain/test_code/SIM_test_nocpyref/S_source_py.cpp:3845:
/home/tbrain/test_code/SIM_test_nocpyref/include/VehicleOne.hh:24:17: note: declared private here
    VehicleOne & operator= (const VehicleOne &);
                 ^~~~~~~~
make: *** [build/Makefile_swig:65: build/home/tbrain/test_code/SIM_test_nocpyref/S_source_py.o] Error 1

This could be a swig issue but confirmation would be nice.

[hchen99]

If extending all the way up to sim objects in S_define, then should not produce error https://nasa.github.io/trick/documentation/building_a_simulation/Model-Source-Code.html#noncopyable-objects

[excaliburtb]

oh yes, I had that in the original sim with the issue. Let me resubmit the example with the sim object class also private constructor and assignment operator

[excaliburtb]

nocpyref.zip

[hchen99]

SWIG 4.2? SWIG 4.1.1 works ok for me on Mac. SWIG 4.2 would have set wrapper for private operator /constructor

[excaliburtb]

redhat 8 standard swig install of 3.0.12

[excaliburtb]

looks like we can do a workaround of using:

##ifdef SWIG
%immutable;
##endif
     VehicleOne & aliasTestObject;
##ifdef SWIG
%mutable;
##endif

but obviously it would be better if swig or Trick (whoever is to blame) didn't require it.

[hchen99]

Ok, when I was testing, didn't test member initializing with constructor so didn't see the error. I saw the error with following:

class VehicleOneSimObject : public Trick::SimObject{ public: VehicleOne testObject; VehicleOne & aliasTestObject; VehicleOneSimObject() : aliasTestObject(testObject) { } ...

Making VehicleOne & aliasTestObject not public won't produce error: class VehicleOneSimObject : public Trick::SimObject{ VehicleOne & aliasTestObject; public: VehicleOne testObject; VehicleOneSimObject() : aliasTestObject(testObject) { }

[hchen99]

looks like we can do a workaround of using:

##ifdef SWIG
%immutable;
##endif
     VehicleOne & aliasTestObject;
##ifdef SWIG
%mutable;
##endif

but obviously it would be better if swig or Trick (whoever is to blame) didn't require it.

Good to know about the workaround. S_source_py.cpp is auto generated by SWIG, so I'd say because swig requires it ;-)

[sharmeye]

The workaround mentioned above is the official guidance offered by SWIG itself for this issue, so I'm going to close this as "not Trick's fault."

[dbankieris]

Looks like this might be a SWIG bug.