Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-09 11:41:56


--- David Abrahams <dave_at_[hidden]> wrote:
[...]

> > Remember that after the exception the original object could be
> > already gone. The variant has just a value initilized object now.
> > Who cares whether this value initialized object has a type from
> > variant types or of some internal type. The rest of the code will
> > have to be able to handle it anyway.
>
> No, that's incorrect. The rest of the code would not have to handle the
> internal type if the variant always contains one of the types it was
> specified with.
>
> > This is why boost::variant has the 'backup' flag. In practice, it
> > is no different from singular variant.
>
> That's incorrect, too. The "backup flag" is an implementation detail
> which doesn't affect the external interface. If the variant could
> contain a type not in the specified list, that would constitute a
> change to its external interface.
>
> Somehow I get the feeling that you're so convinced of your intuition
> that the current design is wrong in some absolute sense, that you're
> unable to think clearly about the issues.

Here is an example

struct mouse_event
{
   int x, y;
};

struct menu_command
{
   int id;
};

typedef variant< mouse_event, keyboard_event > event;

struct vistor
{
   operator()( mouse_event& e );
   operator()( menu_command& e );
}

In case of basic guarantess each of the operators in
visitor must assume that the event was not really
generated by the system because variant might
change it. So we need a flag in each of
the event types:

struct mouse_event
{
   bool valid_data;
   int x, y;
   mouse_event() { valid_data = false; }
};

Why are basic guarantess are better
than singular variant?

Eugene

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk