From: SourceForge.net <no...@so...> - 2009-12-22 10:27:53
|
Bugs item #2919243, was opened at 2009-12-22 10:14 Message generated for change (Comment added) made by gbrchill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2919243&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: tcl Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Hill (gbrchill) Assigned to: Nobody/Anonymous (nobody) Summary: typemap for std::vector<T*> produces list of T** Initial Comment: See bug ID 1386582, previously logged against the Perl wrappers. When the user creates a wrapper for a std::vector<T> the underlying wrapper generation code presents this to the TCL world as a regular TCL list of T* objects. So, member functions of T can be called via dispatch through the pointers in the list. However, when the vector is a vector or T* the wrapper produces a list of pointers to the T*. This is not that helpful. ---------------------------------------------------------------------- >Comment By: Chris Hill (gbrchill) Date: 2009-12-22 10:27 Message: Oops, hit the submit button by mistake. This is with SWIG 1.3.40. I've taken the liberty to extend the existing typemap file to use a specialisation for std::vector<T*> so that the use of the proxy type is avoided, I think. I really know very little about this so I feel only confident enough to submit it as a potential solution and hope that someone more expert than I can give it some consideration and commit it if it does really fix the problem. In my case I am not concerned about the lifetime of the pointers, they are owned by the C++ code so I don't want them to be owned by the TCL client code. Also, I've taken the liberty of modifying the declarations of the conversion functions at the top of the typemap, making them SWIGINTERN, to avoid duplicate symbol problems when multiple wrappers are linked together, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2919243&group_id=1645 |