From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-28 17:34:17
--- Eric Friedman <ebf_at_[hidden]> wrote:
> Here is my idea:
> variant assignment (lhs = rhs):
> * copy content of lhs (onto stack or heap, as appropriate)
> * set "temporary content" pointer in variant to copied content
> * destroy content in storage of lhs
> * copy content of rhs into storage of lhs (***)
> * unset "temporary content" pointer, and indicate new content type
> * destroy copied content (via delete or stack unwinding, as needed)
This is exactly how I thought it would work.
> Since such backup is typically not needed -- indeed, only in the
> specific case that the variant being modified is accessed from the copy
> constructor of a type in the variant -- I think you'll agree such
> overhead is a bit excessive.
> >>A better solution, I believe, is simply to document that accessing a
> >>variant *during* assignment will result in undefined behavior. That way,
> >>unless the user really needs to do something like the above, such (IMHO,
> >>excessive) overhead will be avoided.
> > I think that documenting the special case is almost as
> > good as to say that variant doesn't really
> > provide basic guarantees?
> It always provides basic guarantees except in the following (peculiar)
> A variant's state is undefined if accessed *during* its assignment.
I guess there is no much we can do about it.
> The other possibility is that the library provide a global_variant class
> template for such situations. The most elegant solution is probably a
> specialized assignment policy class. I'll keep this in mind when I
> design the policy-based variant for 1.32.
You suggested to add const_/fixed_variant
and use it in the 'variant' implementation.
Have you considered adding singular_variant
instead in use it in the 'variant' implementation?
I believe that singular_variant will be more
useful in practice by itself than the const_variant and
it should provide all the basic functionality for 'variant'.
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk