The following simple patch to tuple_basic.hpp allows tuples to be constructed from std::pairs (there is already an assignment operator, but the copy constructor is missing for some reason, and is required for TR1 conformity). RCS file: /cvsroot/boost/boost/boost/tuple/detail/tuple_basic.hpp,v retrieving revision 1.28 diff -r1.28 tuple_basic.hpp 627a628,636
template <class T, class U> tuple(const std::pair<T, U>& p) : inherited(p.first, p.second, detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull()) { BOOST_STATIC_ASSERT(length<tuple>::value == 2);// check_length = 2 }
Is it acceptable to add this? Many thanks, John Maddock.
This made me remember my own old post about tuples & pairs: http://lists.boost.org/MailArchives/boost/msg64193.php i.e to make the tuple::get<> accessor support pairs also. (actual patches: http://lists.boost.org/MailArchives/boost/msg05245.php) I spoke to Jaakko about this at the time and he was postivite, but it seems it ended up in the backlog.. Myself I almost forgot about it during the summer. Perhaps this could be reconsidered? Regards // Fredrik Blomqvist John Maddock wrote:
The following simple patch to tuple_basic.hpp allows tuples to be constructed from std::pairs (there is already an assignment operator, but the copy constructor is missing for some reason, and is required for TR1 conformity).
RCS file: /cvsroot/boost/boost/boost/tuple/detail/tuple_basic.hpp,v retrieving revision 1.28 diff -r1.28 tuple_basic.hpp 627a628,636
template <class T, class U> tuple(const std::pair<T, U>& p) : inherited(p.first, p.second, detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull()) { BOOST_STATIC_ASSERT(length<tuple>::value == 2);// check_length = 2 }
Is it acceptable to add this?
Many thanks,
John Maddock.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Fredrik Blomqvist" <fredrik_blomqvist@home.se> writes:
This made me remember my own old post about tuples & pairs: http://lists.boost.org/MailArchives/boost/msg64193.php i.e to make the tuple::get<> accessor support pairs also. (actual patches: http://lists.boost.org/MailArchives/boost/msg05245.php)
I spoke to Jaakko about this at the time and he was postivite, but it seems it ended up in the backlog.. Myself I almost forgot about it during the summer. Perhaps this could be reconsidered?
I think the fusion tuples are already TR1-compatible (?) and we are supposed to transition over to them immediately (?) anyway. Joel? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Fredrik Blomqvist" <fredrik_blomqvist@home.se> writes:
This made me remember my own old post about tuples & pairs: http://lists.boost.org/MailArchives/boost/msg64193.php i.e to make the tuple::get<> accessor support pairs also. (actual patches: http://lists.boost.org/MailArchives/boost/msg05245.php)
I spoke to Jaakko about this at the time and he was postivite, but it seems it ended up in the backlog.. Myself I almost forgot about it during the summer. Perhaps this could be reconsidered?
I think the fusion tuples are already TR1-compatible (?) and we are supposed to transition over to them immediately (?) anyway. Joel?
Yes. Fusion has been here with us for almost 2 years now and the code is very mature. I've already used it in a couple of projects and it is holding up pretty well. If possible, I'd like to transition to it as soon as possible. I tried to contact Jaakko a few times. I'm not sure if he received my emails. The last time we got in touch, he's very enthusiastic about it. In fact, he co-authored the tuples part of Fusion (along with Jeremiah Willcock. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman <joel@boost-consulting.com> writes:
David Abrahams wrote:
"Fredrik Blomqvist" <fredrik_blomqvist@home.se> writes:
This made me remember my own old post about tuples & pairs: http://lists.boost.org/MailArchives/boost/msg64193.php i.e to make the tuple::get<> accessor support pairs also. (actual patches: http://lists.boost.org/MailArchives/boost/msg05245.php)
I spoke to Jaakko about this at the time and he was postivite, but it seems it ended up in the backlog.. Myself I almost forgot about it during the summer. Perhaps this could be reconsidered? I think the fusion tuples are already TR1-compatible (?) and we are supposed to transition over to them immediately (?) anyway. Joel?
Yes. Fusion has been here with us for almost 2 years now and the code is very mature. I've already used it in a couple of projects and it is holding up pretty well. If possible, I'd like to transition to it as soon as possible. I tried to contact Jaakko a few times. I'm not sure if he received my emails. The last time we got in touch, he's very enthusiastic about it. In fact, he co-authored the tuples part of Fusion (along with Jeremiah Willcock.
Maybe it's time for Jaakko to simply transfer maintainership of the tuples library to Joel, so he can proceed? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Jaakko Järvi wrote:
Maybe it's time for Jaakko to simply transfer maintainership of the tuples library to Joel, so he can proceed?
Joel, please go a head. I'll contribute as much as I can, but it would be most welcomed if Joel can take the lead.
Wow, thanks for your trust. Ok, I'll do my very best. Perhaps what I need to ask, at least, is to be able to consult with you every now and then. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Jaakko Järvi wrote:
Maybe it's time for Jaakko to simply transfer maintainership of the tuples library to Joel, so he can proceed?
Joel, please go a head. I'll contribute as much as I can, but it would be most welcomed if Joel can take the lead.
Wow, thanks for your trust. Ok, I'll do my very best. Perhaps what I need to ask, at least, is to be able to consult with you every now and then.
Ok, replying to myself, here's what I am planning: 1) I intend to refactor fusion to allow different forms of containers with varying characteristics. I plan to have: a) vector b) list c) set d) map 2) The unifying force is the (as usual): iterator 3) There will be intrinsic functions that work on specific containers (e.g. cons for lists; thus having full backward compatibility with old tuples). 4) As I intend to follow the MPL mold, I will follow MPL naming convention (e.g. "at" instead of "get", vector instead of tuple). 5) Provide a tuple TR1 interface on top of fusion. 6) Provide a backward compatible interface (for old tuples) on top of fusion. I'd like to hear your thoughts. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
I'd like to hear your thoughts.
Ahem... "documentation" ;-)
Ahem ahem, of course :-) -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Ok, replying to myself, here's what I am planning:
1) I intend to refactor fusion to allow different forms of containers with varying characteristics. I plan to have: a) vector b) list c) set d) map 2) The unifying force is the (as usual): iterator 3) There will be intrinsic functions that work on specific containers (e.g. cons for lists; thus having full backward compatibility with old tuples). 4) As I intend to follow the MPL mold, I will follow MPL naming convention (e.g. "at" instead of "get", vector instead of tuple). 5) Provide a tuple TR1 interface on top of fusion. 6) Provide a backward compatible interface (for old tuples) on top of fusion.
I'd like to hear your thoughts.
What namespaces would the various components go in? I understand the plan had been to move the contents of boost::fusion into boost::tuples, but if the primary sequence type is no longer going to be called tuple, I'd rather have fusion stay in boost::fusion and just put the TR1 interface in boost::tuples. Also, I think having both 5) and 6) will be confusing. I'd prefer to get rid of 6). This will obviously break some code, but it will be much easier to adapt old code to the new interface than it was, e.g., to adapt code to use the new iterator adaptors. Jonathan
Jonathan Turkanis wrote:
Joel de Guzman wrote:
Ok, replying to myself, here's what I am planning:
1) I intend to refactor fusion to allow different forms of containers with varying characteristics. I plan to have: a) vector b) list c) set d) map 2) The unifying force is the (as usual): iterator 3) There will be intrinsic functions that work on specific containers (e.g. cons for lists; thus having full backward compatibility with old tuples). 4) As I intend to follow the MPL mold, I will follow MPL naming convention (e.g. "at" instead of "get", vector instead of tuple). 5) Provide a tuple TR1 interface on top of fusion. 6) Provide a backward compatible interface (for old tuples) on top of fusion.
I'd like to hear your thoughts.
What namespaces would the various components go in? I understand the plan had been to move the contents of boost::fusion into boost::tuples, but if the primary sequence type is no longer going to be called tuple, I'd rather have fusion stay in boost::fusion and just put the TR1 interface in boost::tuples.
I agree with you.
Also, I think having both 5) and 6) will be confusing. I'd prefer to get rid of 6). This will obviously break some code, but it will be much easier to adapt old code to the new interface than it was, e.g., to adapt code to use the new iterator adaptors.
5 and 6 will have to either-or through a PP define. Yes, it can't be both at the same time. We can deprecate 6 and phase it out in the future. We can't simply kill it now. TR1 deos not provide a way to extend a tuple, for example. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Jonathan Turkanis wrote:
Joel de Guzman wrote:
5) Provide a tuple TR1 interface on top of fusion. 6) Provide a backward compatible interface (for old tuples) on top of fusion.
Also, I think having both 5) and 6) will be confusing. I'd prefer to get rid of 6). This will obviously break some code, but it will be much easier to adapt old code to the new interface than it was, e.g., to adapt code to use the new iterator adaptors.
5 and 6 will have to either-or through a PP define. Yes, it can't be both at the same time. We can deprecate 6 and phase it out in the future. We can't simply kill it now. TR1 deos not provide a way to extend a tuple, for example.
Okay, I thought people who used cons lists were relying on an implementation detail, but I see that it is documented under "advanced features." Still, I'm not sure why you can't eliminate 6) at the same time you introduce fusion. People who need extensible tuples can use fusion sequences. Jonathan
Jonathan Turkanis wrote:
Joel de Guzman wrote:
Jonathan Turkanis wrote:
Joel de Guzman wrote:
5) Provide a tuple TR1 interface on top of fusion. 6) Provide a backward compatible interface (for old tuples) on top of fusion.
Also, I think having both 5) and 6) will be confusing. I'd prefer to get rid of 6). This will obviously break some code, but it will be much easier to adapt old code to the new interface than it was, e.g., to adapt code to use the new iterator adaptors.
5 and 6 will have to either-or through a PP define. Yes, it can't be both at the same time. We can deprecate 6 and phase it out in the future. We can't simply kill it now. TR1 deos not provide a way to extend a tuple, for example.
Okay, I thought people who used cons lists were relying on an implementation detail, but I see that it is documented under "advanced features."
Still, I'm not sure why you can't eliminate 6) at the same time you introduce fusion. People who need extensible tuples can use fusion sequences.
That will lessen my work a lot. But don't you think that's too abrupt? Perhaps those who use old tuple's advanced features are advanced users anyway who won't mind tweaking their code? Toughts? Jaakko? Anyone? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman <joel@boost-consulting.com> writes:
Jonathan Turkanis wrote:
Joel de Guzman wrote:
Jonathan Turkanis wrote:
Joel de Guzman wrote:
5) Provide a tuple TR1 interface on top of fusion. 6) Provide a backward compatible interface (for old tuples) on top of fusion.
Also, I think having both 5) and 6) will be confusing. I'd prefer to get rid of 6). This will obviously break some code, but it will be much easier to adapt old code to the new interface than it was, e.g., to adapt code to use the new iterator adaptors.
5 and 6 will have to either-or through a PP define. Yes, it can't be both at the same time. We can deprecate 6 and phase it out in the future. We can't simply kill it now. TR1 deos not provide a way to extend a tuple, for example. Okay, I thought people who used cons lists were relying on an implementation detail, but I see that it is documented under "advanced features." Still, I'm not sure why you can't eliminate 6) at the same time you introduce fusion. People who need extensible tuples can use fusion sequences.
That will lessen my work a lot. But don't you think that's too abrupt? Perhaps those who use old tuple's advanced features are advanced users anyway who won't mind tweaking their code? Toughts? Jaakko? Anyone?
I don't mind tweaking my code. It seems "more principled" to supply a backward-compatible interface. But I don't think the burden of the cons-based tuple changing namespaces would be too much. So for example, you could move it to boost::tuples::old::tuple _and_ make it fusion-compatible. People who can only wrap their heads around a small tweak will just tweak the namespace they use to refer to that component. Others can start using the Fusion idioms right off. Or you could do one more release with the old tuples where they are, _and_ make them fusion-compatible. If you do that, my sense is that nobody will switch right away, and they'll be just as surprised if this changed after 2 releases as they would be if it changed after one. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Feb 15, 2005, at 7:31 PM, Joel de Guzman wrote:
Jonathan Turkanis wrote:
Joel de Guzman wrote:
Jonathan Turkanis wrote:
Joel de Guzman wrote:
5) Provide a tuple TR1 interface on top of fusion. 6) Provide a backward compatible interface (for old tuples) on top of fusion. Also, I think having both 5) and 6) will be confusing. I'd prefer to get rid of 6). This will obviously break some code, but it will be much easier to adapt old code to the new interface than it was, e.g., to adapt code to use the new iterator adaptors.
5 and 6 will have to either-or through a PP define. Yes, it can't be both at the same time. We can deprecate 6 and phase it out in the future. We can't simply kill it now. TR1 deos not provide a way to extend a tuple, for example. Okay, I thought people who used cons lists were relying on an implementation detail, but I see that it is documented under "advanced features." Still, I'm not sure why you can't eliminate 6) at the same time you introduce fusion. People who need extensible tuples can use fusion sequences.
That will lessen my work a lot. But don't you think that's too abrupt? Perhaps those who use old tuple's advanced features are advanced users anyway who won't mind tweaking their code? Toughts? Jaakko? Anyone?
I think it would be too abrupt (to just not provide the old tuple features). Even thought directly relying on cons lists are documented as advanced features, they are documented. But I think it would be fine to just keep the old tuples around for a few releases, and not bother replicating the old interface on top of fusion. That would seem like a wasted effort. We could just have a #define like BOOST_USE_OLD_DEPRECATED_TUPLES that would include the old implementation. If a user downloads a new release of Boost, and realizes that his code that relies on old tuple features does not work, there would be a quick fix with the #define, but it would clearly indicate that it's time to rework parts of the code. Best, Jaakko
Jaakko Järvi wrote:
On Feb 15, 2005, at 7:31 PM, Joel de Guzman wrote:
Jonathan Turkanis wrote:
Joel de Guzman wrote:
Jonathan Turkanis wrote:
Joel de Guzman wrote:
5) Provide a tuple TR1 interface on top of fusion. 6) Provide a backward compatible interface (for old tuples) on top of fusion.
Also, I think having both 5) and 6) will be confusing. I'd prefer to get rid of 6). This will obviously break some code, but it will be much easier to adapt old code to the new interface than it was, e.g., to adapt code to use the new iterator adaptors.
5 and 6 will have to either-or through a PP define. Yes, it can't be both at the same time. We can deprecate 6 and phase it out in the future. We can't simply kill it now. TR1 deos not provide a way to extend a tuple, for example.
Okay, I thought people who used cons lists were relying on an implementation detail, but I see that it is documented under "advanced features." Still, I'm not sure why you can't eliminate 6) at the same time you introduce fusion. People who need extensible tuples can use fusion sequences.
That will lessen my work a lot. But don't you think that's too abrupt? Perhaps those who use old tuple's advanced features are advanced users anyway who won't mind tweaking their code? Toughts? Jaakko? Anyone?
I think it would be too abrupt (to just not provide the old tuple features). Even thought directly relying on cons lists are documented as advanced features, they are documented. But I think it would be fine to just keep the old tuples around for a few releases, and not bother replicating the old interface on top of fusion. That would seem like a wasted effort.
We could just have a #define like BOOST_USE_OLD_DEPRECATED_TUPLES that would include the old implementation.
It won't really be a wasted effort. 1) I can take advantage of more user's code base to test the implementation for things that are not covered by the regression tests. 2) Users can already use features outside the classic tuples API such as the algorithms like for_each, find_if, etc. OTOH, I have only limited time, so I am now inclined to simply keep the old tuples around. Depends, I guess on how much effort the compatibility layer will take. If it's just a day or two of coding, then I think it's time well spent.
If a user downloads a new release of Boost, and realizes that his code that relies on old tuple features does not work, there would be a quick fix with the #define, but it would clearly indicate that it's time to rework parts of the code. >
Right. I loud nagging warning might be just what we need. Something like: "warning: 3 months to go before this becomes history", then... "warning: 2 months to go before this becomes history", then... "warning: 1 month to go before this becomes history", then... "You missed the train. I warned you, didn't I?", :-) -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Jaakko Järvi <jarvi@cs.tamu.edu> writes:
On Feb 15, 2005, at 7:31 PM, Joel de Guzman wrote:
We could just have a #define like BOOST_USE_OLD_DEPRECATED_TUPLES that would include the old implementation.
If a user downloads a new release of Boost, and realizes that his code that relies on old tuple features does not work, there would be a quick fix with the #define, but it would clearly indicate that it's time to rework parts of the code.
That can lead to ODR problems, though. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 02/15/2005 02:53 PM, Jonathan Turkanis wrote:
Joel de Guzman wrote:
Jonathan Turkanis wrote:
Joel de Guzman wrote:
5) Provide a tuple TR1 interface on top of fusion. 6) Provide a backward compatible interface (for old tuples) on top of fusion. [snip] 5 and 6 will have to either-or through a PP define. Yes, it can't be both at the same time. We can deprecate 6 and phase it out in the future. We can't simply kill it now. TR1 deos not provide a way to extend a tuple, for example.
Okay, I thought people who used cons lists were relying on an implementation detail, but I see that it is documented under "advanced features."
Since the ForwardOp, as defined here: http://www.boost.org/libs/mpl/doc/refmanual/fold.html is pretty equivalent to a cons operation when it's defined as: template<class Head,class Tail> struct forward_op_cons : Tail { Head value; }; couldn't fusion's fold be modified to allow the result to be a cons-like tuple. Then, if needed, a simple "adapting" derivation can make the result look pretty much like the existing tuple. IOW, couldn't fusion's tuple result be a sequence, as done by fold_seq in the fold_seq_test.zip file here: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=cppljevans/mpl ?
Larry Evans <cppljevans@cox-internet.com> writes:
Since the ForwardOp, as defined here:
http://www.boost.org/libs/mpl/doc/refmanual/fold.html
is pretty equivalent to a cons operation when it's defined as:
template<class Head,class Tail> struct forward_op_cons : Tail { Head value; };
?? That's not a binary lambda expression. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 04/29/2005 08:32 AM, David Abrahams wrote:
Larry Evans <cppljevans@cox-internet.com> writes:
Since the ForwardOp, as defined here:
http://www.boost.org/libs/mpl/doc/refmanual/fold.html
is pretty equivalent to a cons operation when it's defined as:
template<class Head,class Tail> struct forward_op_cons : Tail { Head value; };
?? That's not a binary lambda expression.
In fold_seq_test.zip in the vault under cppljevans/mpl there's the code: typedef mpl::fold_seq < types , start_state , my_node< _2, _1> >::type where my_node is essentially the above forward_op_cons: template<class L, class R> struct my_node { typedef my_node partial_type; }; OK, I guess to be precise, I should have said the 2nd arg to fold (or fold_seq) is the lambda expression: forward_op_cons< _2, _1> where forward_op_cons is defined as: ... I now see how this was unclear.
On Feb 14, 2005, at 7:32 PM, Joel de Guzman wrote:
but it would be most welcomed if Joel can take the lead.
Wow, thanks for your trust. Ok, I'll do my very best. Perhaps what I need to ask, at least, is to be able to consult with you every now and then.
By all means! Jaakko
Hi All, On Feb 14, 2005, at 10:21 AM, Joel de Guzman wrote:
Yes. Fusion has been here with us for almost 2 years now and the code is very mature. I've already used it in a couple of projects and it is holding up pretty well. If possible, I'd like to transition to it as soon as possible. I tried to contact Jaakko a few times. I'm not sure if he received my emails. The last time we got in touch, he's very enthusiastic about it. In fact, he co-authored the tuples part of Fusion (along with Jeremiah Willcock.
Haven't had much time for Boost lately, sorry. AFAIK fusion tuples should be ready for prime time and are TR1 compatible, against the spec as it was about a year ago. We were quite careful on that. There's been a few changes after that, but mostly they were just stripping of features (like stream manipulators). Not sure what to do with such features, should they be thrown away, provided by including separate headers, ...? Of course, fusion tuples are not entirely backwards compatible (the old tuples document and expose the cons-interface), so we might want to leave the old ones hanging around as deprecated features for a couple of release rounds? Best, Jaakko
On 02/14/2005 09:21 AM, Joel de Guzman wrote:
David Abrahams wrote: [snip]
I think the fusion tuples are already TR1-compatible (?) and we are supposed to transition over to them immediately (?) anyway. Joel?
Yes. Fusion has been here with us for almost 2 years now and the code is very mature. I've already used it in a couple of projects and it is holding up pretty well. If possible, I'd like to transition to it as soon as possible. I tried to contact Jaakko
Could you provide some benchmarks justifying use of fusion tuple vs. indexed_types/composite_product.hpp. I know David provided some reasons in: http://article.gmane.org/gmane.comp.lib.boost.devel/115108 however, no benchmarks were provided and no "detailed" justifcation explaining why it would be better than composite_product. Indeed, it would be impossible at that time since apparently the composite_product code hadn't been looked at, according to this quote: I guess you're assuming I've looked at your code again ;-) from: http://article.gmane.org/gmane.comp.lib.boost.devel/115530 I'd be happy to help with coding and running benchmarks.
Larry Evans wrote:
On 02/14/2005 09:21 AM, Joel de Guzman wrote:
David Abrahams wrote: [snip]
I think the fusion tuples are already TR1-compatible (?) and we are supposed to transition over to them immediately (?) anyway. Joel?
Yes. Fusion has been here with us for almost 2 years now and the code is very mature. I've already used it in a couple of projects and it is holding up pretty well. If possible, I'd like to transition to it as soon as possible. I tried to contact Jaakko
Could you provide some benchmarks justifying use of fusion tuple vs. indexed_types/composite_product.hpp. I know David provided some reasons in:
http://article.gmane.org/gmane.comp.lib.boost.devel/115108
however, no benchmarks were provided and no "detailed" justifcation explaining why it would be better than composite_product. Indeed, it would be impossible at that time since apparently the composite_product code hadn't been looked at, according to this quote:
I guess you're assuming I've looked at your code again ;-)
from:
http://article.gmane.org/gmane.comp.lib.boost.devel/115530
I'd be happy to help with coding and running benchmarks.
Hi Larry, Yes, benchmarks would be great. However, if my plan pushes through, benchmarks would not be immediately necessary. Please see my other post: "Fusion plan". Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 02/14/2005 06:48 PM, Joel de Guzman wrote:
benchmarks would not be immediately necessary. Please see my other post: "Fusion plan".
I searched for "Fusion plan" in subject, but that showed nothing. Then I looked at all of your posts for the last month, but none looked promising. Could you give more details so I can find it? TIA. Larry
Larry Evans wrote:
On 02/14/2005 06:48 PM, Joel de Guzman wrote:
benchmarks would not be immediately necessary. Please see my other post: "Fusion plan".
I searched for "Fusion plan" in subject, but that showed nothing. Then I looked at all of your posts for the last month, but none looked promising.
Could you give more details so I can find it?
I just posted it. You should see it by now. If not: Here's what I am planning: 1) I intend to refactor fusion to allow different forms of containers with varying characteristics. I plan to have: a) vector b) list c) set d) map 2) The unifying force is the (as usual): iterator 3) There will be intrinsic functions that work on specific containers (e.g. cons for lists; thus having full backward compatibility with old tuples). 4) As I intend to follow the MPL mold, I will follow MPL naming convention (e.g. "at" instead of "get", vector instead of tuple). 5) Provide a tuple TR1 interface on top of fusion. 6) Provide a backward compatible interface (for old tuples) on top of fusion. I'd like to hear your thoughts. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 02/14/2005 07:38 PM, Joel de Guzman wrote:
Larry Evans wrote: [snip]
Could you give more details so I can find it? I just posted it. You should see it by now. If not: I see it.
Here's what I am planning:
1) I intend to refactor fusion to allow different forms of containers with varying characteristics. I plan to have: a) vector b) list c) set d) map [snip] 4) As I intend to follow the MPL mold, I will follow MPL naming convention (e.g. "at" instead of "get", vector instead of tuple). I'm confused because an instance of mpl::vector<T1,T2,...,Tn> contains no data but an instance of a tuple<T1,T2,...,Tn> contains an instance of T1,T2,...,Tn. Aren't both needed?
Larry Evans wrote:
On 02/14/2005 07:38 PM, Joel de Guzman wrote:
Larry Evans wrote:
[snip]
Could you give more details so I can find it?
I just posted it. You should see it by now. If not:
I see it.
Here's what I am planning:
1) I intend to refactor fusion to allow different forms of containers with varying characteristics. I plan to have: a) vector b) list c) set d) map
[snip]
4) As I intend to follow the MPL mold, I will follow MPL naming convention (e.g. "at" instead of "get", vector instead of tuple).
I'm confused because an instance of mpl::vector<T1,T2,...,Tn> contains no data but an instance of a tuple<T1,T2,...,Tn> contains an instance of T1,T2,...,Tn. Aren't both needed?
fusion::vector, fusion::list, fusion::set and fusion::map all have data. These are different incarnations of the tuple with different characteristics. So, like STL and MPL, you can choose the right structure for your needs. The unifying factor is fusion's *iterator* concept. For instance, while developing Spirit-2, I came across the need to have a cons-list based hetero-structure which is cheaper to build piece meal than a vector (flat) based structure that Fusion currently uses. Later on, I came across the need to have an associative tuple. So, really, it should be the same as STL. While stl::vector, stl::list, stl::set and stl::map are homo-structures, fusion::vector, fusion::list, fusion::set and fusion::map are hetero-structures. All Fusion algorithms can work on the various forms. And, any structure that conforms to Fusion's iterator concept automatically becomes a full fledged citizen. std::pair comes to mind. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 02/14/2005 09:13 PM, Joel de Guzman wrote: [snip]
currently uses. Later on, I came across the need to have an associative tuple. So, really, it should be the same as STL.
So fusion::set<T1,T2> would be a pair of sets of type std::set<T1> and std::set::<T2> and with member functions: fusion::set<T1,T2>::insert(T1); fusion::set<T1,T2>::insert(T2); ?
Larry Evans wrote:
On 02/14/2005 09:13 PM, Joel de Guzman wrote: [snip]
currently uses. Later on, I came across the need to have an associative tuple. So, really, it should be the same as STL.
So fusion::set<T1,T2> would be a pair of sets of type std::set<T1> and std::set::<T2> and with member functions:
fusion::set<T1,T2>::insert(T1); fusion::set<T1,T2>::insert(T2);
No. Not like that. It will be an associative tuple akin to mpl::set, but with data. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 02/15/2005 03:39 AM, Joel de Guzman wrote:
Larry Evans wrote:
On 02/14/2005 09:13 PM, Joel de Guzman wrote: [snip]
currently uses. Later on, I came across the need to have an associative tuple. So, really, it should be the same as STL.
So fusion::set<T1,T2> would be a pair of sets of type std::set<T1> and std::set::<T2> and with member functions:
fusion::set<T1,T2>::insert(T1); fusion::set<T1,T2>::insert(T2);
No. Not like that. It will be an associative tuple akin to mpl::set, but with data.
I'm still not clear. Will there be a fusion::set<T1,T2>::insert of any type? Will elements of type T1 and T2 be put in the same set using something like boost::any?
Larry Evans wrote:
On 02/15/2005 03:39 AM, Joel de Guzman wrote:
I'm still not clear. Will there be a fusion::set<T1,T2>::insert of any type?
Close, but no. There will be an insert(s, k) function. Will elements of type T1 and T2 be put in the
same set using something like boost::any?
No. No type erasure here. The set will contain heterogenious types. There will be no need for boost::any. Perhaps mpl::set will make it clear? http://www.boost.org/libs/mpl/doc/refmanual/set.html I will try to follow MPL's interface, using functions instead of metafunctions. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 02/15/2005 04:27 AM, Joel de Guzman wrote: [snip]
Close, but no. There will be an insert(s, k) function. What are the s and k types w.r.t. fusion::set<T1,T2,...,Tn>?
[snip]
No. No type erasure here. The set will contain heterogenious types. There will be no need for boost::any.
Perhaps mpl::set will make it clear? http://www.boost.org/libs/mpl/doc/refmanual/set.html
There's insert<s, x>::type described there, but both s and x are types, not instances of types.
Larry Evans wrote:
On 02/15/2005 04:27 AM, Joel de Guzman wrote: [snip]
Close, but no. There will be an insert(s, k) function.
What are the s and k types w.r.t. fusion::set<T1,T2,...,Tn>?
[snip]
No. No type erasure here. The set will contain heterogenious types. There will be no need for boost::any.
Perhaps mpl::set will make it clear? http://www.boost.org/libs/mpl/doc/refmanual/set.html
There's insert<s, x>::type described there, but both s and x are types, not instances of types.
Of course! That's because MPL uses metafunctions. Fusion's counterpart will be: insert(s, k). Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 02/15/2005 05:12 AM, Joel de Guzman wrote:
Larry Evans wrote: [snip]
What are the s and k types w.r.t. fusion::set<T1,T2,...,Tn>?
[snip]
Of course! That's because MPL uses metafunctions. Fusion's counterpart will be: insert(s, k).
Is the above insert a non-member function with signature: template<typename T1, ...,typename Tn> void insert(fusion::set<T1,,,Tn>& s, Tk e); for some k in 1...n, and the above insert places element e in s?
Larry Evans wrote:
On 02/15/2005 05:12 AM, Joel de Guzman wrote:
Is the above insert a non-member function with signature:
template<typename T1, ...,typename Tn> void insert(fusion::set<T1,,,Tn>& s, Tk e);
for some k in 1...n, and the above insert places element e in s?
Ehm... Yes, it is a non-member function. No, it does not mutate s. It does return another set. It is purely functional (no side- effects). Isn't the MPL doc clear enough? http://www.boost.org/libs/mpl/doc/refmanual/set.html Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 02/15/2005 06:47 AM, Joel de Guzman wrote:
Larry Evans wrote:
On 02/15/2005 05:12 AM, Joel de Guzman wrote:
Is the above insert a non-member function with signature:
template<typename T1, ...,typename Tn> void insert(fusion::set<T1,,,Tn>& s, Tk e);
for some k in 1...n, and the above insert places element e in s?
Ehm...
Yes, it is a non-member function. No, it does not mutate s. It does return another set. It is purely functional (no side- effects).
Isn't the MPL doc clear enough? http://www.boost.org/libs/mpl/doc/refmanual/set.html
But that talks about adding a type, Tk to an mpl::set, not an instance of that type e, to an instance of a set. Maybe what you have in mind is that the elements are represented as type, integral_c<Tk, e>? But then how could a function call (i.e. insert(s,k) ) work since it's arguments are instances not types? Consider tuple. With tuple<T1,T2>, any operation on an instance of T1 or T2 you can do with tupel<T1,T2>. Likewise, I was thinking that since fusion::set<T1,T2> has data, there would be operations for that data, i.e. for instances of T1 and T2. IOW the operations would include adding an instance of T1 or T2 to the fusion::set just as with tuple<T1,T2> you have availble operations on instance of T1 or T2.
Larry Evans wrote:
On 02/15/2005 06:47 AM, Joel de Guzman wrote:
Yes, it is a non-member function. No, it does not mutate s. It does return another set. It is purely functional (no side- effects).
Isn't the MPL doc clear enough? http://www.boost.org/libs/mpl/doc/refmanual/set.html
But that talks about adding a type, Tk to an mpl::set, not an instance of that type e, to an instance of a set.
Didn't I already explain that? Isn't it already clear that Fusion is about functions and values while MPL is about meta-functions and types?
Maybe what you have in mind is that the elements are represented as type, integral_c<Tk, e>?
No!
But then how could a function call (i.e. insert(s,k) ) work since it's arguments are instances not types?
In MPL you use metafunctions: insert<s,k>::type In Fusion, you use plain ole functions: insert(s,k) In MPL s and k are types. In Fusion, s and k are values.
Consider tuple. With tuple<T1,T2>, any operation on an instance of T1 or T2 you can do with tupel<T1,T2>. Likewise, I was thinking that since fusion::set<T1,T2> has data, there would be operations for that data, i.e. for instances of T1 and T2. IOW the operations would include adding an instance of T1 or T2 to the fusion::set just as with tuple<T1,T2> you have availble operations on instance of T1 or T2.
To avoid a long and winding discussion, I think it's better if you just look at the tests. While I still do not have sets and maps there, this sample code for push_back might be illustrative: // Testing push_back { char const* s = "Ruby"; typedef tuple<int, char, double, char const*> tuple_type; tuple_type t1(1, 'x', 3.3, s); { std::cout << push_back(t1, 123456) << std::endl; BOOST_TEST((push_back(t1, 123456) == make_tuple(1, 'x', 3.3, s, 123456))); } { std::cout << push_back(t1, "funny") << std::endl; BOOST_TEST((push_back(t1, "funny") == make_tuple(1, 'x', 3.3, s, std::string("funny")))); } { std::cout << push_back(t1, t1) << std::endl; BOOST_TEST((push_back(t1, t1) == make_tuple(1, 'x', 3.3, s, t1))); } } { typedef boost::mpl::vector_c<int, 1, 2, 3, 4, 5> mpl_vec; std::cout << boost::fusion::push_back( mpl_vec(), boost::mpl::int_<6>()) << std::endl; BOOST_TEST((boost::fusion::push_back( mpl_vec(), boost::mpl::int_<6>()) == make_tuple(1, 2, 3, 4, 5, 6))); } HTH, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 02/15/2005 08:08 AM, Larry Evans wrote: [snip]
Yes, it is a non-member function. No, it does not mutate s. It does return another set. It is purely functional (no side- effects). Then it's different from tuple<T1,...,Tn> since any mutating operation Ti::op on an instance of Ti can be performed on the corresponding member variable in an instance of tuple<T1,...,Tn>?
See boost-sandbox.sourceforge.net/vault/cppljevans/field_visitor_tests /field_sets.hpp for an example of what I had thought you were talking about here:
fusion::vector, fusion::list, fusion::set and fusion::map all have data. These are different incarnations of the tuple with different characteristics.
when you said fusion::set had data. Having data implies, at least to me, that the data can be modified.
Larry Evans wrote:
On 02/15/2005 08:08 AM, Larry Evans wrote: [snip]
Yes, it is a non-member function. No, it does not mutate s. It does return another set. It is purely functional (no side- effects).
Then it's different from tuple<T1,...,Tn> since any mutating operation Ti::op on an instance of Ti can be performed on the corresponding member variable in an instance of tuple<T1,...,Tn>?
I don't understand what you are saying.
See boost-sandbox.sourceforge.net/vault/cppljevans/field_visitor_tests /field_sets.hpp for an example of what I had thought you were talking about here:
fusion::vector, fusion::list, fusion::set and fusion::map all have data. These are different incarnations of the tuple with different characteristics.
when you said fusion::set had data. Having data implies, at least to me, that the data can be modified.
I do not understand why we are having an impedance mismatch here. It seems to me that we're in different universes. I do not even understand why this matters at all. Having data *does not* imply that the data is mutable. It can be const, for example. Or, in purely functional terms, you do not wish to have side-effects. Still, the data is there, in real bits and bytes. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman <joel@boost-consulting.com> writes:
Larry Evans wrote:
On 02/15/2005 08:08 AM, Larry Evans wrote: [snip]
Yes, it is a non-member function. No, it does not mutate s. It does return another set. It is purely functional (no side- effects). Then it's different from tuple<T1,...,Tn> since any mutating operation Ti::op on an instance of Ti can be performed on the corresponding member variable in an instance of tuple<T1,...,Tn>?
I don't understand what you are saying.
See boost-sandbox.sourceforge.net/vault/cppljevans/field_visitor_tests /field_sets.hpp for an example of what I had thought you were talking about here:
fusion::vector, fusion::list, fusion::set and fusion::map all have data. These are different incarnations of the tuple with different characteristics. when you said fusion::set had data. Having data implies, at least to me, that the data can be modified.
I do not understand why we are having an impedance mismatch here. It seems to me that we're in different universes. I do not even understand why this matters at all. Having data *does not* imply that the data is mutable. It can be const, for example. Or, in purely functional terms, you do not wish to have side-effects. Still, the data is there, in real bits and bytes.
And in fact it can be mutated, at least in most fusion structures. It's the _structure_ that can't be mutated. Just like boost::tuple. You can change the elements, but you can't change their number and type (in-place). -- Dave Abrahams Boost Consulting www.boost-consulting.com
Joel de Guzman <joel@boost-consulting.com> writes:
Larry Evans wrote:
On 02/15/2005 05:12 AM, Joel de Guzman wrote: Is the above insert a non-member function with signature: template<typename T1, ...,typename Tn> void insert(fusion::set<T1,,,Tn>& s, Tk e); for some k in 1...n, and the above insert places element e in s?
Ehm...
Yes, it is a non-member function. No, it does not mutate s. It does return another set. It is purely functional (no side- effects).
Isn't the MPL doc clear enough? http://www.boost.org/libs/mpl/doc/refmanual/set.html
Patience, Joel. The whole functional thing is a bit unexpected in the runtime world for many C++ programmers. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 02/14/2005 07:59 PM, Larry Evans wrote:
On 02/14/2005 06:48 PM, Joel de Guzman wrote:
benchmarks would not be immediately necessary. Please see my other post: "Fusion plan".
I searched for "Fusion plan" in subject, but that showed nothing. Then I looked at all of your posts for the last month, but none looked promising.
Could you give more details so I can find it? Never mind. It just showed up.
On Feb 14, 2005, at 7:06 AM, John Maddock wrote:
The following simple patch to tuple_basic.hpp allows tuples to be constructed from std::pairs (there is already an assignment operator, but the copy constructor is missing for some reason, and is required for TR1 conformity).
RCS file: /cvsroot/boost/boost/boost/tuple/detail/tuple_basic.hpp,v retrieving revision 1.28 diff -r1.28 tuple_basic.hpp 627a628,636
template <class T, class U> tuple(const std::pair<T, U>& p) : inherited(p.first, p.second, detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull()) { BOOST_STATIC_ASSERT(length<tuple>::value == 2);// check_length = 2 }
Is it acceptable to add this?
I think we could do better, but it would be stretching TR1 (which I think is good). I think any compatible tuple-like type should be convertible to tuple (pair, array, maybe complex?, anything else that declares itself tuple-like and implements the tuple interface). Furthermore, I think is_convertible should answer correctly, even for negative cases (for those pair that are not convertible to a 2-tuple). E.g.: pair<short, long> p(0, 1); tuple<long, short> t1(p); array<int, 2> a = {1, 2}; tuple<long, short> t2(a); static_assert(is_convertible<array<int, 2>, tuple<long, short> >::value, "array<int, 2> is not convertible to tuple<long, short>"); static_assert(is_convertible<pair<short, long>, tuple<long, short>
::value, "pair<short, long> is not convertible to tuple<long, short>"); static_assert(!is_convertible<pair<short*, long>, tuple<long, short> ::value, "pair<short*, long> is convertible to tuple<long, short>");
Such a converting constructor can be done generically, instead of once for each tuple-like type, if we bring back the (sorely missed) is_tuple_like trait. Actually, now that I think more about it, I'm not positive is_tuple_like is really needed (but my proof of concept currently uses it). template <class P> tuple(const P& p, typename Metrowerks::restrict_to<__tuple_convertible<P, tuple>::value>::type* = 0); Where __tuple_convertible does a size check, and an element by element is_convertible check. -Howard
Howard Hinnant wrote:
I think we could do better, but it would be stretching TR1 (which I think is good).
I think any compatible tuple-like type should be convertible to tuple (pair, array, maybe complex?, anything else that declares itself tuple-like and implements the tuple interface). Furthermore, I think is_convertible should answer correctly, even for negative cases (for those pair that are not convertible to a 2-tuple).
I'd definitely like some standard way for a type to declare itself tuple-like. Why didn't it make it into TR1? I use a version of it here, to allow arbitrary tuple-like types to take advantage of a form of tuple i/o: http://www.kangaroologic.com/format_lite/libs/format_lite/doc/?path=4.2.5 Jonathan
On Feb 14, 2005, at 2:52 PM, Jonathan Turkanis wrote:
Howard Hinnant wrote:
I think we could do better, but it would be stretching TR1 (which I think is good).
I think any compatible tuple-like type should be convertible to tuple (pair, array, maybe complex?, anything else that declares itself tuple-like and implements the tuple interface). Furthermore, I think is_convertible should answer correctly, even for negative cases (for those pair that are not convertible to a 2-tuple).
I'd definitely like some standard way for a type to declare itself tuple-like. Why didn't it make it into TR1?
I use a version of it here, to allow arbitrary tuple-like types to take advantage of a form of tuple i/o:
http://www.kangaroologic.com/format_lite/libs/format_lite/doc/? path=4.2.5
<nod> I use is_tuple_like too. It was in the original proposal. It got dumped somewhere along the way. I'm not sure why. When tuple was first voted into TR1, enable_if was brand new and pretty exotic. Parts of tuple that benefited from (and depended on) enable_if were dumped. It may be that is_tuple_like got thrown out along with that dump. Imho, tuple did not benefit from that exercise. We get another shot at it for C++0X though. So existing practice that is a little better than TR1 can still help. -Howard
Howard Hinnant wrote:
On Feb 14, 2005, at 2:52 PM, Jonathan Turkanis wrote:
Howard Hinnant wrote:
I'd definitely like some standard way for a type to declare itself tuple-like. Why didn't it make it into TR1?
I use a version of it here, to allow arbitrary tuple-like types to take advantage of a form of tuple i/o:
http://www.kangaroologic.com/format_lite/libs/format_lite/doc/? path=4.2.5
<nod> I use is_tuple_like too. It was in the original proposal. It got dumped somewhere along the way. I'm not sure why. When tuple was first voted into TR1, enable_if was brand new and pretty exotic. Parts of tuple that benefited from (and depended on) enable_if were dumped. It may be that is_tuple_like got thrown out along with that dump. Imho, tuple did not benefit from that exercise. We get another shot at it for C++0X though. So existing practice that is a little better than TR1 can still help.
FYI, Fusion already has the infrastructure to do that. For instance, MPL sequences are tuple sequences and vice versa. It's a matter of defining some helper classes that implement something akin to MPL's TAG dispatch mechanism. Hence, a user can (in theory) make any form of tuple-like structure play along well. Alas, the TR1 interface is not sufficiently rich to handle all forms of tuple like structures. In particular, get<N> assumes O(1) access, which is obviously not always true. Fusion, like MPL and STL uses iterators as the underlying and unifying concept. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Howard Hinnant wrote:
On Feb 14, 2005, at 7:06 AM, John Maddock wrote:
The following simple patch to tuple_basic.hpp allows tuples to be constructed from std::pairs (there is already an assignment operator, but the copy constructor is missing for some reason, and is required for TR1 conformity).
RCS file: /cvsroot/boost/boost/boost/tuple/detail/tuple_basic.hpp,v retrieving revision 1.28 diff -r1.28 tuple_basic.hpp 627a628,636
template <class T, class U> tuple(const std::pair<T, U>& p) : inherited(p.first, p.second, detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull()) { BOOST_STATIC_ASSERT(length<tuple>::value == 2);// check_length = 2 }
Is it acceptable to add this?
I think we could do better, but it would be stretching TR1 (which I think is good).
I think any compatible tuple-like type should be convertible to tuple (pair, array, maybe complex?, anything else that declares itself tuple-like and implements the tuple interface).
What is the technical definition of a tuple-like type ?
On Feb 14, 2005, at 7:40 PM, Edward Diener wrote:
Howard Hinnant wrote:
On Feb 14, 2005, at 7:06 AM, John Maddock wrote:
The following simple patch to tuple_basic.hpp allows tuples to be constructed from std::pairs (there is already an assignment operator, but the copy constructor is missing for some reason, and is required for TR1 conformity).
RCS file: /cvsroot/boost/boost/boost/tuple/detail/tuple_basic.hpp,v retrieving revision 1.28 diff -r1.28 tuple_basic.hpp 627a628,636
template <class T, class U> tuple(const std::pair<T, U>& p) : inherited(p.first, p.second, detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull(), detail::cnull()) { BOOST_STATIC_ASSERT(length<tuple>::value == 2);// check_length = 2 }
Is it acceptable to add this?
I think we could do better, but it would be stretching TR1 (which I think is good).
I think any compatible tuple-like type should be convertible to tuple (pair, array, maybe complex?, anything else that declares itself tuple-like and implements the tuple interface).
What is the technical definition of a tuple-like type ?
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf and search for is_tuple_like. There's a nicely written compact definition. In a nutshell, it implements the tuple interface, and registers itself with the is_tuple_like trait. -Howard
participants (10)
-
David Abrahams -
Edward Diener -
Fredrik Blomqvist -
Howard Hinnant -
Jaakko Järvi -
Jaakko Järvi -
Joel de Guzman -
John Maddock -
Jonathan Turkanis -
Larry Evans