(I appologize for the two awkward replies I had sent before. It seems that my news client and myself have some issues to resolve...)

<scleary@jerviswebb.com> wrote:

[snip]
>
> 2) The Visitor concept brings a couple questions to mind:
>   a) Why allow modification (termed "persistency" in the docs)?  No other
> FunctionObject abstraction does, and modern C++ users are well-acquainted
> with and used to the associated restrictions on FunctionObjects.

Indeed we had some discussions about this issue. The final argument was that
the usage scenarios are different for a visitor and for (traditional)
FunctionObject: In the STL context a FunctionObject is needed when one action
should be repeatedly applied over a single sequence of objects. This task is carried out by a *single* invocation of the appropriate algorithm. A Visitor, on the other
hand, is likely to be applied over several variant instances, which are not
necessarily stored inside a container. Hence, the code will (likely) have
several apply_visitor() calls, where a different variant object is passed to
each one. If the visitor was passed by value, we would end up with something
like this:

struct my_visitor { .... };

typedef variant<A,B,C> variant_type;
void f(variant_type x, variant_type y, variant_type z)
{
    my_visitor vis1 = apply_visitor(my_visitor(), x);
    my_visitor vis2 = apply_visitor(vis1, y);
    my_visitor vis3 = apply_visitor(vis2, z);

    // do something with vis3 ....

}

I feel that this code is overly verbose and counter-intuitive.

[Two other points - in favor of the pass-by-reference method -  are the
ability to use polymorphic visitors without slicing them, and the reduced
overhead, since copy-construction is avoided. However, these points are less
substantial than the first argument, since you can use a simple wrapper
class to work-around the problems.]

>  b) Do Boost.Lambda expressions qualify as Visitors?  I am not familiar
>enough with the implementation of either library to be able to tell...
>

A valid visitor must expose a nested type,  result_type, which specifies its
return type. I believe it should be possible (although I did not try it yet)
to wrap a lambda expression inside a proxy class which will define
result_type as void.

-Itay