Boost logo

Boost :

From: Eric Friedman (ebf_at_[hidden])
Date: 2003-10-28 16:20:28

Fernando Cacciola wrote:

> "E. Gladyshev" <egladysh_at_[hidden]> escribió en el mensaje
>>--- Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:
>>>How about not requiring a visitor overload for boost::empty?
>>Sorry, I am not sure I understand.
>>Could you give some more details... piece of code?
> What I meant is to change variant so as to treat boost::empty specially and,
> for instance, never visit it.
>>From the user POV, this amounts to loose the requirement that the visitor
> must handle 'empty' as a visiting type.

Well, first of all, simply ignoring visitation is not possible because,
in general, visitation may have a non-void result. Thus if we wish to
"ignore" visitation, the closest thing would be to throw an exception.

So there are two choices:

1) Visitors need not handle the boost::empty case -- but if a variant
    containing boost::empty is visited, boost::bad_visit (or some other
    exception) is thrown. As always, variant can be checked for
    boost::empty content via the variant::empty method.

2) Visitors must handle the boost::empty case, as they must handle
    every other bounded type. [This is the current behavior.]

I prefer option 2 since it is "safer"; it forces the programmer to
consider and explicitly handle (or ignore) the possibility of
boost::empty content at compile-time.

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.

> Now, I do remember that this was originially a choice but it turned
> out that instructing variant to have special knowldege of such a
> singular type was very complex. I'm just suggesting that however
> complex it might be, seems to solve some of this issues.

As I hope is clear from above, the issue is *not* about difficulty of
implementation; rather, it is a question of design.

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.


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