Question

Okay, I’ve already asked 2 questions about my problem and despite the fact that the replies were really helpful, I am not able to find an optimal solution for my problem. Let me explain my main objective/problem now.

Due to some constraints I can’t use std_vector.i in my swig interface, but I need to use a C++ object of (vector of vectors of string)vector<vector<string>> in Python. I implemented a solution where I am converting whole vector<vector<string> > to Python “List of Lists” wherein I am doing the following conversions:
each C++ string to Python String using PyString_FromString()
each vector<string> to Python Lists l1, l2, l3, l4…
and finally vector<vector<string> > to a Python List containing l1, l2, l3, l4.. as elements.

Although, the above solution works fine and I am able to access the string values in Python but this solution doesn’t look optimal to me.

I would prefer a class (without using std_vector.i) whose object I can pass as a function argument to be populated with values and after returning from the function I should be able to access the values using ob[0][0] etc. In this way I will have to make only one conversion (C++ string to python string) ,for each value accessed, in __getitem__. But I don’t know how to define a class representing vector<vector<string> > in Python without using %template.

Answer 1

I’ve put together an example of a minimal wrapper for std::vector<std::vector<std::string > > which works without including any extra SWIG files (e.g. std_vector.i and std_string.i).

I also put together a small header file to test my implementation with:

#include <vector>
#include <string>
#include <algorithm>
#include <iterator>
#include <iostream>

inline void print_vec(const std::vector<std::string>& v) {
  std::copy(v.begin(),v.end(), std::ostream_iterator<std::string>(std::cout, "\n"));
}

inline void print_vec_vec(const std::vector<std::vector<std::string> >& v) {
  std::for_each(v.begin(),v.end(),print_vec);
}

std::vector<std::vector<std::string> > make() {
  static std::vector<std::string> test1;
  static std::vector<std::string> test2;

  static std::vector<std::vector<std::string> > ret;
  test1.push_back("hello");
  test2.push_back("world");
  test2.push_back("another");
  ret.push_back(test1);
  ret.push_back(test2);
  return ret;
}

It’s the smallest implementation I could think of that usefully exercises the generated interface.

The SWIG interface I wrote provides a skeleton definition of std::vector – just enough to persuade SWIG to actually wrap the thing. We also extend it for the two cases we care about to provide an implementation of __getitem__, the minimum requirement for the obj[x][y] syntax you want to be able to use.

%module Test

%{
#include "test.hh"
%}

namespace std {
template <typename T>
class vector {
};
}

%extend std::vector<std::vector<std::string> > {
  std::vector<std::string> __getitem__(unsigned i) throw(std::out_of_range) {
    return $self->at(i);
  }
}

%extend std::vector<std::string> {
  const char * __getitem__(unsigned i) throw(std::out_of_range) {
    return $self->at(i).c_str();
  }
}

%template (VecString) std::vector<std::string>;
%template (VecVecString) std::vector<std::vector<std::string> >;

%include "test.hh"

There’s a trick there with c_str() to avoid including std_string.i. This interface allows me to do things like this in Python:

Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Test
>>> t=Test.make()
>>> print t[0][0]
hello
>>>

It currently doesn’t raise the correct type of Python exception in __getitem__. You can do that either with %include "exception.i" or with %exception and writing your own try/catch around $action.

You’ll probably also want to provide a similar implementation of __setitem__ to make this useful.

This is probably no faster than std_vector.i, or your home brew typemap that converts to Python list of list directly. In general though I don’t think doing it like this is a good idea — using the existing std_vector.i implementation instead of reinventing the wheel seems far more logical.