[C++-sig] segfault wrapping iterator_facade input iterators
Hi all,
I'm having some trouble using boost.python to expose an input iterator that I've
implemented using boost::iterator_facade. I've included an example below. The
code will print garbage when iterating in python and segfault for more
complicated iterators, but works fine if std::input_iterator_tag is changed to
forward_iterator_tag. I've noticed this happens in VC9 and gcc.
The problem goes away if line 65 in boost/python/object/iterator.hpp is changed
from "return *self.m_start++;" to something like:
result_type r = *self.m_start;
++self.m_start;
return r;
It seems that this change should be made for input iterators, since the postfix
increment operator is allowed to return void. However, I don't fully
understand why this is a problem in my case since iterator_facade returns a
proxy iterator that can be dereferenced.
Thanks for any help,
Alec
#include
#include
using namespace boost::python;
class container
{
public:
class iter : public boost::iterator_facade
{
public:
iter(int* i) : m_i(i) {}
private:
friend class boost::iterator_core_access;
void increment() { m_i++; }
int& dereference() const { return *m_i; }
bool equal(const iter& other) const { return m_i == other.m_i; }
int* m_i;
};
container() : m_data() {}
iter begin() { return iter(m_data); }
iter end() { return iter(m_data+5); }
private:
int m_data[5];
};
BOOST_PYTHON_MODULE(iter_example)
{
class_("container")
.add_property("data", range(&container::begin, &container::end))
;
}
--
import iter_example
c = iter_example.container()
for x in c.data:
print x
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] GSoC Boost.Python project
Hello I am working on the project proposal for GSoC 2011 for the Boost.python project, and I would like a little help. 1. ndarray.hpp mentions that functionality needs to be added like the one in boost::python::numeric::array . Stefan suggested that Jim might be able to help with what exactly was intended. Is there anything specific in mind ? 2. Neal mentions that efficiency needs to be improved. Could you please help me with a little more detail about that, Neal ? 3. ndarray.hpp also mentions that the templates "Should probably take ranges of iterators rather than actual container objects." Could someone explain what is intended ? Am I missing out on something essential ? Anything I should keep in mind ? Tips and pointers. Please help me out here. Thanks, Ankit ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] GSoC Boost.Python project
On 03/30/2011 08:01 PM, Ankit Daftery wrote: Hello I am working on the project proposal for GSoC 2011 for the Boost.python project, and I would like a little help. 1. ndarray.hpp mentions that functionality needs to be added like the one in boost::python::numeric::array . Stefan suggested that Jim might be able to help with what exactly was intended. Is there anything specific in mind ? If one looks at the Numpy C-API or the list of methods available to numpy.ndarray, there are a lot more than are present in the wrapper in ndarray.hpp. Some of these should be added to ndarray.hpp. 2. Neal mentions that efficiency needs to be improved. Could you please help me with a little more detail about that, Neal ? 3. ndarray.hpp also mentions that the templates "Should probably take ranges of iterators rather than actual container objects." Could someone explain what is intended ? This is just a question of how best to pass a sequence of integers that specify the shape and stride of array. Making the argument a specific C++ container type requires the user to use exactly that type and to fill it with exactly those elements; it's usually considered better form to accept a range of iterators when you can. Taking iterator ranges makes for a lot of arguments, though, which makes the API a little unwieldy, especially considering the size of the containers has to be the same. I think one of the goals for the GSoC project would be to look at different ways to rework that API and see what various people like best. Am I missing out on something essential ? Anything I should keep in mind ? Tips and pointers. In one of my previous emails on this list I wrote down what my goals would be for this project (including the two discussed above). In general, I think it's about taking the sandbox library and cleaning it up to the point where it's at a boost level of quality, and possibly revisiting some of the design decisions that went into it. Jim ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
