Re: [boost] Re: generalization of types in variant

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.

Eugene

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/