On 01/10/13 21:38, Rob Stewart wrote:
On Jan 10, 2013, at 6:29 PM, Joel de Guzman <djowel@gmail.com> wrote:
On 1/9/13 11:03 PM, Paul Smith wrote:
On Tue, Jan 8, 2013 at 8:48 PM, Peter Dimov <lists@pdimov.com> wrote:
Paul Smith wrote:
The only way to make everyone happy is to guarantee that a moved-from recursive variant is a valid variant.
Well, the performance hit from `new T` is making a lot of people unhappy, so technically, this is not true. :-)
Unfortunately, that's probably not the worst thing about it. The fact that it can also throw is the one that has the more subtle and far reaching consequences.
And that is utterly disappointing. This "conservative" move makes all proxy-like objects with pointer ownership very inefficient! While we are advocating pass by value!
So... can anyone finally give a good definition of what "valid" means?
Validity depends upon the class in question. A smart pointer can be null and still valid. In your case, the class has the semantics that it always references a value. Changing that, to permit a null state, may be acceptable or it may have unacceptable side effects. Perhaps a new type, with the null state, can be added and used in some of the current contexts.
The "truly tagged" variant here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/composite_st... has such a null state. When constructed with no arguments, it's in this null state. It's "truly tagged" because there can be duplicate bounded types distinguished only by the tag value. IOW, although: variant<T1,T1> is not valid, one_of_maybe<int,T1,T1> is. The one thing bad about this is that to get a T1 out, you *must* supply the value. For example: get<0> to get the 1st T1, iff the tag is 0 and get<1> to get the 2nd T1, iff the tag is 1 otherwise, if the tag is -1, no values have been put into the one_of_maybe, it's in the null state. However, that's also a good thing because there has been a problem with variants needing duplicate types: http://sourceforge.net/mailarchive/message.php?msg_id=24003772 The other bad thing about one_of_maybe is it's slower to compile than boost variant. I'm unsure why but I'd guess it's because there's more template meta-programming involved :( Hope the above gives some ideas about how to solve this problem. -regards, Larry
That your tests passed after your changes suggests that Spirit might well use such a type without problem.
___ Rob
_______________________________________________ Unsubscribe & other changes: