Re: [Boost-users] [signals] slot_call_iterator caching bug?

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-02-16 16:09:53

-----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-----