
Hello, I shall be putting Fusion in the CVS (HEAD) soon. The old Fusion(1) under the Spirit directory will cease to exist. I shall try to adjust all boost libraries that rely on it to use the new Fusion2 instead. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Joel de Guzman wrote:
Hello,
I shall be putting Fusion in the CVS (HEAD) soon. The old Fusion(1) under the Spirit directory will cease to exist. I shall try to adjust all boost libraries that rely on it to use the new Fusion2 instead.
Fusion2 is in CVS now. I adjusted tr1::tuple to use Fusion2 instead. Fusion1 is still in the Spirit directory pending some tweaks to xpressive (some incompatibility problem breaks it), so I'll keep it there for a while, until I find an xpressive fix. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Joel de Guzman <joel@boost-consulting.com> writes:
Joel de Guzman wrote:
Hello,
I shall be putting Fusion in the CVS (HEAD) soon. The old Fusion(1) under the Spirit directory will cease to exist. I shall try to adjust all boost libraries that rely on it to use the new Fusion2 instead.
Fusion2 is in CVS now. I adjusted tr1::tuple to use Fusion2 instead.
Totally cool! Did you write the necessary components to make boost::tuple and boost::cons conforming fusion tuples? -- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
Joel de Guzman wrote:
Hello,
I shall be putting Fusion in the CVS (HEAD) soon. The old Fusion(1) under the Spirit directory will cease to exist. I shall try to adjust all boost libraries that rely on it to use the new Fusion2 instead. Fusion2 is in CVS now. I adjusted tr1::tuple to use Fusion2 instead.
Totally cool!
Did you write the necessary components to make boost::tuple and boost::cons conforming fusion tuples?
Not yet. There are still lots of work to do, but that's a high item in the todo list. One higher priority item is to make it easier to make conforming fusion sequences. It would be a good idea to do that first and leverage that for boost::cons. There's also an interesting use-case that became apparent recently: making arbitrary structs/classes conforming sequences easily-- as easy as providing a single function. Pardon me if this is rather sketchy at this point, but imagine being able to write: Our user defined struct: struct point { float x, float y; }; Customization: fusion::map<keys::x_, keys::y_, float&, float&> as_fusion_sequence(point& p) { return fusion::map_tie<keys::x_, keys::y_>(p.x, p.y); } Use: point p = { 123.456, 789.012 }; fusion::for_each(p, std::cout << _1 << std::endl); Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Joel de Guzman <joel@boost-consulting.com> writes:
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
Joel de Guzman wrote:
Hello,
I shall be putting Fusion in the CVS (HEAD) soon. The old Fusion(1) under the Spirit directory will cease to exist. I shall try to adjust all boost libraries that rely on it to use the new Fusion2 instead. Fusion2 is in CVS now. I adjusted tr1::tuple to use Fusion2 instead.
Totally cool!
Did you write the necessary components to make boost::tuple and boost::cons conforming fusion tuples?
Not yet. There are still lots of work to do, but that's a high item in the todo list. One higher priority item is to make it easier to make conforming fusion sequences. It would be a good idea to do that first and leverage that for boost::cons. There's also an interesting use-case that became apparent recently: making arbitrary structs/classes conforming sequences easily-- as easy as providing a single function. Pardon me if this is rather sketchy at this point, but imagine being able to write:
Our user defined struct:
struct point { float x, float y; };
Customization:
fusion::map<keys::x_, keys::y_, float&, float&> as_fusion_sequence(point& p) { return fusion::map_tie<keys::x_, keys::y_>(p.x, p.y); }
Use:
point p = { 123.456, 789.012 }; fusion::for_each(p, std::cout << _1 << std::endl);
That's nice, but I don't think it's really the same thing. Doesn't it incur an extra level of indirection? -- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
There's also an interesting use-case that became apparent recently: making arbitrary structs/classes conforming sequences easily-- as easy as providing a single function. Pardon me if this is rather sketchy at this point, but imagine being able to write:
Our user defined struct:
struct point { float x, float y; };
Customization:
fusion::map<keys::x_, keys::y_, float&, float&> as_fusion_sequence(point& p) { return fusion::map_tie<keys::x_, keys::y_>(p.x, p.y); }
Use:
point p = { 123.456, 789.012 }; fusion::for_each(p, std::cout << _1 << std::endl);
That's nice, but I don't think it's really the same thing. Doesn't it incur an extra level of indirection?
Not the same as what? Sorry, I think I missed something in your question/comment. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Joel de Guzman <joel@boost-consulting.com> writes:
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
There's also an interesting use-case that became apparent recently: making arbitrary structs/classes conforming sequences easily-- as easy as providing a single function. Pardon me if this is rather sketchy at this point, but imagine being able to write:
Our user defined struct:
struct point { float x, float y; };
Customization:
fusion::map<keys::x_, keys::y_, float&, float&> as_fusion_sequence(point& p) { return fusion::map_tie<keys::x_, keys::y_>(p.x, p.y); }
Use:
point p = { 123.456, 789.012 }; fusion::for_each(p, std::cout << _1 << std::endl);
That's nice, but I don't think it's really the same thing. Doesn't it incur an extra level of indirection?
Not the same as what? Sorry, I think I missed something in your question/comment.
It's not really the same as making point actually *be* a conforming fusion sequence, in some sense, is it? You've sorta "cheated" by giving it a kind of implicitly-recognized conversion into a view. -- Dave Abrahams Boost Consulting www.boost-consulting.com

On 9/1/06, David Abrahams <dave@boost-consulting.com> wrote:
It's not really the same as making point actually *be* a conforming fusion sequence, in some sense, is it? You've sorta "cheated" by giving it a kind of implicitly-recognized conversion into a view.
Don't you need the functionality that Joel describes if you deal with code from a library that you didn't write, such as anything provided by Microsoft? Or if you are dealing with legacy code? Jeremy

Jeremy Day wrote:
On 9/1/06, David Abrahams <dave@boost-consulting.com> wrote:
It's not really the same as making point actually *be* a conforming fusion sequence, in some sense, is it? You've sorta "cheated" by giving it a kind of implicitly-recognized conversion into a view.
Don't you need the functionality that Joel describes if you deal with code from a library that you didn't write, such as anything provided by Microsoft? Or if you are dealing with legacy code?
Well, first, to answer Dave, yes, it's not really the same thing. We are talking about conversion versus adaptation. I would say though that both will be useful. Conversion has the disadvantage that a copy step from the source structure to the target sequence will be required. This might not be expensive, especially if you will be using ties (sequence of references) and your structure is small (e.g. point, rect, std::pair). Still, it's not zero overhead. On the other hand, adaptation is copy-free. You essentially make an arbitrary type a truly conforming sequence that can be used as-is. The cost is the added complexity, and hence work, in adaptation. We are still trying to make the procedure as painless as possible, but it can't be as simple as the one-overload conversion; you'll have to write a slew of functions and metafunctions. In either case, we already made sure that conversion and adaptation are both non-intrusive. That was a requirement from the very start. Hence, you *can* adapt a type without having to modify it. The adaptation of std::pair for fusion is an example. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (3)
-
David Abrahams
-
Jeremy Day
-
Joel de Guzman