Vector of const pointers

[wsfulton]

Has anybody got vector of const pointers to work with any of the
scripting languages? With Ruby and Python, at least, I get a pile of
type_name and type_info template errors which I havn't got to the bottom
of yet.

Typical example:

%module example

%include <std_vector.i>

%inline %{
#include <vector>
  struct Calendar { ... };
  void foo(std::vector<const Calendar *> calendars);

%}

%template(VectCalendar) std::vector<const Calendar*>;

The code compiles if I use a non-const Calendar* in %template, but then
a runtime error ensues when using 'foo'.

William

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[nitro-4]

Am 23.01.2008, 14:16 Uhr, schrieb William S Fulton  
<wsf@...>:

> Has anybody got vector of const pointers to work with any of the
> scripting languages? With Ruby and Python, at least, I get a pile of
> type_name and type_info template errors which I havn't got to the bottom
> of yet.
>
> Typical example:
>
> %module example
>
> %include <std_vector.i>
>
> %inline %{
> #include <vector>
>   struct Calendar { ... };
>   void foo(std::vector<const Calendar *> calendars);
>
> %}
>
> %template(VectCalendar) std::vector<const Calendar*>;
>
> The code compiles if I use a non-const Calendar* in %template, but then
> a runtime error ensues when using 'foo'.

I think there were some reports here about vector of const pointers. They  
all ran into the compilation problems you mention. Maybe searching this  
list turns up anything which might help you.
If you don't find anything I'd be willing to help with this. I've dealt  
with the utl vector stuff for quite a while now and maybe can shed some  
insights.

-Matthias

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[wsfulton]

Nitro wrote:

> Am 23.01.2008, 14:16 Uhr, schrieb William S Fulton
> <wsf@...>:
>
> > Has anybody got vector of const pointers to work with any of the
> > scripting languages? With Ruby and Python, at least, I get a pile of
> > type_name and type_info template errors which I havn't got to the bottom
> > of yet.
> >
> > Typical example:
> >
> > %module example
> >
> > %include <std_vector.i>
> >
> > %inline %{
> > #include <vector>
> >   struct Calendar { ... };
> >   void foo(std::vector<const Calendar *> calendars);
> >
> > %}
> >
> > %template(VectCalendar) std::vector<const Calendar*>;
> >
> > The code compiles if I use a non-const Calendar* in %template, but then
> > a runtime error ensues when using 'foo'.
>
> I think there were some reports here about vector of const pointers.
> They all ran into the compilation problems you mention. Maybe searching
> this list turns up anything which might help you.
> If you don't find anything I'd be willing to help with this. I've dealt
> with the utl vector stuff for quite a while now and maybe can shed some
> insights.
>

I'd certainly appreciate some help as it just takes so long to decipher
all this. I found that Marcelo fixed vector<const int*>, see this thread:

http://thread.gmane.org/gmane.comp.programming.swig/7947

The checkin was on 4 May 2006:

Update of /cvsroot/swig/SWIG/Lib/python
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26996/Lib/python

Modified Files:
        pystdcommon.swg
Log Message:
fix std::vector<const int*>, reported by tagna@...
Index: pystdcommon.swg
===================================================================
RCS file: /cvsroot/swig/SWIG/Lib/python/pystdcommon.swg,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** pystdcommon.swg 6 Jan 2006 21:37:59 -0000 1.16
--- pystdcommon.swg 4 May 2006 05:24:02 -0000 1.17
***************
*** 23,26 ****
--- 23,33 ----
    };
 
