Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-28 16:50:11

--- Eric Friedman <ebf_at_[hidden]> wrote:
> By contrast, option 1 allows code to raise an error detectable only at
> runtime, regardless of whether such behavior was intended or not. It
> also gives special (unwarranted?) semantics to boost::empty; it is no
> longer "just another type." This may possibly complicate manipulation of
> variant objects in generic code.

As I said in one of my previous post.
boost::empty seems to make generic code practically
imposible for binary variants.
Let me refocus my original question a bit.
The goal is to implement a generic binary visitor.

struct binary_visitor
   template< typename T, typename U >
   void operator()( T& x, T& y ) { x.f(y); }

typedef variant<type1, type2, type3 ...> v_t;
v_t v1, v2;
apply_visitor( binary_visitor(), v1, v2 ); //Ok

// same code with optimization
typedef variant<boost::empty, type1, type2, type3 ...> v_t;
v_t v1, v2;
apply_visitor( binary_visitor(), v1, v2 ); //*** Error

So the bottom line question is how do you optimize it?

> I do agree, however, that the need to explicitly handle boost::empty in
> visitors does somewhat complicate the use of boost::empty as an
> optimization. Perhaps the cannot_visit class I proposed elsewhere in
> this thread is a good solution.
> I'm open to suggestions.

I was thinking about it myself.
cannont_visit may work just fine, it'll definitely solve my problem.

typedef variant< cannot_visit<boost::empty>, type1, type2, type3 ...> v_t;

BTW: cannont_visit will be useful for othe purposes not just
an optimization. It seem like cannot_visit is a must have.


Do you Yahoo!?
Exclusive Video Premiere - Britney Spears

Boost list run by bdawes at, gregod at, cpdaniel at, john at