[Swig-user] %template, stl conainters and memory management

[Andrew H. <and...@di...>]

Hi, I'm still fairly new to swig and I've been getting on well, I use the Pimpl idiom to allow the bindings to retain the C++ objects for as long as they live in the managed language and this works really well but I've hit a bit of an issue with passing collections to the managed language, basically I have a rough setup as follows:

ObjectImpl.h
class ObjectImpl
{
}

Object.h
class ObjectImpl;
class Object
{
  std::shared_ptr<ObjectImpl> pimpl;
}

Object.i
%template(ObjectList) std::vector<Object>;

class Object
{
  ObjectList getObjectList();
};

Now when I pass an ObjectList to the managed language and get objects out of the ObjectList the getitem method is called which adds the address of the C++ Object to a new C# object, sets it's swigCMemOwn to false and passes that out. A side effect of this is that when the C# ObjectList goes out of scope, it deletes the C++ std::vector<Object> and the address inside any C# Object retrieved from the list now dangles.

As a workaround, given I'm using the Pimpl idiom, I can safely use getitemcopy as opposed to getitem and they will point to the same underlying object, to do this I had to modify std_vector.i which isn't ideal. I was wondering if there is any way I can achieve this with swig inside my own .i files? I tried to use a %typemap(cscode) but It didn't work because it seems only one of these can be used per type and the one inside std_vector.i takes precedent.

I was also wondering if it was possible to provide it as an option for people who use the Pimpl idiom to bind to swig which I expect would be the most common usage? I also had a thought that maybe std_vector.i could be reworked to provide an actual C# List<Object> which took copies of the source C++ Objects and wrapped them at instantiation, this way the C# garbage collector could properly track the objects on a granular basis and it'd solve the one caveat with my own workaround which is pointer comparisons between 2 C# Objects retrieved from the ObjectList would work as expected, whereas I'd currently have to implement a comparison operator that deferred to the Impl comparison to achieve that.

Hope all that makes sense?
Thanks,
Andy.


Digital Barriers e-Mail Confidentiality and Disclaimer

This message contains confidential information and is intended only for the individual named. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

Digital Barriers plc is a company registered in England and Wales. Registered number: 7149547. Registered office: Cargo Works, 1-2 Hatfields, London SE1 9PG, United Kingdom. For further information about Digital Barriers, please visit www.digitalbarriers.com<http://www.digitalbarriers.com/>.


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________