On 1/29/13 12:47 AM, Larry Evans wrote:
On 01/21/13 18:25, Joel de Guzman wrote:
On 1/22/13 8:13 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Jan 21, 2013 at 3:54 PM, Joel de Guzman <djowel@gmail.com> wrote:
On 1/22/13 7:49 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Jan 21, 2013 at 3:33 PM, Joel de Guzman <djowel@gmail.com> wrote:
On 1/22/13 3:57 AM, Antony Polukhin wrote:
I've got some nice idea from discussion: nullable variant. If many > people use or want to use a variant with a type, that represents > empty > state, we can create a separate nullable variant class. I think that > nullable variant can be implemented more efficient that the current > variant. For example we can simplify copy/move constructors and > assignment operators, guarantee fast noexcept default construction, > simplify metaprogamming and reduce compilation times. Maybe someone > want to implement it? > > I like it! If you implement it, I'll be your first user :-) I don't really care much about this "never empty" guarantee and I think it's not really worth the trouble.
How is this different from variant< blank, ... > ?
Less work behind the scenes.
You mean fewer LOC / simpler implementation (believable) or faster compiled code (I'd be skeptical)?
Agreed.
Lighter TMP load.
Agreed, but I'm not sure how much the "never empty guarantee" accounts for the present TMP load.
Agreed.
better noexcept
guarantees. Etc.
I don't see this. I would think constructing blank has the same noexcept guarantees as assigning a pointer to null, and can equally well be propagated out to the variant interface. You might have a specific case in mind, though?
No. After thinking about it for a while, you are right.
Do you presently use variant< blank, ... >? If not, is it because of the above reasons?
I *always* use variant< blank, ... > (or something similar). And that is precisely why I don't care much about the never-empty guarantee.
Regards,
I'm a bit confused about what nullable variant means. I can see 2 possible interpretations:
1) allow recursive_wrapper<T>::_p == 0. This only occurs when moving from a variant containing a recursive_wrapper. 2) ensure a moved from variant is put into the same state as a default constructed variant.
Closer to 2. A nullable_variant is simply a variant with an implied "blank" type as the first in the type list. It's equivalent to variant<blank, T...> I can imagine that the implementation of this will be cleaner and simpler than the current implementation with lots of code that deals with the never-empty guarantee. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com