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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk