[variant, MPL] Is there a variant -> mpl sequence metafunction ?
make_variant_over<Seq>::type creates a variant type from an MPL Sequence. Is there an operation that would do the opposite, create an MPL sequence from a variant? I cannot just use the type parameter list as such because the types that stand for an empty type are different in both libraries: boost::detail::variant::void_ in variant, and something else in MPL. Best, Jaakko -- Jaakko Järvi, jarvi@cs.tamu.edu
On 05/17/2005 10:07 PM, Jaakko Järvi wrote:
make_variant_over<Seq>::type
creates a variant type from an MPL Sequence.
Is there an operation that would do the opposite, create an MPL sequence from a variant?
I cannot just use the type parameter list as such because the types that stand for an empty type are different in both libraries: boost::detail::variant::void_ in variant, and something else in MPL. I'd suggest making variant part of mpl. With that, the problem disappears. Also, variant and tuple are duals of each other, in category theory terms; hence, it would make sense if the implementations reflected this duality. The code at:
http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/inde... is an intial attempt at exploiting this duality.
On May 17, 2005, at 10:22 PM, Larry Evans wrote:
On 05/17/2005 10:07 PM, Jaakko Järvi wrote:
make_variant_over<Seq>::type creates a variant type from an MPL Sequence. Is there an operation that would do the opposite, create an MPL sequence from a variant? I cannot just use the type parameter list as such because the types that stand for an empty type are different in both libraries: boost::detail::variant::void_ in variant, and something else in MPL. I'd suggest making variant part of mpl. With that, the problem disappears.
Yes, variant, mpl, tuple (or fusion), should play well together. A good first step would be to start using the same type to mark that no type was specified (instead of the variations void_, null_t, ...).
Also, variant and tuple are duals of each other, in category theory terms; hence, it would make sense if the implementations reflected this duality. The code at:
http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/ boost/indexed_set/?hideattic=0
is an intial attempt at exploiting this duality.
Interesting, I must delay examining this until later, but for now, please note that current tuple code base will be replaced with Fusion, hopefully in 1.34. Best, Jaakko -- Jaakko Järvi, jarvi@cs.tamu.edu
Jaakko Järvi wrote:
On May 17, 2005, at 10:22 PM, Larry Evans wrote:
On 05/17/2005 10:07 PM, Jaakko Järvi wrote:
[...]
I'd suggest making variant part of mpl. With that, the problem disappears.
Yes, variant, mpl, tuple (or fusion), should play well together. A good first step would be to start using the same type to mark that no type was specified (instead of the variations void_, null_t, ...).
FYI, variant is now a valid fusion sequence. I needed that in the course of Spirit2 development and Dan Marsden wrote an adapter for us. Thanks Dan! With it, you can do stuff like: *fusion::find_if<some_meta_function>(v) = val; Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman <joel@boost-consulting.com> writes:
Jaakko Järvi wrote:
On May 17, 2005, at 10:22 PM, Larry Evans wrote:
On 05/17/2005 10:07 PM, Jaakko Järvi wrote:
[...]
I'd suggest making variant part of mpl. With that, the problem disappears.
Yes, variant, mpl, tuple (or fusion), should play well together. A good first step would be to start using the same type to mark that no type was specified (instead of the variations void_, null_t, ...).
FYI, variant is now a valid fusion sequence.
I don't get it. What are the values of the non-stored elements? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
Jaakko Järvi wrote:
On May 17, 2005, at 10:22 PM, Larry Evans wrote:
On 05/17/2005 10:07 PM, Jaakko Järvi wrote: [...]
I'd suggest making variant part of mpl. With that, the problem disappears. Yes, variant, mpl, tuple (or fusion), should play well together. A good first step would be to start using the same type to mark that no type was specified (instead of the variations void_, null_t, ...). FYI, variant is now a valid fusion sequence.
I don't get it. What are the values of the non-stored elements?
Default constructed *only* when dereferenced. Iteration only does not touch the data. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Larry Evans <cppljevans <at> cox-internet.com> writes:
On 05/17/2005 10:07 PM, Jaakko Järvi wrote:
make_variant_over<Seq>::type
creates a variant type from an MPL Sequence.
Is there an operation that would do the opposite, create an MPL sequence from a variant?
I cannot just use the type parameter list as such because the types that stand for an empty type are different in both libraries: boost::detail::variant::void_ in variant, and something else in MPL. I'd suggest making variant part of mpl. With that, the problem disappears. Also, variant and tuple are duals of each other, in category theory terms; hence, it would make sense if the implementations reflected this duality. The code at:
sandbox/boost/indexed_set/?hideattic=0
is an intial attempt at exploiting this duality.
Aren't you referrring to http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost- sandbox/boost/indexed_types/?hideattic=0 instead? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On 05/18/2005 01:09 AM, Joaquin M Lopez Munoz wrote: [snip] Hi Joaquin,
Aren't you referrring to
http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost- sandbox/boost/indexed_types/?hideattic=0
instead?
Apparently the long URL is wrapped by something, because it appears the same in your post as it does in mine, i.e. the URL is broken between boost- and sandbox/boost. I don't know of a way to prevent that and hope that people are aware of the problem and simply concatenate the two adjacent lines to get the complete URL.
Larry Evans ha escrito:
On 05/18/2005 01:09 AM, Joaquin M Lopez Munoz wrote: [snip] Hi Joaquin,
Aren't you referrring to
http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost- sandbox/boost/indexed_types/?hideattic=0
instead?
Apparently the long URL is wrapped by something, because it appears the same in your post as it does in mine, i.e. the URL is broken between boost- and sandbox/boost.
I don't know of a way to prevent that and hope that people are aware of the problem and simply concatenate the two adjacent lines to get the complete URL.
Sorry, what I meant is that you wrote: http://.../indexed_set/... when it should have been http://.../indexed_types/... :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On 05/18/2005 07:40 AM, Joaquín Mª López Muñoz wrote: [snip]
Sorry, what I meant is that you wrote:
when it should have been
:)
OOPS. Yes, you're right.
Jaakko Järvi wrote:
make_variant_over<Seq>::type
creates a variant type from an MPL Sequence.
Is there an operation that would do the opposite, create an MPL sequence from a variant?
http://tinyurl.com/b3nkf, under Notes: "The bounded types of the variant are exposed via the nested typedef types, which is an MPL-compatible Sequence containing the set of types that must be handled by any visitor to the variant." -- Daniel Wallin
Jaakko Järvi writes:
make_variant_over<Seq>::type
creates a variant type from an MPL Sequence.
Is there an operation that would do the opposite, create an MPL sequence from a variant?
I cannot just use the type parameter list as such because the types that stand for an empty type are different in both libraries: boost::detail::variant::void_ in variant, and something else in MPL.
Shouldn't matter. The variant docs say: The bounded types of the variant are exposed via the nested typedef types, which is an MPL-compatible Sequence containing the ^^^^^^^^^^^^^^^^^^^^^^^^^^ set of types that must be handled by any visitor to the variant. If that's not the case, it's a bug in the variant code. -- Aleksey Gurtovoy MetaCommunications Engineering
I somehow missed the types typedef. Just what I needed. Thanks Aleksey, and Daniel for the same piece of advice on a different email! Jaakko On May 19, 2005, at 7:03 AM, Aleksey Gurtovoy wrote:
Shouldn't matter. The variant docs say:
The bounded types of the variant are exposed via the nested typedef types, which is an MPL-compatible Sequence containing the ^^^^^^^^^^^^^^^^^^^^^^^^^^ set of types that must be handled by any visitor to the variant.
If that's not the case, it's a bug in the variant code.
-- Aleksey Gurtovoy MetaCommunications Engineering
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Jaakko Järvi, jarvi@cs.tamu.edu
participants (8)
-
Aleksey Gurtovoy -
Daniel Wallin -
David Abrahams -
Jaakko Järvi -
Joaquin M Lopez Munoz -
Joaquín Mª López Muñoz
-
Joel de Guzman -
Larry Evans