[signals] slot_call_iterator caching bug?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF1eBV5vihyNWuA4URAiOHAKDIqGjobUlH40+TIZ6pmD3s7E4aSgCfRIEZ +R0rr1t3upDKhxVPdy9x0uo= =jELp -----END PGP SIGNATURE-----
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. Regards Timmo Stange
Timmo Stange wrote:
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.
On a side note, I think this may have some funny implications. The iterator_facade cannot return an iterator for the post-increment operator, because dereferencing it would violate the same rule. So I guess if you traverse the slot range in the combiner with "i++", you will call all the slots without ever dereferencing the iterator, while traversal with "++i" will not call them. Or am I missing something here? Regards Timmo Stange
-----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-----
Frank Mori Hess wrote:
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 }
What I meant is that with "++next" you pass the position referred to by "begin" and with "*begin" you reuse that position, which I interpret as a second pass. I don't know what the standard exactly says and I don't have a copy here, but I'm quite sure the same wouldn't work with a lot of input iterators that are widely used. You at least couldn't rely on getting the value you expect with an istream_iterator, for example. Regards Timmo Stange
On Friday 16 February 2007 16:09 pm, you wrote:
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).
Oh, nevermind. Now I see the line in the docs for the input iterator concept that would be violated: [3] After executing ++i, it is not required that copies of the old value of i be dereferenceable or that they be in the domain of operator==. -- Frank
participants (2)
-
Frank Mori Hess -
Timmo Stange