|
Boost : |
From: Eric Friedman (ebf_at_[hidden])
Date: 2002-07-25 00:07:59
"David Abrahams" <dave_at_[hidden]> wrote:
[snip]
> If I understand what this visitation business is about (I might not), I
> favor:
>
> apply(visitor, var);
>
> which goes nicely with
>
> extract<X>(var);
>
> -Dave
Good point-- I guess I should explain variant visitation a bit for the
group...
Visitation allows a compile-time type-safety guarantee that a particular
operation (i.e. the "visitor") knows how to handle any of a given variant
type's bounded types. (Contrast with repeated extract<T> attempts, which may
not cover all possible types.)
For example, a visitor to a boost::variant<int, double, std::string> _must_
handle int, double, and std::string values in order to result in successful
program compilation.
In regular C++ terms, a visitor is a function object offering function-call
operator() overloads for each type bounded by the variant; of course large
swaths of these "overloads" may be provided for via a templated
function-call operator().
So to put this into a concrete example (using Boost.Lambda), your proposal
would have the following syntax:
apply(std::cout << _1, var); // display the contents of var
rather than my proposed syntax:
var.visit_with(std::cout << _1);
or Itay's proposed syntax:
var(std::cout << _1);
I'm not sure whether I like yours or mine better. Anyone else have an
opinion?
Thanks,
Eric
P.S. One further observation/question: if we continue to go down this road
of preferring free functions over members, should variant::type be removed
as well? The functionality of variant::type is captured entirely by:
const std::type_info& type = var.visit_with(ll_typeid(_1));
or, in terms more verbose (but more portable to broken compilers):
struct reflector : generic_visitor<const std::type_info&> //
generic_visitor provides result_type member
{
template <typename T>
result_type operator()(const T& operand) const
{ return typeid(operand); }
};
...
const std::type_info& type = var.visit_with(reflector());
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk