Dan Eloff <dan.eloff@gmail.com> writes:
Just use boost::iterator_facade to implement your iterator and myriad issues will disappear.
Almost, it cut the code down to about 1/3 of the size and 1/6 the complexity, allowing me to much more easily see where the problems were and how to fix them.
However, one problem did not go away. Boost::Python does the C++ equivelent of:
for( iter it = ctn.begin(); !(it == ctn.end()); ) *it++;
The choice of post-increment was evil in my scenario. I had a C third-part function returning a pointer to a heap allocated structure or NULL if there is no more data. Calling the function a second time frees the previous results memory.
No matter how I looked at the problem, I kept ending up with 2 of these structures at any given point in time, one being held by the temporary iterator being returned from the post increment, and one by the modified original iterator.
One was of course invalid. I could have copied it into a new memory block before obtaining the second, but doing that would double the copying and memory usage of an already memory intensive operation.
I did eventually get it working, but through a blatant hack only. Knowing the order the operations, I realised that if I put the code from the increment() function into equal() function before the comparison is made then everything will work out fine.
I was unable to think of a better solution, perhaps you can think of one?
For things like this the solution is usually to store the dereferenced value inside the iterator itself. You might look into using boost::optional for efficiency in this case.
May I ask why Boost::Python uses post-increment and then derefencing instead of pre-increment after derefencing. I don't understand why it was done this way, but I'm sure there was a good reason.
I'm not sure there _is_ a good reason. If you'd like to patch it to do it the other way, and if all of the Boost.Python regression tests still pass, I'll apply your patch. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com