Brendon Costa | 16 Dec 03:43 2006
Picon

std:: containers and pointers

Hi all,

I think this will probably be a common question but i could not get the
archive search to work and was unable to find anything helpful elsewhere
on the web.

The gist of the question is:
How do i get STL containers like std::map to work with pointers?

I have tried using typedefs for the pointers like below:
class Example
{
...
};
typedef Example* ExamplePtr;

#ifdef SWIG
namespace std
{
   %template(StringExampleMap) map<string, ExamplePtr>;
}
#endif

// Some function that returns a map.
std::map<std::string, ExamplePtr> Get();

However this does not seem to work for all STL containers. In particular
it fails to work for maps and vectors. Is there a common way to solve
this problem (I am sure it is a common problem)?

(Continue reading)

Brendon Costa | 16 Dec 07:27 2006
Picon

Re: std:: containers and pointers

Brendon Costa wrote:
> Hi all,
> 
> The gist of the question is:
> How do i get STL containers like std::map to work with pointers?
> 

Well it seems this problem has been resolved in recent versions of SWIG.
I just downloaded 1.3.31 and that problem has been fixed in the simple
test case.

However in my project I get an error when compiling the SWIG generated
wrapper file. SWIG is generating a wrapper file that contains a section
that is attached below.

The last inline template function called type_name() resolves to making
a call to traits<Type>::type_name(), however the traits struct is
defined as

template <class Type> struct traits {};

and has no static member function called type_name(). This causes a
compile error. I noticed that some other places in the wrapper file
there are specializations of this template which DO contain these static
methods. One example is the partial specialization for pointers. Is the
type I am using supposed to have a specialization or is the initial
traits declaration incorrect?

This only happens when i use the %template command to generate data for
a specific template instantiation that is:
(Continue reading)

Brendon Costa | 17 Dec 06:29 2006
Picon

Re: std:: containers and pointers

Sorry for all the emails, this one clarifies what i said in the last
one. I did not have a simplified example of the problem befor ewhich i
have included in this email.

I have included a cut-down segment of swig code that seems to reproduce
the problem described in the previous email. This code basically
produces invalid C++ wrapper code that will not compile.

I am using SWIG 1.3.31

However if i change the map's second type parameter from a Parent* to
Parent then it works fine. However in my program I have an abstract
parent type for that parameter and can not make it a non-pointer.

Any thoughts on how I can solve this problem?

Thanks,
Brendon.

%module edoc
%{
%}

%include "std_string.i"
%include "std_map.i"
#include <string>
#include <map>

%inline %{
class Parent
(Continue reading)

Nitro | 17 Dec 15:10 2006

Re: std:: containers and pointers

Am 17.12.2006, 06:29 Uhr, schrieb Brendon Costa <brendon <at> christian.net>:

> Sorry for all the emails, this one clarifies what i said in the last
> one. I did not have a simplified example of the problem befor ewhich i
> have included in this email.
>
>
> I have included a cut-down segment of swig code that seems to reproduce
> the problem described in the previous email. This code basically
> produces invalid C++ wrapper code that will not compile.
>
> I am using SWIG 1.3.31
>
> However if i change the map's second type parameter from a Parent* to
> Parent then it works fine. However in my program I have an abstract
> parent type for that parameter and can not make it a non-pointer.
>
> Any thoughts on how I can solve this problem?
>
> Thanks,
> Brendon.
>
>
> %module edoc
> %{
> %}
>
> %include "std_string.i"
> %include "std_map.i"
> #include <string>
(Continue reading)

Brendon Costa | 17 Dec 21:34 2006
Picon

Re: std:: containers and pointers

Nitro wrote:
> 
> Maybe some of the SWIG developers can comment on this. If they don't do
> within a week or so, make sure you enter this item to the bugtracker. In
> the meantime you can workaround the problem by appending this code to
> your interface file:
> 
> -Matthias
> 

Thanks a lot for the help. That has fixed the problem for the moment. I
will enter this into the bugtracker if no other comments come up.

Brendon.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Gmane