-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 16 February 2007 15:47 pm, Timmo Stange wrote:
Frank Mori Hess wrote:
It seems to me the purpose of the cache in the slot_call_iterator is to prevent the slot from being run multiple times if the combiner does multiple dereferences on an iterator. However, since the cache is shared, if a copy of an already dereferenced iterator is made and incremented, then the original iterator will run the slot a second time when dereferenced. So is this a bug, or is it just unspecified what will happen if you dereference a slot iterator more than once?
Such a combiner would violate the single pass traversal limitation of the input iterator concept. The cache solution allows dereferencing the same iterator multiple times to acquire the same value without calling the slot again, which already is a stronger guarantee than an input iterator usually provides. The combiner example in the docs makes use of it.
Timmo, Thanks for you reply. I don't think I'm violating anything spelled out in the single pass traversal requirements (maybe violating the spirit but not the letter). You don't have to do any decrements to see the behavior, just copies and increments. And whether or not dereference results in slot execution is entirely outside single pass traversal, and something we should specify explicitly. To be clear, what I'm saying is something like the following: operator()(Iterator begin, Iterator end) { *begin; // slot executes; *begin; // slot does not execute; Iterator next = begin; ++next; *begin; // slot executes again } - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF1h2h5vihyNWuA4URAp8zAKCc3dfyRmLj7uKwk2eDel7kk4HkbwCeJAix CtJBCl7REBlcNH8rG+kwwr4= =NlXb -----END PGP SIGNATURE-----