Issue704

Title Derive ProxyIterator from std::iterator
Priority bug Status resolved
Superseder Nosy List florian, jendrik, malte
Assigned To florian Keywords
Optional summary

Created on 2017-01-05.12:26:22 by florian, last changed by florian.

Messages
msg6051 (view) Author: florian Date: 2017-01-09.21:45:53
The serious bug is fixed and the Windows buildbot shows a happy green again.
msg6048 (view) Author: jendrik Date: 2017-01-09.17:54:52
Fast Downward Heartbleed has been averted!
msg6046 (view) Author: malte Date: 2017-01-09.17:46:02
Once the serious issue I just brought up on bitbucket is fixed, feel free to merge!
msg6040 (view) Author: jendrik Date: 2017-01-09.12:11:57
No objections from my side.
msg6039 (view) Author: florian Date: 2017-01-09.11:58:00
I did a local test on the Windows buildbot and the current code fixes the issue
we had there. Can we merge this?
msg6033 (view) Author: florian Date: 2017-01-08.10:15:34
I used blind search with stubborn sets (EC) pruning which at least uses some
std::sort and the results look good to me:

http://ai.cs.unibas.ch/_tmp_files/pommeren/issue704-v1-issue704-base-issue704-v1-compare.html
http://ai.cs.unibas.ch/_tmp_files/pommeren/issue704-v1-total_time-astar-blind-ssec-issue704-base-issue704-v1.png
msg6030 (view) Author: malte Date: 2017-01-06.15:28:59
It's probably useful to run at least one configuration that exercises the code.
Perhaps one where we actually use the ProxyIteration inside a standard library
algorithm (which is what prompted this issue, IIRC).
msg6029 (view) Author: florian Date: 2017-01-06.14:11:27
Should I run experiments for this? If so, what kind of configs?
msg6027 (view) Author: florian Date: 2017-01-06.02:42:17
Implementing an iterator is more complicated than I thought. As we discussed, I
tried implementing a ForwardIterator, but this has to have a reference (T& or
const T&) as the return value of operator*(). So I looked at InputIterator
instead. This seems to be the way to go when returning proxies (see last
paragraph in the notes of the documentation:
http://en.cppreference.com/w/cpp/concept/InputIterator).

Still, to fully implement an InputIterator, we also have to implement
operator->(). This is possible, but we would need another intermediate class (a
"proxy proxy"), if I understand this correctly:
http://stackoverflow.com/questions/26495962

The stackoverflow question also says that the standard algorithms tend not to
use ->, so we might get away with not implementing it for now.

Finally, we have to specify all template parameters of iterator (because we want
both "value_type" and "reference" to be our proxy). In this case, deriving from
iterator is not that useful anymore. The struct iterator<> only consists of 5
typedefs and we cannot use these typedefs within the derived class (because
c++). So I think in this case it makes more sense to add the templates manually.
I made two commits to show what I mean.

The current state is on bitbucket:
https://bitbucket.org/FlorianPommerening/downward-issues/pull-requests/31/issue704/diff
msg6012 (view) Author: malte Date: 2017-01-05.13:25:19
I think the algorithms we currently use don't benefit from random access, so I
would only implement random access iterators if the additional implementation
effort is close to zero.
msg6011 (view) Author: florian Date: 2017-01-05.12:26:22
Currently, the windows build fails because ProxyIterator does not define
iterator tags. We could add a definition for the tags, but according to this
stackoverflow question, the clean way is to derive from std::iterator
(http://stackoverflow.com/questions/36032551).

We can also extend the iterator to a random access iterator, which might speed
up some algorithms that select the most efficient implementation based on these
traits. See
http://en.cppreference.com/w/cpp/iterator/iterator_tags
History
Date User Action Args
2017-01-09 21:45:53floriansetstatus: reviewing -> resolved
messages: + msg6051
2017-01-09 17:54:52jendriksetmessages: + msg6048
2017-01-09 17:46:02maltesetmessages: + msg6046
2017-01-09 12:11:57jendriksetmessages: + msg6040
2017-01-09 11:58:00floriansetstatus: chatting -> reviewing
messages: + msg6039
2017-01-08 10:15:34floriansetmessages: + msg6033
2017-01-06 15:28:59maltesetmessages: + msg6030
2017-01-06 14:11:27floriansetmessages: + msg6029
2017-01-06 02:42:17floriansetassignedto: florian
messages: + msg6027
2017-01-05 13:25:19maltesetstatus: unread -> chatting
messages: + msg6012
2017-01-05 12:26:22floriancreate