|
Boost : |
From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-10-08 19:56:54
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of E. Gladyshev
> Sent: Wednesday, October 08, 2003 7:36 PM
> To: Boost mailing list
> Subject: Re: [boost] Variant implementation change (was re: unions)
>
>
> --- Eric Friedman <ebf_at_[hidden]> wrote:
> > To mitigate the concerns of Eugene Gladyshev and Dave Abrahams, I've
> > modified variant to search through its bounded types for one that is
> > nothrow default-constructible and may be used as a "fallback" type in
> > the event of variant assignment failure. The change is now in CVS.
> >
> > Thus, for example, variant<int,T> and variant<T,int> now both operate
> > without any dynamic allocation, irrespective of the presence or behavior
> > of a default constructor for T.
>
> Thanks, Eric. I'll do a get tonight.
> Some people argured that it is not possible to ensure
> basic exception safety w/o backup heap.
> I guess it is not true?
He's not saying that, he's just saying that the no-throw default
constructible type no longer has to be the first one in the list for it to
be used as the fallback type.
IMHO this solution is as near to perfect as we're likely to get.
> > However, this change still does not resolve the question with respect to
> > generic code, where it is not known if any of the types Ti provided to
> > some generic code are nothrow default-constructible.
> >
>
> If the user doesn't provide a nothrow default-constructible type,
> perhaps variant should use an internal (1 char or 0 size)
> nothrow default-constructible type and set an 'undefined'
> flag similar to the 'backup' flag that you already have.
I think this is the same as the 'singular' solution that was discussed
earlier. Can you get this effect by putting boost::empty as the first type
in all of your variants? This way those who want variants that can be empty
can have them, while those who don't won't have it thrust upon them.
Brock
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk