您可能还想提供 __setitem__ 的类似实现以使其有用.这可能不比 std_vector.i 快，或者你的自制类型映射直接转换为 Python 列表列表.总的来说，虽然我不认为这样做是个好主意——使用现有的 std_vector.i 实现而不是重新发明轮子似乎更合乎逻辑.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. 解决方案 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 linux2Type "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. 这篇关于在没有 std_vector.i 的情况下实现对 std::vector 的支持的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！
