From: Marcelo M. <mm...@ac...> - 2005-12-13 22:39:05
|
Ok, thanks, there was a missing typemap that produce the strange behaviour. Try the CVS version again, you will get the warning as expected, still, you have to resolve the overloading manually using rename. Marcelo Charlie Savage wrote: > SWIG is latest from CVS (checked out today). Don't know if it worked > or not on earlier versions, never tested it. Platform is Windows XP, > SWIG built with MingW, the module is built with either VC++ or MingW. > > Charlie > > Marcelo Matus wrote: > >> Some quick questions: >> >> What swig version are you using? >> >> Did it work before?, with which version? >> >> Marcelo >> >> Charlie Savage wrote: >> >>> I'm trying to update the SWIG wrapper for the GEOS library and have >>> run into an interesting problem (wrapping with Ruby and Python). >>> The library has several instances of classes that have overloaded >>> methods that take templated parameters like this: >>> >>> class Bar { >>> public: >>> Bar() {} >>> >>> void test (const std::vector<int>& vec) >>> { >>> } >>> >>> void test(std::vector<int>* vec) >>> { >>> delete vec; >>> } >>> >>> }; >>> >>> To make matters more interesting, the pointer versions of the >>> methods take over ownership of passed in parameters. >>> >>> SWIG doesn't deal with these very well. >>> >>> The first issue is that SWIG generates code to treat these two >>> methods as overloaded methods, as opposed to complaining that they >>> are indistinguishable and thus making the second one "shadowed." >>> Note that if you use a class as the parameter instead of a template >>> SWIG will complain: >>> >>> class Foo {}; >>> >>> class Bar { >>> public: >>> Bar() {} >>> >>> void test (const Foo& foo) >>> { >>> } >>> >>> void test(Foo* foo) >>> { >>> delete foo; >>> } >>> >>> }; >>> >>> >>> The second issue is that regardless of the order of the methods in >>> the source code, SWIG always prefers this version: >>> >>> void test(std::vector<int>* vec) >>> >>> Over this version: >>> >>> void test (const std::vector<int>& vec) >>> >>> Thus its impossible to call the second one. >>> >>> It seems to me that SWIG should not treat these methods as >>> overloaded, and instead just use the first one and generate >>> warnings. Then the developer could use SWIG's %rename functionality >>> to unhide the "shadowed" method. >>> >>> >>> Thanks, >>> >>> Charlie >>> >>> ----------------------- >>> >>> >>> >>> // Simple tests of overloaded functions >>> %module overload_constant >>> >>> %include "std_vector.i" >>> %template(IntVector) std::vector<int>; >>> >>> %{ >>> #include <vector> >>> %} >>> >>> >>> %inline %{ >>> >>> >>> class Bar { >>> public: >>> Bar() {} >>> >>> void test(std::vector<int>* vec) >>> { >>> delete vec; >>> } >>> >>> void test (const std::vector<int>& vec) >>> { >>> } >>> }; >>> %} >>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. Do you grep through >>> log files >>> for problems? Stop! Download the new AJAX search engine that makes >>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>> _______________________________________________ >>> Swig-devel mailing list >>> Swi...@li... >>> https://lists.sourceforge.net/lists/listinfo/swig-devel >> >> >> >> >> |