+   template <class Type> struct traits_from<const Type *> {
+     static PyObject *from(const Type* val) {
+       return traits_from_ptr<Type>::from(const_cast<Type*>(val), 0);
+     }
+   };
+
+
    template <class Type>
    inline PyObject *from(const Type& val) {


I couldn't find anything else on vectors of const pointers.

William

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[nitro-4]

I did some experimentation on this, below is my interface file I used for  
testing (1.3.31, hope that doesn't make a difference).

The problem appears because the const and non-const versions trigger  
different templates in std/std_vector.i. The const version uses the first  
template defined in this file, the non-const version uses the lower one  
which is tagged with this note:

   // ***
   // This specialization should dissapear or get simplified when
   // a 'const SWIGTYPE*&' can be defined
   // ***

The difference between those templates is that they generate different  
traits each. The trait that needs to be presented in the final file is

   namespace swig {
     template <>  struct traits<Calendar > {
       typedef pointer_category category;
       static const char* type_name() { return"Calendar"; }
     };
   }

The fix marcelo checked in makes sure that "const* type" resolve to the  
"type" trait. Now the const version generates an improper trait for  
"const* type". That's why the compiler will later complain that it can't  
find the type_name() for Calendar as there is only a trait for const  
Calendar*.
The two lines in the code below fix the problem apparently. The generated  
code compiles fine and I can load the wrapper. I can do this:

import problem
v = problem.VectCalendar()
problem.foo(v)

and it will print "foo called".
Doing

c = problem.Calendar()
problem.append(c)

does not work, because Calendar is not a const Calendar (I guess). I am  
not sure if this is supposed to work at all. Maybe you can comment on this.

Finally, I am not sure whether this "fix" only fixes the apparent problem  
or if there's a much deeper problem with const vectors somewhere under the  
covers.

-Matthias


%module problem

%include <std_vector.i>

%inline
%{
        #include <vector>
        struct Calendar
     {
           int day;
        };

        #define CONST_VERSION

        #ifndef CONST_VERSION
                void foo(std::vector<Calendar *> calendars)
                {
                        printf("foo called");
                }
        #else
                void foo(std::vector<const Calendar *> calendars)
                {
                        printf("foo called");
                }
        #endif

%}

#define CONST_VERSION

// these two lines fix the problem
%traits_swigtype(Calendar);
%fragment(SWIG_Traits_frag(Calendar));

#ifndef CONST_VERSION
        %template(VectCalendar) std::vector<Calendar*>;
#else
        %template(VectCalendar) std::vector<const Calendar*>;
#endif

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[wsfulton]

Nitro wrote:

> I did some experimentation on this, below is my interface file I used
> for testing (1.3.31, hope that doesn't make a difference).
>
> The problem appears because the const and non-const versions trigger
> different templates in std/std_vector.i. The const version uses the
> first template defined in this file, the non-const version uses the
> lower one which is tagged with this note:
>
>   // ***
>   // This specialization should dissapear or get simplified when
>   // a 'const SWIGTYPE*&' can be defined
>   // ***
>
> The difference between those templates is that they generate different
> traits each. The trait that needs to be presented in the final file is
>
>   namespace swig {
>     template <>  struct traits<Calendar > {
>       typedef pointer_category category;
>       static const char* type_name() { return"Calendar"; }
>     };
>   }
>
> The fix marcelo checked in makes sure that "const* type" resolve to the
> "type" trait. Now the const version generates an improper trait for
> "const* type". That's why the compiler will later complain that it can't
> find the type_name() for Calendar as there is only a trait for const
> Calendar*.
> The two lines in the code below fix the problem apparently. The
> generated code compiles fine and I can load the wrapper. I can do this:
>
> import problem
> v = problem.VectCalendar()
> problem.foo(v)
>
> and it will print "foo called".
> Doing
>
> c = problem.Calendar()
> problem.append(c)
>

shouldn't this read
  v.append(c)
?
I think that the const Calendar * container should be different to the
non-const one. They are separate beasts in the Java/C# modules, so we
may as well keep that consistent. However, adding to the container
should be possible.

> does not work, because Calendar is not a const Calendar (I guess). I am
> not sure if this is supposed to work at all. Maybe you can comment on
> this.
>
> Finally, I am not sure whether this "fix" only fixes the apparent
> problem or if there's a much deeper problem with const vectors somewhere
> under the covers.
>
Matthias, this is great. I'll try this out tomorrow, but meanwhile is
there any chance of making a patch to pycontainers.swg so that it is
fixed for everyone and then I can test it on the entire test-suite?


William

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[nitro-4]

Am 24.01.2008, 22:53 Uhr, schrieb William S Fulton  
<wsf@...>:

> I think that the const Calendar * container should be different to the  
> non-const one. They are separate beasts in the Java/C# modules, so we  
> may as well keep that consistent. However, adding to the container  
> should be possible.

Adding was not possible I think.

>> does not work, because Calendar is not a const Calendar (I guess). I am
>> not sure if this is supposed to work at all. Maybe you can comment on  
>> this.
>>
>> Finally, I am not sure whether this "fix" only fixes the apparent
>> problem or if there's a much deeper problem with const vectors somewhere
>> under the covers.
>>
> Matthias, this is great. I'll try this out tomorrow, but meanwhile is  
> there any chance of making a patch to pycontainers.swg so that it is  
> fixed for everyone and then I can test it on the entire test-suite?

I am not sure about the proper fix right now. I'd like to refrain from  
hacking something in which might work for your case, but where I don't  
know if it helps the general problem or if it has any strange side-effects  
(which are most likely not caught by the current test suite). If we can  
understand and get the vector<const*> things to work, I am willing to  
submit a patch for this.

-Matthias

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[wsfulton]

Nitro wrote:

> Am 24.01.2008, 22:53 Uhr, schrieb William S Fulton
> <wsf@...>:
>
>> I think that the const Calendar * container should be different to the
>> non-const one. They are separate beasts in the Java/C# modules, so we
>> may as well keep that consistent. However, adding to the container
>> should be possible.
>
> Adding was not possible I think.
>
>>> does not work, because Calendar is not a const Calendar (I guess). I am
>>> not sure if this is supposed to work at all. Maybe you can comment on
>>> this.
>>>
>>> Finally, I am not sure whether this "fix" only fixes the apparent
>>> problem or if there's a much deeper problem with const vectors somewhere
>>> under the covers.
>>>
>> Matthias, this is great. I'll try this out tomorrow, but meanwhile is
>> there any chance of making a patch to pycontainers.swg so that it is
>> fixed for everyone and then I can test it on the entire test-suite?
>
> I am not sure about the proper fix right now. I'd like to refrain from
> hacking something in which might work for your case, but where I don't
> know if it helps the general problem or if it has any strange
> side-effects (which are most likely not caught by the current test
> suite). If we can understand and get the vector<const*> things to work,
> I am willing to submit a patch for this.

I've committed a fix to svn. Would be good if anyone interested can try
it out.

William

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user